model: fix edge case for Edm.DateTimeOffset.from_json() without offset

We were expecting that the offset part is mandatory and that the service should return /Date(1659430517461+0000)/ for offset set to UTC. Unable confirm in odata.org and W3C specifications, but some services (SAP included) works for this Edm type as if offset is not mandatory for the UTC timezone.
Now, if the offset part is missing in incoming JSON payload, it should work as if +0000 was provided.
FIXES #231

Codecov Report
Base: 92.34% // Head: 92.31% // Decreases project coverage by -0.02% :warning:

Coverage data is based on head (2865f22) compared to base (5d14908).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #232      +/-   ##
==========================================
- Coverage   92.34%   92.31%   -0.03%
==========================================
  Files           6        6
  Lines        2847     2849       +2
==========================================
+ Hits         2629     2630       +1
- Misses        218      219       +1

Impacted Files
Coverage Δ

pyodata/v2/model.py
93.29% <100.00%> (-0.05%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

LGTM


Antialias resets to true if you regain focus after losing.

I am passing false for the antialias parameter in Game. If you leave focus of the game and then come back it starts smoothing the sprites. If you run Phaser.Canvas.getSmoothingEnabled it will then return true. Am I supposed to be checking getSmoothingEnabled and calling setSmoothingEnabled in the update loop or is this a bug?

I can't replicate this at all, please provide a sample. Here is the test case I used to check this against the dev branch:

var transparent = false;
var antialias = false;

var game = new Phaser.Game(800, 600, Phaser.AUTO, 'phaser-example', this, transparent, antialias);

function preload() {

    game.load.image('girl', 'assets/pics/manga-girl.png');

}

function create() {

    game.stage.backgroundColor = '#0076a3';

    var sprite = game.add.sprite(32, -100, 'girl');
    sprite.scale.set(4);

}

function render () {

    game.debug.text("Anti-alias: " + game.antialias, 10, 32);

}

Isn't that the wrong flag to test? Shouldn't it be getSmoothingEnabled?
On Jul 8, 2015 9:09 AM, "Richard Davey"<EMAIL_ADDRESS>wrote:

Closed #1758 https://github.com/photonstorm/phaser/issues/1758.
—
Reply to this email directly or view it on GitHub
https://github.com/photonstorm/phaser/issues/1758#event-350757858.

I don't believe so, no - he said he was using the antialias parameter. getSmoothingEnabled will be 'undefined' if you use antialias. game.renderer.renderSession.smoothProperty is set correctly to imageSmoothingEnabled (on chrome at least). More over though, I cannot make a previously non-aliased game suddenly appear aliased just by swapping to another window and back again, so unless there is a test case that demonstrates the issue exactly I'm not entirely sure there is one.


BUG: Loading more communities causes refetching

Describe the bug

When pressing the View More button in the /communities page, all the communities are refetched causing a loading state
The order of the communities is changed

Reproducing the bug**

Go to the /communities page
Press View More

Expected behavior

The new communities should just be added to the existing ones

Screenshots

Platforms
All platforms
Additional context

Severity:

[ ] High (completely break the functionality and usability of the site)
[ ] Medium (significant disruption or degrade user experience)
[x] Low (only cause minor disruption keeping the site functional)

Fetching more communities excluding the currently loaded ones should fix it. Once the new communities are loaded, they can be concatenated with the list of the existing communities. Each time more communities are loaded, they are concatenated with the previous state.

Hi, I could try working on this one tomorrow

@alefDev-prog That would be great. I can fix it myself but I am doing other projects. I also left it to give people a chance to contribute.


Pull request to fix issue #66

The first bug https://github.com/edickie/ciftify/issues/66 reports was caused by a missing comma in setup.py. The second was caused by ciftify/io.py hiding python's built-in io.py script (breaking functions like 'open'). As a bonus, I also fixed an unrelated broken link :)

Oh right, I stopped part way through updating those because you said you didnt want it named that. Have you decided on a final name?

let's go with niio for "neuroimaing input output"..Looks like there's
nothing similar to that in PyPI...
On Wed, Jun 20, 2018 at 10:15 AM, Dawn E. Smith<EMAIL_ADDRESS>wrote:

Oh right, I stopped part way through updating those because you said you
didnt want it named that.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/edickie/ciftify/pull/67#issuecomment-398765143, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AMl59pDjxiTVRChgklOeCbApS-pKnHZVks5t-lkMgaJpZM4UuWoY
.

Ok, I've updated all the references to niio. Should be good now!


Autodetect SMTP port to connect to

summary-report.py currently has SMTP port hard coded.
There is already #3 to allow the user to specify the port via command line argument, this is an improvement over that issue.
Autodetect SMTP port by trying all the common ports one by one - 587, 465, 25. This should be done only if the user does not specify a port.
You might want to wait for #1 and #3 to be fixed and merged so that it becomes a bit easier to work on this.

I'll go ahead and give this a try, I suppose I'll wait for #1 to be finished before I go ahead.


Consult for how to include @property field or @hybird_property in api response list data of modeladmine

my SQLmodel have some caluated field which define by @propety , i want to include it in the model list api. response data.
Do you have any idea how to deal with it. My previous is to add it in the schema_list, but it always feedback null due to the framework logics.  If you have other idea to deal the issue, it would be appriaite..
Besides, SQLModel currently can not support sqlalchemy hybird_property, so it is not available before sqlmodel supports.

reference: https://github.com/amisadmin/fastapi-amis-admin/blob/120ddbcf9efcf7ab6f47eed2b38d75c0a9dbed27/tests/test_crud/test_SqlalchemyCrud_fields.py#L144


[Bug]: Login is broken on latest update

Is there an existing issue for this?

[X] I have searched the existing issues

Example public repository
coolify
Description

Latest auto-update broke the login (see screenshot)
I am unable to login into the dashboard (and reroll to a previous version)
Edit: This only seems to happen on auto-filled credentials (in this case icloud keychain or browser autofill, both won't work).
entering the credentials manually seems to work.
Steps To Reproduce

update to latest version (in my case auto-update)
Login

Version
3.12.8

Please close this, apparently it's a bug on icloud keychain extension. It just happened at the same time the latest coolify update rolled out - unlucky coincidence


PR: Migrate Console Plugin to new API

Description of Changes

[ ] Wrote at least one-line docstrings (for any new functions)
[ ] Added unit test(s) covering the changes (if testable)

[ ] Included a screenshot or animation (if affecting the UI, see Licecap)

Issue(s) Resolved

Fixes #
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct: @goanpeca

Hello @goanpeca! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file spyder/plugins/console/widgets/internalshell.py:

Line 297:80: E501 line too long (80 > 79 characters)

In the file spyder/plugins/console/widgets/main.py:

Line 99:36: E261 at least two spaces before inline comment
Line 109:1: W293 blank line contains whitespace
Line 133:79: W291 trailing whitespace
Line 143:43: W291 trailing whitespace
Line 196:33: E116 unexpected indentation (comment)
Line 197:33: E116 unexpected indentation (comment)
Line 216:79: W291 trailing whitespace
Line 231:1: W293 blank line contains whitespace
Line 250:79: W291 trailing whitespace
Line 323:1: W293 blank line contains whitespace
Line 330:1: W293 blank line contains whitespace
Line 350:1: W293 blank line contains whitespace
Line 368:26: E201 whitespace after '('
Line 368:48: E202 whitespace before ')'
Line 388:1: W293 blank line contains whitespace
Line 397:1: W293 blank line contains whitespace
Line 411:1: W293 blank line contains whitespace

In the file spyder/plugins/history/plugin.py:

Line 132:80: E501 line too long (81 > 79 characters)

In the file spyder/plugins/workingdirectory/plugin.py:

Line 139:80: E501 line too long (81 > 79 characters)

Hi @ccordoba12 addressed all the issues (except a couple I think) and made the rebase.

I checked most functionality and it's working fine. I only left a minor comment about the wrong tabified behavior of the internal console itself.

Fixed!
Thanks for the review!


Fix cluster scoped kustomizations + update e2e tests + add custom namespace kuttl test [K8SSAND-1137, K8SSAND-1159]

What this PR does:
Cluster scoped deployments currently fail due to a combination of factors:

Flaky kustomizations which aim to deploy a cluster-scoped cass-operator in the k8ssandra-operator repository. There are working cluster-scoped deployments in the cass-operator repo which we adopt in this PR.
Namespace creation for the k8ssandra-operator is set up as a component - this causes failures when the namespace is used as a source in replacements for ClusterRoleBindings which are created when cluster-scoping k8ssandra-operator. We are moving namespace creation into config/default (i.e. as a kustomization, not a component) because - given components applied last in the transformation pipeline - it otherwise can't be a source for the replacements in ClusterRoleBinding's subjects.
We are moving to always use a cluster-scoped cass-operator, because there is no reason to namespace scope it and this causes additional complexity.
The use of a namespace: ... transformation throughout the kustomizations and e2e tests is undesirable, because it errors when deploying cass-operator into a cass-operator NS due to namespace transformation conflicts. A more targeted approach is adopted, whereby we patch the namespace created in config/default and then use it as a replacement for metadata.namespace for all resources created in the k8ssandra-operator ns only.

With these issues fixed, the E2E tests needed to be updated to reflect the new structure. In particular:

We remove the use of the namespace transformer in all templates.
We remove the use of kustomize edit namespace type calls in all e2e tests.
We remove the use of the --namespace flag in all kubectl apply operations scripted from the e2e tests.
We centralise instead on the patch -> replace process described above to create e2e test namespaces and deploy resources to them.

Which issue(s) this PR fixes:
Fixes #285, #278
Checklist

[x] Changes manually tested
[x] Automated Tests added/updated
[ ] Documentation added/updated
[ ] CHANGELOG.md updated (not required for documentation PRs)
[ ] CLA Signed:  DataStax CLA

Tests currently failing

Run e2e tests / CreateSingleMedusa (Also fails on main)
Run multi-cluster e2e tests / CreateMultiMedusa (Also fails on main)
Run multi-cluster e2e tests / CheckStargateApisWithMultiDcCluster (Also fails on main)

From additional testing on main I can confirm that CreateSingleMedusa fails there too, and so does CheckStargateApisWithMultiDcCluster.
I am marking this ready for review as a result.

I have briefly started looking at the changes. Awesome that you have a solution for the namespace problem.

It has been a delicate operation but it does work.

We definitely do not want to always use a cluster-scoped cass-operator deployment. We need to support deploying both namespace-scoped and cluster-scoped.

We do support deploying a cluster scoped cass-operator, but the user needs to write their own kustomizations to deploy cass-operator first and then k8ssandra operator (having removed the cass-operator dependancy in the k8ssandra-operator kustomizations).
If you'd like a specific test or kustomization written for this use case please let me know how you'd like it to look and where you'd like it to appear.

This isn't acceptable approach. Most cass-operator users from my reports are using namespace scoped deployments, not cluster scoped. In cass-operator, all versions <= 1.7.1 are only shipped with namespace scoped deployment model, the user had to manually modify them to get cluster-scoped version.

Changing that approach upside-down would probably make some eyes roll.

@burmanm John and I have discussed this and I've agreed to reinstate the namespace scoping of cass-operator for the tests.
I usually advise folks against namespace scoping an operator unless they have a very well thought through rationale to justify doing so. But I would rather get this PR merged - so that at least users CAN cluster-scope k8ssandra operator - than waste time debating whether namespace or cluster scope should be the default.
@jsanda the changes you've requested have been made. As we've discussed offline, the ClusterScoped/MultiDcMultiCluster fails for a variety of reasons, not least Error: Artifact name is not valid: k8s-logs-ClusterScoped/MultiDcMultiCluster. Contains the following character:  Forward slash /.
I have also had to upgrade the kustomize version in use and remove the use of go-get-tool to build kustomize from source (in favour of downloading the binary artefact) because go-get-tool refuses to work.
Please let me know if you are now happy to approve this, I think that the tests should now pass (barring ClusterScoped/MultiDcMultiCluster and MultiDcAuthOnOff which I think are known-broken).

Oop, looks like MultiDcAuthOnOff does work now. Magic. So the only test failing is ClusterScoped/MultiDcMultiCluster.
I've added in another kuttl test to confirm that when k8ssandra-operator and cass-operator are cluster-scoped (and installed in namespaces k8ssandra-operator and cass-operator) a K8ssandraCluster deployment to a third NS will result in the expected StatefulSet being deployed.

Oh right. Now we have merge conflicts. I'll look into that.

@burmanm can you please pick up the review on this? Miles has been done with it. I just haven't been able to get back to it.

@jsanda I'm not sure if this will be done today now.
That rebase was a nightmare, but most tests are now working. However for some reason I now see failures on CreateMultiReaper to the effect of:
Messages:   	secret multi-dc-reaper-t7dwpb/reaper-cql-secret is not managed by test

This is the first I've seen of that error, so it must be due to a problem I've introduced while rebasing.
There are a few other areas where some other tests are failing. I'm scratching my head about some of them as they should not have been affected by any of the work I've done. I will continue to investigate.

E2E tests shouldn't have a difference in how they deploy these components compared to what we provide to our users. While we hope to maintain that they don't differ or that these patches are not necessary - our e2e tests can't actually verify that's the case.

When I first read this I hadn't looked at all of the latest changes. This led to some confusion on my part because I thought we are already doing this. Then I saw the changes in e2e_framework.go  that use kustomize patches to change the namespace . I agree with the above comment, and I also agree that in general that patches aren't generally how users will configure the namespace. They will use a namespace transform. We actually have an example for that in the install guide.
My confusion led to a follow up conversation with @burmanm. He suggested that it would be better to deploy both k8ssandra-operator and cass-operator in the same namespace. After some discussion I do agree for a couple reasons. First, it's easier for the user if we can deploy everything, or as much as possible (cert-manager is currently an exception), to the same namespace. cass-operator is an implementation detail. There are k8ssandra users who are unaware that there is this cass-operator component that is driving things. When I think about from that perspective, installing both operators in the same namespace makes a lot of sense. Secondly, for a namespace-scoped install we already install both of them into the same namespace. Installing both operators into the same namespace for a cluster-scoped deployment keeps things more consistent which is another plus.
With all that in mind I would like to do the following:

Change the kustomize code in e2e_framework.go back to use the namespace transform as it did previously
Revert back to keep the kustomize components

As the k8s docs mention components are useful for adding reusable pieces of configuration when you have optional features.

Change the kustomizations so that are not trying to deploy anything into the cass-operator namespace

@Miles-Garnsey I realize that this will result in some undo/redo/undo work. I apologize for that, but I think it is the best path forward.

Addressing some comments here:

E2E tests shouldn't have a difference in how they deploy these components compared to what we provide to our users. While we hope to maintain that they don't differ or that these patches are not necessary - our e2e tests can't actually verify that's the case.

@burmanm I do not understand this comment. The e2e tests are explicitly designed to randomise the namespace (presumably so they can be run in parallel?) so they have to differ from how the user deploys things. If anything, I've reduced the discrepancies between test/real deployments here by just adjusting the ns in one place instead of adjusting it in 3 different places as the original code did.
Please clarify.

I agree with the above comment, and I also agree that in general that patches aren't generally how users will configure the namespace. They will use a namespace transform. We actually have an example for that in the install guide.

@jsanda I've explicitly dealt with this issue in the original ticket.
I think the ticket addresses a lot of the ideas currently under discussion and explains why they are not tenable. But I will address your suggestions again here and link to my previous explanations.
Namespace transforms
If users attempt to use a NS transform (namespace:...) in the kustomize.yaml file as you propose, I believe they will get the same error that our own kustomizations are currently generating. I do not believe that this is an effective way to change the namespace where the upstream kustomizations have multiple namespaces, and if our install guide says otherwise, I suspect it is wrong.
I have also discussed this in the PR description here.
Please let me know if I'm missing something here, but I do not believe that this proposal will fly.
Kustomize components

Revert back to keep the kustomize components

Again, as discussed here, this will not work due to the order of transformation applied in the kustomize transformation pipeline.

As the k8s docs mention components are useful for adding reusable pieces of configuration when you have optional features.

I'm aware of the intended use of components, I believe I first recommended (private link, sorry to anyone who doesn't have access) using them. I recommend reading the detailed KEP for components in order to understand why using them in the current fashion will break the subject replacement on ClusterRoleBindings as discussed in the original ticket.

Change the kustomizations so that are not trying to deploy anything into the cass-operator namespace

This may be possible, but will be limiting to users who want to deploy cass-operator and k8ssandra-operator into different namespaces, as it is similar to removing a label. I don't recommend it and would like to address it in a separate PR, this one is becoming a magnet for off-topic discussion and I do not think enlarging it again is productive or helpful.

The exact problem is that you don't use namespace transformer. That's how we would tell our users to do it, that's how kustomize documentation says to use it. Not some replacements strategy, which works quite differently to what namespace transformer does.
Here we potentially mask an issue where user can't deploy the k8ssandra-operator since kustomize doesn't work correctly, yet our e2e tests pass fine - because they fix an issue. Especially if you just said "it doesn't work", then that's a crappy story.
And as said, we shouldn't use more than one namespace if possible. It's a hindrance to users not knowing how many namespaces they need to potentially request access to or why they would need more than one (why would they? I can't come up with any sane reason why it makes sense).

So let me propose a requirement and we can talk through the solution with that in mind.
Quite frankly we should have had this conversation sooner, and I'm sorry we didn't. This one snuck around the grooming discussions because I didn't realize it was bigger than a quick bug fix, we'll need to get better at that.
We want the operators to all be deployed to the same namespace and we do not need to support a scenario now where they can deployed in any other fashion.
How does that simplify the solution?
We need progress here, so let's looks for that simplification. With that definition what do you all think @jsanda @Miles-Garnsey @burmanm ?

If we deploy the operators to the same namespace, I think it could be as simple as this.

If we deploy the operators to the same namespace, I think it could be as simple as this.

As covered in the ticket and earlier comments, this solution produces the following error:
$ kustomize build config/deployments/control-plane/cluster-scope | kubectl apply -f -
Error from server (Invalid): error when creating "STDIN": ClusterRoleBinding.rbac.authorization.k8s.io "manager-rolebinding" is invalid: subjects[0].namespace: Required value

We want the operators to all be deployed to the same namespace and we do not need to support a scenario now where they can deployed in any other fashion.

@jdonenine thanks for clarifying that, it certainly would have been good to know at the outset.
The requirement on these tickets were:

Write a test to deploy a k8ssandraCluster into a namespace outside the operator's namespace.
(When it became clear this ^^ functionality was broken) Fix the cluster-scoped kustomizations.

Looking at the current deployments we have the following:
$kustomize build config/deployments/control-plane/cluster-scope | grep 'namespace: '
  namespace: cass-operator
  namespace: k8ssandra-operator
  namespace: cass-operator
  namespace: k8ssandra-operator
  namespace: cass-operator
  namespace: k8ssandra-operator
  namespace: cass-operator
  namespace: cass-operator
  namespace: k8ssandra-operator
  namespace: system
  namespace: k8ssandra-operator
  namespace: k8ssandra-operator
  namespace: cass-operator
  namespace: cass-operator
  namespace: k8ssandra-operator
  namespace: cass-operator
  namespace: cass-operator
  namespace: k8ssandra-operator
  namespace: cass-operator
  namespace: cass-operator
      namespace: cass-operator

We can see that currently, the cluster-scoped control-plane deployment deploys cass-operator into the cass-operator namespace. If this was something we wanted to change, that change was not in the original requirements.
I'm happy to look at that topic as a separate ticket, but I am keen to get this merged, since expanding scope at this point (when we don't have consensus on show stopping issues like this) seems like it risks wasting a lot of effort.

When we talked yesterday we were under the impression that in a namespace-scoped deployment everything went into k8ssandra-operator, it was that behavior that we wanted to be consistent with.
I guess it's safe to assume that's correct?  What you mentioned was for a cluster-scoped deployment, which right now we would assume to be a mixture.  But our working assumption was in that case that it could be pretty easily made to work in that fashion.
You mentioned the error that you get with the quick example @jsanda threw into a previous comment, obviously there's something missing from what he had there, but I don't know that it was meant to be a fully baked solution or not - I don't know that that error means that it can't be as minimal a change as proposed there or not I guess.

When we talked yesterday we were under the impression that in a namespace-scoped deployment everything went into k8ssandra-operator,

This is correct, in the existing (broken) cluster-scoped kustomizations, cass-operator goes into the cass-operator namespace.

I guess it's safe to assume that's correct? What you mentioned was for a cluster-scoped deployment, which right now we would assume to be a mixture. But our working assumption was in that case that it could be pretty easily made to work in that fashion.

You mentioned the error that you get with the quick example @jsanda threw into a previous comment, obviously there's something missing from what he had there, but I don't know that it was meant to be a fully baked solution or not - I don't know that that error means that it can't be as minimal a change as proposed there or not I guess.

I really want to move the conversation on that topic elsewhere because this PR has taken ~3 days of rebasing time already and is in its 4th major revision. I really advise against adding more to the scope right now given there are disagreements on other topics (e.g whether the namespace: transformation should even be used).
I don't know what the intention of that code sample was, I can get into detail explaining that when you are using the namespace:  transform you need to take special care over the ClusterRolebinding's subject namespace because it sometimes isn't correctly patched. This applies even moreso when you are patching it from a  RoleBinding to a ClusterRoleBinding.
I don't know if I'd describe any of that as simple, or that it could be pretty easily made to work in that fashion when there's so much contention over other issues, to be completely honest.
I really advocate solving the issue as scoped before we start bringing in additional questions like whether we want to move all resources in k8ssandra-operator because there are just too many unrelated conversations happening at once on this PR, and I am starting to think it needs to be closed, re-scoped, and started from scratch.

I think this rebase is now working. @jsanda if you want to take a look at whether the tests are passing in your morning, we might be lucky enough that this is ready for approval.

FYI, near as I can tell, the broken test was because the kustomizations that generateCassOperatorKustomization  in e2e_framework.go generates used to move cass-operator into the test's namespace, but they now adhere more closely to what happens when the user deploys (which was, and remains, deployment to cass-operator ns).
That did necessitate a small change in the e2e test BeforeTest() function though so that it knows not to look in the test namespace for cass-operator in cluster scoped tests.
We'll probably revert all of that back out eventually, as we move to single namespace deployment (tracked here) but I like passing tests.


Dynamic Validate

Hi,
I have in my code a v-for that render 1 or 'n' input and would like that dynamic validate the fields.
For using v-for my verification is in field different of the input.
My v-model dont the validate field in label
Has anyone ever experienced this?
          <q-field class="erp-params-modal-field"
                v-for="current in currentRow"
                :key="current.id"
                :error="$v.current.field.$error"
                :error-label="errorMsg($v.current.field, current.label)" >
                <q-input
                     v-model="current.description"
                     :color="$colors.primary"
                     :float-label="current.label"
                     @keyup.enter="verification" />
              </q-field>

+1
I also have this problem.
I have an array of fields, and I create form inputs in a v-for loop.
Is there a way to set up a validations: {} object in a loop, basing on elements in my array?

Please refer to $each documentation. It's all already explained.


Integrator: Atomicity of operation

Problem
When integrator is doing its job it goes through lot of operations - writing to database, copying files, etc. Problem is when something fails. It will leave stuff in invalid state.
Case study
Publishing renders on farm. It will create versions in database and then starts copying. For some reason (but it really doesn't matter if it is missing file or invalid permissions) copying of files fails, integrator crashes and then we have versions in database and partial stuff on disk.
Solution
Parts of it can be solved by validators (checking if we have all files before integrating them) but some errors can occur during integration itself. Those should fail gracefully, rolling back whole "session".
Integrator should create journal of operations. If one of them failed then next action should go over this journal and revert everything back.
[cuID:PYPE-1351]

Mongo modification abilities

pymongo can use (and internally is using) operations that are sent to mongo in bulks
it is possible to store operations into list and then tell to execute them in mongo

Example
Right now we're creating version or updating existing version directly in mongo at the beginning of integration, but we can store InsertOne or UpdateOne operation which can be executed at the end of integration with method bulk_write (documentation)

this requires to create _id of new version document in code with ObjectId()
until integration is finished you can't tell that somebody is already trying to publish that version

if you would run 2 processes to publish with same subset, asset and project then one process may override files of the second and in database will be 2 version documents with same parent and same name (version number)

Mongo modification abilities

pymongo can use (and internally is using) operations that are sent to mongo in bulks
it is possible to store operations into list and then tell to execute them in mongo

Example
Right now we're creating version or updating existing version directly in mongo at the beginning of integration, but we can store InsertOne or UpdateOne operation which can be executed at the end of integration with method bulk_write (documentation)

this requires to create _id of new version document in code with ObjectId()
until integration is finished you can't tell that somebody is already trying to publish that version

if you would run 2 processes to publish with same subset, asset and project then one process may override files of the second and in database will be 2 version documents with same parent and same name (version number)

Database is one thing, file system other. Atomicity there is much harder to achieve - but it is equally important, especially with big renders, etc.

Database is one thing, file system other. Atomicity there is much harder to achieve - but it is equally important, especially with big renders, etc.

Related to #416

Related to #416

This hit the fan today, when ftrack integrator fails on publishing renders on farm because of invalid SSL certificate. All work almost done, files published, version created in Avalon and that last one bit fails. So deadline will try again and again creating more versions on disk and database.

if you would run 2 processes to publish with same subset, asset and project then one process may override files of the second

We should probably introduce some "soft" locks. My idea is that:

When publishing reaches integrator, lock in db should stop integration of possible concurrent publishes of the same subset.
Journal of all file io operations is created and live to the end of session. If failure is detected at the end, this journal is reversed and files returned to pre-integration state.
We need to think about how many tries (if more then one) Deadline - or farms in general - should have on publishing job.

also depends on #1355

We need to think about how many tries (if more then one) Deadline - or farms in general - should have on publishing job.

We had previously set this to 3 at machine and every machine got at most 1 try.

The logic added in this commit integrates files as .tmp files during integration, and upon errors try to rename the individual files. However, as came up on Discord renaming those .tmp files can produce errors with hardlinks. That particular issue does not occur if we instead write to .tmp folder and only rename the folder instead of the direct hardlinked filepath.
So I was thinking of proposing something along the lines of a transactional temp directory. Here's some quick pseudocode I threw together:
import os
import sys
import six
import contextlib

def transaction_dir(path):
    """Use temporary directory that we can rollback if errors occur.

    This yields a temporary folder next to the provided `path` which
    is basically `path + ".tmp{tmp_id}"`. This folder can be used to
    position and copy files to during the context. After the context
    if no errors occurred the folder is renamed to `path`.

    If errors occur it tries to behave a transactional rollback and
    remove the temporary folder. Actual files MOVED to the
    transaction dir are not MOVED back. This context manager only
    tries to manage the folder itself and move its content on success
    or remove the folder when errors occurred.

    """

    # Final path is not allowed to exist - we do not overwrite
    assert not os.path.exists(path), "Path already exists: %s" % path

    # Create the folder with .tmp and a tiny uuid or timestamp
    # e.g. /folder.tmp.202212001
    # todo: Use an actual uuid or timestamp
    tmp = path + ".tmp.202212001"
    create_folder(tmp)

    def _rollback():
        # Before Py3.8
        # On Windows, shutil.rmtree delete the contents of a
        # directory junction before removing the junction.
        # Source: https://docs.python.org/3/library/shutil.html#shutil.rmtree
        shutil.rmtree(tmp)
        six.reraise(*sys.exc_info())

    try:
        # Yield the temporary folder path
        yield tmp
    except Exception:
        # Rollback: remove the tmp folder
        _rollback()
    else:
        # Success: Rename the folder to final location
        try:
            os.rename(tmp, path)
        except Exception:
            # If the final rename of the folder fails we should still
            # roll back and report the error
            _rollback()

    finally:
        # Confirm the temp folder is removed
        # and the expected final path exists
        # just for sake of sanity
        try:
            assert not os.path.exists(tmp)
            assert os.path.exists(path)
        except Exception:
            _rollback()

with transaction_dir("C:/test/v001") as folder:
    # folder is the path to the v001.tmp directory
    # that gets renamed to v001 after this context
    # >>> copy_file(src, os.path.join(folder, "myfile.txt"))
    pass

Thoughts?
Like anything filesystem related this is a non-trivial beast to tackle with a filesystem not being transaction based like a database. But this might at least solve the hardlink issue during integration some were facing on Windows every now and then.

I think that the tmp directory approach is definitely closer to atomicity then individual files. But still as every publish plugin can do whatever it wants it is hard to enforce it. One way would be that plugins inherit from TransactionalPlugin and that will define common methods to register generated file, added db data and changes to files/db. New file could be "batch grouped" to tmp folders and those renamed when "commiting" transactions. More difficult would be handling of changes then adding/removing stuff.

Just wondering, how much more trivial would a rollback become for the AYON database backend?


Versions 1.56+ breaks auto attach for custom interpreter

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.56+
OS Version:

Steps to Reproduce:
Before version 1.56 I was able to have a launch configuration with the following settings.
		 { 	"type": "khonsu", 	"request": "launch", 	"name": "Launch Khonsu", 	"interpreter": "C:/Khonsu.exe", 	"args": [ 		"--debug", 		"${file}" 	] },
If I then loaded the script file and use "Run and Debug" with the above configuration, the Khonsu.exe would be launched and VSCode would be attached to it for debugging.
This is no longer working and instead requires that the "Run and Debug" be launched twice, the first time to start the process and the second time to attach to it.

/causedByExtension

VS Code has no built-in debugger "khonsu".
Please file this issue against the "khonsu" debugger extension.

I'm not saying that this "Khonsu.exe" is a part of the debugger, but that VSCode no longer auto attaches to the process that was launched by it.

@ngzaharias the "type": "khonsu" determines which debugger extension is used to interpret the other properties of the launch config. The property "interpreter" is nothing that VS Code understand, so it must be something understood by the debugger extension that define the debug type "khonsu".


Support 2D in CoordTransform

[x] I agree to follow the project's code of conduct.
[x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

Currently CoordTransform::transform accepts three &mut [f64] slices (for x, y, and z coordinates).  This prevents us from using it for 2D transform (whereas in the C api, we would have passed null ptr for z).  This PR supports that by checking if the z slice is empty, and passes null_ptr instead.
Also, currently we only check if the x and y slices have the same length.  This causes sigsegv when passing incorrect z slice.  We've also added a assertion for that.
Modified one of the existing tests that didn't use the z coordinate to instead pass an empty slice.

One test was failing because of this line.  The z slice is longer, but we weren't checking it earlier.  The test was about coordinate range, which would still happen, if not for the assertion that is now triggerred.  Fixed it to pass the same length for all slices.

Since the method already return a Result, why do we assert on the number of inputs and panic?

Runtime error vs. panic is often a subjective matter, but panic's are preferable in some circumstances.
I'm not speaking for @rmanoka - but FWIW, I'd also have it panic here, rather than return a runtime error.
Runtime error's are useful for things that can be handled by the calling code, but this error seems to indicate a bug in the calling code.
from https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-panic.html (emphasis mine)

If someone calls your code and passes in values that don’t make sense, the best choice might be to call panic! and alert the person using your library to the bug in their code so they can fix it during development. Similarly, panic! is often appropriate if you’re calling external code that is out of your control and it returns an invalid state that you have no way of fixing.
However, when failure is expected, it’s more appropriate to return a Result than to make a panic! call. Examples include a parser being given malformed data or an HTTP request returning a status that indicates you have hit a rate limit. In these cases, returning a Result indicates that failure is an expected possibility that the calling code must decide how to handle.

Ya, I wonder about it too.  There are a couple of other such calls, where we do assert! even though we return Result.  Example: RasterBand::read_*.  I also didn't find a natural candidate in enum GdalError so decided to leave it as is for now.

Ya, I agree with @michaelkirk .  Passing wrong slice lengths is clearly a wrong usage, so the assertion sounds better.   Added some helpful docs declaring the semantics, and also improved the assertion message.

@jdroenner @michaelkirk @lnicola  anyone have time for a quick review of this?  It's a fairly minor, non-breaking change, but makes it easy to use with 2-D data (which is a fairly common use case)

Might be worth adding a tests with a 3D transform too.
bors d+

By the way, these are basically nits, so you can just r+ if you prefer.

Maybe another test with an empty z slice? The failing one doesn't check that it works.

Thanks @lnicola ;  have added a trivial test for z coordinate (ensure it remains same as input).  I wasn't sure what vertical datums get shipped with all versions of gdal, so didn't want to break any builds by adding a complicated test.  Will merge this once CI passes.

Maybe another test with an empty z slice? The failing one doesn't check that it works.

It does because it panics or segfaults if the z slice isn't handled properly.

bors r+


Add cidan extractor and interface

Stub nwb here
Add extractor and interface for CIDAN segmentation software (with customized output for HigleyLab).
CIDAN output

[x] parameters.json: file containing all the settings for the algorithm

[x] roi_list.json: file containing the pixel_mask for each roi
[
    {
        "id": 0,
        "coordinates": [[286,276],[286,278],[287,274],...],
    }
    {
        "id": 1,
        "coordinates": [...],
    }
    {
        "id": 2,
        "coordinates": [...],
    }
    {
        "id": 3,
        "coordinates": [...],
    }
    ...
]

[x] timetraces.mat: file containing df/f traces (simple rois x frames matrix)

Can you open an issue here so we don't forget adding CIDAN to roiextractors eventually?

Can you open an issue here so we don't forget adding CIDAN to roiextractors eventually?

#26


Theme="islands" by default

Does it really need to specify the value of theme property manually? Seems the library doesn't support any other themes and implements only Yandex Islands style, so maybe theme should be defined as islands by default?

You can use App to set default theme:
<App theme="islands">
    <Button>Islands</Button>
</App>

But actually I agree.

Does it really need to specify the value of theme property manually? Seems the library doesn't support any other themes and implements only Yandex Islands style.

Well, if we're talking about styles, the library doesn't have any own styles, as you might've noticed. Never the less, I think that in most cases, a theme should be set globally on the application level, as @pasaran has suggested. In this case, there is no need to have any predefined theme in components, don't you think so?

Just a small note about our App component: every component defines a theme as a prop that might be set through the context. So actually, you can do it in any of your own top-level components:
class Page extends Component {
  getChildContext() {
    return { theme: 'islands' };
  }

  static childContextTypes = {
    theme: React.PropTypes.string,
  }
}

In this case, there is no need to have any predefined theme in components, don't you think so?

Seems it would be really convenient to have one. If I need to redefine it I always can set it manually using props or child context, but seems it's a kind of theory case.

Recently, I faced the case where default theme would be really harmful:
I'm in the process of rewriting a project that uses bootstrap heavily to react-islands. In order to do it gracefully, I'm changing separate parts of the page to these components, while leaving CSS classes and styles from bootstrap.
If Link and Button had a default theme it would overlap with the theme from bootstrap. The only solution for this problem, that I can think of would be a temporal "fake" theme to components.
Worth to say, this is only valid for simple components like Link and Button and in I'm strongly against of such usage in general. But I think an ability to not have a theme at all is a feature that shouldn't be rejected.


python38Packages.google-resumable-media: 1.3.3 -> 2.0.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python38Packages.google-resumable-media is: "Utilities for Google Media Downloads and Resumable Uploads"
meta.homepage for python38Packages.google-resumable-media is: "https://github.com/GoogleCloudPlatform/google-resumable-media-python"
meta.changelog for python38Packages.google-resumable-media is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

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

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

found 2.0.0 with grep in /nix/store/ifqz321qb6n0389nchr9zz0pbjhr4g44-python3.8-google-resumable-media-2.0.0

found 2.0.0 in filename of file in /nix/store/ifqz321qb6n0389nchr9zz0pbjhr4g44-python3.8-google-resumable-media-2.0.0

directory tree listing: https://gist.github.com/4781cfc44502f30066fa11596abedce2

du listing: https://gist.github.com/c8ec17c8545d1e7886b1a9a6bc230a69

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

88 total rebuild path(s)

22 package rebuild(s)

22 x86_64-linux rebuild(s)
22 i686-linux rebuild(s)
22 x86_64-darwin rebuild(s)
22 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
dvc-with-remotes
python38Packages.gensim
python38Packages.google-cloud-automl
python38Packages.google-cloud-bigquery
python38Packages.google-cloud-storage
python38Packages.google-resumable-media
python38Packages.pathy
python38Packages.smart-open
python38Packages.spacy
python38Packages.spacy-transformers
python38Packages.textacy
python39Packages.gensim
python39Packages.google-cloud-automl
python39Packages.google-cloud-bigquery
python39Packages.google-cloud-storage
python39Packages.google-resumable-media
python39Packages.pathy
python39Packages.smart-open
python39Packages.spacy
python39Packages.spacy-transformers
python39Packages.textacy
snakemake

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ifqz321qb6n0389nchr9zz0pbjhr4g44-python3.8-google-resumable-media-2.0.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ifqz321qb6n0389nchr9zz0pbjhr4g44-python3.8-google-resumable-media-2.0.0
ls -la /nix/store/ifqz321qb6n0389nchr9zz0pbjhr4g44-python3.8-google-resumable-media-2.0.0/bin

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

8 packages marked as broken and skipped:

python38Packages.pathy
python38Packages.spacy
python38Packages.spacy-transformers
python38Packages.textacy
python39Packages.pathy
python39Packages.spacy
python39Packages.spacy-transformers
python39Packages.textacy

14 packages built:

dvc-with-remotes
python38Packages.gensim
python38Packages.google-cloud-automl
python38Packages.google-cloud-bigquery
python38Packages.google-cloud-storage
python38Packages.google-resumable-media
python38Packages.smart-open (python38Packages.smart_open)
python39Packages.gensim
python39Packages.google-cloud-automl
python39Packages.google-cloud-bigquery
python39Packages.google-cloud-storage
python39Packages.google-resumable-media
python39Packages.smart-open (python39Packages.smart_open)
snakemake

Maintainer pings
cc @SuperSandro2000 for testing.

Result of nixpkgs-review pr 135141 at 51884a77 run on aarch64-linux 1

6 packages marked as broken and skipped:

python38Packages.spacy
python38Packages.spacy-transformers
python38Packages.textacy
python39Packages.spacy
python39Packages.spacy-transformers
python39Packages.textacy

2 packages failed to build:

python38Packages.pathy
python39Packages.pathy

14 packages built successfully:

dvc-with-remotes
python38Packages.gensim
python38Packages.google-cloud-automl
python38Packages.google-cloud-bigquery
python38Packages.google-cloud-storage
python38Packages.google-resumable-media
python38Packages.smart-open
python39Packages.gensim
python39Packages.google-cloud-automl
python39Packages.google-cloud-bigquery
python39Packages.google-cloud-storage
python39Packages.google-resumable-media
python39Packages.smart-open
snakemake

2 suggestions:

warning: duplicate-check-inputs
Dependencies listed in propagatedBuildInputs should not be repeated in checkInputs.
Detected duplicates:

python3.9-google-auth-1.34.0

Near pkgs/development/python-modules/google-resumable-media/default.nix:24:3:
   |
24 |   checkInputs = [ google-auth google-cloud-testutils mock pytestCheckHook pytest-asyncio ];
   |   ^

Near pkgs/development/python-modules/google-resumable-media/default.nix:22:3:
   |
22 |   propagatedBuildInputs = [ google-auth google-crc32c requests ];
   |   ^

warning: duplicate-check-inputs
Dependencies listed in propagatedBuildInputs should not be repeated in checkInputs.
Detected duplicates:

python3.8-google-auth-1.34.0

Near pkgs/development/python-modules/google-resumable-media/default.nix:24:3:
   |
24 |   checkInputs = [ google-auth google-cloud-testutils mock pytestCheckHook pytest-asyncio ];
   |   ^

Near pkgs/development/python-modules/google-resumable-media/default.nix:22:3:
   |
22 |   propagatedBuildInputs = [ google-auth google-crc32c requests ];
   |   ^

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement. Does something look off? Please file an issue or reach out on IRC.


istio-1.4.3: Healthy pod return error 503 for every request

After a regular deployment to our cluster, with scale of 4, one of the pods started on a machine (Let call it Machine A) that was marked by aws as have a hardware issue (it resolved by aws before the deployment). we start see some connection reset when trying to call the service (directly or via the gateway).
We saw that the pod that started on Machine A had a connection issue but still marked as healthy,
here is the response when the pod got the request:
(base) ip-xx-xx-xx-37:~ hany$ curl -v http://xxxxxxx/xxxx/health
*   Trying xx.xx.xx.xx:80...
* TCP_NODELAY set
* Connected to xxxxx.co (xx.xx.xx.xx) port 80 (#0)
> GET /xxxxxx/health HTTP/1.1
> Host: xxxxxx
> User-Agent: curl/7.65.3
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 503 Service Unavailable
< content-length: 91
< content-type: text/plain
< date: Sun, 22 Mar 2020 11:42:18 GMT
< server: istio-envoy
<
* Connection #0 to host xxxxx left intact
upstream connect error or disconnect/reset before headers. reset reason: connection failure

Here is the log of istio-sidecar in trace level:
out.txt
Please notice:

we verified that new pods in the same machine working fine without any connection reset by peer errors
The same error we see in other outbound traffic in 1.4.3 (opened on istio before few days ago with the same error code (Unknow error code 104):
https://github.com/istio/istio/issues/22265

[Envoy (Epoch 0)] [2020-03-22 12:48:38.808][27][debug][misc] [external/envoy/source/common/network/io_socket_error_impl.cc:29] Unknown error code 104 details Connection reset by peer

Restart of the istio-proxy container does not resolve the issue
Restart of our container does not resolve the issue
Restart of the pod and starting it again make it work

And the main issue that we worry about is how can we know if the pod is healthy? cause in our situation, Kubernetes API marked it as healthy and send traffic to it, but in fact, it wasn't
We are running on to istio-1.4.3 on eks 1.14,
Our main configuration:

MTLS ENABLED
SDS DISABLED
rewriteAppHTTPProbe = true

I also meet the situation when envoy should proxy to http://xxx.xx.svc.cluster.local but it proxies to https://xxx.xx.svc.cluster.local and return witch code 503, it's unacceptable.

Anyone can help with this, please we really need help here, it happened again and again and again, it sounds like not production ready

@1hanymhajna are you able to reproduce this in any way? From Istio perspective, it looks like health probes are passing. Since you restart container without fixing, I doubt it is some startup related issues. It seems like the remote backend you are hitting is having issues? Based on the remote close logs?

@1hanymhajna any more info? I suspect this is not Istio as the root cause


Feature Request: make active pane more distinguishable

Feature Requested
The color difference between the title of the active pane and the other pane is very small, which makes it a bit hard to know where the active pane is. Maybe make the other pane darker or make the active pane more prominent by changing the title text color to accent color ?
Relevant Screenshots

Checklist

[x] The feature would be useful to more users than just me. (→ If it's only relevant to you, have you considered using a CSS Snippet?)
[x] I have checked that the feature is not already available via the Style Settings plugin.

Hi, that's a good idea. My main problem is, that any method of emphasizing the active pane needs to work with the default settings of the theme, where titlebar and header bar are hidden. And if both are hidden, the options for emphasizing the active pane are limited. :/
And making the inactive panes darker would decrease readability, and you do want to work with both panes after all.
Do you have idea any good idea maybe? because I couldn't come up with a good solution for that one :(

I don't know what is possible with css, but I have 2 ideas :

Highlight the border of the active pane (top only/bottom only/ left and right or even the four borders at the same time) whatever looks best. In my opinion, color the tiny top bar of the active pane to gray like the delimiter

https://user-images.githubusercontent.com/38974541/148083173-cf6d3cad-ffc6-4cd1-92c8-9f8db27a9906.mov

make 2 background colors, one for the active pane and the other for the inactive panes.

Okay, I made the inactive panes a bit more "shadowy", that should help as well! :)


Added Dell PowerEdge C6525

AMD Zen2 bare metal install from iDRAC VirtualMedia (DVD)
Includes rpaste sysinfo output for comparision

Looks good to me.


Awesome mod! but I do have an issue with the door and rain sound effects.

I found out what mod causes the problem it was  your  et_futurum_requiem mod and the lord of the rings mod. for some reason they effect minecraft in a way where the sound effect for rain is turned off and same for the opening sound effect for the doors, trap doors for both mods. I am not sure why it happens but it may do with the code for both mods due to having the same set of doors. I am not an expert of coding so I can't really tell what would be happening but i just have a feeling it may be something between the programing for the door features.
just hoping if there is a way to have this fixed
if there is not then I will just simply remove the lord of the rings mod. (even though it does add a bit more stuff that i would like to keep) or I could just ignore the bug entirely.
hope to hear from you soon or anyone that can help.

I am not the author of et_futurum_requiem so I think you might be in the wrong place. I'm not sure what you're trying to describe but it doesn't sound like something Particle Rain would be causing.


Warning when too many qubits are allocated in QuantumSimulator

Please describe what you would like the feature to accomplish.
When allocating too many qubits using QuantumSimulator, the program allocates a lot of memory is blocked for a long time.
Describe the solution you'd like
A warning that too many qubits are allocated to use QuantumSimulator (before the actual memory is allocated), possibly with a suggestion to use SparseSimulator instead.
Describe alternatives you've considered
Noticing that program uses a lot of memory using Activity Monitor and then stop program manually.
Additional context
Here is an example program that just idles and requests more than 100 gb of main and virtual memory.
QDK version: 0.24.201332
macOS 12.3.1 (21E258)
Processor: 2.3 GHz Quad-Core Intel Core i7
Memory: 32 GB 3733 MHz LPDDR4X

Program:
namespace Project {
    @EntryPoint()
    operation RunProgram() : Unit {
        use qs = Qubit[48];
    }
}

Running
dotnet run

idles as described above with no warning or error, but
dotnet run -- -s SparseSimulator

terminates successfully immediately.
I've seen this problem causing InteropServices.SEHException on a Windows machine.

A related issue is reported in https://github.com/microsoft/qsharp-compiler/issues/584


Firmware update error in RealSense viewer(2.38.1 RELEASE).

librealsense
2.38.1 RELEASE

|
|OS|Windows|
Intel RealSense Viewer / Depth Quality Tool has crashed with the following error message:
RealSense error calling rs2_stop(sensor:000002D0DB9262C0):
    stop_streaming() failed. UVC device is not streaming!

@jakemin, thanks for the report.
Duplicate of #7211

Hi @jakemin,
thanks for your report
We also able to duplicate this issue on our side
We will looking into this issue

The issue has been resolved (#7211 ).
You'll need to re-download Realsense-Viewer v2.38.1 from the release's page to proceed.


add image-building to pipeline

related to concourse/ci#221
I'm not sure what the reason for building btrfs-progs from source was originally, but the tests seem to work fine if we just use the existing apt package in debian buster/go:1. So a side effect of this PR is that we're now testing against btrfs-progs v4.20 instead of v4.15.

We're going to increase the scope of this PR, since it hasn't been reviewed yet. Right now, the plan is to add

better resource icons
slack notifications on job failures


implemented search functionality

Description

-> abstracted out the search bar into a full fledged shop component which takes initial search param or "" if none present and sets url search parameters to the values provided in the input box.
-> modified the get-products server component from hitting an axios endpoint to dynamically fetch the data using the available search parameters in combination.
->tested the working, screen recording attached below, everything's working as expected, also the searchclient component is made reusable.

Related Issues

Closes #945

Screenshots / videos (if applicable)

https://github.com/user-attachments/assets/fb33e5ac-203a-4929-98d2-e0663d82bcb2

@ShivanshPlays Please resolve your conflict.

@mdazfar2 check bro


Review dedicate Slack room links

When creating this project website, one thing we observed is that most k8s projects have their own Slack workspaces, e.g.
https://github.com/open-policy-agent/opa
https://github.com/cilium/cilium
We thought it was a bit too early to create a dedicated workspace and still be able to manage it effectively when we launched. I propose revisiting this soon. I suspect we'll want to create a new workspace but there may be other approaches.

Would be happy to contribute in building the workspace out when the timing feels right!

When creating this project website, one thing we observed is that most k8s projects have their own Slack workspaces, e.g.
https://github.com/open-policy-agent/opa https://github.com/cilium/cilium
We thought it was a bit too early to create a dedicated workspace and still be able to manage it effectively when we launched. I propose revisiting this soon. I suspect we'll want to create a new workspace but there may be other approaches.

That would be great and will definitely make the converstaions more easy and fast. Would love to contribute in building a healthy community.

Current plan is to move to CNCF slack! @alexkubecost have an invite we can add to the website?


eROSITA (eFEDS) exposure maps seem to cause FITSIO bugs

OSError                                   Traceback (most recent call last)
~/code/XGA/xga/products/phot.py in _read_wcs_on_demand(self)
207             # Reads only the header information
--> 208             self._header = read_header(self.path)
209         except OSError:
/opt/anaconda3/envs/xga_dev/lib/python3.8/site-packages/fitsio/fitslib.py in read_header(filename, ext, extver, case_sensitive, **keys)
237
--> 238     return FITSHDR(_fits.read_header(hdunum))
239
OSError: FITSIO status = 412: datatype conversion overflow
Error in ffc2dd converting string to double: 2.662896678238377E-315
Error in ffc2d evaluating string as a double: 2.662896678238377E-315
When we try to read them in using the XGA exposure map class

fthedit {file name} REFYCRVL delete
should be what you need


Enable cranelift-codegen's new all-arch feature to maintain full architecture support by default

This quick patch goes along with the corresponding PR in Cranelift adding the all-arch feature.
The changes in the linked PR will remove all architectural support by default, allowing dependent projects (such as Wasmtime) to specify exactly which architectures they want to support. In mainline Wasmtime's case, full architectural support is desired, so this patch will simply maintain existing functionality once the Cranelift changes are merged in.
Tagging @sunfishcode @npmccallum @steveeJ @alexcrichton for review.

This looks good! We can merge this once the Cranelift PR lands.

@sunfishcode @bnjbvr Bump -- with the corresponding Cranelift PR merged, this should also be integrated to maintain the same level of support.

@tschneidereit do you know if we can run this through the new CI pipeline? I would be surprised if this breaks something but I'd still like to see the CI green before mering it.

@steveeJ apologies for the late reply! The new CI should run automatically for all new PRs/new commits in PRs, but you can also trigger it manually like so:
/AzurePipelines run

Unfortunately that doesn't seem to have worked :( Pushing a new commit here should work, though

@steveeJ @sunfishcode The current test failures look related to the current 0.40 release of cranelift not having the required commit yet (seems like it just missed the cutoff for the 0.40 release...)
Is this a situation where we'd want to merge after the next Cranelift release?

Yep, looks good.


change the adapter to make systemjs bundle inclusion configurable #84

copying the implementation from https://github.com/Workiva/karma-jspm

LGTM
Thanks for the PR!


Is there any essential difference between  "ff2n" and "fracfact"?

Excuse me.
As I know, full-factorial design can manipulate all the main and interaction effects already. The meaning of fraction factorial design is to reduce the runs based on that some interaction have little effect, such as some high-order interactions.
Why do I need "fracfact" if the runs of "fracfact" is equal or even bigger than the runs of "ff2n"?
Just because "fracfact" can list the columns of interaction?

@CodeEremite, since you closed the issue, would you mind commenting on why?

@CodeEremite, since you closed the issue, would you mind commenting on why?


Map mysqlnd Packets out of order error as ConnectionException

Map mysqlnd Packets out of order error as ConnectionException for MySQL driver.
Close #82

@vokomarov i mean Integration testing.
For example, can we create MySQL connection with wait_timeout=1 then wait 1 second and try to send any query?

@roxblnfk ok, I see. It looks like we can try to set wait_timeout using SQL query
SET SESSION wait_timeout=1

and then check if ConnectionException thrown at the next query.
But that will test only MySQL server has gone away error. I have no idea of how to force Packets out of order mysqlnd error. Probably there is a relation with mysqlnd.net_read_timeout ini variable. Need to test.

Hey @roxblnfk , any progress on this?
I saw some builds failed but I can't reproduce same error.

Hey @roxblnfk , any progress on this?
I saw some builds failed but I can't reproduce same error.

Hi. I'm waiting for a report from another team that can test this on their projects.
I think this has gone on for a long time and we need to move on without them..

From my side I can report successful resolution of issue #82 which I deployed previous week on production. There is no "Packets out of order" error happened since these changes was deployed.
https://github.com/cash-track/api/commit/328a119954bfcf8f9fca62b6bc23457dbeb21440

Test Spiral\Database\Tests\Driver\MySQL\ExceptionsTest::testPacketsOutOfOrderConsideredAsConnectionException failed only on php 7.2 (may be also on 7.3)
Can you add condition in this test case to skip it on php 7.2?

@roxblnfk Made some additional local tests with 7.2 and 7.3, confirming that "General error" thrown on both of them when trying to "SET SESSION wait_timeout=1". Updated tests to be launched on >=7.4.

@vokomarov thank you


Cargo.lock should not be ignored

The official guide for crates.io/cargo says that the Cargo.lock file shouldn't be pushed for libraries, but should be pushed for binaries. Since this is a binary, it would be nice to have it pushed.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ryankurte (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ryankurte (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

We generally don't use Cargo.lock.
Binaries are always supposed to work with the latest compatible semver compatible crates and we cannot verify that upstream promise (with or without Cargo.lock).
Cargo.lock only creates a maintenance burden and in our case without any benefits. NB: If anything tends to create a problem then it's the llvm-tools version used by the installed Rust toolchain and we don't have any control about them.
Of course if someone is interested in providing reproducible and/or curated builds, they're free to add and maintain their own Cargo.lock themselves.

We generally don't use Cargo.lock.
Binaries are always supposed to work with the latest compatible semver compatible crates and we cannot verify that upstream promise (with or without Cargo.lock).
Cargo.lock only creates a maintenance burden and in our case without any benefits. NB: If anything tends to create a problem then it's the llvm-tools version used by the installed Rust toolchain and we don't have any control about them.
Of course if someone is interested in providing reproducible and/or curated builds, they're free to add and maintain their own Cargo.lock themselves.

Alright, then I will close this PR :+1:

Alright, then I will close this PR :+1:


[BUG] Updating Rancher CA will not update the cacerts hash in harvester

This may be a rancher bug or harvester, starting here first.
Describe the bug
I recently updated the CA of my Rancher (kubectl get setting cacerts -n cattle-system) instance and then starting getting x509 errors from my harvester provisioner. Provisioning would then fail.
In order for me to have Rancher successfully manage my downstream harvester cluster, I had to go to the harvester ui, clear the cluster-registration-url and re-add it. Then it seems that harvester re-pulled the cacerts value.

This is the expected behavior of Rancher and please refer to update-ca-cert for more details.

When Rancher is configured with a certificate signed by a private CA, the CA certificate chain is downloaded into Rancher agent containers. Agents compare the checksum of the downloaded certificate against the CATTLE_CA_CHECKSUM environment variable. This means that, when the private CA certificate is changed on Rancher server side, the environvment variable CATTLE_CA_CHECKSUM must be updated accordingly.

close as of the above description, and feel free to re-open it if u have any better suggestions, thanks.


Consider: GitHub actions for CI

No rush or urgency here
We should look into using GitHub actions as our CI runner. It looks like it supports most/all of what we need. It supports running tests on linux, windows, and macos. It supports using docker images. It supports caching data between runs. It supports nice UI integration, and real-time streaming of logs in the UI (awesome!).
Some obvious concerns are:

I believe we can only cache 5GB per repo, which I imagine would not be enough.
There may be other resource limits that we'd hit.

We can, of course, also consider running our own GitHub Action runners, but that's more work.
Just something that we might want to consider since Kokoro sometimes bites us.

@devjgm should we summarize your findings and close this?

Ping ?

Summary:

I added basic GitHub actions support in https://github.com/googleapis/google-cloud-cpp/pull/4333
Configuring them was easy, and the UX using them was very nice.
The worker machines running our code were (IIRC) only 2-core machines, and the builds were very slow.
GA have built-in support for caching build artifacts (yay!), but the cache size is limited to 5G per repository. We'd needmore like 50-100G.
Had a difficult time getting the GA Mac builds working. Not sure why. Seemed like just very slow and ended up timing out?? Not sure. Didn't debug.

I think we probably could replace Kokoro with GA, but we'd probably need to host our own GA "runners" (which we could do) and run them on bigger machines.... but doing this would nullify much of the benefit/simplicity of GA in the first place.
FWIW, other googleapis/ projects are moving lots of their builds to GA (and off of kokoro).
So, I think we experimented w/ them. At this point I don't think it makes sense to move everything to GA for our C++ builds.


check_aws_rds: update

The file has not changed ever since https://github.com/percona/percona-monitoring-plugins/commits/master/nagios/bin/pmp-check-aws-rds.py :)

yup, so, I took this from a PR https://github.com/percona/percona-monitoring-plugins/pull/93/commits

https://github.com/percona/percona-monitoring-plugins/pull/93/files
Actual changes are clear.


Making static fonts: merge makeStaticFont() into SamsaVF_compileBinaryForInstance()

Making static fonts uses two different functions, depending on whether we are reading the VF from a file (in which case we use SamsaVF_compileBinaryForInstance() or if we read from memory (we use makeStaticFont()). The SamsaVF_compileBinaryForInstance() function is more recent and we should move all of makeStaticFont’s logic into that function.

Fixed in 8802494aaedb16b75dae7f086acf2a30a2233d53
Lots of improvements to instantiation: new exportInstance() method handles both frontend and node

Merged old makeStaticFont() function (which we used for front-end instantiation) into compileBinaryForInstance() method (which we use for node instantiation).
"name" table now includes updated values (subFamily name, fullFontName, PostScript name, etc.), and always inserts nameIDs 16 and 17.
Compiled glyphs are now written in place in the front-end file, rather than to a temporary buffer then copied. Seems to be quicker.
compileBinaryForInstance() method renamed exportInstance(), fixed in samsa-cli.js too.
Added "DSIG" to the list of tables that are not exported in static fonts (because it becomes invalid).


update symfony/console and fzaninotto/faker

The faker and symfony/console packages are outdated.
If you want install faker-cli as a global package, you may get errors. Other packages may nowadays require symofny/console 3.x.
I updated Faker to 1.7 and symfony/console to 3.4.
This require also a newer version of PHP (5.5).

I am sorry, but I will not continue this project. The project is now archived on github and abandoned on packagist.


security vulnerabilities

Hi team,
In our vulnerability scan report there are 8 HIGH and 1 CRITICAL vulnerabilities in prometheus/alertmanager:v0.25.0

Component
Vulnerability
Severity
Installed Version
Latest Version
Description

golang-runtime
CVE-2023-24538
CRITICAL
1.19.4
1.20.3
https://github.com/advisories/GHSA-v4m2-x4rp-hv22

golang-runtime
CVE-2023-24536
HIGH
1.19.4
1.20.3
https://github.com/advisories/GHSA-9f7g-gqwh-jpf5

golang-runtime
CVE-2023-24534
HIGH
1.19.4
1.20.3
https://github.com/advisories/GHSA-8v5j-pwr7-w5f8

golang-runtime
CVE-2023-24537
HIGH
1.19.4
1.20.3
https://github.com/advisories/GHSA-fp86-2355-v99r

golang-runtime
CVE-2022-41722
HIGH
1.19.4
1.20.3
https://github.com/advisories/GHSA-fp44-cj2j-3jhx

golang-runtime
CVE-2022-41723
HIGH
1.19.4
1.20.3
https://github.com/advisories/GHSA-vvpx-j8f3-3w6h

golang-runtime
CVE-2022-41724
HIGH
1.19.4
1.20.3
https://github.com/advisories/GHSA-89mw-w342-mqrr

golang-runtime
CVE-2022-41725
HIGH
1.19.4
1.20.3
https://github.com/advisories/GHSA-w4h2-22wh-m6jx

busybox
CVE-2022-28391
HIGH
1.34.1
1.35.0
https://github.com/advisories/GHSA-h8c3-8522-vxc6

My suggestion: Golang and busybox version update to 1.20.3 and 1.36.0 respectively would solve the problem.

Can we expect a fix in the upcoming release ?

Yes these warnings should be fixed in the next Alertmanager release. No ETA though.

Thanks !! I will be waiting for the latest release

any ETA for the release?

Hi @simonpasquier, we were wondering if it's now possible to share some ETA/plans for the next release?
Thanks in advance!


I'd like to be able to update dates in the Summary view of the release planner

Would love to get the pen to edit that from the summary, like for PM:

FYI @JonathanCrd as you work on the new UI

Done, now you can edit the release target month from the summary view.
This will update our records as well as the ADO work item.


Add GitHub version of ETH Py150 Corpus

Add the redistributable version of ETH Py150 Corpus

The RemoteDatasetTest is fixed on master so it's fine

thanks for rebasing :)
CI is green now, merging


Mocking the store when testing

I am trying to write tests for my application. I would like to create a mock store, so that for example, I can override dispatch(_ action: Action) preventing my tests actually dispatching the action to my middleware, however allowing me to still assert it was called etc.
I was able to do something like this
       class TestStore: Store<AppState> {
            static var wasCalled = false
            override func dispatch(_ action: Action) {
                guard action is FetchCompany else { return }
                TestStore.wasCalled = true
            }
        }

This however requires me to mock out my entire app state when I am setting up my TestStore which I'd prefer to avoid if possible, instead only mocking out the reducer I care about.
I thought if my store conformed to StoreType I can easily override it
var store: StoreType = Store<AppState>(reducer: appReducer, state: nil, middleware: middleware, automaticallySkipsRepeats: true)

But this just causes an error:

Protocol 'StoreType' can only be used as a generic constraint because it has Self or associated type requirements

I understand how to test my reducers and actions, but I'm really struggling to see how I can test my classes that subscribe to the store.

Why must you mock your entire app state? A little more context on the example you gave would help understand.
For this:

I understand how to test my reducers and actions, but I'm really struggling to see how I can test my classes that subscribe to the store.

Some advice I can give, is that we just call the subscription method directly newState() in many test scenarios. If you are testing subscribe/unsubscribe timing this wouldn't work.

Perhaps I'm setting up my test wrong, but I am getting the following:

Which requires me to add the state of each reducer:

An example test with this behaviour would be
  func test_calls_fetch_company_on_init() {
       class TestStore: Store<AppState> {
           static var wasCalled = false
           override func dispatch(_ action: Action) {
               guard action is FetchCompany else { return }
               TestStore.wasCalled = true
           }
       }

       func appReducer(_ action: Action, _ state: AppState?) -> AppState {
           return AppState.init(company: <#T##CompanyState#>)
       }

       store = TestStore(reducer: appReducer, state: nil)

       XCTAssertTrue(TestStore.wasCalled)
   }

One method I use for reducing the requirements for Mocking is to have subscribers use a generic referring to only a section of state:
(Note this is pseudo code to provide an example and might need tweaks to compile & use)
protocol HasAccounts {
   var accounts: [Account] { get }
}

struct AppState {
    var accounts: [Account]
}

extension AppState: HasAccounts {}

class SomeSubscriber<S: StoreType>: StoreSubscriber where S.State: HasAccounts {
    init(store: S) {
        store.subscribe(self) { $0.select { $0.accounts } }
    }

    func newState(state: [Account]) {
        // ...
    }
}

Then when I'm testing I can make a mock state that conforms:
class SomeSubscriberTests {
    struct MockState: HasAccounts {
        var accounts: [Account]
    }

    func testFoo() {
        // create Store<MockState>, create SomeSubscriber(store: storeWithMockState)
        // tests
    }
}

@nodediggity

I can second that calling TheSubscriber.newState(state:) should suffice. It's the only thing I need to do in my tests, too, to see how services react to state changes. If you need to execute actual reducers, my spider senses tingle and I wonder why that is so.

As @mjarvis mentioned, you should limit your subscribers to a sub-state. If you narrow this down, it's not that painful to setup a state stub in your tests, because you don't need to create the whole AppState.

Re: replacing the dispatch function, I mentioned my "recording" store service here once: https://github.com/ReSwift/ReSwift/issues/323#issuecomment-360452118, see below for details and a current implementation

Recording test store
Given these types in my state module:
// In my app:

public typealias DefaultStore = Store<AppState>

/// Factory for the real store object with reducers and middleware included
public func createStore() -> DefaultStore { ... }

/// Root state type
public struct AppState {
    // I'm using this instead of an empty initializer `AppState()`:
    static var default: AppState { ... }
    // ...
}

And these test helpers:
// In my tests

/// Store that isn't calling any reducer or middleware
func nullDefaultStore() -> DefaultStore {
    return DefaultStore(
        reducer: { _, _ in AppState.default },
        state: nil,
        middleware: [])
}

class DefaultStoreRecording {
    init(store: DefaultStore = nullDefaultStore()) {
        self.store = store
        let originalDispatch = self.store.dispatchFunction
        self.store.dispatchFunction = { action in
            self.actions.append(action)
            originalDispatch?(action)
        }
    }

    let store: DefaultStore
    var actions = [Action]()
    var firstAction: Action? { return actions.first }
    var didRecordAction: Bool { return actions.isNotEmpty }

    func reset() {
        actions = []
    }
}

I can see how services dispatch actions like so:
func testFoo_DispatchesBar() {
    let recording = DefaultStoreRecording()
    let service = TheService(store: recording.store)

    service.foo()

    XCTAssertEqual(recording.firstAction, BarAction())
}

Maybe one of the stumbling blocks for you is that you don't inject a store instance and rely on a global variable instead?
Bonus helper: execute (async) callback when an action passes through
This can be helpful if you want direct callbacks on action dispatching, e.g. when you expect middlewares to dispatch additional actions. I don't actually test middleware with this. I used this with another helper to write integration tests that interact with the UI of the app and assert on a sequence of actions being dispatched for complex workflows, so I could write:
wait(for: [storeAdapter.expect("display search results", forAction: SearchingNotesFinished.self)], timeout: 2)

The basis to forward actions directly and, not, uses a real store from production:
class ForwardingDefaultStore {

    let store: DefaultStore

    init(store: DefaultStore = createStore(), actionDidProcess: @escaping (_ action: ReSwift.Action) -> Void) {
        self.store = store
        let defaultDispatch = self.store.dispatchFunction!
        self.store.dispatchFunction = { action in
            defaultDispatch(action)
            actionDidProcess(action)
        }
    }
}

@nodediggity I'm usually not one to end advice with "you're doing it wrong", so first I'll say, you're example is showing that you are testing that a side-effect has occurred in a reducer. That's not a good place to be as reducers should be pure functions. No side-effects.
If you have no choice in the matter, and just need to test it. I would go with advice already given. To see where that leaves you.
My final piece of advice is that from my experience, your entire state should have some pretty sensible defaults. If you can't simply do AppState() I'd consider revisiting those defaults.

@jimisaacs I'm not sure where you are seeing a side effect in my test?
I was intending to assert that once my view model had loaded, it fired off an action w/ the correct type.
In the case of the test above, if the next action was not of the correct type, the test failed.
None the less, some really useful info in this post and I have been able to make some changes in my approach that have allowed me to better test my application follow all you advice.
Thank everyone, much appreciated 👍

If you are good to go, disregard this question. Though following on your question...

I was intending to assert that once my view model had loaded, it fired off an action w/ the correct type.
@nodediggity what actually triggers the dispatch of FetchCompany in that test example?

The only thing I see is initializing from the example is store being initialized and provided a single reducer, which initializes some state. No middleware or view models I can see. This would normally mean that nothing is dispatched at this point. So either there is something happening outside of the test, or there is a side-effect somewhere.

@jimisaacs ah yes, I'm with you now - I'm afraid my example was probably too small to give an proper overview of what is happening.
My action is dispatched by the view model, triggered by a call from viewDidLoad.
That action is then picked up by middleware and triggers an api request.
The success or failure of that request dispatches actions that are then picked up by my reducer, populating the results or an error prop on the state.
Apologies, I see now it wasn't at all clear from my original post 👍


Web PI instructions missing a step

On the page https://docs.microsoft.com/en-us/iis/application-frameworks/scenario-build-a-php-website-on-iis/configuring-step-1-install-iis-and-php the Web PI instructions are missing a step: in step two you have to download the MSI, then install Web PI, then run Web PI.

@jmussman Please move this issue to https://github.com/MicrosoftDocs/iis-docs/issues


utf-8 bom issue

ERROR in ./~/babel-loader!./~/svg-react-loader!./ui/images/affirm-logo.svg
Module build failed: Error: Non-whitespace before first tag.
Line: 0
Column: 1
Char: m
    at error (/Users/chetcorcos/code/styleguide/node_modules/svg-react-loader/node_modules/xml2js/node_modules/sax/lib/sax.js:652:8)
    at strictFail (/Users/chetcorcos/code/styleguide/node_modules/svg-react-loader/node_modules/xml2js/node_modules/sax/lib/sax.js:675:22)
    at Object.write (/Users/chetcorcos/code/styleguide/node_modules/svg-react-loader/node_modules/xml2js/node_modules/sax/lib/sax.js:955:11)
    at Parser.exports.Parser.Parser.parseString (/Users/chetcorcos/code/styleguide/node_modules/svg-react-loader/node_modules/xml2js/lib/xml2js.js:481:31)
    at Parser.parseString (/Users/chetcorcos/code/styleguide/node_modules/svg-react-loader/node_modules/xml2js/lib/xml2js.js:7:59)
    at Object.module.exports (/Users/chetcorcos/code/styleguide/node_modules/svg-react-loader/index.js:45:15)
 @ ./checkout/main.js 50:17-65

@ccorcos Can you supply that SVG for me to test against?

crap. I meant to close this. It was a problem with the way I was loading it. you need to prefix require("-!... when you're overriding other loaders...

Ahh.. Ok. cool.

@ccorcos I have same problem on OSX. How exactly did you override loader? I'm using it as in example:
const Icon = require('babel!svg-react!./settings.svg?name=Settings');

const Icon = require('-!babel!svg-react!./settings.svg?name=Settings');

Ok thanks. My problem at the end was that svg-reat-loader seems not to work with webpack 2.1.0-beta.4. Downgrade to 1.12.14 solved my problem.

The -! prefix worked for me also, for anyone looking for ES6/2015 syntax, try:

import myIcom from '-!babel!svg-react!assets/images/fooIcon.svg?name=myIcon';

I also had this problem – I had to remove svg from other webpack loaders (e.g. I was trying to use react-inlinesvg simultaneously).

Nice. This allowed it to work for me in create-react-app as I can't change the existing loaders.

@hunthunthunt I am getting the error: : The node API for babel has been moved to babel-core.  when using the import command you have provided.

Sorry to post on closed thread, posting my exp so that others can take help.
Not sure why(I am not expert webpack and its loaders), but for me prefixing with simple ! worked, -! was not working.

@vikasrohit Yeah totally right man. Just prefixing it with ! worked for me too.
I used the following path import
import Icon from '!svg-react-loader!../assets/icons/menu.svg';
with the following config in webpack
{
    test: /\.svg$/,
    loader: 'svg-react-loader',
    query: {
        classIdPrefix: '[name]-[hash:8]__'
    }
}


Added admission_year in users table and updated frontend of signup form

Some other changes :

When user tries to sign up with a username, which is already taken, appropriate error message is returned
Rename branch to course
Remove mobile field from signup form
Reduce expiry time for JWT token to 24 hours, for security reasons
Added PhD as a course
Modified lint:fix script in the main package.json file, for it to work correctly

Looks good,
here's an idea:
what if all the APIs under the auth folder which requires access_token are shifted to user folder... like this:
    - auth
        -
        -
        -
        -


Error while submitting image.

Hi Again!
Now i've reached na error while trying to upload an image. error:
Intervention \ Image \ Exception \ NotReadableException
Open: C:\Users\Administrator.NATAL\Desktop\TechnicSolder\TechnicSolder\vendor\intervention\image\src\Intervention\Image\AbstractDecoder.php
287.            case $this->isDataUrl():
288.                return $this->initFromBinary($this->decodeDataUrl($this->data));
289.
290.            case $this->isBase64():
291.                return $this->initFromBinary(base64_decode($this->data));
292.
293.            default:
294.                throw new Exception\NotReadableException("Image source not readable");
295.        }
296.    }

Couple things to check right off the bat:

Does the /public/resources folder exist?
Does IIS have write permission to the public/resource folder?
Does the temporary upload path defined in php.ini exist?
Does the temporary upload path defined in php.ini have IIS_IUSRS permission?

Another thing that might be helpful is to turn on debug mode in /app/config/app.php (set 'debug' => true). and copy/paste the whole stack trace into a gist, and link it here.

I think the problem is with the permissions in the temp folder. I will try.

Thank you very much

Can this be closed?


Videos not download on browser

Since the extension was updated, videos downloaded for example from dmax, are downloaded to the extension but then never downloaded via the browser.

https://it.dplay.com/dmax/highway-security-spagna/stagione-1-episodio-13/ works for me.
can you please share your OS/Browser?

I use Windows 10/Chrome, can you try download "https://es.dplay.com/dmax/como-el-clima-cambio-la-historia/temporada-1-episodio-1/"?

No, because it's protected

Have the same issue, with videos originating from Open University, the download used to work in the previous version.

I am trying to download other caps and they all download with .ts extension that I cannot reproduce with vlc

found the problem, fixed on v2.1.1, you can download the zip file or wait for chrome store the publish the update, firefox will probably release it in a few hours.
thanks for helping me to identify the bug.

Good evening. I am having the same problem with version 2.0.0, I am able to download, but does not reproduce

Solved and pending review on chrome
Solved and released on firefox: https://addons.mozilla.org/en-US/firefox/addon/hls-downloader/


Shell-session doesn't get highlighted

Information

Language: shell-session
Plugins: Line Highlight, File Highlight, Show Language, Highlight Keywords, Remove initial line feed, Inline color, Keep Markup, Command Line, Normalize Whitespace, Toolbar, Copy to Clipboard Button, Download Button, Match braces, Diff Highlight

Using latest version of Prism
Description
I am unable to get anything with language-shell-session to highlight on my site OR the PrismJS "Test drive" page (https://prismjs.com/test.html#language=shell-session).

Code snippet

Page snippet

scp <path_to_your_local_file> <username>@[private]:~
out Debian GNU/Linux 8
out (your file)                                          100%   (file size)   (average transfer speed)   (total time elapsed)

The only page where I've seen it appear to work is the examples page (https://prismjs.com/examples.html)

Shell session is not intended to be used with the Command Line plugin. The shell session language is supposed to be a simple replacement for the Command line plugin for the case that Prism plugins aren't supported in your environment or you don't want to use the Command line plugin.
Shell session will identify commands by the $ prefix and interpret everything else as the output of commands. This is useful when writing shell tutorials but it's also the reason why you didn't see any highlighting.
Command line, on the other hand, doesn't make any assumptions. You have to explicitly tell it which lines are command and which are output. From your snippet, I can see that you already did that correctly.
Now, with the background info out of the way, let's fix your snippet. There are two problems:

You're using the wrong language. Use shell instead of shell session.
You're not using the language-xxxx class format to declare the language. Prism won't detect the language unless it's declared like this.

This should work.

scp <path_to_your_local_file> <username>@[private]:~
out Debian GNU/Linux 8
out (your file)                                          100%   (file size)   (average transfer speed)   (total time elapsed)

I hope this solves your issue.


Version

requires 5.1 or higher, 5.0 does not work

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

ID: eee44614-5f56-f5c3-b729-ed2fcbafcc35
Version Independent ID: 524598ca-76aa-c8f5-cde1-d6bd626b757b
Content: Introducing the Azure PowerShell Az module
Content Source: docs-conceptual/azps-1.3.0/new-azureps-module-az.md
GitHub Login: @sptramer
Microsoft Alias: sttramer

The version requirements were recently changed to be correct in the Install Azure Powershell documentation.


Add SQL db connector

Description
Add SQL DB connector
Fixes https://github.com/ballerina-platform/ballerina-extended-library/issues/64
One line release note:
Add SQL DB connector
Type of change

[X] New feature (non-breaking change which adds functionality)

Test Configuration:

Ballerina Version: SLBeta3
Operating System: Linux
Java SDK: JDK 11

Checklist:
Changes to OpenAPI definition

[X] Modified info section of the OpenAPI definition file - Example

description - what the connector is about
x-ballerina-init-description OpenAPI extension - connector initialization details
x-ballerina-display OpenAPI extension - connector name and path to the connector icon

Changes to connector module

[X] Added license header at the top of each .bal file.
[X] Added Package.md as per the guide here
[X] Added Module.md for the module of the  connector as per the guide here
[ ] Created a directory called resources at the root of the connector and copied the connector icon there.
Name of the icon file need to be <connector-name>.svg
[X] Added Ballerina.toml file with following information. For keywords refer to guide

Verifying connector module

[X] Compiled the connector successfully with the targeted ballerina version.
[X] Conducted smoke tests on the connector (Recommended when OpenAPI definition is obtained from an unofficial source)

Security checks

[X] Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines?
[X] Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets?

Ci build is failing. Please check


[Improvement][Flink] Flink tasks do not support Generic CLI mode

Describe the question
(1)Flink deployment modes currently not supported：yarn-per-job
(2) Some parameters cannot be selected
What are the current deficiencies and the benefits of improvement
It is more convenient to submit Flink tasks
Which version of DolphinScheduler:
-[1.3.5-release]
Describe alternatives you've considered
（1）Add Options for Generic CLI mode:
-t,--target  For the "run" action the currently available
targets are: "remote", "local", "kubernetes-session",
"yarn-per-job", "yarn-session". For the
"run-application" action the currently available
targets are: "kubernetes-application",
"yarn-application".
（2）It is recommended to add a few parameters:
-d,--detached
-p,--parallelism
-s,--fromSavepoint
--allowNonRestoredState

@syb853553110 yarn-per-job mode is supported in Flink task.
Generic CLI mode you said does not support, because the mode is supported from flink 1.10.
Attention: Generic CLI mode is still replaced with yarn-cluster mode which is just equivalent to yarn-per-job mode

@syb853553110 Could you please rename the title to [Improvement][Flink] Flink tasks do not support Generic CLI mode? Thx so much!
`

close by #4937


API: Add option for app icon update

It would be nice to be able to disable update_app_icon updates, because it calls renders (and occasionally segfaults). It seems like this should be an opt-in feature, but given that it's already in master, perhaps it should be made an opt-out one with a new kwarg to BackgroundPlotter init -- that is what this PR implements.

Pushed some commits to add a set_icon method, and use the existing PyVista logo by default. With this pyvistaqt PR and https://github.com/mne-tools/mne-python/pull/8117 I get this:

I also fixed the Unknown mouseover by setting the app name to PyVista. Maybe PyQt5 is better/more generic, not sure.

I am having a tough time meeting the style requirements. It seems like some things that black prefers, pycodestyle does not. @tkoyama010 any ideas here?

Ahh, one of W503 or W504 must be disabled because they conflict. I'll pick W503 because when I ran Black it made W504-compliant code (and also I think W504 is the preferred one nowadays)

Ahh, one of W503 or W504 must be disabled because they conflict. I'll pick W503 because when I ran Black it made W504-compliant code (and also I think W504 is the preferred one to enable nowadays)

+1 for this. Black takes precedence over all checkers.

Thanks @larsoner !