playlist crunches

When playing a playlist it will show as believed it normally should for a second and then seems to "crunch" into the upper right... sometimes... most of the time, mostly at the beginning of the playlist, I feel. I have checked my other addons and they don't seem to be the cause.

Yeah.That happens when you use the small player view with a playlist.With the "Theater" view the play list shows fine.
I used to use a small view player with custom 720p size,but had to move to a "Theater" view because of that bug.Got used to the "Theater" view now.
On a side note if i set a custom size for a player view after i change to it from the button in the player,i can no longer change to the other view.The button stops working.Changing views works fine with default player sizes.

I'm experiencing exactly same problem.
Whenever I enable Player > Player Size > Enable Resize it causes the Playlist area (besides the player window) to collapse so that there's only a tiny strip of the playlist barely visible at the top of the window.
When viewing videos that are NOT part of a playlist, there's no such problem. The list of 'suggested' videos correctly displays beside the player window, and this list slides down and out of the way when the large player / cinema mode button is pressed on the player.
If I disable just the YTC Resize feature, then the Playlist goes back to displaying correctly again.
The issue only happens for me in Firefox. In Opera I don't experience any such issue when YouTube Center's auto-resize is enabled.

I confirm that disabling Resize option fixes the playlist issue.

I've got a piece of css that appears to fix the playlist issue (at least better than my first attempt, which I can't really find any more):
    .watch-small #player-playlist {
      margin-top: 0 !important;
    }
    #player-playlist .watch-playlist {
      height: 360px;
    }
    @media (min-height: 360px) {
      #player-playlist .watch-playlist {
        height: 480px;
      }
    }
    .ytcenter-resize .watch-small #player-api {
      position: absolute !important;
    }

Actually, this issue should be fixed in the latest version. Could someone verify this?

Just tested it with v546 and with the small player it is still broken(exactly like the screenshot from 1st comment).

okay

It seems to be working in Chrome. I will try to test it in Firefox.

Alrighty, thanks~

Ayy, just wanted to say thanks for all the activity here guys and the add-on in general.


There are no eligible queues for the provided execution requirements.

I'm using tag 2.10.2 and working on configuring a build farm cluster to satisfy the build requirements on multiple container images, such that executions are restricted to only a subset of workers.
Suppose I have two types of workers hosting different OS os-1 and os-2, and I want all actions of a build target only executed by os-1 workers.
From this doc my understanding is that I can configure two queues os_1_pool and os_2_pool, and match os-1 workers only to os_1_pool, by the below configs.
Then I can somehow set the exec_properties of my target to be queued only to os_1_pool, which later be executed by only os-1 workers.
bazel build --remote_executor=grpc://server:port --remote_default_exec_properties=os=1 //:my_target
server
backplane:
  queues:
    - name: "os_1_pool"
      allowUnmatched: false
      properties:
        - name: "os"
          value: "1"
    - name: "os_2_pool"
      allowUnmatched: false
      properties:
        - name: "os"
          value: "2"

worker_1
backplane:
  queues:
    - name: "os_1_pool"
      allowUnmatched: false
      properties:
        - name: "os"
          value: "1"
worker:
   xxxx

worker_2
backplane:
  queues:
    - name: "os_2_pool"
      allowUnmatched: false
      properties:
        - name: "os"
          value: "2"
worker:
   xxxx

But now I'm having following exception when starting worker_1
Oct 18, 2024 3:48:14 PM build.buildfarm.worker.PipelineStage decideTermination
SEVERE: MatchStage::run(): stage terminated due to exception
java.lang.RuntimeException: There are no eligible queues for the provided execution requirements. One solution to is to configure a provision queue with no requirements which would be eligible to all operations. See https://bazelbuild.github.io/bazel-buildfarm/docs/architecture/queues/ for details. Below are the eligibility results for each provisioned queue:
The properties are not eligible for the os_1_pool queue.
matched: {}
unmatched: {}
still required: {os=[1]}

I also tried the example provided in the doc and got the same exception.
My questions are:

Am i doing it correct and why I'm having this exception?
Is this the correct approach to solve my initial requirement?

Thanks.

Comment to increase visibility

You need to declare dequeueMatchSettings for each worker independently to indicate that they provide the properties required by operations, and should pull from only matching queues. In your case, you are getting this exception because none of what the worker provides (nothing, as declared), matches what requirements exist for executions entering the queues.
In your case, the os-1 workers would have properties to match with the settings in the os_1_pool, likewise for os-2.

Thanks for the reply. In this case my understanding is that for os-1 worker to work, it should

Declare os_1_pool queue in its backplane setting
Declare dequeueMatchSetting in its worker field to match what os_1_pool expect as properties.

In this case would having different backplane queue settings in os-1 worker and os-2 worker make much difference, comparing to having same backplane setting but different dequeueMatchSetting?
Also could we update the above worker example in Operation Queue doc to add corresponding dequeueMatchSetting so others won't have similar problems?

It makes no difference to have the same (or different) queue settings on the workers - in fact, I recommend that they be the same, and that 'queues' be constant across all hosts except those that you want to deliberately not know about a particular queue. All members of a cluster should (generally) know about the same queues, and workers should have different dequeueMatchSettings as you've indicated here.
I'll see what I can do about the docs.

Very informative! Thanks, closing this issue.


Backup and restore dashboard in the Console

 Issue by marktani
Tuesday Sep 26, 2017 at 17:10 GMT
Originally opened as https://github.com/graphcool/prisma/issues/593

What feature are you missing?
A dashboard in the Console that gives an overview about existing backups, create new ones, apply backups to the current or other projects.
How could this feature look like in detail? Tradeoffs?
Might even be expanded to a full deployment dashboard, so you could control deployment + data backups + restore there.

I see that users on the project plan have backups created daily, https://www.graph.cool/cloud/.
Where can I list / restore for a generated backup?


Wrapper type for data that should never be logged

Fixes #11519.
So far this is just creating the new wrapper type. If this looks okay, I'll start adding this wrapper in places where tokens and secret keys are held or passed.

r? @Eh2406

This is more general than I had in mind. I would love to see what you end up doing with it. I was imagining a new type around String, so if your generic version gets difficult consider simplifying.

Thanks for taking a look! Sounds good, I'll give it a shot like this for now, but keeping the newtype approach in mind if things get hard (or if we decide that having this be generic is unnecessary).

I added the wrapper to most of the interfaces in ops::registry and util::auth. If this looks roughly like what you were envisioning, I'm happy to add this to other modules too as needed :smiley:

Hi! I changed back to using Secret<&str> and tried to improve the docs a bit. I also added a doctest to ensure that the Debug impl is working as expected.
I also noticed a few places where tokens were being read or generated and then put inside a Secret, so I refactored those a little bit in the latest commit. I think it might be a little better, but also a little less readable, so I'd be interested to see what you think.

:pushpin: Commit efb972ae76c4e755b94466304c57dfc2b7a829d7 has been approved by Eh2406
It is now in the queue for this repository.

:hourglass: Testing commit efb972ae76c4e755b94466304c57dfc2b7a829d7 with merge d6ba7a3c5841d36b9d95d7e6a7481eba8109b018...

:broken_heart: Test failed - checks-actions

@bors retry

:hourglass: Testing commit efb972ae76c4e755b94466304c57dfc2b7a829d7 with merge ba6217e40fc05ac95f8a0fbe77aa83cdbc907a10...

:sunny: Test successful - checks-actions
Approved by: Eh2406
Pushing ba6217e40fc05ac95f8a0fbe77aa83cdbc907a10 to master...


Water does not affect player physics

You fall through water like air.

This seems to be only below y=0.

Please confirm whether it is only below y=0, or if it occurs above y=255 as well.

Also occurs above y=255.

Can also confirm it happens above 255. Lava is not effected at all though, above 255 or below 0.

fixed in 40840e6e851ce9d31ceaad704a0f6b9473988ab4


Add defaults to tilemap set_cell function example

Adds defaults to the tilemap set_cell function example. Closes https://github.com/godotengine/godot-docs/issues/3829.

That should be fixed now.

Thanks!

Cherry-picked for 3.2.3.


Bug in RecoverFEMSolution when x and X aren't aliases

In BilinearForm::RecoverFEMSolution and Operator::RecoverFEMSolution, it is sometimes assumed that X (the linear algebra solution vector) and x (the grid function) point to the same memory, e.g. when the prolongation $P$ is the identity operator
https://github.com/mfem/mfem/blob/701870a7daea3f846613feb296b2f71a6afd007e/linalg/operator.cpp#L148-L166
and
https://github.com/mfem/mfem/blob/701870a7daea3f846613feb296b2f71a6afd007e/fem/bilinearform.cpp#L829-L846
However, this assumption isn't checked, and can easily be broken, for example this diff to ex1:
diff --git a/examples/ex1.cpp b/examples/ex1.cpp
index d3480df4e..94b869d75 100644
--- a/examples/ex1.cpp
+++ b/examples/ex1.cpp
@@ -210,8 +210,9 @@ int main(int argc, char *argv[])
    a.Assemble();

    OperatorPtr A;
-   Vector B, X;
-   a.FormLinearSystem(ess_tdof_list, x, b, A, X, B);
+   Vector B, Y;
+   a.FormLinearSystem(ess_tdof_list, x, b, A, Y, B);
+   Vector X = Y;

    cout << "Size of linear system: " << A->Height() << endl;

This can lead to hard-to-find bugs, because everything works correctly, except the grid function x is never recovered (RecoverFEMSolution basically does nothing in this case).

Proposed solution: we should check if X and x really do point to the same data, and if not, just set x = X;.

