ComboBox refresh issue

Describe the bug
Combo box display text is blank if item source is updated after value is set.
To Reproduce
I have a basic combo box.
<ComboBox ItemsSource="{Binding Databases}" SelectedItem="{Binding Database}"/>

Properties in the view model
        Public Property Database As String
            Get
                Return _settings.Database
            End Get
            Set
                _settings.Database = Value
                RaisePropertyChanged(NameOf(Database))
            End Set
        End Property

        Public ReadOnly Property Databases As ReadOnlyCollection(Of String)
            Get
                Return _databases
            End Get
        End Property

        Private Async Sub LoadDatabases()
            Try
                Dim builder As SqlConnectionStringBuilder = _settings.GetBuilder("master")
                Using connection As New SqlConnection(builder.ToString())
                    Await connection.OpenAsync()
                    Dim cmd As New SqlCommand("select Name from sys.Databases", connection)
                    Dim reader As SqlDataReader = Await cmd.ExecuteReaderAsync()
                    Dim newDatabases As New List(Of String)
                    While reader.Read()
                        newDatabases.Add(reader.GetString(0))
                    End While
                    _databases = New ReadOnlyCollection(Of String)(newDatabases)
                    RaisePropertyChanged(NameOf(Databases))'the combo box dropdown shows the items, however display text  is blank
                    RaisePropertyChanged(NameOf(Database))'adding this also didnt work
                    Dim db As String = Database'my workaround
                    Database = ""
                    Database = db
                End Using
            Catch ex As Exception
            End Try
        End Sub

Expected behavior
No response
Avalonia version
11.1.3
OS
Windows
Additional context
No response