Ah, you're right that it's documented (but I didn't look at the FormLinearSystem documentation, which is a bit more explicit about it).
The reason this came up for me is in the context of time stepping. In that context, you don't necessarily want to call FormLinearSystem every time step (since for linear problems you can just use the same OperatorHandle every time). So it can be convenient to use FormSystemMatrix and then do the right-hand side assembly by hand. Calling RecoverFEMSolution at the end of this procedure breaks that requirement.
Are you sure raising an error is better than just doing x = X in that case?

RecoverFEMSolution is meant to be used with FormLinearSystem. From a user's perspective: if you are not using FormLinearSystem, how do you know calling RecoverFEMSolution is the right thing to do?

So maybe we should have another member function that sets up the right-hand side without recreating the eliminated/constrained operator? What else is the recommended way to create multiple right-hand sides without recreating the operator?
In any case, I think it would be better if either it "just worked" (i.e. x = X) or gives an error.
To me at least it makes sense that
a.RecoverFEMSolution(X, b, x);

and
a.RecoverFEMSolution(Y, b, x);

should result in x having the same values whenever X and Y are vectors with the same values.
Doesn't that seem like a logical behavior?

Not everyone will read the documentation carefully.
I agree with Will that it will be desirable for above to "just work".
If there is a way to do that without much overhead, I think we should do it.

The reason I slightly prefer to raise an error is that the user can easily fix that and thus avoid the unnecessary copy. It's not a big deal to do the copy but it circumvents the optimization we have to avoid such copies.

So maybe we should have another member function that sets up the right-hand side without recreating the eliminated/constrained operator? What else is the recommended way to create multiple right-hand sides without recreating the operator?

In (Par)BilinearForm one can call FormLinearSystem multiple times to setup a linear system with different r.h.s. and/or essential b.c. without touching the matrix. This is the case when the form uses the legacy assembly mode.
In the matrix-free case in Operator, it makes sense to add a method that does the elimination without re-creating the ConstrainedOperator. The same is true for (Par)BilinearForm -- to add elimination method that works with all assembly levels and does not touch the system matrix.


[QUERY] Why not use primary connection string?

Query/Question
I would like to use this SDK to connect to Cosmos, but why go against the primary used method of connecting to a Mongo/Cosmos database with a primary connection string (which already includes, host, port, key etc) and force the user to split it up themselves, or map new fields into existing microservices to prevent us splitting it?
Why is this not a Bug or a feature Request?
I'm guessing this has been done for a reason, but can't see why you would do this.
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Query Added
[x] Setup information Added

@brian-duffy  - I guess the main reason is to support key rotation using Azure key vault, or any other service. I don't think there is any other reason to do this other than above.


Refactor get/set text

Now only "nodeType=3" will used when both getting and setting text, not clobbering all innerhtml
New methods for altering the inner HTML directly we then added for use in the couple of classes that require this expanded functionality (<markup> tag, etc)

:+1:


JAVA-1310: Make mapper's ignored properties configurable

Reboot of @avivcarmis original pull request:

target 3.x branch
rebase on top of current 3.x
get rid of my initial implementation

Reminder of the remaining tasks:

PropertyScanScope class will be changed to an enum containing {GETTERS_AND_SETTERS, FIELDS, BOTH}.
HierarchyScanStrategy class will be migrated to a single field of type Class<?> indicating the deepest ancestor to scan.
=> I think it would also be useful to indicate if the bound is inclusive or not. In some cases you may have a common parent and you'll want to say "up to this parent included", but in others you may have multiple independent trees, and it will be "up to Object excluded".
Add this change.
Document the fact that MappingManager getters will account for configuration object only for the first time, then they'll be ignored as discussed here.
Make configuration immutable (maybe switch to builders) and remove duplication on mapper creation as discussed here.
Move class docs to getter methods.
Move nested classes to top level ones.
Rename transient config properties and document transient hierarchy (config transient props vs. class annotation transient properties vs. transient annotation) as discussed here. => I've removed the annotation-level config property
Rename PropertyMappingStrategy values to {OPT_IN, OPT_OUT} as discussed here.
Reuse AnnotationParser.VALID_COLUMN_ANNOTATIONS as discussed here.
Account for java transient modifier as discussed here (i'm actually +1 on that, fell for it myself when i started using the mapper).
Rename MapperConfiguration to MappingConfiguration.
Last thing left open is whether we want to remove PropertyScanConfiguration field and move it's props to MappingConfiguration top level. => no, let's keep it separate

Let's finish this first and we'll focus on 1316 next.

The code is currently broken, removing the annotation-level exclusions creates an issue with Object.getClass(), even if it's excluded in the configuration we try to create a PropertyMapper for it, which fails because there is no corresponding setter.
We should not try to create property mappers for ignored fields, I'm trying to move the checks earlier.

Ok I have completed the remaining tasks and fixed the tests.
A couple of remarks:

All classes moved to the child config package;
All classes are now immutable and use the builder pattern;
Hierarchy scan: we have previously agreed to remove/reduce HierarchyScanStrategy, but indeed we might have overlooked the inclusion/exclusion problem. I propose the following:

Keep HierarchyScanStrategy, replace deepestAllowedAncestor with nearestExcludedAncestor (i.e. make this the actual stop class = inclusive);
Remove scanOnlyAnnotatedClasses: I think I missed this parameter and it seems too much for me, and besides, we do not encourage users to inherit from annotated classes. If we want to re-introduce this parameter, then we will have to introduce a separate annotation (e.g. @MappedSuperclass).

Also added one commit to disable mapper-level configuration in favor of manager-level configuration only. I honestly do not see a valid use case for mapping the same class in two different ways under the same application, but I'm open to discussion.

Also added one commit to disable mapper-level configuration in favor of manager-level configuration only. I honestly do not see a valid use case for mapping the same class in two different ways under the same application, but I'm open to discussion.

What about mapping two different classes with a different set of property exclusions?

@olim7t cheers! sorry for not being available for a couple of days. everything looks great. let me know if there's anything else i can do regarding 1310.
At the meantime i'll try to sum everything up with 1316. Since it's based on my 1310 branch it might be a bit of a struggle to rebase it. I think before we start coding we might want to finish here, rebase and then go ahead.

What about mapping two different classes with a different set of property exclusions?

Hmm sorry but is this realistic? Even if it were, I don't think we have users willing to have this feature as of now, so why not add it later if need be? (it's not breaking)

I added a commit for the inclusive/exclusive hierarchy bound.
Two things bother me about transient properties:

you can't remove the defaults (this could be easily addressed with an additional builder method that replaces the set instead of adding to it)
the exclusions are shared across all mapped classes and UDTs.
Per-class configuration is not a good answer to this, because UDT codecs share the configuration of the first table that required it, so there would be no deterministic way to know which one is used. And you couldn't have different exclusions for a table and its fields' UDTs either.
Another approach would be a single configuration, but with dotted notation for excluded properties. This gets very complicated (* and ** matching comes to mind), and there is currently no trivial way to pass the current prefix to a UDT codec (again because UDT codecs are shared across all mappers that need them).

I can't think of a good solution for 2. Maybe I'm overthinking this; if we're confident that shared exclusions are good enough, then we can keep the current implementation and I'm fine with a single, manager-wide configuration object.

I am starting to have second thoughts about the usefulness of PropertyScanConfiguration. After my latest commits it's been reduced to nothing more than a wrapper for some strategies, so I would now be in favor of removing it altogether. Wdyt?

The API seems really nice so far, will keep reviewing and will push some more tests tomorrow.

can we rebase this?  Would be good to do now since it's lagging a little bit behind 3.x.

Happy to see things kicking in...looking forward to using the new API.
Let me know if I can still help somehow.

Happy to see things kicking in...looking forward to using the new API.
Let me know if I can still help somehow.

I think we are close to code-complete here. The only minor nit I would like to offer for discussion is: the builder pattern in MapppingConfiguration. Like I explained for PropertyMapper, these configuration classes are not expected to execute concurrently and therefore do no need to be strict about immutability or thread-safety. Under this perspective, the builder pattern seems to bit a bit overkill; in addition, a simple, mutable version of MappingConfiguration with a public default constructor would be easier to extend (if that ever makes sense one day).

A few test issues popped up after rebase, looking into it, probably an easy explanation.

It looks like the issue has to do with fields being quoted (presumably for case sensitivity) in a UDT when they don't always need to be:

Will see where/why that could be happening.

I'm not sure if anybody would want to implement a different PropertyMapper considering we have the different mapping Strategies options

There are things that you can do by overriding protected methods that go beyond strategies (e.g. your comment about white list).

if there is really a use for the javaConvention part of the NamingStrategy

One example was if you use field access and your naming convention includes a prefix, for example private String _userName or private String mUserName (personally I don't like it but you see it sometimes).

if there is really a use for the javaConvention part of the NamingStrategy

Hungarian notation is still pretty much common, although I admit I've been seeing it less and less frequently.

Pushed up some more tests.  I think at this point we are pretty good on coverage (can always add more to test more permutations but I think what we have is adequate enough).   All of my comments/concerns have been addressed and things are working pretty well.   👍 'ing the PR, but will follow convo/commits as they come.

I introduced a test failure (not using frozen on UDT)...fixing.

@adutra

these configuration classes are not expected to execute concurrently and therefore do no need to be strict about immutability or thread-safety

To put it differently, attempting to change the configuration at runtime would have unpredictable consequences.
PropertyMapper is pretty safe since the configuration exposes an interface with no mutating methods. As for MappingConfiguration, I'd rather keep it immutable to make it clear that it's not supposed to change; a builder is overkill for only one field, but it's better for future backward compatibility.
So I vote to keep things as is.

I used the "squash and merge" strategy and I just realized it doesn't preserve the original commit author 😞  Sorry @avivcarmis I would have mentioned you in the commit message if I had known that.


Add Zawrs extension tests

Description

Add Zawrs extension test.

Related Issues

NA

Ratified/Unratified Extensions

[X] Ratified
[ ] Unratified

List Extensions

https://github.com/riscv/riscv-zawrs

Reference Model Used

[X] SAIL
[ ] Spike
[ ] Other - < SPECIFY HERE >

Mandatory Checklist:

[X] All tests are compliant with the test-format spec present in this repo ?
[ ] Ran the new tests on RISCOF with SAIL/Spike as reference model successfully ?
[ ] Ran the new tests on RISCOF in coverage mode
[ ] Link to Google-Drive folder containing the new coverage reports (See this for more info): < SPECIFY HERE >
[ ] Link to PR in RISCV-ISAC from which the reports were generated : < SPECIFY HERE >
[X] Changelog entry created with a minor patch

Optional Checklist:

[ ] RISCV-V CTG PR link if tests were generated using it : < SPECIFY HERE >
[X] Were the tests hand-written/modified ?
[ ] Have you run these on any hard DUT model ? Please specify name and provide link if possible in the description
[ ] If you have modified arch_test.h Please provide a detailed description of the changes in the Description section above.

You could be tricky and, in the timeout cases, check mtime or cycles and see that they at least incremented (the timeout should be provided to the test in terms of cycles (probably) and the test should check that it incremented by more than one, for example.

The Zawrs specifies its wrs.sto referring to an implementation-define short timeout. You cannot assume that cycles is incrementing during that timeout (it might for example be clock gated as is allowed for WFI implementations) and also mtime might not increase.

That is right. Adding such checks to the ACT will go beyond what architecture compatibility requires.

Well, not really. We expect DUT to provide a number in terms of
instructions retired or cycles or mtime, guaranteed to be larger than the
timeout,
and we can check that no interrupt has occurred when we inject an interrupt
after that time. The test pass criteria is a function of that number that
is provided to the test,
but that condition is true for a lot of tests with implementation defined
parameters.
On Mon, Jan 29, 2024 at 5:47 AM Ved Shanbhogue @.***>
wrote:

That is right. Adding such checks to the ACT will go beyond what
architecture compatibility requires.
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/pull/432#issuecomment-1914729168,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJQSPAOXBPSDUCMD4QLYQ6R6HAVCNFSM6AAAAABCORU5V2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJUG4ZDSMJWHA
.
You are receiving this because you commented.Message ID:
@.***>


ScaffoldMessenger will detect and assert for nested scaffolds

Description
This adds an assertion when calling ScaffoldMessenger.showSnackBar when nested Scaffolds are using the same ScaffoldMessenger. A ScaffoldMessenger should be placed in between levels of nested Scaffolds in order to control which one receives SnackBars.
Related Issues
Fixes https://github.com/flutter/flutter/issues/69929
Tests
ScaffoldMessenger will assert when presenting to nested Scaffolds
Checklist
Before you create this PR, confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[x] No, no existing tests failed, so this is not a breaking change.

Closing as we are looking at implementing different functionality.

Closing as we are looking at implementing different functionality.


Open position failed: Pulling Option info faild

We're trying to do market BUY orders using OpenD and this SDK. It was working great for months then we started getting this error coming from the OpenD server: "Open position failed: Pulling Option info faild" (faild is not a typo, we are receiving it this way).
As an example, we tried to BUY a QTY of "2" of "US.SPY240521P522000" as a "MARKET" order.
Those errors started to appear on all orders starting May 17th 2024.
We cannot find any reference to this error in the documentation and MooMoo support told us that the error is not coming from OpenD even tough we thoroughly confirmed that it was in fact coming from the OpenD server.
Using OpenD Ver.8.1.4108 with SDK Ver.8.1.4108

Expired options are not supported，please confirm whether the option has expired.
If the problem still exists, Provide log information as follows.
https://openapi.moomoo.com/moomoo-api-doc/en/qa/opend.html#7649
发件人: @.*** @.> 代表 quasifin
发送时间: 2024年5月26日 2:31
收件人: MoomooOpen/py-moomoo-api @.>
抄送: Subscribed @.***>
主题: [MoomooOpen/py-moomoo-api] Open position failed: Pulling Option info faild (Issue #5)
We're trying to do market BUY orders using OpenD and this SDK. It was working great for months then we started getting this error coming from the OpenD server: "Open position failed: Pulling Option info faild" (faild is not a typo, we are receiving it this way).
As an example, we tried to BUY a QTY of "2" of "US.SPY240521P522000" as a "MARKET" order.
Those errors started to appear on all orders starting May 17th 2024.
We cannot find any reference to this error in the documentation and MooMoo support told us that the error is not coming from OpenD even tough we thoroughly confirmed that it was in fact coming from the OpenD server.
Using OpenD Ver.8.1.4108 with SDK Ver.8.1.4108
—
Reply to this email directly, view it on GitHub https://github.com/MoomooOpen/py-moomoo-api/issues/5 , or unsubscribe https://github.com/notifications/unsubscribe-auth/BBDO3CQ626MAZSGH7LOSGHDZEDKFXAVCNFSM6AAAAABIJC4H3WVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMYTOMJWHA3DCMA .
You are receiving this because you are subscribed to this thread.  https://github.com/notifications/beacon/BBDO3CS7JCO4TRSTGBFJTLDZEDKFXA5CNFSM6AAAAABIJC4H3WWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHIUHJP4I.gif Message ID: @.*** @.***> >

Hi, can you provide your moomoo ID, so that we can check what is the exact problem. You can also try to restart your OpenD, and see if the problem is still there.
From: @.*** @.> On Behalf Of quasifin
Sent: Sunday, May 26, 2024 2:31 AM
To: MoomooOpen/py-moomoo-api @.>
Cc: Subscribed @.***>
Subject: [MoomooOpen/py-moomoo-api] Open position failed: Pulling Option info faild (Issue #5)
We're trying to do market BUY orders using OpenD and this SDK. It was working great for months then we started getting this error coming from the OpenD server: "Open position failed: Pulling Option info faild" (faild is not a typo, we are receiving it this way).
As an example, we tried to BUY a QTY of "2" of "US.SPY240521P522000" as a "MARKET" order.
Those errors started to appear on all orders starting May 17th 2024.
We cannot find any reference to this error in the documentation and MooMoo support told us that the error is not coming from OpenD even tough we thoroughly confirmed that it was in fact coming from the OpenD server.
Using OpenD Ver.8.1.4108 with SDK Ver.8.1.4108
—
Reply to this email directly, view it on GitHub https://github.com/MoomooOpen/py-moomoo-api/issues/5 , or unsubscribe https://github.com/notifications/unsubscribe-auth/BBDO3CQ626MAZSGH7LOSGHDZEDKFXAVCNFSM6AAAAABIJC4H3WVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMYTOMJWHA3DCMA .
You are receiving this because you are subscribed to this thread.Message ID: @.***>


Simple way to add hosts into /etc/hosts file

This is useful for cases where the fake hostname needs to be used
e.g. when accessing FreeIPA Web UI which is sensitive on used hostname.
It is uncomfortable task to read the values from mrack list and add
them manualy to /etc/hosts.
The change introduces two commands to help with this case:

$ mrack eh add to add all active hosts into /etc/hosts
$ mrack eh clear to remove all records added by mrack.

Mrack adds two markers into the /etc/hosts file and adds records
between them. This should work also with multiple runs of mrack in
separate tests. If the section already contains the fake hostname then
this line is overwritten with a new value. This is useful when
provisioning hosts for the same task after they were previously
removed.
Signed-off-by: Petr Vobornik<EMAIL_ADDRESS>

Is it possible that you could divide this work into two commits for feature and tests?

I don't see an added value of the task to spend time on it. Tests are part of the change and this is not e.g. FreeIPA where there were are valid reasons - easier backporting of only tests.

We need rebase here.


Updating documentation for addons to not throw deprecation

Not calling this._super in the init hook for addons throws deprecations in consuming applications. Made a simple update to the addon snippet for babel decorator support in the readme.

Thank you!


Make use of NonZero

Make clear to readers that the value 0 is not supported and has no special meaning.
Also allows the compiler to improve enum layouts.

Please add a CHANGELOG.md entry and mark it as a breaking change.

Please add a CHANGELOG.md entry and mark it as a breaking change.

Added a Changelog entry, restored the possibility to explicitly specify WASTEBIN_MAX_PASTE_EXPIRATION=0 and thus not marked it breaking.

Thanks for this as well :+1:


src: adding support for coveralls

@alexalikiotis I'm going to merge this because we still have test issues. But at least the configuration is already in place.


Feature: Use gray and white grid in ColorPickerButton to indicate transparency

Resolved / Related Issues

[x] Were these changes approved in an issue or discussion with the project maintainers? In order to prevent extra work, feature requests and changes to the codebase must be approved before the pull request will be reviewed. This prevents extra work for the contributors and maintainers.
Closes #12369

Validation
How did you test these changes?

[x] Did you build the app and test your changes?
[x] Did you check for accessibility? You can use Accessibility Insights for this.
[ ] Did you remove any strings from the en-us resource file?

[ ] Did you search the solution to see if the string is still being used?

[ ] Did you implement any design changes to an existing feature?

[ ] Was this change approved?

[ ] Are there any other steps that were used to validate these changes?

Settings - Appearances - Theme Color

Screenshots (optional)


Unable to provision cluster

Description
When the Runtime CR is created, the status is set to an error. Given Runtime:
apiVersion: infrastructuremanager.kyma-project.io/v1
kind: Runtime
metadata:
  generation: 1
  labels:
    kyma-project.io/broker-plan-id: 4deee563-e5ec-4731-b9b1-53b42d855f0c
    kyma-project.io/broker-plan-name: azure
    kyma-project.io/global-account-id: e449f875-b5b2-4485-b7c0-98725c0571bf
    kyma-project.io/instance-id: 1ec864c2-b67b-41b6-ba56-eac2974f5c62
    kyma-project.io/region: westeurope
    kyma-project.io/runtime-id: xxx7310b-3a47-4ed5-9009-7925f0b4d166
    kyma-project.io/shoot-name: d7c1cc5
    kyma-project.io/subaccount-id: github-actions-keb-integration
    operator.kyma-project.io/kyma-name: 3a67310b-3a47-4ed5-9009-7925f0b4d166
    kyma-project.io/controlled-by-provisioner: "false"
  name: maper-test-04
  namespace: kcp-system
spec:
  security:
    administrators:
    -<EMAIL_ADDRESS>    networking:
      filter:
        egress:
          enabled: false
        ingress:
          enabled: false
  shoot:
    controlPlane:
      highAvailability:
        failureTolerance:
          type: node
    kubernetes:
      kubeAPIServer:
        oidcConfig: {}
    name: mapertest03
    networking:
      nodes: <IP_ADDRESS>/22
      pods: <IP_ADDRESS>/13
      services: <IP_ADDRESS>/13
    platformRegion: cf-eu10
    provider:
      type: azure
      workers:
      - machine:
          image:
            name: gardenlinux
            version: 1443.9.0
          type: Standard_D2s_v5
        maxSurge: 3
        maxUnavailable: 0
        maximum: 20
        minimum: 3
        name: ""
        zones:
        - "3"
        - "1"
        - "2"
    purpose: production
    region: westeurope
    secretBindingName: sap-skr-dev-cust-00002-kyma-integration

the status is:
status:
  conditions:
  - lastTransitionTime: "2024-08-08T06:30:31Z"
    message: Gardener API create error
    reason: GardenerErr
    status: "False"
    type: Provisioned
  state: Failed

Expected result
Cluster is created, status is set to "Ready"
Actual result
Provisioning fails.
Steps to reproduce
Create the given runtime using kubectl

it looks like the name of the worker is required.
Please enhance error messages for better debugging.

We will include Gardener's error message.

There is still a problem with provisioning, the following Runtime applied by kubectl gets "failed" soon (gardener shoot is not failed):
apiVersion: infrastructuremanager.kyma-project.io/v1
kind: Runtime
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"infrastructuremanager.kyma-project.io/v1","kind":"Runtime","metadata":{"annotations":{},"creationTimestamp":"2024-08-09T12:44:35Z","finalizers":["runtime-controller.infrastructure-manager.kyma-project.io/deletion-hook"],"generation":1,"labels":{"kyma-project.io/broker-plan-id":"4deee563-e5ec-4731-b9b1-53b42d855f0c","kyma-project.io/broker-plan-name":"azure","kyma-project.io/controlled-by-provisioner":"false","kyma-project.io/global-account-id":"e449f875-b5b2-4485-b7c0-98725c0571bf","kyma-project.io/instance-id":"d01b8790-03e6-497a-87a2-6a62ebc59f1f","kyma-project.io/region":"westeurope","kyma-project.io/runtime-id":"00f6c848-60e4-49be-a2a5-d94d923d3e0e","kyma-project.io/shoot-name":"c-741831f","kyma-project.io/subaccount-id":"github-actions-keb-integration","operator.kyma-project.io/kyma-name":"00f6c848-60e4-49be-a2a5-d94d923d3e0e"},"name":"maper-test-kim3","namespace":"kcp-system","resourceVersion":"4033488203","uid":"48995d2a-8d20-48f6-9adf-c1e277249183"},"spec":{"security":{"administrators":["test@test.com"],"networking":{"filter":{"egress":{"enabled":false},"ingress":{"enabled":false}}}},"shoot":{"controlPlane":{"highAvailability":{"failureTolerance":{"type":"node"}}},"kubernetes":{"kubeAPIServer":{"oidcConfig":{"clientID":"9bd05ed7-a930-44e6-8c79-e6defeb7dec9","groupsClaim":"groups","issuerURL":"https://kymatest.accounts400.ondemand.com","signingAlgs":["RS256"],"usernameClaim":"sub","usernamePrefix":"-"}},"version":"1.29"},"name":"c-bbbaaa","networking":{"nodes":"<IP_ADDRESS>/22","pods":"<IP_ADDRESS>/13","services":"<IP_ADDRESS>/13","type":"calico"},"platformRegion":"cf-eu10","provider":{"type":"azure","workers":[{"machine":{"image":{"name":"gardenlinux","version":"1443.9.0"},"type":"Standard_D2s_v5"},"maxSurge":3,"maxUnavailable":0,"maximum":20,"minimum":3,"name":"w1","volume":{"size":"50Gi","type":"Standard_LRS"},"zones":["1","3","2"]}]},"purpose":"production","region":"westeurope","secretBindingName":"sap-skr-dev-cust-00002-kyma-integration"}}}
  creationTimestamp: "2024-08-13T10:49:59Z"
  finalizers:
  - runtime-controller.infrastructure-manager.kyma-project.io/deletion-hook
  generation: 1
  labels:
    kyma-project.io/broker-plan-id: 4deee563-e5ec-4731-b9b1-53b42d855f0c
    kyma-project.io/broker-plan-name: azure
    kyma-project.io/controlled-by-provisioner: "false"
    kyma-project.io/global-account-id: e449f875-b5b2-4485-b7c0-98725c0571bf
    kyma-project.io/instance-id: d01b8790-03e6-497a-87a2-6a62ebc59f1f
    kyma-project.io/region: westeurope
    kyma-project.io/runtime-id: 00f6c848-60e4-49be-a2a5-d94d923d3e0e
    kyma-project.io/shoot-name: c-741831f
    kyma-project.io/subaccount-id: github-actions-keb-integration
    operator.kyma-project.io/kyma-name: 00f6c848-60e4-49be-a2a5-d94d923d3e0e
  name: maper-test-kim3
  namespace: kcp-system
  resourceVersion: "4041029997"
  uid: 67e6542a-2b5f-4ecb-8d71-a14df3ff1a60
spec:
  security:
    administrators:
    -<EMAIL_ADDRESS>    networking:
      filter:
        egress:
          enabled: false
        ingress:
          enabled: false
  shoot:
    controlPlane:
      highAvailability:
        failureTolerance:
          type: node
    kubernetes:
      kubeAPIServer:
        oidcConfig:
          clientID: 9bd05ed7-a930-44e6-8c79-e6defeb7dec9
          groupsClaim: groups
          issuerURL: https://kymatest.accounts400.ondemand.com
          signingAlgs:
          - RS256
          usernameClaim: sub
          usernamePrefix: '-'
      version: "1.29"
    name: c-bbbaaa
    networking:
      nodes: <IP_ADDRESS>/22
      pods: <IP_ADDRESS>/13
      services: <IP_ADDRESS>/13
      type: calico
    platformRegion: cf-eu10
    provider:
      type: azure
      workers:
      - machine:
          image:
            name: gardenlinux
            version: 1443.9.0
          type: Standard_D2s_v5
        maxSurge: 3
        maxUnavailable: 0
        maximum: 20
        minimum: 3
        name: w1
        volume:
          size: 50Gi
          type: Standard_LRS
        zones:
        - "1"
        - "3"
        - "2"
    purpose: production
    region: westeurope
    secretBindingName: sap-skr-dev-cust-00002-kyma-integration
status:
  conditions:
  - lastTransitionTime: "2024-08-13T10:50:15Z"
    message: Gardener API create error
    reason: GardenerErr
    status: "False"
    type: Provisioned
  state: Failed

another example: from Today:
apiVersion: infrastructuremanager.kyma-project.io/v1
kind: Runtime
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"infrastructuremanager.kyma-project.io/v1","kind":"Runtime","metadata":{"annotations":{},"creationTimestamp":"2024-08-14T12:46:01Z","finalizers":["runtime-controller.infrastructure-manager.kyma-project.io/deletion-hook"],"generation":1,"labels":{"kyma-project.io/broker-plan-id":"5cb3d976-b85c-42ea-a636-79cadda109a9","kyma-project.io/broker-plan-name":"preview","kyma-project.io/controlled-by-provisioner":"false","kyma-project.io/global-account-id":"e449f875-b5b2-4485-b7c0-98725c0571bf","kyma-project.io/instance-id":"2fe02d64-1067-4c7c-9cf9-8ade43056d15","kyma-project.io/region":"eu-central-1","kyma-project.io/runtime-id":"eb67e5b3-da61-474c-8c5f-4b77f7d57290","kyma-project.io/shoot-name":"c-maper10","kyma-project.io/subaccount-id":"github-actions-keb-integration","operator.kyma-project.io/kyma-name":"eb67e5b3-da61-474c-8c5f-4b77f7d57290"},"name":"maper010","namespace":"kcp-system"},"spec":{"security":{"administrators":["test@test.com"],"networking":{"filter":{"egress":{"enabled":false},"ingress":{"enabled":false}}}},"shoot":{"controlPlane":{"highAvailability":{"failureTolerance":{"type":"node"}}},"kubernetes":{"kubeAPIServer":{"oidcConfig":{"clientID":"9bd05ed7-a930-44e6-8c79-e6defeb7dec9","groupsClaim":"groups","issuerURL":"https://kymatest.accounts400.ondemand.com","signingAlgs":["RS256"],"usernameClaim":"sub","usernamePrefix":"-"}},"version":"1.29"},"name":"c-maper10","networking":{"nodes":"<IP_ADDRESS>/22","pods":"<IP_ADDRESS>/13","services":"<IP_ADDRESS>/13"},"platformRegion":"cf-eu10","provider":{"type":"aws","workers":[{"machine":{"image":{"name":"gardenlinux","version":"1443.9.0"},"type":"m6i.large"},"maxSurge":3,"maxUnavailable":0,"maximum":20,"minimum":3,"name":"cpu-worker-0","volume":{"size":"50","type":"gp2"},"zones":["eu-central-1c","eu-central-1b","eu-central-1a"]}]},"purpose":"production","region":"eu-central-1","secretBindingName":"sap-aws-skr-dev-cust-00002-kyma-integration"}}}
  creationTimestamp: "2024-08-14T13:33:55Z"
  finalizers:
  - runtime-controller.infrastructure-manager.kyma-project.io/deletion-hook
  generation: 1
  labels:
    kyma-project.io/broker-plan-id: 5cb3d976-b85c-42ea-a636-79cadda109a9
    kyma-project.io/broker-plan-name: preview
    kyma-project.io/controlled-by-provisioner: "false"
    kyma-project.io/global-account-id: e449f875-b5b2-4485-b7c0-98725c0571bf
    kyma-project.io/instance-id: 2fe02d64-1067-4c7c-9cf9-8ade43056d15
    kyma-project.io/region: eu-central-1
    kyma-project.io/runtime-id: eb67e5b3-da61-474c-8c5f-4b77f7d57290
    kyma-project.io/shoot-name: c-maper10
    kyma-project.io/subaccount-id: github-actions-keb-integration
    operator.kyma-project.io/kyma-name: eb67e5b3-da61-474c-8c5f-4b77f7d57290
  name: maper010
  namespace: kcp-system
  resourceVersion: "4043203808"
  uid: 391e2f94-94cd-4450-a849-56f6748e9283
spec:
  security:
    administrators:
    -<EMAIL_ADDRESS>    networking:
      filter:
        egress:
          enabled: false
        ingress:
          enabled: false
  shoot:
    controlPlane:
      highAvailability:
        failureTolerance:
          type: node
    kubernetes:
      kubeAPIServer:
        oidcConfig:
          clientID: 9bd05ed7-a930-44e6-8c79-e6defeb7dec9
          groupsClaim: groups
          issuerURL: https://kymatest.accounts400.ondemand.com
          signingAlgs:
          - RS256
          usernameClaim: sub
          usernamePrefix: '-'
      version: "1.29"
    name: c-maper10
    networking:
      nodes: <IP_ADDRESS>/22
      pods: <IP_ADDRESS>/13
      services: <IP_ADDRESS>/13
    platformRegion: cf-eu10
    provider:
      type: aws
      workers:
      - machine:
          image:
            name: gardenlinux
            version: 1443.9.0
          type: m6i.large
        maxSurge: 3
        maxUnavailable: 0
        maximum: 20
        minimum: 3
        name: cpu-worker-0
        volume:
          size: "50"
          type: gp2
        zones:
        - eu-central-1c
        - eu-central-1b
        - eu-central-1a
    purpose: production
    region: eu-central-1
    secretBindingName: sap-aws-skr-dev-cust-00002-kyma-integration
status:
  conditions:
  - lastTransitionTime: "2024-08-14T13:33:55Z"
    message: Gardener API create error
    reason: GardenerErr
    status: "False"
    type: Provisioned
  state: Failed

The issues described above were caused by the following:

shoot.provider.workers.volume.size has incorrect value ("50" instead "50Gi")
shoot.provider.workers.name property is missing
shoot.provider.networking.type property is missing

The problem number 1 is caused by the lack of validations. Here is the following ticket: https://github.com/kyma-project/infrastructure-manager/issues/229 that will be addressed at some point.
As it comes to the problems number 2 and 3 they should be addressed in KIM. shoot.provider.networking.type  default value should be set in the configuration. For the time being you can refer to this PR to see what Runtime CR expects.

There is still a problem with provisioning, the following Runtime applied by kubectl gets "failed" soon (gardener shoot is not failed):
apiVersion: infrastructuremanager.kyma-project.io/v1
kind: Runtime
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"infrastructuremanager.kyma-project.io/v1","kind":"Runtime","metadata":{"annotations":{},"creationTimestamp":"2024-08-09T12:44:35Z","finalizers":["runtime-controller.infrastructure-manager.kyma-project.io/deletion-hook"],"generation":1,"labels":{"kyma-project.io/broker-plan-id":"4deee563-e5ec-4731-b9b1-53b42d855f0c","kyma-project.io/broker-plan-name":"azure","kyma-project.io/controlled-by-provisioner":"false","kyma-project.io/global-account-id":"e449f875-b5b2-4485-b7c0-98725c0571bf","kyma-project.io/instance-id":"d01b8790-03e6-497a-87a2-6a62ebc59f1f","kyma-project.io/region":"westeurope","kyma-project.io/runtime-id":"00f6c848-60e4-49be-a2a5-d94d923d3e0e","kyma-project.io/shoot-name":"c-741831f","kyma-project.io/subaccount-id":"github-actions-keb-integration","operator.kyma-project.io/kyma-name":"00f6c848-60e4-49be-a2a5-d94d923d3e0e"},"name":"maper-test-kim3","namespace":"kcp-system","resourceVersion":"4033488203","uid":"48995d2a-8d20-48f6-9adf-c1e277249183"},"spec":{"security":{"administrators":["test@test.com"],"networking":{"filter":{"egress":{"enabled":false},"ingress":{"enabled":false}}}},"shoot":{"controlPlane":{"highAvailability":{"failureTolerance":{"type":"node"}}},"kubernetes":{"kubeAPIServer":{"oidcConfig":{"clientID":"9bd05ed7-a930-44e6-8c79-e6defeb7dec9","groupsClaim":"groups","issuerURL":"https://kymatest.accounts400.ondemand.com","signingAlgs":["RS256"],"usernameClaim":"sub","usernamePrefix":"-"}},"version":"1.29"},"name":"c-bbbaaa","networking":{"nodes":"<IP_ADDRESS>/22","pods":"<IP_ADDRESS>/13","services":"<IP_ADDRESS>/13","type":"calico"},"platformRegion":"cf-eu10","provider":{"type":"azure","workers":[{"machine":{"image":{"name":"gardenlinux","version":"1443.9.0"},"type":"Standard_D2s_v5"},"maxSurge":3,"maxUnavailable":0,"maximum":20,"minimum":3,"name":"w1","volume":{"size":"50Gi","type":"Standard_LRS"},"zones":["1","3","2"]}]},"purpose":"production","region":"westeurope","secretBindingName":"sap-skr-dev-cust-00002-kyma-integration"}}}
  creationTimestamp: "2024-08-13T10:49:59Z"
  finalizers:
  - runtime-controller.infrastructure-manager.kyma-project.io/deletion-hook
  generation: 1
  labels:
    kyma-project.io/broker-plan-id: 4deee563-e5ec-4731-b9b1-53b42d855f0c
    kyma-project.io/broker-plan-name: azure
    kyma-project.io/controlled-by-provisioner: "false"
    kyma-project.io/global-account-id: e449f875-b5b2-4485-b7c0-98725c0571bf
    kyma-project.io/instance-id: d01b8790-03e6-497a-87a2-6a62ebc59f1f
    kyma-project.io/region: westeurope
    kyma-project.io/runtime-id: 00f6c848-60e4-49be-a2a5-d94d923d3e0e
    kyma-project.io/shoot-name: c-741831f
    kyma-project.io/subaccount-id: github-actions-keb-integration
    operator.kyma-project.io/kyma-name: 00f6c848-60e4-49be-a2a5-d94d923d3e0e
  name: maper-test-kim3
  namespace: kcp-system
  resourceVersion: "4041029997"
  uid: 67e6542a-2b5f-4ecb-8d71-a14df3ff1a60
spec:
  security:
    administrators:
    -<EMAIL_ADDRESS>    networking:
      filter:
        egress:
          enabled: false
        ingress:
          enabled: false
  shoot:
    controlPlane:
      highAvailability:
        failureTolerance:
          type: node
    kubernetes:
      kubeAPIServer:
        oidcConfig:
          clientID: 9bd05ed7-a930-44e6-8c79-e6defeb7dec9
          groupsClaim: groups
          issuerURL: https://kymatest.accounts400.ondemand.com
          signingAlgs:
          - RS256
          usernameClaim: sub
          usernamePrefix: '-'
      version: "1.29"
    name: c-bbbaaa
    networking:
      nodes: <IP_ADDRESS>/22
      pods: <IP_ADDRESS>/13
      services: <IP_ADDRESS>/13
      type: calico
    platformRegion: cf-eu10
    provider:
      type: azure
      workers:
      - machine:
          image:
            name: gardenlinux
            version: 1443.9.0
          type: Standard_D2s_v5
        maxSurge: 3
        maxUnavailable: 0
        maximum: 20
        minimum: 3
        name: w1
        volume:
          size: 50Gi
          type: Standard_LRS
        zones:
        - "1"
        - "3"
        - "2"
    purpose: production
    region: westeurope
    secretBindingName: sap-skr-dev-cust-00002-kyma-integration
status:
  conditions:
  - lastTransitionTime: "2024-08-13T10:50:15Z"
    message: Gardener API create error
    reason: GardenerErr
    status: "False"
    type: Provisioned
  state: Failed

but the shoot was created with a success!

We will investigate this case.

Another attempts fail with messages
    message: 'Gardener API create error: shoots.core.gardener.cloud "bd0e0e5" already
      exists'

    message: 'Gardener API create error: shoots.core.gardener.cloud "ad0e0e5" already
      exists'

The first attempt was with shoot name generated during E2E tests.
The latter was by changing shoot name in previously created Runtime CR - so there is extremely high probability the shoot name was not used before.

The issues described above were caused by the following:

shoot.provider.workers.volume.size has incorrect value ("50" instead "50Gi")
shoot.provider.workers.name property is missing
shoot.provider.networking.type property is missing
shoot.provider.workers.machine.image object must be provided

The problem number 1 is caused by the lack of validations. Here is the following ticket: #229 that will be addressed at some point.
Problems number 2, 3 and 4 must be addressed in KIM. shoot.provider.networking.type default value should be set in the configuration. For the time being you can refer to this PR to see what Runtime CR should currently be passed.

Problem 1 is resolved in KEB PR , currently we use always the same unit Gi but it is added to volume size.

After manually changing shoot name again, for a few secs we have state Pending then we got:
  conditions:
  - lastTransitionTime: "2024-08-19T10:38:33Z"
    message: 'Gardener API create error: shoots.core.gardener.cloud "badcafe00" already
      exists'
    reason: GardenerErr
    status: "False"
    type: Provisioned

Test for preview plan on DEV - cryptic error message:
status:
  conditions:
  - lastTransitionTime: "2024-08-20T02:10:48Z"
    message: Gardener API create error
    reason: GardenerErr
    status: "False"
    type: Provisioned
  state: Failed

Entire Runtime CR:
apiVersion: infrastructuremanager.kyma-project.io/v1
kind: Runtime
metadata:
  creationTimestamp: "2024-08-20T02:10:32Z"
  finalizers:
  - runtime-controller.infrastructure-manager.kyma-project.io/deletion-hook
  generation: 1
  labels:
    kyma-project.io/broker-plan-id: 5cb3d976-b85c-42ea-a636-79cadda109a9
    kyma-project.io/broker-plan-name: preview
    kyma-project.io/controlled-by-provisioner: "false"
    kyma-project.io/global-account-id: e449f875-b5b2-4485-b7c0-98725c0571bf
    kyma-project.io/instance-id: 8eaf1089-cabb-491d-914e-47e19aff1354
    kyma-project.io/region: eu-central-1
    kyma-project.io/runtime-id: aa2a9662-c997-4513-8e37-ab01fa729717
    kyma-project.io/shoot-name: f675a9d
    kyma-project.io/subaccount-id: github-actions-keb-integration
    operator.kyma-project.io/kyma-name: aa2a9662-c997-4513-8e37-ab01fa729717
  name: aa2a9662-c997-4513-8e37-ab01fa729717
  namespace: kcp-system
  resourceVersion: "4054093395"
  uid: dcb95cee-8436-4d8d-b46d-7c80ea10114b
spec:
  security:
    administrators:
    -<EMAIL_ADDRESS>    networking:
      filter:
        egress:
          enabled: true
        ingress:
          enabled: false
  shoot:
    controlPlane:
      highAvailability:
        failureTolerance:
          type: node
    kubernetes:
      kubeAPIServer:
        oidcConfig:
          clientID: 9bd05ed7-a930-44e6-8c79-e6defeb7dec9
          groupsClaim: groups
          issuerURL: https://kymatest.accounts400.ondemand.com
          signingAlgs:
          - RS256
          usernameClaim: sub
          usernamePrefix: '-'
      version: "1.29"
    name: f675a9d
    networking:
      nodes: <IP_ADDRESS>/22
      pods: <IP_ADDRESS>/13
      services: <IP_ADDRESS>/13
      type: calico
    platformRegion: cf-eu10
    provider:
      type: aws
      workers:
      - machine:
          image:
            name: gardenlinux
            version: 1443.9.0
          type: m6i.large
        maxSurge: 3
        maxUnavailable: 0
        maximum: 20
        minimum: 3
        name: cpu-worker-0
        volume:
          size: 50Gi
          type: gp2
        zones:
        - eu-central-1c
        - eu-central-1b
        - eu-central-1a
    purpose: production
    region: eu-central-1
    secretBindingName: sap-aws-skr-dev-cust-00002-kyma-integration
status:
  conditions:
  - lastTransitionTime: "2024-08-20T02:10:48Z"
    message: Gardener API create error
    reason: GardenerErr
    status: "False"
    type: Provisioned
  state: Failed

After manually changing shoot name again, for a few secs we had state Pending then we got:
  conditions:
  - lastTransitionTime: "2024-08-19T10:38:33Z"
    message: 'Gardener API create error: shoots.core.gardener.cloud "badcafe00" already
      exists'
    reason: GardenerErr
    status: "False"
    type: Provisioned

It should be fixed by the following PR: https://github.com/kyma-project/infrastructure-manager/pull/350 .

Provisioning of preview plan fails again.
status:
  conditions:
  - lastTransitionTime: "2024-08-22T02:11:10Z"
    message: Gardener API create error
    reason: GardenerErr
    status: "False"
    type: Provisioned
  state: Failed

I managed to reproduce the error using the Runtime CR from @jaroslaw-pieszka last failed attempt. I didn't manage to find what is the reason of the failure yet. Sharing the status from the broken shoot.
status:
  conditions:
    - type: APIServerAvailable
      status: 'True'
      lastTransitionTime: '2024-08-23T14:29:18Z'
      lastUpdateTime: '2024-08-23T14:29:18Z'
      reason: HealthzRequestSucceeded
      message: API server /healthz endpoint responded with success status code.
    - type: ControlPlaneHealthy
      status: Progressing
      lastTransitionTime: '2024-08-23T15:11:28Z'
      lastUpdateTime: '2024-08-23T14:54:24Z'
      reason: ControlPlaneUnhealthyReport
      message: >-
        ControlPlane extension (shoot--kyma-dev--md-kim03/md-kim03) reports
        failing health check: deployment "aws-custom-route-controller" in
        namespace "shoot--kyma-dev--md-kim03" is unhealthy: condition
        "Available" has invalid status False (expected True) due to
        MinimumReplicasUnavailable: Deployment does not have minimum
        availability.
    - type: ObservabilityComponentsHealthy
      status: Progressing
      lastTransitionTime: '2024-08-23T15:08:27Z'
      lastUpdateTime: '2024-08-23T14:23:17Z'
      reason: DeploymentMissing
      message: 'Missing required deployments: [kube-state-metrics]'
    - type: EveryNodeReady
      status: Progressing
      lastTransitionTime: '2024-08-23T15:09:28Z'
      lastUpdateTime: '2024-08-23T15:10:28Z'
      reason: WorkerUnhealthyReport
      message: >-
        Worker extension (shoot--kyma-dev--md-kim03/md-kim03) reports failing
        health check: machine
        "shoot--kyma-dev--md-kim03-cpu-worker-0-z1-6f484-8qp6j" failed: Machine
        shoot--kyma-dev--md-kim03-cpu-worker-0-z1-6f484-8qp6j failed to join the
        cluster in 20m0s minutes.
    - type: SystemComponentsHealthy
      status: Progressing
      lastTransitionTime: '2024-08-23T15:11:28Z'
      lastUpdateTime: '2024-08-23T15:12:28Z'
      reason: DeploymentUnhealthy
      message: >-
        Deployment "kube-system/blackbox-exporter" is unhealthy: condition
        "Available" has invalid status False (expected True) due to
        MinimumReplicasUnavailable: Deployment does not have minimum
        availability.
  constraints:
    - type: HibernationPossible
      status: 'True'
      lastTransitionTime: '2024-08-23T14:29:18Z'
      lastUpdateTime: '2024-08-23T14:29:18Z'
      reason: NoProblematicWebhooks
      message: All webhooks are properly configured.
    - type: MaintenancePreconditionsSatisfied
      status: 'True'
      lastTransitionTime: '2024-08-23T14:29:18Z'
      lastUpdateTime: '2024-08-23T14:29:18Z'
      reason: NoProblematicWebhooks
      message: All webhooks are properly configured.
  gardener:
    id: prjl5geENMygoz0C5Il9bTglCe0SvgTqsSaTW36IstsjzDBMltENb3m8EFhhN1et
    name: gardenlet-6c8d99b9d9-zn5ph
    version: v1.101.2
  hibernated: false
  lastOperation:
    description: >-
      Flow "Shoot cluster reconciliation" encountered task errors: [task
      "Waiting until shoot worker nodes have been reconciled" failed: Error
      while waiting for Worker shoot--kyma-dev--md-kim03/md-kim03 to become
      ready: error during reconciliation: Error reconciling Worker: failed while
      waiting for all machine deployments to be ready: machine(s) failed: 1
      error occurred: "shoot--kyma-dev--md-kim03-cpu-worker-0-z1-6f484-c6ktl":
      Machine shoot--kyma-dev--md-kim03-cpu-worker-0-z1-6f484-c6ktl failed to
      join the cluster in 20m0s minutes.] Operation will be retried.
    lastUpdateTime: '2024-08-23T15:09:03Z'
    progress: 89
    state: Error
    type: Create
  lastErrors:
    - description: >-
        task "Waiting until shoot worker nodes have been reconciled" failed:
        Error while waiting for Worker shoot--kyma-dev--md-kim03/md-kim03 to
        become ready: error during reconciliation: Error reconciling Worker:
        failed while waiting for all machine deployments to be ready: machine(s)
        failed: 1 error occurred:
        "shoot--kyma-dev--md-kim03-cpu-worker-0-z1-6f484-c6ktl": Machine
        shoot--kyma-dev--md-kim03-cpu-worker-0-z1-6f484-c6ktl failed to join the
        cluster in 20m0s minutes.
      taskID: Waiting until shoot worker nodes have been reconciled
      lastUpdateTime: '2024-08-23T15:09:03Z'

@jaroslaw-pieszka could you double check if it can be related to regions & zones configuration? I've been creating clusters with different tiny changes and made this working by changing region to region: eu-central-1 and by setting zones to:
    zones:
    - eu-central-1a
    - eu-central-1b
    - eu-central-1c

Attaching the runtimeCR that has worked for me and the failing one before the modification mentioned above
jareksruntimepending_modified44_working.txt
jareksruntimepending_modified3_not_working.txt

The issue with eu-west-2 was fixed.
I've now tried to reproduce the issue @jaroslaw-pieszka had with this Runtime CR and @piotrmiskiewicz had with this Runtime CR and both clusters were successfully created. However, neither of those examples is related to the recently broken eu-west-2 region.
@piotrmiskiewicz, @jaroslaw-pieszka - could you try again?

currently KEB is able to create Runtime which becomes Ready (in few minutes)


Added end-to-end integration test for the BacktestTradingSession. Che…

…cks for correct transaction history, rebalance orders and final market values.

Coverage increased (+27.09%) to 75.362% when pulling fce3df92f62e952fbb2a1c93604ad94208633455 on e2e-int-test into c17c2cb4eea82a51adb6f6ddb8a8b1db544bc9f9 on development.


Is the Authorize attribute needed in Razor Pages? What about Roles, Claims and Policies?

I am pretty much confused as to how Authorization/Authentication would now work in Razor Pages. What if you want to set the equivalent of MVC [Authorize(Policy = "AtLeast21")] in Razor Pages? It seems to me that the docs about Claims, Role-based policies semantics dot not exactly apply in Razor Pages anymore, is that correct? Thanks!

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

ID: f3a49eaa-a2ee-baac-e614-5e2f7c74072a
Version Independent ID: 09513dc8-546a-ea10-9f0b-cde361127647
Content: Razor Pages authorization conventions in ASP.NET Core
Content Source: aspnetcore/security/authorization/razor-pages-authorization.md
Service: asp.net-core
GitHub Login: @guardrex
Microsoft Alias: riande

@Ponant The [Authorize] filter attribute has been supported since 2.0 in Razor Pages, but note that it works at the page model class level: https://docs.microsoft.com/aspnet/core/mvc/razor-pages/filter?view=aspnetcore-2.1&viewFallbackFrom=aspnetcore-2.0#authorize-filter-attribute
There's a line in the Filters for RP topic at that top that explains ...

Razor Page filters are similar to ASP.NET Core MVC action filters, except they can't be applied to individual page handler methods.

I looked to see if there was an issue open discussing supporting a scenario where filters could be applied to individual page handler methods, but I don't see one. You can ask the engineers by opening an issue in the MVC repo: https://github.com/aspnet/Mvc/issues. If you do, please cc/ me on it, so I can see what they say.

better alternative to transcribe [Authorize(Policy="AtLeast21")] in the new Razor Page?

You should be able to put that on a page model class. It will apply the policy to ALL handlers for that page.

AuthorizePage?

Yes, that's right. There's an overload that will allow you to specify a policy ...
https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.dependencyinjection.pageconventioncollectionextensions.authorizepage?view=aspnetcore-2.1#Microsoft_Extensions_DependencyInjection_PageConventionCollectionExtensions_AuthorizePage_Microsoft_AspNetCore_Mvc_ApplicationModels_PageConventionCollection_System_String_System_String_
Tell you what ... I'm going to add an example of that to the topic. Right now, there's just this one line there. It's a good idea to add a quick example in the text. I'll use this issue to track the work, and I'll get to it within a couple of weeks (we're crazy busy at the moment with 2.1 work).

what would become services.AddAuthorization(options => { options.AddPolicy("AtLeast21", policy => policy.Requirements.Add(new MinimumAgeRequirement(21))); });

AFAIK, yes. That should work. If it doesn't work, ping me back, and I'll take a closer look (it's been a while since I've played with putting a policy on the AddAuthorization extension method). However, I think what you show is correct.

@guardrex , ok I will try it out but my question was to be able to go through my code as I am porting things to Razor Pages.
In the meantime, yes I think I think the docs could be updated, examples are much better than a sentence :) .
I think you could see with @blowdart if there is no need for an update on
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims?view=aspnetcore-2.1
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-2.1
and also roles and resource-based policies. All these docs use as an example traditional MVC, so dropping a few lines of code of equivalent-or-superior razor page framework would really help, or in the worst case some bold statement to explain to the reader that this also applies to Razor Pages but that the code is not shown.

It does sound like there's a doc update needed, either a page for traditional MVC and one for Razor Pages, or mix them into one (which might confuse people)

@blowdart , I learned pretty much all I needed from your single Workshop 2.0, but it was all traditional MVC. The equivalent for RazorPages would just perfect for many people I think. I looked up if you talked about razor pages and security, but nothing so far.

For me that's kind of on purpose for a couple of reasons,

More people are using MVC so it reaches more
It's easier to demo, because it's attributes, and no hopping back to config to add rules.

need for an update on ...

It does sound like there's a doc update needed, either a page for traditional MVC and one for Razor Pages, or mix them into one (which might confuse people)

I'll take a look when I get to this, but the updates for this issue will be for the RP conventions topic. When I see where more work is needed (e.g., Security TOC area), then I'll open one or more new issues for that. That work will probably fall to another author.
I should be able to look at this in a few weeks. Sorry for the delay, but I'm slammed at the moment.

I totally agree with your points @blowdart , at the same time it seems that Razor Pages will be cleaner in the long run. As a side note, let me say that this AddDefaultIdentity really sucks (sorry for the team). Here in Europe GDPR is ruling and you cannot just take an identity library without knowing what is inside. And it is pretty much likely you will have to override it. Scafolding did not help much. And AddIdentity seems an outsider.