This is a common issue with ComboBoxes, and SelectingItemControls in general.
If a change in the ItemsSource causes the current SelectedItem to no longer be in the collection, the ComboBox sets SelectedItem to null.  The binding system makes an attempt to push that null to the Source, but rejects the change and sets a DataValidationError.  It doesn't notify either side of the binding that this has happened.  At this point the ComboBox thinks SelectedItem is null, but the Source thinks it's OldValue.  If Source raises a PropertyChanged event realizing this desync has happened, the binding system ignores it because the value on Source hasn't changed.  If the ComboBox tries to set the OldValue, the binding system ignores it because the new value matches the one on the Source and so doesn't clear the Validation error.
The only workarounds I know of at present (if you're not using DataValidationErrors) are to either force a change at Source as you are, or keep a record of the old value in the View containing the ComboBox, and if ComboBox.SelectedItem ever becomes null set the old value (or current Source value) directly to ComboBox.SelectedItem.

In this case I set the combo box value and then set the item source

In this case I set the combo box value and then set the item source

Assuming you're talking ViewModel side, that probably actually makes the problem worse.  ViewModel tells ComboBox there's a new SelectedItem.  ComboBox checks against the old ItemSource, finds the new SelectedItem is missing, and sets SelectedItem to null.  Bindings eat the null, and now ComboBox thinks it's null while the ViewModel thinks it's the right value.

Basically (as far as I can tell) when ComboBox tries to set SelectedItem to null, something in this block fails and returns false: https://github.com/AvaloniaUI/Avalonia/blob/37ba4ce58e2e9d251b21310019fda40b81099b19/src/Avalonia.Base/Data/Core/BindingExpression.cs#L314-L338
At this point ComboBox thinks the value is null, and the Binding expression and VM think it is X.  If the VM tries to raise PropertyChanged the Binding ignores it because it hasn't, and doesn't push it to the ComboBox.  If the ComboBox tries to set SelectedItem back to X the Binding ignores it because that's what it already thinks it is, but it doesn't clear any errors.
I think this is correct on the Source side of things, but when this situation happens there probably needs to be a way for the Binding to reset the bound value on the Target's side.  Unfortunately at the moment that probably ends up in infinite loops, so in all likelihood SelectingItemControls need to be smarter about how they handle changes in SelectedItem / ItemsSource but there's a lot going on there and it's pretty messy.

OK, that makes sense because after I update the item source it shows blank in the UI but the ViewModel still has the value.


Include all data driven tests for reporting skips

Closes #2674
We now have a new configuration parameter named
“-includeAllDataDrivenTestsWhenSkipping” which
when used would cause a data driven test to report
All its iterations as skipped when there is a failure
in its upstream dependencies.
Fixes #2674  .
Did you remember to?

[X] Add test case(s)
[X] Update CHANGES.txt
[X] Auto applied styling via ./gradlew autostyleApply

We encourage pull requests that:

Add new features to TestNG (or)
Fix bugs in TestNG

If your pull request involves fixing SonarQube issues then we would suggest that you please discuss this with the
TestNG-dev before you spend time working on it.
Note: For more information on contribution guidelines  please make sure you refer our Contributing section for detailed set of steps.

@juherr - Fixed all the review comments. Please check.

⚠ Tests are failing

The test failures are because of auto style violations.. Sigh! I thought I did that before pushing code... Anyways.. will go home and take a look at it and fix it along with sub classing part and proceed with merging this.

Fixed the test failures due to code formatting. Merging this PR.


added possibility to declare plugins

I sometimes have the need to add more checks on a project basis. Instead of reinventing the wheel completely I thought it might be best to write frosted plugins instead.

Looks great!
Thanks!


Does mark support merging of cells in tables?

Simple tables do work. However, I couldn't make merged (virtically or horizontally) cells in a table using a few examples from extended markdown. Hence the question is - does mark support merging of cells?

Interested in this as well


Add Doc parameters and overhaul rendering options

Codecov Report
Attention: Patch coverage is 87.96296% with 13 lines in your changes are missing coverage. Please review.

Project coverage is 96.83%. Comparing base (61667de) to head (4232f2d).

Files
Patch %
Lines

...main/java/com/opencastsoftware/prettier4j/Doc.java
85.39%
12 Missing and 1 partial :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##               main      #80      +/-   ##
============================================
- Coverage     97.78%   96.83%   -0.95%
- Complexity      211      236      +25
============================================
  Files            10       11       +1
  Lines           632      727      +95
  Branches        109      125      +16
============================================
+ Hits            618      704      +86
- Misses            6       18      +12
+ Partials          8        5       -3

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


feat(api): add multi-namespace ClusterCryostat API

This PR adds a new ClusterCryostat CRD. This is essentially a cluster-scoped version of the Cryostat CRD with a couple of additions. Instead of installing Cryostat into the same namespace of the CR, the ClusterCryostat CRD has an Spec.InstallNamespace property. Then there is the Spec.TargetNamespaces property where the user can specify which namespaces they want this Cryostat instance to work with. The operator accomplishes this by creating a RoleBinding in each of these namespaces, binding the CR's service account to the Cryostat Role (now a Cluster Role to save resources).
The reasoning for making a new CRD instead of using the existing Cryostat is to guard against unexpected privilege escalation. OLM-installed operators automatically aggregate view, edit, and admin permissions for each CRD to the corresponding Cluster Roles using role aggregation. A cluster-admin might give an unprivileged user admin or edit permissions for a particular namespace by binding the admin or edit cluster role to that user. This cluster-admin may not expect that giving such permissions to a user would allow them to create a Cryostat CR that in turn creates a multi-namespace Cryostat installation through the Spec.TargetNamespaces field. By making ClusterCryostat cluster-scoped, the only way to allow unprivileged users to create one is by a cluster-admin explicitly creating a Cluster Role Binding for a user. This action makes it explicit that the user will be authorized to monitor as much of the cluster as they wish with Cryostat.
Here is an example for a user "developer" that has the "admin" role bound to it in the current namespace:
$ kubectl create -f config/samples/operator_v1beta1_clustercryostat.yaml
Error from server (Forbidden): error when creating "config/samples/operator_v1beta1_clustercryostat.yaml": clustercryostats.operator.cryostat.io is forbidden: User "developer" cannot create resource "clustercryostats" in API group "operator.cryostat.io" at the cluster scope
$ kubectl create -f config/samples/operator_v1beta1_cryostat.yaml
cryostat.operator.cryostat.io/cryostat-sample created

In order to not break API between minor releases and to allow unprivileged users to still create single-namespace Cryostat installations as before, the existing Cryostat CRD remains. Much of the code changes of this PR are to make the controller and test code able to handle an abstraction of the two CRDs, called CryostatInstance in the new model package.
I had to make test changes in quite a few places to avoid hardcoding the "cryostat" CR name for all created resources. This is necessary because for cluster-wide CRs we want to be able to test with two (differently named) CRs at once to ensure they don't conflict with each other.
To test in OpenShift:

Build an operator bundle:make oci-build bundle bundle-build OPERATOR_IMG=quay.io/foo/cryostat-operator:tag BUNDLE_IMG=quay.io/foo/cryostat-operator-bundle:tag

Push both images to Quay
Install bundle with Operator SDK (install cert-manager first, if not already done):operator-sdk run bundle --install-mode AllNamespaces quay.io/foo/cryostat-operator-bundle:tag

In the OpenShift Console, navigate to "Operators -> Installed Operators". Select "Cryostat Operator".
Create a ClusterCryostat, filling in the new Install Namespace and Target Namespaces fields.

Fixes: #513

Thanks for the explanation writeup, it sounds like it makes a lot of sense to me. Building and manual testing everything looks great too. It'll take some time to work through the patch review but I'll be looking at it this week.

I've seen this error come up a couple times, but I'm not sure what causes it.
1.6771049505679452e+09	INFO	controllers.ClusterCryostat	Reconciling ClusterCryostat	{"Request.Name": "clustercryostat-sample"}
1.6771049505681043e+09	ERROR	controllers.ClusterCryostat	Error reading ClusterCryostat instance	{"Request.Name": "clustercryostat-sample", "error": "cache had type *v1beta1.Cryostat, but *v1beta1.ClusterCryostat was asked for"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:121
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:320
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:273
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:234

I've seen this error come up a couple times, but I'm not sure what causes it.
1.6771049505679452e+09	INFO	controllers.ClusterCryostat	Reconciling ClusterCryostat	{"Request.Name": "clustercryostat-sample"}
1.6771049505681043e+09	ERROR	controllers.ClusterCryostat	Error reading ClusterCryostat instance	{"Request.Name": "clustercryostat-sample", "error": "cache had type *v1beta1.Cryostat, but *v1beta1.ClusterCryostat was asked for"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:121
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:320
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:273
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:234

In the most recent occurrence, I noticed that I deployed the operator using the make deploy target. This causes the WATCH_NAMESPACES environment variable to be set to the current namespace. The leads to the controller manager's cache being restricted to this namespace. Perhaps the error is caused by this restriction, and just manifesting in an odd way.
From https://sdk.operatorframework.io/docs/building-operators/golang/operator-scope/#overview:

IMPORTANT: When a Manager instance is created in the main.go file, the Namespaces are set via Manager Options as described below. These Namespaces should be watched and cached for the Client which is provided by the Manager. Only clients provided by cluster-scoped Managers are able to manage cluster-scoped CRD’s.

If this is the cause of the error, perhaps we want to disable the ClusterCryostat controller for SingleNamespace operator installations. We could simply not start the ClusterCryostat controller and log a message.

I've seen this error come up a couple times, but I'm not sure what causes it.
1.6771049505679452e+09	INFO	controllers.ClusterCryostat	Reconciling ClusterCryostat	{"Request.Name": "clustercryostat-sample"}
1.6771049505681043e+09	ERROR	controllers.ClusterCryostat	Error reading ClusterCryostat instance	{"Request.Name": "clustercryostat-sample", "error": "cache had type *v1beta1.Cryostat, but *v1beta1.ClusterCryostat was asked for"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:121
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:320
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:273
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.1/pkg/internal/controller/controller.go:234

In the most recent occurrence, I noticed that I deployed the operator using the make deploy target. This causes the WATCH_NAMESPACES environment variable to be set to the current namespace. The leads to the controller manager's cache being restricted to this namespace. Perhaps the error is caused by this restriction, and just manifesting in an odd way.
From https://sdk.operatorframework.io/docs/building-operators/golang/operator-scope/#overview:

IMPORTANT: When a Manager instance is created in the main.go file, the Namespaces are set via Manager Options as described below. These Namespaces should be watched and cached for the Client which is provided by the Manager. Only clients provided by cluster-scoped Managers are able to manage cluster-scoped CRD’s.

This last sentence doesn't seem to match up with what I'm seeing. The underlying Informer will restrict list/watches to a set of namespaces, if provided. This doesn't happen for cluster-scoped resources though:
https://github.com/kubernetes-sigs/controller-runtime/blob/f6f37e6cc1ec7b7d18a266a6614f86df211b1a0a/pkg/cache/internal/informers.go#L378-L508

If this is the cause of the error, perhaps we want to disable the ClusterCryostat controller for SingleNamespace operator installations. We could simply not start the ClusterCryostat controller and log a message.

I've tried this and still encounter the error. I'm now able to reliably reproduce it:

Install the operator
Create a ClusterCryostat.
The operator should deploy Cryostat as expected.
Restart the operator with kubectl rollout restart deploy cryostat-operator-controller-manager
The above error should occur.

Still no idea why this is happening, but it's pretty bad. So I'm going to hold off on merging until we can figure this out. At least now we have a reproducer.

Fixed now, it was just a typo in the ClusterCryostatList struct... @andrewazores still good to merge?


[Fix bug]fix prelu, now can use on 2d input and add one test

Like https://github.com/dmlc/tvm/issues/2428 says, CHECK_EQ is not necessary. So del it ,now prelu works fine in fc, Del assert in nn.elemwise.py which check input must be 4-d, add one test.

Thanks @XiaolongMeng , this is now merged


Added another recommended flag to the Procfile web process

What's this PR do?
https://devcenter.heroku.com/articles/node-memory-use#tuning-the-garbage-collector
https://devcenter.heroku.com/articles/node-best-practices#avoid-garbage
How should this be reviewed?

👀

Checklist

[x] Tested on local.

Codecov Report

Merging #920 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #920   +/-   ##
========================================
  Coverage    30.53%   30.53%
========================================
  Files           37       37
  Lines         1238     1238
========================================
  Hits           378      378
  Misses         860      860

Continue to review full report at Codecov.

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


Update notification channel discovery and conformance

Resolves issue #58 by working with the notion of notification channel:

Adds definition for notification-channel-resource.
Describes notification-channel-discovery via notification-channel-resource (servers can advertise link relations describedby ( server-link-resource-notification-channel ) and http://www.w3.org/ns/solid#storageDescription ( server-link-storage-notification-channel ) and notification-channel description.
Adds notification-channel-conformance

I'm +1 to merge in the current form

Follows https://github.com/solid/notifications-panel/blob/main/meetings/2022-08-25.md#update-notification-channel-discovery-and-conformance


Properly Handle Custom Http Endpoints

In the current version, should_use_http only returns true iff the endpoint url is in the Endpoints enum.
The register_otel function, however, accepts custom hosts as a string:
EndpointsType = Union[str, List[str], Endpoints, List[Endpoints]]

def register_otel(
    endpoints: EndpointsType,

So, if you call register_otel with an endpoint that is not in the Endpoints enum, (say, http://localhost:7000), then should_use_http will return false, even if the user intends to send things over http.
This pull request adjusts should_use_http to consider strings as input types.

Hey @lou-k, thanks for bringing this up. It was introduced in this PR.


python38Packages.django-sites: 0.10 -> 0.11

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python38Packages.django-sites is: "Alternative implementation of django "sites" framework\nbased on settings instead of models.\n"
meta.homepage for python38Packages.django-sites is: "https://github.com/niwinz/django-sites"
meta.changelog for python38Packages.django-sites is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 0.11 with grep in /nix/store/21ik7qj2vlj55wm82i8rnwh4qc1ahc1p-python3.8-django-sites-0.11

found 0.11 in filename of file in /nix/store/21ik7qj2vlj55wm82i8rnwh4qc1ahc1p-python3.8-django-sites-0.11

Rebuild report (if merged into master) (click to expand)

6 total rebuild path(s)

3 package rebuild(s)

3 x86_64-linux rebuild(s)
3 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
docbookrx
python38Packages.django-sites
python39Packages.django-sites

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/21ik7qj2vlj55wm82i8rnwh4qc1ahc1p-python3.8-django-sites-0.11 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python38Packages.django-sites https://github.com/r-ryantm/nixpkgs/archive/8821c9a315d965b866f5f6bab4f82e021360317b.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/21ik7qj2vlj55wm82i8rnwh4qc1ahc1p-python3.8-django-sites-0.11
ls -la /nix/store/21ik7qj2vlj55wm82i8rnwh4qc1ahc1p-python3.8-django-sites-0.11/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

python38Packages.django-sites
python39Packages.django-sites

Maintainer pings

duplicate of https://github.com/NixOS/nixpkgs/pull/149418

@ryantm Please fix the bot.

@dotlambda do you have a suggestion for how it could detect your duplicate PR?

Yes, it should view python*Packages.xyz as aliases for the same package.
Btw, I also wonder why this PR as well as https://github.com/NixOS/nixpkgs/pull/149737 were created.


Hashmap is not cleaned on every execution

I have created a simple project based on the LSM example that uses a HashMap to exchange information between the eBPF program and the user space program. However, I notice that when I execute the user space program (which loads the eBPF program), the map still has information from the previous execution.
Is this the expected behavior? If so, why?

are you using pinned maps?
if possible point to your codebase


Add support for JSON logging

Coverage increased (+0.007%) to 60.261% when pulling 4fac726cf414b239cd156529377181a26fa43e04 on castrapel:json_logging into 37e58574066921f50485398d195994b1b805c216 on Netflix:master.


Fix the wrong usage in the example

Description
The document uses a nonexisting property from the variable e, which should be event_symbol.
Related issue(s)
It is not really causing issues but is misleading in the example.
Pre-merge checklist

[x] Code formatted correctly (check with make lint)
[ ] Code implemented for both sync and async
[ ] Passing tests locally (check with make test, make sure you have TT_USERNAME, TT_PASSWORD, and TT_ACCOUNT environment variables set)
[ ] New tests added (if applicable)

Please note that, in order to pass the tests, you'll need to set up your Tastytrade credentials as repository secrets on your local fork. Read more at CONTRIBUTING.md.

Thanks!


Create Archive Goal Modal

When Archive Goal button in the navbar is clicked Archive Goal Modal pops up
Solves issue #247

You are making PR from a stale branch

You are making PR from a stale branch

What's the current branch? Everyone is staying staging, which I pulled from in the first place...

You don't have conflicts anymore. Just work on the lines I highlighted.


python312Packages.reflex: init at 0.5.9

Description of changes
https://reflex.dev

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 333337 at 6ff9b46c run on aarch64-darwin 1

4 packages failed to build:

python311Packages.reflex
python311Packages.starlette-admin
python312Packages.reflex
python312Packages.starlette-admin

4 packages built successfully:

python311Packages.reflex-hosting-cli
python311Packages.sqlalchemy-file
python312Packages.reflex-hosting-cli
python312Packages.sqlalchemy-file

The errors seem to be caused by darwin sandbox.

The errors seem to be caused by darwin sandbox.

this maybe?
--- a/pkgs/development/python-modules/reflex/default.nix
+++ b/pkgs/development/python-modules/reflex/default.nix
@@ -120,10 +120,15 @@ buildPythonPackage rec {
     "test_potentially_dirty_substates"
     # flaky, KeyError: 'reflex___state____state'
     "test_preprocess"
+    # flaky, depends on test order
+    "test_ensuring_pk"
   ];
   disabledTestPaths = [
     "benchmarks/"
     "integration/"
+  ] ++ lib.optionals stdenv.isDarwin [
+    # sandbox issues
+    "tests/sqla/test_sync_engine.py"
   ];

   pythonImportsCheck = [ "reflex" ];

btw, which fork do you use to post gists of the logs?

btw, which fork do you use to post gists of the logs?

I use a fork based on this PR.
I would like to submit a PR, but... I haven't yet.

Result of nixpkgs-review pr 333337 at c1dfc595 run on aarch64-darwin 1

3 packages failed to build:

python311Packages.reflex
python311Packages.sqlalchemy-file
python311Packages.starlette-admin

5 packages built successfully:

python311Packages.reflex-hosting-cli
python312Packages.reflex
python312Packages.reflex-hosting-cli
python312Packages.sqlalchemy-file
python312Packages.starlette-admin

not sure what the error might be, but if this doesn't work i might just mark it broken on darwin

man i dislike darwin, the sandbox is so flaky...


Add containerd's docs directory

Signed-off-by: Kazuyoshi Kato<EMAIL_ADDRESS>

The preview website is https://deploy-preview-121--containerd-io.netlify.app/docs/latest/getting-started/.
Right now, it doesn't look great compared to #120, but we can improve the look & feel by adopting Hugo's documentation-oriented themes like https://www.docsy.dev/.
It would be better to not complicate the stack by having multiple documentation generators.

Can we remove /docs/getting-started and redirect it to /docs/latest/getting-started?

Seems broken

Fixed the broken menu.
Regarding the redirection, the Getting Started guide needs to have metadata like https://github.com/containerd/containerd.io/blob/main/content/docs/getting-started.md. Let me fix other parts first.

Fixed the broken menu.

The new docs don't seem reachable from the top page

It would be better to not complicate the stack by having multiple documentation generators.

If sphinx is easier to use than hugo, we can completely replace hugo with sphinx.
Just reopening #120, add logo, and redirecting / to /docs/latest would be enough as the first step.

The new docs don't seem reachable from the top page

Yes. I'd like to add at least add <title> before making them reachable. But to do that, I need to edit files on containerd/containerd first.

If sphinx is easier to use than hugo, we can completely replace hugo with sphinx.

Honestly both are not that different in terms of the ease of use. Hugo may work better for us at this time since we already have Hugo-based website. Migrating that to Sphinx may not bring us much value.

I checked the issue #120, and I think docs based on Sphinx look much better than that based on Hugo. The vertical directory is more familiar to readers, as Kubernetes, Istio, Kubespray, Karmada and some other CNCF projects also use vertical layout. I would like to help with doc migration.

Is this still planned?

Alternative:

https://github.com/containerd/containerd.io/issues/149

I like this approach.  It doesn't have to be in this PR, but we should also consider doing something like https://github.com/containerd/containerd.io/blob/main/.github/workflows/sync-releases.yml so it stays reasonably up-to-date too.

picking this up – gonna rebase and implement the doc syncing


rclpy: 1.8.0-1 in 'rolling/distribution.yaml' [bloom]

Increasing version of package(s) in repository rclpy to 1.8.0-1:

upstream repository: https://github.com/ros2/rclpy.git
release repository: https://github.com/ros2-gbp/rclpy-release.git
distro file: rolling/distribution.yaml
bloom version: 0.10.3
previous version for package: 1.7.0-1

rclpy
* Change index.ros.org -> docs.ros.org. (#755 <https://github.com/ros2/rclpy/issues/755>)
* Use py::class_ for rcl_event_t (#750 <https://github.com/ros2/rclpy/issues/750>)
* Convert Clock to use a C++ Class (#749 <https://github.com/ros2/rclpy/issues/749>)
* Convert Service to use C++ Class (#747 <https://github.com/ros2/rclpy/issues/747>)
* Fix windows warning by using consistent types (#753 <https://github.com/ros2/rclpy/issues/753>)
* Use py::class_ for rmw_service_info_t and rmw_request_id_t (#748 <https://github.com/ros2/rclpy/issues/748>)
* Convert Timer to use a C++ Class (#745 <https://github.com/ros2/rclpy/issues/745>)
* Add PythonAllocator (#746 <https://github.com/ros2/rclpy/issues/746>)
* Use py::class_ for rmw_qos_profile_t (#741 <https://github.com/ros2/rclpy/issues/741>)
* Combine pybind11 modules into one (#743 <https://github.com/ros2/rclpy/issues/743>)
* Use py::class_ for rcl_duration_t (#744 <https://github.com/ros2/rclpy/issues/744>)
* Fix bug in unique_ptr type argument (#742 <https://github.com/ros2/rclpy/issues/742>)
* Convert Client to use C++ Class (#739 <https://github.com/ros2/rclpy/issues/739>)
* Converting last of _rclpy.c to pybind11 (#738 <https://github.com/ros2/rclpy/issues/738>)
* Make sure only non-empty std::vector of arguments are indexed (#740 <https://github.com/ros2/rclpy/issues/740>)
* Use py::class_ for rcl_time_point_t (#737 <https://github.com/ros2/rclpy/issues/737>)
* Convert logging mutex functions to pybind11 (#735 <https://github.com/ros2/rclpy/issues/735>)
* Document misuse of of parameter callbacks (#734 <https://github.com/ros2/rclpy/issues/734>)
* Convert QoS APIs to pybind11 (#736 <https://github.com/ros2/rclpy/issues/736>)
* Contributors: Addisu Z. Taddese, Alejandro Hernández Cordero, Chris Lalancette, Greg Balke, Jacob Perron, Michel Hidalgo, Shane Loretz

Please hold for coordinated merge.


Show example and examples hint for schemas

Reason/Context
In OpenAPI (any version) their schema format used example instead of examples, so if we find a schema with the use of example I think we should provide a hint that lets the user know of a potential problem.
It's not a problem as the user could have intentionally wanted to use a custom keyword called example, so I don't think it warrants a warning or error.

It should be done on parser-js side in spectral rule. I will move that issue to the appropriate repo.


Odd Polyline breaks when zoomed out

Zoomed in

Zoomed out

Happens in all scene modes and materials, it's more obvious with the outline material, but I'm lazy and din't resnap.

Here's a more obvious shot, notice the outline cuts through the center of the polyline at the inside corners:


Apollo didn't turn right, maybe a bug

System information

OS Platform and Distribution (e.g., Linux Ubuntu 18.04): Linux Ubuntu 18.04
Apollo installed from (source or binary): source
Apollo version (3.5, 5.0, 5.5, 6.0): 6.0
Output of apollo.sh config if on master branch:

Steps to reproduce the issue:
Hello Apollo team! Recently I am testing Apollo 6.0 with LGSVL and I found something that may be a bug of Planning module. Here is the steps of testing:

The case is in map BorregasAve, as this picture shows:

I use LGSVL as simulator of Apollo. For ego configuration, I use 3D ground truth and signal sensor to replace Perception module, which ensure the correctness of NPC cars and signals.

The destination point is on the road right of junction. In this case, the ego should deal with scenario TRAFFIC LIGHT UNPROTECTED RIGHT TURN. And since I did not turn on config enable_right_turn_on_red in modules/planning/conf/scenario/traffic_light_unprotected_right_turn_config.pb.txt, the ego will stop before the stop line of junction. At this moment, in cyber_monitor, topic of traffic light is here:

4 items represent 4 signals in picture. In cyber_monitor they are all red now.

After starting simulation, ego will drive to stop line and then stop:

in picture we just see 3 signals, and the last signal is here:

At this moment, cyber_monitor shows:

Seems that the last signal cannot be seen by ego, which is reasonable.

However, after signals turn green, ego did not run, like this:

Based on log files, I found that the stage of Planning module at this moment is STOP in TRAFFIC LIGHT UNPROTECTED RIGHT TURN. Here is the code:

for (const auto& traffic_light_overlap_id :
       GetContext()->current_traffic_light_overlap_ids) {
    // get overlap along reference line
    current_traffic_light_overlap = scenario::util::GetOverlapOnReferenceLine(
        reference_line_info, traffic_light_overlap_id,
        ReferenceLineInfo::SIGNAL);
    if (!current_traffic_light_overlap) {
      continue;
    }

    // set right_of_way_status
    reference_line_info.SetJunctionRightOfWay(
        current_traffic_light_overlap->start_s, false);

    const double distance_adc_to_stop_line =
        current_traffic_light_overlap->start_s - adc_front_edge_s;
    auto signal_color = frame->GetSignal(traffic_light_overlap_id).color();
    ADEBUG << "traffic_light_overlap_id[" << traffic_light_overlap_id
           << "] start_s[" << current_traffic_light_overlap->start_s
           << "] distance_adc_to_stop_line[" << distance_adc_to_stop_line
           << "] color[" << signal_color << "]";

    // check distance to stop line
    if (distance_adc_to_stop_line >
        scenario_config_.max_valid_stop_distance()) {
      traffic_light_all_stop = false;
      break;
    }

    // check on traffic light color
    if (signal_color != TrafficLight::GREEN) {
      traffic_light_all_green = false;
      traffic_light_no_right_turn_on_red =
          CheckTrafficLightNoRightTurnOnRed(traffic_light_overlap_id);
      break;
    }
  }

  if (traffic_light_all_stop && traffic_light_all_green) {
    return FinishStage(true);
  }

  if (!traffic_light_no_right_turn_on_red) {
    if (traffic_light_all_stop && !traffic_light_all_green) {
      // check distance pass stop line
      const double distance_adc_pass_stop_line =
          adc_front_edge_s - current_traffic_light_overlap->end_s;
      ADEBUG << "distance_adc_pass_stop_line[" << distance_adc_pass_stop_line
             << "]";
      if (distance_adc_pass_stop_line >
          scenario_config_.min_pass_s_distance()) {
        return FinishStage(false);
      }

      if (scenario_config_.enable_right_turn_on_red()) {
        // when right_turn_on_red is enabled
        // check on wait-time
        if (GetContext()->stop_start_time == 0.0) {
          GetContext()->stop_start_time = Clock::NowInSeconds();
        } else {
          auto start_time = GetContext()->stop_start_time;
          const double wait_time = Clock::NowInSeconds() - start_time;
          ADEBUG << "stop_start_time[" << start_time << "] wait_time["
                 << wait_time << "]";
          if (wait_time >
              scenario_config_.red_light_right_turn_stop_duration_sec()) {
            return FinishStage(false);
          }
        }
      }
    }
  }

For the signal part, seems that Apollo will check all the traffic light overlap, if all of them are green, traffic_light_all_stop will be set as true, which causes stage transition. Besides, due to logs added by my codes, I found that a traffic light overlap seems to be created when simulation starts. That is, at the first time ego can see the signal beside the road, so ego creates a traffic light overlap for it. However, when ego passes the signal, it cannot see it any more, but the overlap is still in GetOverlapOnReferenceLine. So it will still be checked by Planning module, but the color of signal is always UNKNOWN, which stops the ego permanently.
The same problem will happen in LEFT TURN scenario too. I do not know whether it is a bug, and I cannot find related issues either. Hope for your reply, thanks!

Hi @1Jyfc
Can you share some screenshots of Dreamview during the scenario? It would be extremely helpful to share a cyber record file recorded via cyber_recorder record -a
I am aware of a similar issue that cause the planning module to fail moving forward, https://github.com/ApolloAuto/apollo/issues/14551 causes Apollo to stop indefinitely on top of a stop line. But to trigger this bug, Apollo must be initialized directly on top of a stop line. Based on your screenshot, you initialized Apollo a few meters in front of the stop line, therefore it should be a different issue.
Once you share the cyber record file, it will be much easier for others to look at the details of the planning messages.

You can see dreamview/PNC_Monitor or planning topic to find the reason why vehicle stop

Thanks for your reply!
20230323162844.record.zip @YuqiHuai Here is the cyber record file. I cannot use python API to record, because it will cause this error:
FileNotFoundError: [Errno 2] No such file or directory: "docker exec -u $USER apollo_dev_jyf pkill -f 'cyber_recorder record'"
so I record by shell.
And I add some log codes in planning module to log out some useful information, mainly in modules/planning/scenarios/traffic_light/unprotected_right_turn/stage_stop.cc. And according to this log, stage of planning module switches into right turn after 7 check points, and at first time the status is:

At the first check point of scenario "right turn" stage "stop", 4 overlaps are created for 4 signals, and at this time they are all red. I tried to figure out the SL position of overlap and ego and printed out. I found that the 4 overlaps share the same S.
And after several check points, the ego passes the fourth signal, but doesn't pass the overlap, so it is still checked, and its color changes into UNKNOWN, both in log and Dreamview (Here, when I replay the record, in Dreamview the traffic light always remain red, but when I use LGSVL it will show UNKNOWN). After other signals turn green, it still remains UNKNOWN, which causes traffic_light_all_stop && traffic_light_all_green cannot be satisfied. Here !traffic_light_no_right_turn_on_red && traffic_light_all_stop && !traffic_light_all_green is satisfied, but since ego doesn't pass stop line, distance_adc_pass_stop_line > scenario_config_.min_pass_s_distance() cannot be satisfied. So in this case if configuration of right turn on red light is disabled, the ego will not drive any more. In fact at this time ego is still ahead of stop line, so the overlap will not be canceled.
I think this case is like #14551 but not totally the same. In my log I also find the same logs, but if the traffic light can be considered as GREEN, it will cause stage switch.

I spent some more time thinking about this scenario and I agree with this being a bug in Apollo. But the fix might be complicated. @1Jyfc @qwetqwe

Above is an illustration of signals and the stop line the signal is controlling at the junction.

Above is the screenshot of Apollo at the junction in the SVL simulator. Boxed in red is signal_9.

In a realistic environment with Apollo's perception, I do not think Apollo could detect signal_9 in any way because it has already moved passed it. Therefore theoretically at this exact junction, Apollo can only make a right turn in simulations (and someone has to correct the TrafficLightDetection to include signal_9); in the real world, Apollo won't detect signal_9 and will stop indefinitely at this stop line.
The root cause of the bug should be Apollo looping through GetContext()->current_traffic_light_overlap_ids and checking every signal that overlaps, ignoring the fact that at certain locations, not all signals can be detected.

I have attempted to provide a fix to address the issue.
At a high level: 1) stop stage is only interested in overlapping signals that are detected; if an overlapping signal is not detected, consider it done.
Discussion
https://github.com/YuqiHuai/apollo/blob/3ee79789c2bbcf470b9f9a4e3cd345f4451afdee/modules/planning/scenarios/traffic_light/unprotected_right_turn/stage_stop.cc#L67-L85
https://github.com/YuqiHuai/apollo/blob/3ee79789c2bbcf470b9f9a4e3cd345f4451afdee/modules/planning/scenarios/traffic_light/unprotected_right_turn/stage_stop.cc#L104
This part of the code maps to high-level goal 1. This part ensures planning can transition from STOP to CRUISE stage. However, this is not enough to fix the issue. The stop fence for signal_9 is still not removed, planning's main decision is still stopping for signal_9. Shown in the image (left) is a much lighter stop fence, compared to the unfixed version (right) with a much darker stop fence (probably because many are stacked together)

with partial fix
original

I did not find the most appropriate place to address the above issue therefore I thought of high-level goal 2.
https://github.com/YuqiHuai/apollo/blob/3ee79789c2bbcf470b9f9a4e3cd345f4451afdee/modules/planning/scenarios/traffic_light/unprotected_right_turn/stage_stop.cc#L87-L101
This considers overlapping signals that are not in interested signals as "done", so signal_9 is considered done once it is no longer detected, its stop fence will also be removed.

Using the temporary fix I provided, observe the bug symptom is gone. Notice in the screenshot I am replaying reproduce.record which originally will lead to a scenario in which Apollo stops indefinitely at this stop line.
Any feedback is highly appreciated and thanks @1Jyfc for finding this interesting scenario!

@YuqiHuai Thanks for your feedback! I just discuss this issue with some experts and I also consider it as a bug. For the question about whether signal sensor can provide true messages, I tried not to use signal sensor, but to use perception module of Apollo, which got the same result. And in real world, in this situation I do not think ego can detect such signal either.
In fact, in log file we can find that the 4 overlaps created for 4 signals share the same area of reference line, which represents the stop line. And when a signal is passed by ego, it cannot be detected any more, but its overlap is still in scenario, which will be repeatedly checked.
I think the logic of considering passed light is meaningful, which avoid the situation that ego passes the red light too fast. But in this case 4 signals share the same overlap, then I think the judgment about signals related to this overlap should ignore the unseen signal with the same overlap.

@1Jyfc Sounds good. This is a great scenario revealing correct perception output may not be what the planning module expects as the "correct input". In this case, planning is expecting 4 TL detections while perception can only realistically detect 3.
The analysis should help @qwetqwe to evaluate and confirm this being a bug, and my temporary fix should be able to justify the root cause of over consideration (i.e., considering a traffic light that is not detectable). This bug should also impact all other traffic light related decision making. You can verify this by sending a routing request that asks the ego car to go straight instead of turning right in the scenario you reported, I imagine Apollo will also stop indefinitely due to not being able to detect signal_9.
You are saying "considering passed light is meaningful", can you elaborate a bit more on what kind of scenario may cause issues related to red lights? I disagree with this a bit because intuitively, a human driver would not make decisions based on a traffic light that he cannot see; if he cannot see any lights, then it is safer to stop at the stop line. Therefore a fix matching this intuition is: only consider detected lights and make a conservative if 1) no light is detected or 2) detected lights for the current overlap have different colors.

You are saying "considering passed light is meaningful", can you elaborate a bit more on what kind of scenario may cause issues related to red lights? I disagree with this a bit because intuitively, a human driver would not make decisions based on a traffic light that he cannot see; if he cannot see any lights, then it is safer to stop at the stop line. Therefore a fix matching this intuition is: only consider detected lights and make a conservative if 1) no light is detected or 2) detected lights for the current overlap have different colors.

@YuqiHuai I considered this problem again and I think you are right. In real world, drivers should not do decisions based on unseen lights. The final problem is to deal with the conflict that ego passes the light but doesn't pass the overlap. Thanks for your feedback!

@1Jyfc Sounds good. Thank you for your feedback as well! This has been a long but interesting discussion.

@YuqiHuai  Thanks for your helpfu reply

@LordonCN Hi! thanks for your feedback!
It is a bit rare to see an issue getting closed without either confirming this to be a bug or actually fixing the issue. It is pretty clear this should be a bug and I am not 100% if the fix I suggested is acceptable to the core developers.
Will any of the Apollo members (e.g., qwetqwe, daohu527) be looking at this more in the future?

@LordonCN Hi! thanks for your feedback!
It is a bit rare to see an issue getting closed without either confirming this to be a bug or actually fixing the issue. It is pretty clear this should be a bug and I am not 100% if the fix I suggested is acceptable to the core developers.
Will any of the Apollo members (e.g., qwetqwe, daohu527) be looking at this more in the future?

Hello YuqiHuai
I have already told him(@qwetqwe) about this and we appreciate it if you could create a pull request.

@LordonCN Oh! That sounds good. Thanks for responding! I'll create a pull request for the right-turn scenario fix and continue adding the fix to other scenarios to the same PR.

Thanks for attention @YuqiHuai @1Jyfc . The main reason is that planning did not get signal_9 status. I think it is map(signal stop line should be behind signal boundary) or lgsvl(simulator should send all traffic lights in front of vehicle path) problem.

Hi @qwetqwe thanks for the feedback!
This might not be an LGSVL problem because its ground truth seems to be modeling ADS's perception module's field of view correctly.
Will this also be considered a planning problem as the planning module is over-expecting information that cannot be detected? Maybe the signal's stop line can be positioned differently, but there are other situations that may cause certain signals to be undetectable (i.e., an attacker purposely blocks a traffic signal).
In summary, is it necessary for planning to see every signal controlling a stop line based on the HD Map, or is it enough to only consider signals that have been detected?

@YuqiHuai Apollo is only a template for developers' secondary development. It can not cover too many corner cases.That will make it hard to learn and maintain.

@qwetqwe Thanks for the explanation! I think I get your point, if specific logic is implemented to handle each corner case, then the documentation is probably no longer manageable. I have a quick follow-up question:
Is it correct, that issues and PRs that discover and handle difficult-to-find situations (like this one) will generally not be considered bugs, and fixes will not be merged?


[Feature] Caching plugin for Flutter WEB

Is there any DIO Plugin available to cache WEB requests with Flutter WEB ?
Current Cache Plugin is based on sqlite who is not Flutter WEB compatible yet.

Is there any DIO Plugin available to cache WEB requests with Flutter WEB ?
Current Cache Plugin is based on sqlite who is not Flutter WEB compatible yet.

Did you get any solution to this?


HMR doesn't handle package version change

Workflow:

Start HMR.
Load page.
Update package in node_modules (content and package.json version have changed)
Nothing happens (old code is in use)
Remove .fusebox (with cache) folder, trigger reload
Nothing happens (old code is in use)

So have to restart fusebox process - new code in use.

Yes that's expected behavior, fuse caches modules in memory that's why it's darn fast. you don't really update modules all the time do you? But we could have a workaround for that. Nothing is impossible :)

Nothing is impossible, right, so why not: watch package.json for loaded modules, and if version changed then reassemble the bundle.
While development it is obviously usual situation when one update dependency version. And in my workflow, I use local dependencies often with yalc which may change even more often, but they support different package.json verson value for any updated version of package content.

You could do it with Sparky and re-trigger your bundle manually. Like that:
const app = fuse.bundle("app").instructions()
Sparky.watch("package.json").file("*" => app.exec())

Just to make it clear, HMR doesn't reload modules, it reloads only your local files, however, we should introduce an API that will force a page to get reloaded

Just to make it clear, HMR doesn't reload node_modules, it reloads only your local files,

What is the actual different between my "local files" and code in node_modules? It is all the code that application is composed of, and the code in node_modules may change, the same way as my local code does. Packages code usually excluded from watching because of speed, as they supposed to change rarely. But why not handle this case out of the box, esp when we have single file package.json in the package that tells that package supposedly change. It will not introduce any slowing down but will be a very convenient addition. I think this need to be considered.

Absolutely! We can plan it, 2.1.0, however, is quite full already, and we are working on finalising it.
But I agree, developing submodules should be easier.

@nchanged something for v3 roadmap?

I think Sparky can do that quite easily no need in watching everything by default.

@nchanged For clarification, if I stop and restart the HMR server, FuseBox should pick up any changes to node_modules, correct?
I'm seeing an issue where even restarting the server, clearing build and .fusebox cache directories, a new npm version is not getting picked up. I have no idea where it's still finding the old code to bundle because it is nowhere in my project anymore. Even a production build picks up the old code.
Building with FuseBox 3.7.1 and using yarn 1.15.2 to install dependencies.
If it's not something obvious I'm missing, I'll make a new issue. Thanks!!

FuseBox v4 Major Upgrade
As of today, the latest major version of FuseBox v4 is available in fuse-box@next. FuseBox has undergone a full re-write from scratch, learning from its mistakes in the previous versions.
There are a lot of improvements, speed and config wise.
Get started here
We are still working on the documentation and polishing before the major release. We are getting very close. And we need help testing.
npm install fuse-box@next

Most of the issues that I am closing have been resolved, however, if you find that your issue is still relevant in v4 don't hesitate to re-open or (better) create a new one with v4 configuration.


Is there a plan to drop support for Python 3.5?

I see a recent commit that replaces string with f-strings. As f-string is only supported since Python 3.6, does that mean the next release is dropping Python 3.5.*?

Yep, version 2 will.


Could not find dgl>=0.7 when installing PyGCL

Hello pygcl team, thanks for your excellent work!
It seems that the latest version of DGL is 0.6.1 when I install it following the official instruction. Then I meet the error "Could not find dgl>=0.7" when I try to install PyGCL. Could you please give me some suggestions to fix this issue?

Hi! Thanks for reaching out. I suggest you could install the newest version by following its official homepage, as the 0.7 version is not available in pypi.

OK. I'll try it. Thanks for your reply!


Android + Angular - Images set via "src" property disappearing when navigating back to view

Did you verify this is a real problem by searching Stack Overflow and the other open issues in this repo?
Yes
Tell us about the problem
On Android, images whose src property has been set dynamically are disappearing when the view is navigated from, and then navigated back to.
As per this component:
export class DashboardComponent {

  @ViewChild("userImage")
  userImage: ElementRef;

  ngAfterViewInit() {
    getImage("http://placehold.it/150x150")
      .then(imageSource => {
          console.log("image downloaded");
          this.userImage.nativeElement.src = imageSource;
      });
  }
}

See this gif for a comparison.

Please provide the following version numbers that your issue occurs with:

CLI: (run tns --version to fetch it)
3.0.3

Cross-platform modules: (check the 'version' attribute in the
node_modules/tns-core-modules/package.json file in your project)
3.0.0

Runtime(s): (look for the "tns-android" property in the
package.json file of your project)
"tns-android": {
"version": "3.1.1"
}

Plugin(s): (look for the version number in the package.json file of your
project)

See https://github.com/rowandh/nativescript-android-image-bug/blob/master/src/package.json
Did the error happen while the app was being constructed? (buildtime error)
No
Did the error happen while the app was executing? (runtime error)
Yes
Please tell us how to recreate the issue in as much detail as possible.

Clone https://github.com/rowandh/nativescript-android-image-bug/tree/master/src
tns run android
Click on the "Search" button
Press the Android back button
Observe that the top image has disappeared and only its background is visible

Happens in both the emulator and on all the physical devices I've tested it with, running Android 6.

This issue was moved to NativeScript/NativeScript#4481

Thanks, I realised I logged this in the wrong place.


canCheckBiometric() not working in Honor 9 lite device

localAuth.canCheckBiometrics is not working in Honor 9 lite which is finger print unlock capable.
 Future<bool> isBiometricSupportedInDevice() async{
    try {
      return await localAuth.canCheckBiometrics;
    } on PlatformException catch (e) {
      print(e);
      return false;
    }
  }

flutter doctor -v :
[√] Flutter (Channel stable, v1.17.0, on Microsoft Windows [Version 10.0.18362.836], locale en-ID)
    • Flutter version 1.17.0 at D:\applns\flutter_windows_v1.12.13+hotfix.9-stable\flutter
    • Framework revision e6b34c2b5c (5 weeks ago), 2020-05-02 11:39:18 -0700
    • Engine revision 540786dd51
    • Dart version 2.8.1

[√] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at C:\Users\A-9295\AppData\Local\Android\sdk
    • Platform android-R, build-tools 29.0.3
    • Java binary at: D:\applns\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
    • All Android licenses accepted.

[√] Android Studio (version 3.4)
    • Android Studio at D:\applns\Android Studio
    • Flutter plugin version 39.0.1
    • Dart plugin version 183.6270
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)

[√] Connected device (2 available)
    • XT1068              • ZX1D64FH5B    • android-arm • Android 6.0 (API 23)
    • AOSP on IA Emulator • emulator-5554 • android-x86 • Android 9 (API 28) (emulator)

• No issues found!

Hi @rakeshh025
Can you please provide your your flutter run --verbose
your pubspec.yaml
and a minimal reproducible code sample.
Thank you

Without additional information we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


Use the reflex.fatalf function instead of the built-in error function

Codecov Report

Merging #78 (d59e262) into master (1eea03f) will increase coverage by 0.11%.
Report is 1 commits behind head on master.
The diff coverage is 64.44%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff             @@
##           master      #78      +/-   ##
==========================================
+ Coverage   76.34%   76.45%   +0.11%
==========================================
  Files          12       12
  Lines        1061     1062       +1
==========================================
+ Hits          810      812       +2
+ Misses        251      250       -1

Flag
Coverage Δ

unittests
76.45% <64.44%> (+0.11%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files
Coverage Δ

lib/exec.lua
93.54% <100.00%> (ø)

lib/renderer.lua
98.41% <100.00%> (+0.02%)
:arrow_up:

lib/token.lua
100.00% <100.00%> (ø)

lib/session.lua
97.04% <88.88%> (ø)

lib/reflex.lua
43.95% <25.00%> (ø)

lib/readcfg.lua
72.41% <0.00%> (+0.31%)
:arrow_up:

lib/response.lua
64.30% <33.33%> (+0.12%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Can't install SubOver!

So i can't install SubOver in my unix os

can u help me!

go install github.com/Ice3man543/SubOver@latest


Data Request with 'train_in_3_mers' key in h5 dataset

Hi ,
I am trying to use below dataset shared earlier but it does not has train_in_3_mers key in it.
https://cuhko365-my.sharepoint.com/:u:/g/personal/221041009_link_cuhk_edu_cn/EccXeRSaTDJHjBDrdD2m06ABKev_9XPNl75Ew8bNlwLIEQ?e=ZibL4V
when I try to train my model with embeddings , it fails as above h5 files shared does not has train_in_3_mers in it.
Will you be able to share dataset with train_in_3_mers for custom training ?
Thank You
Shashi

Hi there,
Because of the large file size, we can't provide the sequence embeddings in the .h5 file.
If you want to train the embedding models, you can easily derive and play with your own 'train_in_3_mers' vectors using the word2vec model in the Gensim package.
Best

Thank you for your response.
One quick question , I was looking at train dataset from h5 file , I was wondering how do we know where is modification in RNA sequence and what type of modification it is to train embeddings. Any pointers on this ?

For the dataset we provided, we have already separated the sequences into 12 different classes and the modification lies exactly in the middle point of the provided RNA sequence. In other words, during the training process, we are learning whether there exists a modification in the middle point of that sequence or not.

Thank you very much. I will try to spend more time to understand it better.


.Net: How to pass an httpClient to the openAi builder.service?

I am implementing a simple chat bot based on a OpenAI model.
      private static async Task InlineFunctions()
      {
          var handler = new HttpClientHandler();
          handler.CheckCertificateRevocationList = false;
          using var httpClient = new HttpClient(handler);

          var builder = new KernelBuilder();

          builder.Services
              .AddLogging(configure => configure.AddConsole())
              .AddAzureOpenAIChatCompletion(
                  "gpg35turbo", //"ingen51-dialogpt-medium-gpt4-4",
                  "gpt-35-turbo",
                  _endpoint, //  Azure OpenAI Endpoint
                  _apiKey // Azure OpenAI Key
                  );

          var kernel = builder.Build();

In the above code I couldn't find a way to pass a custom httpCLient that I need to pass the option handler.CheckCertificateRevocationList = false;
In the follow README file this piece of information is missed:
https://github.com/microsoft/semantic-kernel/blob/main/dotnet/README.md
While I found another way here
https://github.com/microsoft/semantic-kernel/blob/main/dotnet/samples/KernelSyntaxExamples/Example41_HttpClientUsage.cs
I cannot really apply the same method in my code above.

I've actually found a solution.
            var builder = new KernelBuilder()
                                .AddAzureOpenAIChatCompletion(
                                "gpg35turbo", //"ingen51-dialogpt-medium-gpt4-4",
                                "gpt-35-turbo",
                                _endpoint, // Azure OpenAI Endpoint
                                _apiKey, // Azure OpenAI Key
                                httpClient: httpClient
                                );

            builder.Services
                .AddLogging(configure => configure.AddConsole());

Would be great to have it documented.

We have this sample: https://github.com/microsoft/semantic-kernel/blob/main/dotnet/samples/KernelSyntaxExamples/Example41_HttpClientUsage.cs


Incorrect expansion of Structure value with BIT_STRING typed member

When structure member of type BIT_STRING is expanded in the value, its type is an array of integers rather than an array of bools.
Current Behavior
A PLC type BOOL[64] will be expanded as if it were typed DINT[2].
Expected Behavior
A PLC type BOOL[64] should be expanded into an array of bools with length 64.
Context
If the PLC programmer has chosen type BOOL[], there was a purposeful decision to use boolean values rather than integers.   Reading this data out of the PLC should reflect the same type.
Steps to Reproduce (for bugs only)

PLC: Create a UDT with a BOOL[n], then create a tag using this type
EIP: myTag = new Structure("MyTag", null, tagList);
EIP: await PLC.readTag(myTag);
EIP: console.log(myTag.value.MyBits);

Your Environment

Package version (Use npm list - e.g. 1.0.6): 2.3.2
Node Version (Use node --version - e.g. 9.8.0):  14.17.5
Operating System and version: Windows 10
Controller Type (eg 1756-L83E/B): 1756-L74
Controller Firmware (eg 30.11): 20.19

Merged and Published to NPM. Thanks!


refactor(napi/transform): remove context

#6306  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Boshen and the rest of your teammates on  Graphite


📦 Discover injectors through entrypoints

This patch eliminates import-based injector discovery, switching to
distribution package-independent hosting of the respective callables.

pre-commit.ci run


az login fails with unexpected keyword argument 'allow_broker'

Describe the bug
az login fails with TypeError: ClientApplication.__init__() got an unexpected keyword argument 'allow_broker' using the latest (2.42.0) version on openSUSE Tumbleweed.
Command Name
az login
Errors:
The command failed with an unexpected error. Here is the traceback:
ClientApplication.__init__() got an unexpected keyword argument 'allow_broker'
Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/knack/cli.py", line 233, in invoke
    cmd_result = self.invocation.execute(args)
  File "/usr/lib/python3.10/site-packages/azure/cli/core/commands/__init__.py", line 663, in execute
    raise ex
  File "/usr/lib/python3.10/site-packages/azure/cli/core/commands/__init__.py", line 726, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
  File "/usr/lib/python3.10/site-packages/azure/cli/core/commands/__init__.py", line 697, in _run_job
    result = cmd_copy(params)
  File "/usr/lib/python3.10/site-packages/azure/cli/core/commands/__init__.py", line 333, in __call__
    return self.handler(*args, **kwargs)
  File "/usr/lib/python3.10/site-packages/azure/cli/core/commands/command_operation.py", line 121, in handler
    return op(**command_args)
  File "/usr/lib/python3.10/site-packages/azure/cli/command_modules/profile/custom.py", line 139, in login
    subscriptions = profile.login(
  File "/usr/lib/python3.10/site-packages/azure/cli/core/_profile.py", line 154, in login
    user_identity = identity.login_with_auth_code(scopes=scopes, **kwargs)
  File "/usr/lib/python3.10/site-packages/azure/cli/core/auth/identity.py", line 153, in login_with_auth_code
    result = self._msal_app.acquire_token_interactive(
  File "/usr/lib/python3.10/site-packages/azure/cli/core/auth/identity.py", line 112, in _msal_app
    self._msal_app_instance = PublicClientApplication(self.client_id, **self._msal_app_kwargs)
  File "/home/phoenix/.local/lib/python3.10/site-packages/msal/application.py", line 1525, in __init__
    super(PublicClientApplication, self).__init__(
TypeError: ClientApplication.__init__() got an unexpected keyword argument 'allow_broker'

To Reproduce:

az login

Expected Behavior
Environment Summary
Linux-6.0.8-1-default-x86_64-with-glibc2.36, openSUSE Tumbleweed
Python 3.10.8
Installer: PIP

azure-cli 2.42.0

Additional Context

The same error arises when performing an az storage blob upload ... operation:
Skip querying account key due to failure: ClientApplication.__init__() got an unexpected keyword argument 'allow_broker'
Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
RequestId:<redacted>
Time:2022-11-30T10:29:39.1210784Z
ErrorCode:NoAuthenticationInformation

Please refer to this issue https://github.com/Azure/azure-cli/issues/24372


UX problem with email mask

Users (that are not computer experts) often face a user experience problem when they try to use an input with the email input mask. When a user finishes typing email part before @, he takes the mouse and tries to place the cursor after the @ in the mask. When he does it, the cursor become placed before the @ (where it was before) and the user tries to do it again and again. He doesn't know to click the @ or the → button on his keyboard.

As a result, users ask me to remove email input mask and return a plain input field.
Is there a way to workaround this problem?

@FinesseRus ,
I will see if I can solve this in a general way.

I didn't expect such quick response, thank you

@FinesseRus ,
How you made this mask email with placeholder?
Please, share the code :)

@ka-seo, I didn't make it, I went to robinherbots.github.io/Inputmask and clicked the Demo button. You can make it using this way: codepen.io/anon/pen/ZKNRvB.

@FinesseRus ,
Fixed

@RobinHerbots You are great, man! Thank you very much, I didn't expect it.


Make sure byoc secret finalizer is gone then return

Turns out if the Account doesn't exist, there's a nil pointer. Who knew?
This PR makes sure the BYOC secret finalizer logic is removed if the AccountClaim finalizer hotloop situation is hit.

/lgtm
/approve


Split create and start

This PR does the following:

splits start into create and start. Does not define run - that's an impl choice.

Lifecycle flow after with this PR:

create() is invoked to setup the container's NSs, cgroups, etc., but the user process is not yet started. The PID NS is created but paused waiting for the start() operation to be invoked. Control is returned to the caller.
At this point any additional processing (e.g. pre-start hooks) can be invoked by the management/orchestration tooling.
start() is invoked. The config.json's process property is used to start the user-defined process that is to be executed in the PID NS. Whether control is returned to the caller or not will depend on whether a --detach type of option was specified - so this is runtime dependent.
The user-defined process will eventually stop - either by exiting or via some external action (like the stop() operation being invoked).
All of the container resources (NS, cgroups, etc.) created for this container are deleted. Note that any resources used by the container but not created during the create() phase are not deleted as they are owned by some other container.

Motivating usecases:

to simplify the flows/interaction patterns by removing hooks, but still allow for the same functionality
allow for the container's resources to be created prior to defining the user-defined process being defined/run
allow a single orchestrator process to set up the container before the user process starts. Avoid needing to persist potentially private information to disk to make it available to args/env vars of hooks since now the hooks can be within the orchestrator, thus have access to its in-memory state.
allow for a cleaner "sandbox" model where one container (and its resources) are created for the purpose of then being used by other (subordinate) containers.

Signed-off-by: Doug Davis<EMAIL_ADDRESS>

We need an action that replaces the start today, something like run as discussed in the call.

PR has been updated to include a “run” operation - defined as create() followed by start()
-Doug

On Apr 13, 2016, at 7:09 PM, Mrunal Patel<EMAIL_ADDRESS>wrote:
We need an action that replaces the start today, something like run as discussed in the call.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/opencontainers/runtime-spec/pull/384#issuecomment-209573000

I've left some comments inline, but my main concern at the moment is
specifying standard-stream, ‘process.terminal’, and exit-code handling
(see 1).  I'd like to have that cleared up (probably rolling
runtime-linux.md into runtime.md, editing, and attaching it to a
particular operation).  The main issue is whether the host-side
process from ‘create’ or the process from ‘start’ is going to supply
the standard streams and other file descriptors for the container
process.  Whichever process supplies those file descriptors should
also be the one waiting on and returning the container process' exit
code.
My personal preference would be to have:

The runtime-specified container-process code not use its standard
streams at all.
The host-side process from ‘create’ not wait on the container
process's exit code.
The ‘start’ process supply standard streams and other file
descriptors for the container process via a Unix socket.
The ‘start’ process wait on the container process, and exit with its
exit code.

That lets us use the ‘create’ return to signal when a container
process is up and ready for a ‘start’ invocation (vs. polling the
state registry?).
‘process.terminal’ is currently not all that clear to me 2, so I'm
fine if that is still unclear after this PR lands ;).
 Subject: More detail for process.terminal?
 Date: Thu, 14 Jan 2016 14:44:08 -0800
 Message-ID<EMAIL_ADDRESS>

@duglin Completed a review pass. Thanks for pushing this forward!!

On Thu, Apr 14, 2016 at 11:11:06AM -0700, W. Trevor King:
“my main concern at the moment is specifying standard-stream,
‘process.terminal’, and exit-code handling”.
The fact that waitpid(2) and friends only work for child processes
hadn't sunk in.  That means that the host process from ‘create’ has to
stick around and return the container exit code if we want to return
that exit code to a caller who is waiting on a direct child.
This means that we need a different way than “the initial ‘create’
process has exited” to notify interested parties that the container
process is start-able (e.g., so you can run the stuff you used to put
in pre-start hooks).  The notification issue has come up before in the
context of exec [1], with @julz and @crosbymichael talking about event
file descriptors and such.  This may be enough of a reason to keep
pre-start hooks around (although it would probably be good to rename
them post-create commands, since they run after the ‘create’ process
finishes the setup, but possibly well before a ‘start’ command is
called, if ever).
If keeping the ‘create’ host process around is unacceptable, the
caller would have to get the container PID from the ‘create’ call and
wait on the container process directly.  It may be possible to do that
robustly, but it sounds like a lot of work.
I don't see any technical roadblocks for either ‘create’ or ‘start’
supplying the standard streams and terminal handling, but I'd expect
that they should stay with the process handling the exit code for
simplicity.
[1]: From #opencontainers on 2015-09-15 (before we had online logs).
 11:23 < julz> btw just a random thing, I wish there were a way we
    could have the runtime tell me when it has successfully
   launched the process

 and through the next five minutes or so.

Another round of edits have been made.

On Mon, Apr 25, 2016 at 07:15:50AM -0700, Doug Davis wrote:

Another round of edits have been made.

With 6ae7c16d, the lifecycle section looks more like an overview of
how the various operations (create, start, …) fit together.  Instead
of splitting requirements for those operations between the
per-operation sections and the lifecycle section, I'd rather collect
all the requirements in the per-operation section.  The remaining
lifecycle section would be an informative introduction, linking out to
the per-operation sections for details.  Something like:

The runtime's create command is invoked to create the
container.
The following MAY happen in any order:

The runtime's state operation MAY be used to
fetch the container's state JSON.
The runtime's start command MAY be invoked to run the
user-specified code in the container process.
The runtime's stop operation MAY be used to stop the
container process.
Additional actions such as pausing the container, resuming the
container or signaling the container MAY be performed.
The container MAY error out, exit, or crash.

After the container process exits...

Runtime's delete command MAY be invoked with the identifier of
the container.

Although I'm still a fan of not requiring a delete command, and just
having the ‘create’ host process handle the cleanup automatically.

more edits have been made - just minor tweaks.

ping @vishh

I've updated the PR with what I think is the latest thinking on the subject - I've also updated the initial comment with more design/reasoning info.  If more is needed let me know.  @vishh I'd like to add your usecases too, if I missed some so please let me know.
ping @vishh @crosbymichael @philips @mrunalp

Your new usecases 1 look similar to the ones I'd listed in 2,
so +1 there.
I'd rather have a “don't pin” option vs. your current “autoremove”.
As discussed in the call yesterday 3, the autoremove approach still
requires someone to be alive to perform the auto-delete.  The current
functionality, which some folks (including me) want to preserve/allow
is to not pin namespaces at all.  Then all container-related processes
can die, and the kernel will still automatically reap the
container's namespaces.  That's not what everyone wants all the time
(hence the (no-)pinning option), but it is what I want most of the
time ;).  I think a convenient config for this would be to extend the
namespace model to be:

type (string, required) - namespace type…
path (string, optional) - path to namespace file…
pin (boolean, optional) - persist the namespace (e.g. via [bound-mounting or holding open a namespace file][namespaces.7]) until delete.
If false or unset, the death of the container process may remove the only namespace consumer, and the kernel [reaps unused namespaces][namespaces.7] automatically.

The opt-out alternative would be doNotPin or some such, and you could
make that global if you want, but I think a global switch is too
magical (“pin anything you can”?) and I don't like the double-negative
in:
doNotPin: "false"
although folks could just leave it unset (vs. the explicit false), and
I'm likely biased towards opt-in because I don't want the feature
in most cases.
 Subject: Re: Splitting Start into create() and run()
 Date: Thu, 24 Mar 2016 15:04:14 -0700
 Message-ID<EMAIL_ADDRESS>

This PR is super appealing to me as someone developing a CaaS platform based on the runtime-spec w/  runC.
Since we want all of our namespaces to be atomic and tied to the process (/proc//ns/...), we couldn't build/attach our network interfaces until after the container was running (and namespace existed). We had to solve this by creating a small 'supervisor' binary where we'd pass the configuration (process/args to execute) along with a list of network interfaces that the container should expect. Once our compute layer started the container, and prepared all of the interfaces, the supervisor within the container would then execute the desired process -- we could ensure interfaces would be up for our clients' containers. This way, we wouldn't have to encourage the "oh just throw a sleep() into your startup script if it requires immediate networking" that has been making its way through the container community recently.
This PR will allow us to drop the complexity of inserting said binary and instead create everything that is needed from the compute layer on the host before we start the desired container process -- keeping everything clean :). The fact that we can do all of this without calling any hooks will make the entire process even more streamlined.

On Fri, Apr 22, 2016 at 11:13:13PM -0700, W. Trevor King wrote:

The fact that waitpid(2) and friends only work for child processes
hadn't sunk in.  That means that the host process from ‘create’ has
to stick around and return the container exit code if we want to
return that exit code to a caller who is waiting on a direct child.

I put together a ccon branch demonstrating this approach (create's
host process reaping the container, and the start process just passing
in the start trigger, and optionally overriding process JSON) 1.
For start-able notification, I'm only binding the socket after all the
non-process stuff is setup 2, since that was a light-weight
implementation.  Clients interested in taking immediate post-setup
action can poll the socket path, or use something like:
$ inotifywait -q -m -e CREATE /path/to/dir/that/will/hold/the/socket/
Folks who are going to use a create/start split in production will
likely want a lighter-weight (for the client) method, and in that case
the event channel discussed by @julz and @crosbymichael is probably
going to be a better bet.
As of 0430aaf1, I still see no wording in this PR about standard
stream handling, start-able notification, or container-exit-code
reporting.  I expect we want to explain how we expect that to work in
more detail, otherwise implementations will likely be all over the
board ;).

Adding a use case: dynamically adjusting the mounts based on what process is going to be run in the container. This requires access to the host mounts before pivot_root to the container rootfs. See https://github.com/projectatomic/oci-systemd-hook for a hook that does that.

On Wed, May 18, 2016 at 07:11:40AM -0700, Mrunal Patel wrote:

Adding a use case: dynamically adjusting the mounts based on what
process is going to be run in the container. This requires access to
the host mounts before pivot_root to the container rootfs. See
https://github.com/projectatomic/oci-systemd-hook for a hook that
does that.

I'm having trouble wrapping my head around the oci-systemd-hook
workflow.  The init/systemd args check [1,2] makes it feel like the
idea is “the runtime-caller injects this in all configs without having
much knowledge of what the config is about”.  If the config-author was
interested in running systemd under OCI, they could setup the mounts
directly (and use a hook just to write /etc/machine-id).  You might
need a pre-create runtime-side tweak to find the host's cgroup mount,
but that doesn't have to happen inside a hook.
If the goal is to convert images designed to run systemd from
privileged to unprivileged users, then the pre-create config
translator will need more brains, but I still don't see much reason to
do this in a hook.  Using a hook addresses cases like “original config
mounts some other directory to /tmp” or “original config has an
earlier hook which writes content to /tmp” by copying those files into
the new /tmp tmpfs.  But that seems like a small corner case, and I
doubt a hook like this is going to cover all corner cases (i.e. there
will always be some hypothetical configs designed for a privileged
systemd which the script does not successfully convert to an
unprivileged container).
So blocking create/start or retaining pre-pivot hooks seems like a
moderately large cost in order to partially close an already small
hole.

0430aaf → 4b20453 drops ‘delete’, but the implementation in
opencontainers/runc#827 requires it (to cleanup cgroups, etc. 1).
I'm personally a fan of not making create-detaching optional 2, and
with attached ‘create’ calls you wouldn't have to call ‘delete’ (the
host-side ‘create’ process could do that automatically after reaping
the container process).  But even with optional detachment, you'll
still need a ‘delete’ operation for folks who do chose to detach their
‘create’.

If you have create then you need a delete.  The create not detaching is not good because the caller does not know when create is finished without making things super complicated with pipes and sockets.
To the spec:

Create a container runtime create test
Create returns and I run my stuff ...
Start the container runtime start test
It runs or I kill/stop it runtime kill test 9
Since I created the container, i have to delete it runtime delete test

On Wed, May 25, 2016 at 05:20:05PM -0700, Michael Crosby wrote:

If you have create then you need a delete.  The create not detaching
is not good because the caller does not know when create is finished
without making things super complicated with pipes and sockets.

The flip-side to this is that ‘delete’ requires PR_SET_CHILD_SUBREAPER
in callers who care about the container exit status 1.
On the other hand (with an attached ‘create’ process that handles
cleanup for you), you have a few choices for signalling “ready for
‘start’”.  The more obvious choices (as I already outlined in 2)
are:

You can create a file/socket/… when the container process is ready
and callers can poll for it or inotifywait on it 2.
You can expose an event service, and callers can subscribe to hear
about events like “container {ID} is ready to ‘start’”.

Neither one of those sounds like “making things super complicated with
pipes and sockets” to me, and I like having the container's exit code
easily available from the shell.

On Wed, May 25, 2016 at 09:07:09PM -0700, W. Trevor King wrote:

Wed, May 25, 2016 at 05:20:05PM -0700, Michael Crosby:

If you have create then you need a delete.  The create not
detaching is not good because the caller does not know when create
is finished without making things super complicated with pipes and
sockets.

The flip-side to this is that ‘delete’ requires
PR_SET_CHILD_SUBREAPER in callers who care about the container exit
status [1].

And for callers, the best of both worlds is to make --detach a
‘create’ option and have the runtime APIs (e.g. a command-line API)
provide standard methods for noticing “ready to ‘start’”.  Then
callers can pick whichever is most convenient for them in a given
instance.
That doesn't sound particularly onerous from a runtime-support
perspective, and I'm happy to file a PR against
opencontainers/runtime-spec#827 if it would help you judge
maintainability for runC.

Updated based on latest comments - but I have some comments/questions:

I added a "kill" command since we didn't have one but @crosbymichael (in https://github.com/opencontainers/runtime-spec/pull/384#issuecomment-221745368) seemed to indicate we should have one - plus runc has one.  Basically, renamed 'stop' to 'kill'.
the difference between kill and 'delete' is very fuzzy to me.  Kill sends a signal to the process, which should stop it. Once the process stops, shouldn't the PID ns go away along with all of the other namespaces? If so, how is that different than delete?
likewise, if I call delete() and the process is still running I assume it should first do a kill(9) and then delete the NS, etc.  Sounds a lot like kill to me.
If I'm right that everything goes away once the process has exited, how does a user get the exit code of a container once the process has stopped?  Or is delete() more focused on deleting the runtime's metadata about the container (like the exit code) and it lives on beyond the lifecycle of the container's process/NSs/etc...?

the difference between kill and 'delete' is very fuzzy to me. Kill sends a signal to the process, which should stop it. Once the process stops, shouldn't the PID ns go away along with all of the other namespaces? If so, how is that different than delete?

I think kill is just to be able to send a signal to the process. That signal doesn't necessarily stop the container. delete is difference in that besides stopping the container, it also makes sure that it removes all resources held by the container (i.e. created cgroups, files etc. )

@dqminh when the process stops, doesn't the PID ns (and the other NSs) go away?

On the distinction between stop, kill, and delete, proc(5) describes
the following state entries in thatproc/[pid]/stat 1 (for modern
kernels):

R  Running
S  Sleeping in an interruptible wait
D  Waiting in uninterruptible disk sleep
Z  Zombie
T  Stopped (on a signal)
t  Tracing stop
X  Dead

and ps(1) has a bit more context 2 (for modern kernels):

D uninterruptible sleep (usually IO)
R running or runnable (on run queue)
S interruptible sleep (waiting for an event to complete)
T stopped by job control signal
t stopped by debugger during the tracing
X dead (should never be seen)
Z defunct ("zombie") process, terminated but not reaped by its
parent

So I expect “stopped” to mean “process still exists but is paused,
e.g. by SIGSTOP”.  And I expect “exited” to mean “process has finished
and is either a zombie or dead”.  I expect a “kill” operation to shift
the container process to “exited”.
“Delete” is “kill the container process and cleanup any container
resources that outlive the container process (e.g. cgroups created by
‘create’)”.  So after ‘kill’, you still have cgroups created by
‘create’.  But after ‘delete’ those are gone.
On Thu, May 26, 2016 at 05:32:29AM -0700, Doug Davis wrote:

when the process stops, doesn't the PID ns (and the other NSs) go
away?

A PID namespace in which the container process was PID 1 will be
reaped by the kernel when the container process exits.  But other
namespaces may survive the death of the container process (e.g. if
they have other processes still inside them, or if they were
bind-mounted somewhere 3).
And re a comment from 4, with a detaching ‘create’ you need an
orchestration layer setting PR_SET_CHILD_SUBREAPER to collect the exit
code [5,6] (which is why I'd like to make that detaching optional
[7,8]).

LGTM

Made it so that delete() doesn't call kill() per Julz's comment.

LGTM

LGTM

@mrunalp i think you have to "lgtm" again after the PR was merged or it will keep complaining ;)

LGTM

@crosbymichael done.

booo
@duglin it needs rebased

no idea why I had to rebase - there was no conflict. Go figure.

I guess will need LGTM again :)

LGTM

LGTM

yah!

Finally!

🎉


STM32: Fix clock bus for STM32F0 GPIO

Clock bus was not documented correctly in stm32f0.dtsi.
Failure was exposed since recent change in GPIO drivers using bus setting from device tree.
To avoid this kind of issue in future, add default case that return error when unsupported bus is requested from peripheral drivers. Add matching error checking in peripheral drivers.
Fixes #11904

Codecov Report

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

@@            Coverage Diff             @@
##           master   #11925      +/-   ##
==========================================
+ Coverage   48.11%    48.2%   +0.09%
==========================================
  Files         280      280
  Lines       43246    43259      +13
  Branches    10363    10364       +1
==========================================
+ Hits        20806    20854      +48
+ Misses      18285    18253      -32
+ Partials     4155     4152       -3

Impacted Files
Coverage Δ

include/logging/log_core.h
100% <0%> (ø)
:arrow_up:

include/logging/log_msg.h
90.9% <0%> (+1.81%)
:arrow_up:

misc/printk.c
84.93% <0%> (+3.12%)
:arrow_up:

subsys/logging/log_core.c
74.67% <0%> (+4.8%)
:arrow_up:

subsys/logging/log_output.c
69.4% <0%> (+9.58%)
:arrow_up:

Continue to review full report at Codecov.

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

recheck


Export with UMD as 'clappr' and 'Clappr'

If it doesn't export as the same value in package.json main it gets complicated when using the library in another project.
E.g. In an external library webpack can set Clappr as externals: {clappr: 'Clappr'}. When the built dist is then loaded in a browser it ends up using window["Clappr"]. However, if built with another module builder and define or exports exists, then webpack inserts require('Clappr') instead which is wrong.
If in the external library it could be set to external: clappr, this issue wouldn't exist.
Here's an example of the top of a build which is broken (if it is included inside another module builder):
(function webpackUniversalModuleDefinition(root, factory) {
	if(typeof exports === 'object' && typeof module === 'object')
		module.exports = factory(require("Clappr"));
	else if(typeof define === 'function' && define.amd)
		define(["Clappr"], factory);
	else if(typeof exports === 'object')
		exports["ClapprMarkersPlugin"] = factory(require("Clappr"));
	else
		root["ClapprMarkersPlugin"] = factory(root["Clappr"]);
})(this, function(__WEBPACK_EXTERNAL_MODULE_1__) {
return /******/ (function(modules) { // webpackBootstrap
/******/ 	// The module cache
/******/ 	var installedModules = {};

/******/ 	// The require function
/******/ 	function __webpack_require__(moduleId) {

if Clappr was clappr here I think it would be fine.

Coverage remained the same at 71.644% when pulling 6c4748d6434e212514852c1bb050f68ef98c3572 on export-as-clappr-and-Clappr into 5795a09755eaa5a6fedd9c6a5aa0f34661f307f3 on master.

I think it is a solid feature (Leandro's bot)

LGTM @clappr/core thoughts?

Thanks mister @tjenkinson lol

So if we include Clapp in a browser with a script tag like
  <script type="text/javascript" src="http://cdn.clappr.io/latest/clappr.js"></script>

Then the Clapp player should be available in window object as window.Clappr or window.clappr ?
Currently, on my tests it is only available as window.clappr (not window.Clappr) at release 0.2.62

I can reproduce here http://cdn.clappr.io/

Can confirm as well but I swear I tested this :/

maybe its just a webpack version mismatch

I just built it again locally and it's doing
root["clappr"] = root["clappr"] || {}, root["clappr"]["Clappr"] = factory();

which is not what we want we should revert this.

new issue https://github.com/clappr/clappr/issues/1145


documentation: push just repeats what replace says

_For example:
If the current route is '/products' and you call replace('1') you'll navigate to '/products/1'.

If the current route is '/products' and you call replace('/home') you'll navigate to '/home'._

from: https://pub.dev/documentation/routemaster/latest/routemaster/Routemaster/push.html

Does Pushes path into the navigation tree. mean it has to be popped at some point so replace is slightly easier for novices to use?


Cancel timer after test

The cancel function returned by WithTimeout() needs to be called to clean up resources.  However, it was being called too early.  This commit delays the invocation until the test is complete.
Resolves #3665
Signed-off-by: andrew-coleman<EMAIL_ADDRESS>

@Mergifyio backport release-2.5

@Mergifyio backport release-2.4