Yea, GDPR is painful, we're balancing ease of use, with helping you meet your obligations. 2.1 will see enhancements, around cookies and download/delete

Yes I have seen already 2.1 and I am working on it to port an app from 1.0 that we have been building. That is great that you did this, really. Now, GDPR I know quite a bit about it because I have to, and I can see that I agree with a lot of their requirements. Also, I will bet a beer that you will have a similar thing in the US (see the Facebook discussion a few weeks ago at Congress etc).
Regarding you last paragraph and as far as I can see, my understanding of GDPR and for reading the Azure docs on the matter is that GDPR will be a shared responsibility. So I see two reasons why I think it is better to offer a VS experience project template that reveals most of the code from the outset (as it used to be). The first reason is that, in my opinion, 80 devs out of 100 will likely make changes, even minor but they will have to scaffold, so make life easier for them and they can pack to a lib if they want latter. The second reason is that GDPR is not only about what the db contains, but also how you protect the data. The prime example relevant for this discussion is how you set password policies, how set set sign in. Here the practice is to confirm email prior to entering the website. Another practice that will boom in the future is following the NIST recommendation and anyone who does some math would agree with the, the idea of upper case letters+some non alphanumeric one to create pwds is just ridiculous. It is in general better to set long paraphrases. I assume these things can be changed but my point is that it is less direct with this default UI stuff.
If for instance users complain that you are not checking email upon registration can bring you up a fine. I am happy to help if need be.

There's another balancing act here. GDPR is more than just code, as I know you're aware. But most developers aren't. We can't and won't say "This makes your site GDPR compliant", because that's utterly false. You have to make decisions specifically for your own use case.  Which I can't do automatically.
But this is a conversation that should happen down a pub. With an expensed bar bill :)

Of course you cannot say this, but the picture is that you kind of offer a car whereas they (will) need the spare parts as far as they want to have a public or corporate facing website. Trump will pay for the beer!

@Ponant have you seen Create an ASP.NET Core app with user data protected by authorization

@Rick-Anderson thanks, I remember having seen the old traditional MVC example, so this will help.

@joeruder We recommend ASP.NET Core Identity. It's fully featured and well supported by our documentation and sample apps. The docs kick off the coverage with Introduction to Identity.
WRT to your specific questions ...
'Yes' on the template. You'll see that there is app template identity configuration built-in to the dotnet new command and templates available in Visual Studio to help you set up and configure ASP.NET Core Identity. See the Security docs for more info, and more info on the dotnet new command is over at: https://docs.microsoft.com/dotnet/core/tools/dotnet-new
RE: Assigned passwords ... Any approach or configuration that has significant risk isn't recommended or supported by MS. Every practice pertaining to password management that's supported and recommended is covered by the docs. AFAIK none of the supported password management strategies allow the assignment of passwords; however, I'll defer to the security experts here ... and none other than THE @blowdart 🎯 is listening!

Yes you'd use register as a template, no we wouldn't really recommend it, if only because we don't have password expiration, so you can't force a change on first login

@joeruder Use ASP.NET Core Identity like @guardrex mentions.
To manually create the users: adapt code from the Registration page.
For passwords: Create the users with random passwords. Adapt code from the Account/ForgotPassword page to send users an email with a token in the url that when clicked will take them to the Account/Manage/SetPassword page.


why use enwiki8 as the test set for wikitext 103?

Dear authors,
This script transformer-xl/tf/scripts/wt103_base_gpu.sh use enwiki8 as the test data, is it correct?

Sorry it's a typo. We will fix it soon.


Cleanup: remove .travis.yml since it is unused

AFAICT, travis hasn't been disabled for the grpc/grpc repository a long time ago.
https://travis-ci.org/github/grpc/grpc
https://travis-ci.com/github/grpc/grpc
I'm happy to be proven wrong if travis is still being used, but if not, we should delete the travis config to avoid confusing people (I've seen some recently open PRs attempting to make modification to this file).

Since we were only using travis to test grpc-objc, @HannahShiSFB  and @sampajano to confirm that travis.yml is no longer needed.

I'm not sure with this one, it's beyond my knowledge. I think it's only CI related, and I trust your judgement as a CI expert:)
@jtattermusch

Thanks!!

travis hasn't been disabled for the grpc/grpc repository a long time ago

You meant travis *has been disabled, right?

Yes, typo.


How can I stop partial word matches for verse fragment references?

I'm processing the entire text of books (in Markdown format) through this parser to normalize reference formats. I just ran into a couple cases like this:

Pavlus, Efes. 5:18-6:9’un benzeri olan Kol. 3:16-4:1 bölümlerinde “Mesih’in sözü bütün zenginliğiyle imanlıların içinde yaşarsa”, bu kişilerin aynı şekilde mezmurlar, ruhsal ezgiler ve ilahiler söyleyeceğini belirtmektedir.

This is turning up a match for Eph.5.18-Eph.6.9,Col.3.16-Col.4.1 as expected, but the matched string is off. If you extract the original string between the indices for the second match, the match that comes back actually includes the first letter of the text word:
Kol. 3:16-4:1 b

This is trouble because when I go to replace that bit of the string I'm replacing what I get back from the formatter after giving it the OSIS is a properly formatted reference:
 Koloseliler 3:16—4:1

All is well except that the next word bölümlerinde has just become ölümlerinde.
How do I keep the ability to match fragment references in the language settings yet not have it be so greedy? Shouldn't the $AB [b-e] var be matched with a word boundary restriction at the end?

This appears to be a problem with the $CHAPTER variable, not $TO like I was expecting. An entry for bö. seems like the likely culprit in this case.

Yes, the \w probably isn't adequate for your needs here since it won't match the ö: https://github.com/alerque/Bible-Passage-Reference-Parser/blob/master/src/tr/regexps.coffee#L23
As a workaround, you could potentially use the pre_book regexp on line 37 of that file instead of \w.

Aaa, I see what you mean. On the other hand why are we using (?!\w) here (a negative look ahead for a word character) rather than (?=\W) (a positive look ahead for a non-word character) or better yet, just \b to match on a word boundary? Wouldn't that avoid this scenario?

In Javascript, I believe \w, \W, and \b are all ascii-based and would produce equivalent results, wouldn't they? /b\b/ would still match the "b" in "bö".

I believe \w, \W, and \b are all ascii-based and would produce equivalent results, wouldn't they?

Empirical testing says yes, they would.
I still haven't figured out what can go there though. Even that giant class as suggested isn't doing the trick.

What about:
| [b-e] (?! [\wö] )

To solve the immediate problem...

It looks like that expression isn't even the issue. It's matching b[öo] with no look-ahead at all earlier in the expression. Even removing the $AB bit entirely doesn't help.

OK, then here's the next step: https://github.com/alerque/Bible-Passage-Reference-Parser/blob/master/src/tr/grammar.pegjs#L135
Adding ö to the ![a-z] on that line should prevent the grammar from picking it up.


[BUG] Setting manual focus does not always work.

Describe the bug
Manual focus setter does not always work.
With the exact same code and settings, sometimes the focus is set to the desired value (130) and sometimes to 0. The behavior seems to change more frequently if I disconnect and reconnect the device, or if I set/unset the autofocus. The behavior also changes when I leave the device inactive for some minutes.
I managed to reproduce this behavior with two different devices, connected to two different computers. I also tried to change the USB port.
Sometimes I also notice an abrupt change in focal length during the acquisition of the first frames, even though the autofocus is disabled and the manual focus is set to 130. After this abrupt change, the focus sets either to 0 or to the desired value.
To Reproduce
I am currently using the following pipeline. At the end of it I set the autofocus to OFF and manual focus to 130.
pipeline = dai.Pipeline()

# RGB (center) Camera
center_camera = pipeline.createColorCamera()
center_camera.setPreviewSize(1280, 800)
center_camera.setBoardSocket(dai.CameraBoardSocket.RGB)
center_camera.setResolution(dai.ColorCameraProperties.SensorResolution.THE_1080_P)
center_camera.setInterleaved(True)
center_camera.setColorOrder(dai.ColorCameraProperties.ColorOrder.RGB)

# left camera
left_camera = pipeline.createMonoCamera()
left_camera.setResolution(dai.MonoCameraProperties.SensorResolution.THE_800_P)
left_camera.setBoardSocket(dai.CameraBoardSocket.LEFT)

# right camera
right_camera = pipeline.createMonoCamera()
right_camera.setResolution(dai.MonoCameraProperties.SensorResolution.THE_800_P)
right_camera.setBoardSocket(dai.CameraBoardSocket.RIGHT)

# center stream
center_stream = pipeline.createXLinkOut()
center_stream.setStreamName("center")
center_camera.preview.link(center_stream.input)

# left stream
left_stream = pipeline.createXLinkOut()
left_stream.setStreamName("left")
left_camera.out.link(left_stream.input)

# right stream
right_stream = pipeline.createXLinkOut()
right_stream.setStreamName("right")
right_camera.out.link(right_stream.input)

# camera control
cam_control_in = pipeline.createXLinkIn()
cam_control_in.setStreamName("cam_control")
cam_control_in.out.link(center_camera.inputControl)

# device
device = dai.Device(pipeline, usb2Mode=False)
device.startPipeline()
device.setLogLevel(dai.LogLevel.DEBUG)

# set focus
q_control = device.getInputQueue(name="cam_control")
cam_control = dai.CameraControl()
cam_control.setManualFocus(130)
cam_control.setAutoFocusMode(dai.RawCameraControl.AutoFocusMode.OFF)
q_control.send(cam_control)

Expected behavior
Camera focus should be set to the same length every time I run the script.
Screenshots
Running the script - this time it set the focus to 130.

Running the exact same script again - this time the focus is wrong.

Yeah, we noticed that as well with autofocus initially enabled, sometimes it needs more than one set command to get to take effect. It's some bug on the FW side.
For now, could you set manual focus initially at pipeline creation time, this should fix that behavior. Like:
center_camera.initialControl.setManualFocus(130)

# This may be redundant when setManualFocus is used
center_camera.initialControl.setAutoFocusMode(dai.RawCameraControl.AutoFocusMode.OFF)

And if you want to set other types of controls at pipeline creation time, need to use the develop branch. We'll probably make a release as well next week, to include it in main.

Using initialControl instead of "camControl" input queue seems to fix the issue. Thank you.

I have now confirmed you can switch between auto-focus and manual lens control while pipeline is running.  However, when switching to manual focus, it often errors out and does not go to the correct lens position.  If I pause for 2 seconds, and send again, it will then go to the correct manual lens position.

We have a work-in-progress branch with a workaround for this issue:
https://github.com/luxonis/depthai-python/pull/336
https://github.com/luxonis/depthai-core/pull/191


Pets service requests to https://pets-v2.dev-apis.com not working. Can't run course applets that use them.

Requests like https://pets-v2.dev-apis.com/breeds?animal=cat are responding with 403s.

Thanks for reporting. Yes, we're working on getting the API backup ASAP.

Thank you @dtauer. Really enjoying the courses, both intro and intermediate react.

IDK why I closed this, but it's still open.

It's back up and running!


Helm Operator missing ownerReferences for ClusterRole and ClusterRoleBinding

Type of question
For Helm Operator install, why is the ownerReferences set properly for deployments and services but not for clusterrole and clusterrolebinding? Is this the expected behavior? If I wish to, how do I add the ownerReferences to those resources?
Question
What did you do?
I created a helm operator which deploys clusterrole and clusterrolebinding.
$ operator-sdk new nginx-ingress-operator \
    --api-version=example.com/v1alpha1 \
    --kind=NginxIngress \
    --type=helm \
	--helm-chart stable/nginx-ingress
$ cd nginx-ingress-operator/
$ kubectl apply -f deploy/crds/example.com_nginxingresses_crd.yaml
$ kubectl apply -f deploy/crds/example.com_v1alpha1_nginxingress_cr.yaml
$ operator-sdk run --local

What did you expect to see?
When I looked at the clusterrole, it doesn't have the ownerReferences
$ kubectl get clusterrole/example-nginxingress-nginx-ingress -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2020-03-26T19:48:02Z"
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.29.5
    heritage: Helm
    release: example-nginxingress
  name: example-nginxingress-nginx-ingress
  resourceVersion: "529"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/example-nginxingress-nginx-ingress
  uid: f0e53286-59d0-4eff-92c3-49af9325eeb7
rules:
- apiGroups:
  - ""

What did you see instead? Under which circumstances?
When I looked at deployment, I see the ownerReferences
$ kubectl get deployments/example-nginxingress-nginx-ingress-controller -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  ...
  ownerReferences:
  - apiVersion: example.com/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: NginxIngress
    name: example-nginxingress
    uid: 6f4fd985-9f61-43db-a5b6-75de20bfec11
  resourceVersion: "708"
  selfLink: /apis/apps/v1/namespaces/default/deployments/example-nginxingress-nginx-ingress-controller
  uid: 053e56ba-0b95-4dac-bf66-1c615c5199ef

Environment

operator-sdk version:

$ operator-sdk version
operator-sdk version: "v0.16.0-dirty", commit: "55f1446c5f472e7d8e308dcdf36d0d7fc44fc4fd", go version: "go1.13.8 linux/amd64"

Kubernetes version information:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:20:10Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.4", GitCommit:"224be7bdce5a9dd0c2fd0d46b83865648e2fe0ba", GitTreeState:"clean", BuildDate:"2020-01-14T01:25:43Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes cluster kind:
KIND

$ kind version
kind v0.7.0 go1.13.6 linux/amd64

Additional context
Many thanks.

Kubernetes does not allow namespace-scoped resources to own cluster-scoped resources, so the helm operator has a check that prevents adding those invalid owner references.
Is the lack of owner references on those cluster-scoped resources causing a problem?

Thanks Joe for the quick reply.
In some cases, removing the finalizer then deleting the helm operator resource might leave behind some orphans like clusterrole because it doesn't have the ownerReferences so it doesn't get garbage collected.
I guess this is the expected behavior. Manually removing the finalizer means some manual cleanup operations should be done afterwards.
Thanks again, please feel free to close the issue if there is nothing that needs to be done here.

I guess this is the expected behavior. Manually removing the finalizer means some manual cleanup operations should be done afterwards.

That's correct. From a cleanup perspective, the finalizer will ensure that all release resources are removed.
Right now, I'm pretty sure the release secret ALSO does not have an owner reference, so that would be orphaned as well.

One other thing I'm curious about though: the helm-operator sets up watches for the resources that are created in a release. So for example, if the nginx-ingress deployment is manually edited, the operator will detect the change and reconcile it so that it is re-aligned with the release manifest.
Thinking about this, I'm now questioning if the same reconciliation works for release resources that are cluster scoped. Would you mind verifying what happens when you manually edit both a namespace-scoped and cluster-scoped resource that has been deployed by the operator? My hunch is that the namespace-scoped resource will be reset but the cluster-scoped resource won't.

Thinking about this, I'm now questioning if the same reconciliation works for release resources that are cluster scoped. Would you mind verifying what happens when you manually edit both a namespace-scoped and cluster-scoped resource that has been deployed by the operator? My hunch is that the namespace-scoped resource will be reset but the cluster-scoped resource won't.

The namespace-scoped resource did reset.
When I edit the deployment and change the port to 8080 it reverted back to 80
In
          name: nginx-ingress-controller
          ports:
          - containerPort: 80

The cluster-scoped resource did not reset as you predicted.
When I edit the clusterrole,
  verbs:
  - list
  - watch

Added a get and it persisted.
  verbs:
  - get
  - list
  - watch

https://github.com/operator-framework/operator-sdk/blob/v0.16.0/pkg/helm/controller/controller.go#L146
It seems like not watching the cluster scope resources are intentional.

It is, but since we already have a finalizer that runs helm uninstall I think we should theoretically be able to remove that constraint and setup watches on the cluster-scoped resources without relying on owner references.
For example, we may be able to use the EnqueueRequestForAnnotation handler in these cases.

/assign

@mikeshng
Trying to reproduce the issue, to confirm you used kubectl edit to edit the  resources(deployment, and ClusterRole) ?

@mikeshng
Trying to reproduce the issue, to confirm you used kubectl edit to manually edit the resources(deployment, and ClusterRole) ?

It was a while ago, but I am sure it was either kubectl edit or oc edit


[benchmark] BenchmarkDriver check --markdown

Added --markdown flag for the check command to output the BenchmarkDoctor’s report in the Markdown format (as used by swift-ci on GitHub).

@swift-ci benchmark

Build comment file:

It does not. I started a benchmark run

@swift-ci benchmark

And, as it's not a compiler change, it's sufficient if you do a smoke test for this.

Hmm… I ran full test, because I wanted CI to run through bencmark's lit tests, which are not executed during smoke test. Can we at least make those run in smoke, do that I don't need to invoke full test for that reason?

They should run with smoke test, because they are in swift/test. But maybe I'm missing something here.

I think smoke test doesn't build benchmark binaries for some reason. The python tests for benchmark scriptd get executed, but not the Benchmark_O.test.md and Benchmark_Driver.test-sh because they both have REQUIRES: benchmark in them.

But none of them would have caught this bug…😔
I can fix the test to catch that. I just don't add the markdown to args stub, to maintain original API.
It didn't occur to me I need to adjust run_smoke_bench when I've modified the ArgsStub to make the other test's pass...

Build comment file:
Performance: -O

TEST
OLD
NEW
DELTA
RATIO

Regression

ObjectiveCBridgeFromNSArrayAnyObjectToString
47109
53458
+13.5%
0.88x

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

--------------

@eeckstein Can we make smoke test build the benchmark binary?
(I don't know how to make that change...)

That needs negotiation with @shahmishal. We are trying very hard to keep the smoke test time down to a minimum.

@palimondo / @eeckstein How much extra time are we looking at building benchmark binary?

When we just build a single executable, e.g. Benchmark_O (and not the Osize and Onone variants), it's about 5min user time on my machine. + 4 sec to run it (what we should do, because this gives more test coverage)

Really don't know. I'm running my local builds on 2008 MBP…


GD-05: Report shows wrong line number when code is multiline formatted

The used Godot version:
Godot 3.2.1
OS including version:
Windows 10 and MacOS
Describe the bug
When i use multiline formatted code and an assertion reports an failure than the error line is wrong.
Double click jumps to wrong line.
Steps to Reproduce

create a test like this

func test_error_line_number_multiline():
	assert_int(10)\
		.is_not_zero()\
		.is_equal(20)

Run the test
Check the GdUnit inspector for report

The failure report shows the line 25 but the error occurs on line 27

** Node **
This is an godot script get_stack() bug and already reported to godot https://github.com/godotengine/godot/issues/43326

Closed as Godot related issue. godotengine/godot#43326
There is current no workaround to fix this.


NTR: children of abnormal erythrocyte physiology

Proposed new hierarchy
MP:0003656 abnormal erythrocyte physiology
-i-MP:NEW abnormal erythrocyte agglutinability
-i-MP:NEW high erythrocyte agglutinability
-i-MP:NEW low erythrocyte agglutinability
MP:NEW abnormal erythrocyte agglutinability
Def: an anomaly in the ability of red cells to be aggregated or clump
Source: PMID: 4810935
MP:NEW high erythrocyte agglutin ability
Def: greater ability of red cells to be aggregated or clump
Source: PMID: 4810935
MP:NEW low erythrocyte agglutin ability
Def: reduced ability of red cells to be aggregated or clump
Source: PMID: 4810935
Reported by: nicolevasilevsky
Original Ticket: obo/mammalian-phenotype-requests/1757

added terms for abnormal/increased/decreased erythrocyte aggregation - MP:0020453/MP:0020455/MP:0020454
used aggregation rather than agglutinability as this matches the GO term name


Issue with Re-commissioning Thread Devices Using Matter Example Code - Error CHIP:0x000000AC (CON-1319)

<0x1b>[0;32mI (31856) chip[EM]: >>> [E:2397i S:16172 M:231697154] (S) Msg RX from  node 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)<0x1b>[0m
<0x1b>[0;32mI (31876) chip[DMG]: Received Command Response Data, Endpoint=0 Cluster=0x0000_0031 Command=0x0000_0005<0x1b>[0m
<0x1b>[0;32mI (31886) chip[CTL]: Received NetworkConfig response, networkingStatus=1<0x1b>[0m
<0x1b>[0;31mE (31886) chip[CTL]: Error on commissioning step 'ThreadNetworkSetup': 'Error CHIP:0x000000AC'<0x1b>[0m
<0x1b>[0;32mI (31896) chip[CTL]: Going from commissioning step 'ThreadNetworkSetup' with lastErr = 'Error CHIP:0x000000AC' -> 'Cleanup'<0x1b>[0m
<0x1b>[0;32mI (31916) chip[CTL]: Performing next commissioning step 'Cleanup' with completion status = 'Error CHIP:0x000000AC'<0x1b>[0m
<0x1b>[0;32mI (31926) chip[CTL]: Successfully finished commissioning step 'Cleanup'<0x1b>[0m
<0x1b>[0;32mI (31926) chip[CTL]: Commissioning complete for node ID 0x0000000000000001: Error CHIP:0x000000AC<0x1b>[0m
<0x1b>[0;32mI (31936) pairing_command: Device commissioning Failure: MatterError CHIP:0x000000AC<0x1b>[0m
After this error, if I erase the controller and re-commission, it works fine again, but the same issue occurs on the second attempt.

@vishnuprasadvp12345 Please provide details about how are you exactly trying to re-commission the device. I hope the flow is like -

Start to commission a Thread device using <Ecosystem phone app + Hub/ Chip tool + TBR>
Commissioning is successful
Then how do you start re-commissioning on the same device? Who opens the commissioning window? Which phone app is used?

I am closing this now. Please re-open with the details, if you are still facing the issue


android ui layout

https://blog.csdn.net/maniuT/article/details/134313775
onDescendantInvalidated
android barrier

https://blog.csdn.net/shulianghan/article/details/105994710


Switch from cloudpathlib to universal_pathlib

universal_pathlib is fsspec-based and manages more usecases (such as URLs) than cloudpathlib.
It would therefore be useful to switch from cloudpathlib to universal_pathlib when this library will be more stable (and comes with a proper documentation)
However this is a big change, so do it only for 2.0 verison.
In the meantime, prepare the code for the switch with:

[x] Creating an alias for AnyPath
[x] Don't import cloudpathlib outside of functions

Wait for :

https://github.com/fsspec/universal_pathlib/issues/223
https://github.com/fsspec/universal_pathlib/issues/193
https://github.com/fsspec/universal_pathlib/issues/309

The code is OK, see #33 for more insights (merged into 2.0.0 branch)

We are waiting for version 0.3.0 of upathlib to solve the issues mentioned in a precedent comment before any 2.0.0 release.

TODO - Adapt the following modules:

[ ] s3
[ ] unistra


The version you are using is the latest commit in master at the moment you pulled, because of the :latest tag. You can see what commit it is in the footer of any page in your instance.
To get latest-stable (1.7.4), you would use :1.
It would be interesting to see if you have the same issue in 1.7.4.
The git version can be seen in /admin/config.


Failed to open "complete a survey" form

HI Team,
Seems the form is in below statement is not exists anymore, could anyone help to check and fix the issue please? Thanks!
+++
Red Hat Enterprise Linux Images are a private offering on Azure Stack Hub. To make this offering available to your Marketplace Management tab, you will need to complete a survey. After you post the survey, it takes seven business days to see it in your Add from Azure tab within Marketplace Management.
+++
Regards,
Hailian Li

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

ID: dc31e147-b01d-ab0d-f97a-14ace2d658a8
Version Independent ID: 351862a1-a03f-61dd-e619-3af6562870ac
Content: Offer a Red Hat-based virtual machine for Azure Stack Hub - Azure Stack Hub
Content Source: azure-stack/operator/azure-stack-redhat-create-upload-vhd.md
Service: azure-stack
Sub-service: azure-stack-hub
GitHub Login: @sethmanheim
Microsoft Alias: sethm

@Lihailian
Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate.

@sethmanheim
Can you please check and add your comments on this doc update request as applicable.

#please-close

The survey link is back online- https://forms.office.com/r/F10XvmPLVw


[SPARK-30814][SQL] ALTER TABLE ... ADD COLUMN position should be able to reference columns being added

What changes were proposed in this pull request?

In ALTER TABLE, a column in ADD COLUMNS can depend on the position of a column that is just being added. For example, for a table with the following schema:
root:
  - a: string
  - b: long

, the following should work:
ALTER TABLE t ADD COLUMNS (x int AFTER a, y int AFTER x)

Currently, the above statement will throw an exception saying that AFTER x cannot be resolved, because x doesn't exist yet. This PR proposes to fix this issue.
Why are the changes needed?

To fix a bug described above.
Does this PR introduce any user-facing change?

Yes, now
ALTER TABLE t ADD COLUMNS (x int AFTER a, y int AFTER x)

works as expected.
How was this patch tested?

Added new tests

Test build #118443 has started for PR 27584 at commit fd383b3.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/23200/
Test PASSed.

cc @brkyvz @cloud-fan

Test build #118451 has started for PR 27584 at commit cadda78.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/23208/
Test PASSed.

Test build #118443 has finished for PR 27584 at commit fd383b3.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/118443/
Test PASSed.

Test build #118451 has finished for PR 27584 at commit cadda78.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/118451/
Test PASSed.

Test build #118544 has started for PR 27584 at commit 34b1363.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/23299/
Test PASSed.

Test build #118544 has finished for PR 27584 at commit 34b1363.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/118544/
Test FAILed.

retest this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/23308/
Test PASSed.

Test build #118556 has started for PR 27584 at commit 34b1363.

Test build #118556 has finished for PR 27584 at commit 34b1363.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/118556/
Test PASSed.

Test build #118599 has started for PR 27584 at commit 42d1c48.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/23352/
Test PASSed.

LGTM as well!

Test build #118599 has finished for PR 27584 at commit 42d1c48.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/118599/
Test PASSed.

thanks, merging to master/3.0!


Fix on enter in autocomplete component

This was fixed here:
https://github.com/ryanAllMad/js-job-helper/commit/ec426f3e6da4b304ec3800032101886a878a8b65


Update to GOV.UK 4.0.0

Combining into https://github.com/ministryofjustice/help-with-prison-visits-external/pull/748


adding more links to mobile card

Summary
Adding links to the mobile card on the .NET Azure hub to represent common tasks of creating Xamarin + Azure apps

#sign-off