Support testing imagestreams in OpenShift 4

This pull request supports testing
imagestreams in OpenShift 4
Signed-off-by: Petr "Stone" Hracek<EMAIL_ADDRESS>

@hhorak @pkubatrh  PTAL. This pull request supports testing imagestreams in OpenShift 4.  Hopefully, this is the final Pull Request and we have full testing support in OpenShift 4

Each imagestream contains a definition of which container from which registry is used. By default registry.redhat.io.
The default OpenShift 4 installation contains several samples like registry.redhat.io/rhscl/nodejs-12-rhel7. But we would like to test imagestream against our built image.
Command oc image mirror registry.redhat.io/rhscl/nodejs-12-rhel7 <OUR DOCKER REGISTRY> is used for replacing the default container from imagestream into ours. We don't want to modify imagestream to ours.

Wouldn't it be better to define the imagestream by ourselves? I'm thinking about the case when OpenShift 4.x that we'd use does not have a stream for a new version -- in that case, we cannot test the particular version with the default imagestream. But if we added a new imagestream, we can and also can point the image to an appropriate image location. But maybe I'm missing something.

That sounds good.
My idea.
We have a JSON file e.g. https://github.com/sclorg/s2i-nodejs-container/blob/master/imagestreams/nodejs-rhel.json.
We can take a version from this imagestream and update it with our image exported to the docker-registry.
And if the version does not exist, then select a version that can be used as a template like 10.
This will be defined in the test.
I will create a new python script that will do the magic.
@hhorak @pkubatrh WDYT

@hhorak I am not sure I follow. As far as I can tell the test in question is about creating an imagestream we maintain in this repository inside a remote OCP cluster and running a templated app using the imagestream. Considering all pieces come from this repository, how could we have something missing?
I guess the image might not yet be released, so it could be missing from registries, but that could be added as a special case.

What about to test image from upstream defined by imagestream in OpenShift.
E.g. ImageStream s2i-nodejs-container for version:
      {
        "name": "10",
        "annotations": {
          "openshift.io/display-name": "Node.js 10",
          "openshift.io/provider-display-name": "Red Hat, Inc.",
          "description": "Build and run Node.js 10 applications on RHEL 7. For more information about using this builder image, including OpenShift considerations, see https://github.com/sclorg/s2i-nodejs-container/blob/master/10/README.md.",
          "iconClass": "icon-nodejs",
          "tags": "builder,nodejs,hidden",
          "version": "10",
          "sampleRepo": "https://github.com/sclorg/nodejs-ex.git"
        },
        "from": {
          "kind": "DockerImage",
          "name": "registry.redhat.io/rhscl/nodejs-10-rhel7:latest"
        },
        "referencePolicy": {
          "type": "Local"
        }
      }

We have built the image rhscl/nodejs-12-rhel7 in CI and would like to test it by imagestream. The built image is uploaded into our external repostory docker-registry....
But this repository is not present in the imagestream. We we update imagestream so it looks like:
      {
        "name": "10",
        "annotations": {
          "openshift.io/display-name": "Node.js 10",
          "openshift.io/provider-display-name": "Red Hat, Inc.",
          "description": "Build and run Node.js 10 applications on RHEL 7. For more information about using this builder image, including OpenShift considerations, see https://github.com/sclorg/s2i-nodejs-container/blob/master/10/README.md.",
          "iconClass": "icon-nodejs",
          "tags": "builder,nodejs,hidden",
          "version": "10",
          "sampleRepo": "https://github.com/sclorg/nodejs-ex.git"
        },
        "from": {
          "kind": "DockerImage",
          "name": "docker-registry....../nodejs-10-rhel7"
        },
        "referencePolicy": {
          "type": "Local"
        }
      }

then we can test it also from imagestream point of view. Including new versions which does not exist yet in OpenShift 4.X.

@pkubatrh @hhorak I have investigated the issue a little bit more and found some a bit tricky issue for testing imagestreams inside OpenShift 4. We have to update two files for testing imagestreams in OpenShift 4.
E.g. s2i-nodejs-container:
Imagestream file used for testing is https://github.com/sclorg/s2i-nodejs-container/blob/master/imagestreams/nodejs-rhel.json
The template file used for testing is https://github.com/sclorg/nodejs-ex/blob/master/openshift/templates/nodejs.json.
E.g. postgresql-container:
Imagestream file used for testing is: https://github.com/sclorg/postgresql-container/blob/master/imagestreams/postgresql-rhel.json
The template used for testing is https://github.com/sclorg/postgresql-container/blob/master/examples/postgresql-ephemeral-template.json
It is no problem to update both files. Pros: we can test whatever we want, including new versions. Cons: We have to create a script which will update it.
But we can use oc image mirror. Pros. It already works with all 'old' versions. Cons: I don't know if it works with the latest versions which are not released yet in OpenShift.

@hhorak I am not sure I follow. As far as I can tell the test in question is about creating an imagestream we maintain in this repository inside a remote OCP cluster and running a templated app using the imagestream. Considering all pieces come from this repository, how could we have something missing?

I meant this case: Since OCP takes imagestreams and templates sometime during its development, there might be more pieces missing than just what we didn't release. If we test on e.g. OCP 4.4, the imagestreams available are a year old. So even images that we maintain in production for few months are missing there by default. Therefore we need own imagestream.

It is no problem to update both files. Pros: we can test whatever we want, including new versions. Cons: We have to create a script which will update it.
But we can use oc image mirror. Pros. It already works with all 'old' versions. Cons: I don't know if it works with the latest versions which are not released yet in OpenShift.

You mean to mirror the new image (e.g. postgresql 12) as rhel8/postgresql-10? That might lead to confusions and would make debugging harder IMO. So I personally prefer the first option -- rewrite the imagestream and a template.
Or, we can use a different approach and for the purpose of testing the specific image as part of PR tests, to have a dedicated imagestream and also template. It would basically mean to not mix the imagestreams that we maintain for usage by OpenShift with files that we use for testing. The testing files would not change when adding a new version, so it is not a big maintenance cost. It means to have e.g. test/imagestreams/postgresql-is.json and test/templates/postgresql-ephemeral.json and only work with those copies. A test for official imagestreams/*json and examples/*json would be done separately. It would be more clear IMO. (just an idea)

I meant this case: Since OCP takes imagestreams and templates sometime during its development, there might be more pieces missing than just what we didn't release. If we test on e.g. OCP 4.4, the imagestreams available are a year old. So even images that we maintain in production for few months are missing there by default. Therefore we need own imagestream.

Ah, that must have been the part I was missing - I thought we are talking about testing the imagestream configuration files we maintain in our repositories, not the one that is included in a specific OCP cluster. Another question pops into my mind though - why test an already released imagestream?

why test an already released imagestream?

My thinking was to test the built image from PR in CI with the imagestream which we have in our repository. Whether it is working or not.
Our tests use as imagestreams present in the container repository as template stored either in the same repository or in the examples repository, like nodejs-ex.

why test an already released imagestream?

Now I'm not sure what you mean by "already released imagestream" -- is it the imagestream available as default in OCP or is it the file we have in our github registry under imagestream/ dir?

Now I'm not sure what you mean by "already released imagestream" -- is it the imagestream available as default in OCP or is it the file we have in our github registry under imagestream/ dir?

Here I meant any imagestream that is released as part of an OCP release. For example any imagestream currently present in OCP 4.4.
After thinking about it for a while there might still be a value in testing both released, and unreleased (part of the PR tested) imagestreams - to check whether an image works with both imagestreams in case there is some change regarding the example application (moving to some other repository?).

In that case I think the best we can do is to import and test whatever imagestream is currently part of Origin master. That imagestream should have all the image streams that we care about right?

@pkubatrh @hhorak  NAMESPACE parameter works as we expected. PTAL on it. as a reference PR in s2i-perl-container you can use https://github.com/sclorg/s2i-perl-container/pull/188
As soon as this pull request is merged I will try to test it directly in s2i-per-container pull request [test-openshift-4]


fix / enhance behaviour when using custom viewport

Closing this since there has been no activity on this for months and in probability the functionality is already added/fixed in 2.2.2.


Modal Dialog Improvement

[ ] Enter should confirm the modal
[ ] Esc should close it
[ ] clicking outside should close it

Hi,
Are you still looking for someone to fix the Enter and Esc parts of this issue.
If so i would be happy to take them on.

please do

it think the  clicking outside should close it is still to do

ok i will look at that as well


Create: Remove_outermost_parentheses.cpp

Created new file

@dixitt5 Can you please check this and accept PR.


fix(watch): remove unused watch close with hidden trouble

Description

I found a hidden trouble of build watch.
Vite build watch use rollup.watch, but if you call the watcher.close  immediately after the watcher inited, the close is a noop function(See the code here: rollup watch). Rollup bind the watch function after loadFsEvents.
The code in vite may copied from rollup docs and forgot to clean. I think this is a hidden trouble for that may crash the watch mode if rollup change the watch bind from async to sync.
Additional context

If we log the watch.close.toString(), we can see it's an empty function when it called here.
When we add setTimeout to the watch.close, it will close the watch mode suddenly.

What is the purpose of this pull request?

[X] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[X] Read the Contributing Guidelines.
[X] Read the Pull Request Guidelines and follow the Commit Convention.
[X] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[X] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[X] Ideally, include relevant tests that fail without this PR but pass with it.

Thanks for the PR, good catch! Sorry that this one slipped and took so much time to merge!


Adds Witnesses Page

Adds Witness Page.
Changes:

Adds Witnesses Page in Routes
Adds new functions to apiHelpers and sortHelpers
Adds witnessesReducer to reducers

@Kennybll You should ask a core member of Busy before working on feature, specially when we don't explicitly ask for this feature, there should be an issue or card in GitHub Project for it if it's something we approved. Your design proposal is very different from what we have on others pages on the sites. We can't approve your PR like that, we need a mockup for this otherwise you will spend lot of time in this PR.

It is under the Github workflow, as Add an option to vote for a witness. What do you mean by mockup?

I mean we should agree on a design with @pareshUD before doing the integration to avoid too much changes.

So should I close this pull request, or should I contact pareshUD?

You shouldn't start writing code if that feature hasn't been discussed yet. First create an issue, let others give their opinions on the topic, make sure we have everything figured out (features, look and feel, the way it should be implemented) and then announce that you are willing to work on it, this way:

We don't waste time implementing things that will have to be changed (in some cases rewritten from ground up).
No two developers would work on the same feature making one's developer work useless.

You can take a look at those guidelines, they are not accepted yet, but I think it's good starting point and noone would get hurt by respecting those:
https://github.com/busyorg/busy/issues/903

Thanks for the contribution for this PR, but I'll be closing this PR since @Sekhmet or @bonustrack  has not approved of this. We can always reference this PR back when it is time to create a Witness Page with designs from @pareshUD.


TileDB-SOMA 1.2.7

Following
https://github.com/single-cell-data/TileDB-SOMA/wiki/Branches-and-releases
and with pre-release green-light check from #30

Documenting our scattered discussions here:

No need to bump version_r because no change has been made to the R client for this patch release
No need to rerender. We already tried it locally, and the only change is dropping the build for R 4.1 (conda-forge is migrating from 4.1 to 4.3). This release doesn't even generate new R binaries (because of the previous point), so it wouldn't have an immediate effect. And as long as the R 4.1 build is passing, there is no rush to remove support
The patch version is 7 instead of 6 (as it was in #30) to avoid any potential confusion (see #31)


Compiler: add implicit block arguments (_1, _2, etc.)

Note: this PR exists because I wanted to see how hard was it to implement it. It's not decided yet whether this is something that we want... but I enjoy coding these things :-) . Also with this people can try it out themselves.
This is exactly like in Ruby. I chose _1, _2, etc. instead of &1, &2, etc. because & means the start of a block or a block arguments:
foo &.bar
foo &block_argument

so it would be a bit confusing to reuse & to also mean "block argument":
foo { bar &1 } # is &1 a block given to bar?

I also think _1 is visually less noisy than &1. And maybe _1 is a bit easier to type (no need to move the right hand to the middle of the keyboard).
Finally, it's the same as in Ruby so Rubyists will feel familiar with this syntax.
Examples
[1, 2, 3].each { puts _1 }
# Output:
# 1
# 2
# 3

files = ["foo.cr", "bar.cr"]
files.map { File.exists?(_1) }

# same as:
files.map { |file| File.exists?(file) }

%w(World Computer).each { puts "Hello #{_1}!" }
# Output:
# Hello World
# Hello Computer

Hash(String, Array(Int32)).new { _1[_2] = [0] }

# same as:
Hash(String, Array(Int32)).new { |h, k| h[k] = [0] }

Do I like it?
I think for cases like the File.exists? above where it's obvious that each block argument will be a file, and the block is pretty small, that it actually improves readability.
Also with try when you need to do something other than invoke a method on the yielded object:
file = # a nilable string
file.try { File.exists?(_1) }

# instead of:
file.try { |file| File.exists?(file) } # So many files! So confusing!

# or:
file.try { |the_file| File.exists?(the_file) }

Note how the two latter ways of writing it introduce a lot of noise (the block syntax, the variable name). The first way is pretty "zen" in my mind.
I also think it finishes generalizing the block syntax. Right now we have the explicit block syntax:
[1, 2, 3].map { |x| x.to_s }

We have the &. shorthand for when you want to invoke a method on the first and only block argument:
[1, 2, 3].map &.to_s

But no syntax exists for the general case when you want to do something with the block arguments without needing to explicitly mention them. Other languages have it (Kotlin, just for the first argument), Ruby now has _1 and _2, and Elixir has the general &(exp(&1, &2)) expansion syntax.
Breaking change
This is a tiny breaking change because if you had a variable named _1, well, now it's no longer a variable. But I think those cases shouldn't exist... I hope! And fixing those occurrences is easy.

I love it. And agree on the usefulness for shorter code and for try is really nice. That’s primarily what I’d use it for. Easier to write and read in these cases

This is similar in Elixir also: https://elixir-lang.org/getting-started/modules-and-functions.html
I don’t find it confusing using &1 because the concepts are related.
I love this feature. You know it because we talked several times about it 😉. But in any case I would leave the feature and discussion post 1.0

I could/would definitely use this right now, as it would make allot of my code shorter and easier to read.

Note: "you" here doesn't mean the author, just anyone

Ah yes. "Pass a block that accepts no arguments and gets the 2nd from the 1st."
That's how one reads this code. Easy discount on WTFs/sec. And don't try to tell me you'll get used to it. Well, even if you will, the vast majority won't. But I don't believe you will either.
Because you couldn't be bothered to declare the args, every time someone reads that code will have to stumble on it. Do we deserve that? Is it OK to keep going in the direction where code can be read only by its author even if it's not logically convoluted?
I personally wouldn't want that, and I definitely don't trust people to not abuse it (i.e. put it into any expression > 20 chars, where the distance between "cool, it accepts no args" and "wait, what's first?" is already too much) -- sadly Crystal would be particularly exposed to this compared to other languages due to the association with Ruby where there's just no common sense of restraint on one-liners.

What's the semantic for nested blocks and block short syntax?
files.each { Log.debug { _1 } }

That won't work, and it'll log nothing, or the arg to Log.debug, or fail at compile time if nothing is given to Log.debug' block (I don't remember).
But what about:
files.each { Log.debug &.entry(_1) }

Using the dsl syntax demoed in another log pr iirc, will that log each file in files ?

@bew it aways applies to the closest surrounding block
I do agree with @oprypin that this is not needed and that it might be negative to introduce the feature.

Yes, I think we should rather think about how to improve the pass a method as block syntax. Maybe we can allow something like this just in a block shorthand? I think this can solve @oprypin's arguments somewhat, first of all enforcing a short distance and and second it doesn't make you mentally enter into block parse mode by introducing a new "short hand block" parse mode.
Not a syntax proposal, just trying to show that the examples that motivate this can be equally solved with that:
[1, 2, 3].each { puts _1 }
[1, 2, 3].each &:puts
[1, 2, 3].each &:puts(_1)

files = ["foo.cr", "bar.cr"]
files.map { File.exists?(_1) }
files.map &:File.exists?
files.map &:File.exists?(_1)

%w(World Computer).each { puts "Hello #{_1}!" }
%w(World Computer).each &puts("Hello #{_1}!")

Hash(String, Array(Int32)).new { _1[_2] = [0] }
Hash(String, Array(Int32)).new  &.[_2]=([0])

Some more from the forum post. Not arguing that the proposal makes them strictly better than the current expanded form, just to demonstrate the problem space that can be attacked by it.
[1, 2, 3].map { _1 + 3 }
[1, 2, 3].map &.+(3)

(1..9).each_slice(3).map { _1 + _2 + _3 }
(1..9).each_slice(3).map &.+(_2 + _3) # of course that should just be &.sum

[{name: 'foo'}, {name: 'bar'}].map { @1[:name] }
[{name: 'foo'}, {name: 'bar'}].map &.[:name]

user = User.first?
user.try { ChargeCard.call(prince_in-cents: 500, user: _1 }
user.try &:ChargeCard.call(prince_in-cents: 500, user: _1)

password.value.try do
  copy_and_encrypt_password _1, to: encrypted_password
end
password.value.try &:copy_and_encrypt_password(to: encrypted_password)
# above is going to far probably and should be
password.value.try &:copy_and_encrypt_password(_1, to: encrypted_password)

So to formalize:

Extend &. expressions to allow to refer the arguments as _1, _2, _3, ....
If the call in the &. expression  has no explicit argument list, pass it the remaining arguments (second, third, fourth...).
Introduce &: Where &. expands to a call on the first block argument, &: simply skips that part of the expansion.
&: expressions support to refer to the arguments as _1, _2, _3, ... as well.
For &:, if the call has no explicit argument list, pass the arguments (first, second, third...)

So much for the base. Possible extensions

Don't require the number of block arguments to match the number of positional arguments exactly. That is if the the method takes fewer positional arguments than there's block arguments, ignore the extra block arguments.
If the call only has explicit named arguments, pass  the block arguments (for &. starting with the second, for &: starting with the first) to the method as positional arguments as above.

Please let's focus on the semantics of this proposal first. Any signs chosen here are explicitly not part of the proposal and just used for demonstration purposes! I would prefer to keep the discussion focused on semantics and in case those semantics would be a feature beneficial to the language, we can then discuss the best syntax for this.

I feel this feature takes us back to the cryptic Perl-land with all those magic $1 variables and such.
What I'd be reeeeally excited about though, is Elixir-like syntax allowing me to do thing like {"foo.txt" => "bar"}.each(&->File.write(&1, &2)) - which I was missing from the day I've discovered Elixir.

{"foo.txt" => "bar"}.each(&->File.write(&1, &2))

// note that you can do this already:
{"foo.txt" => "bar"}.each(&->File.write(String, String))
But yes, that, or https://github.com/crystal-lang/crystal/pull/9197, seems fine to me, as these don't exhibit the biggest problem I see with this proposal, which is that the syntax for a block with 0 args is reused for a block with any (not immediately visible) number of args.

@oprypin true indeed, what I've missed was the &.foo($1, $2) syntax.

Well, that's exactly what this current proposal gives you, then :smile: :question:

@Sija it seems this PR is what you want but with a different syntax?

Ah yes. "Pass a block that accepts no arguments and gets the 2nd from the 1st."

That's how one reads this code. Easy discount on WTFs/minute. And don't try to tell me you'll get used to it. Well, even if you will, the vast majority won't. But I don't believe you will either. This will be a mental interrupt every single time.

@oprypin I get what you are saying here. BUT, I personally think this is easier to read in the examples @asterite posted. Elixir has some similar syntax and I don't see it abused much and is generally only used for short method lines. Let's be honest too, people use short meaningless variable names with blocks already.
For example:
Benchmark.ips do |x|
  x.report("short sleep") { sleep 0.01 }
  x.report("shorter sleep") { sleep 0.001 }
end

What is x? Does anyone know or care? Probably not. I think it is very common when yielding blocks that the name is not particularly important.
With all that said, if this is not added it is fine. It is just syntactc sugar that I think has proven to be valuable in places like Elixir and is generally not abused, but I get the argument against it 👍

Also know that I first implemented this with &1, & 2, etc., so that syntax is definitely possible.
What @jhass suggests, or doing it almost like how elixir does it, by surrounding the block with &(...) might also be a better idea so that you know the replacement is a bit more scoped.

I like the idea of wrapping it so it is scoped! And I personally think &1 is easier to understand since it seems like a block related thing. _1 looks like an unused variable to me. But that could just be me :)

Elixir has some similar syntax and I don't see it abused much

OK but see the last part of my message.

people use short meaningless variable names with blocks already.

Yes but at least you see upfront how many of the variables there are (as opposed to seeming like there are none)

Yea maybe this proposal could go somewhere if it doesn't reuse the syntax for block with 0 args to mean block with any number of args.

@oprypin You mean this?

sadly Crystal would be particularly exposed to this compared to other languages due to the association with Ruby where there's just no common sense of restraint on one-liners.

Most elixir programmers came from Ruby so if anything this shows that it can work. especially if scoped with &()

I like the idea of wrapping it so it is scoped! And I personally think &1 is easier to understand since it seems like a block related thing. _1 looks like an unused variable to me. But that could just be me :)

For me, _1 also seems like an unused variable.

Most code is read many (10x) more times than it's written. Often by you. At 2am. Six months later.
For this reason, I'm a big fan of naming things even if it makes typing it a big longer.

Most code is read many (10x) more times than it's written. Often by you. At 2am. Six months later.

For this reason, I'm a big fan of naming things even if it makes typing it a bit longer

I generally agree with well named methods, argument, etc. But some cases there is no better name. Like in the try example or the benchmark example. IMO the &1 is just as easy or easier to read in those cases. Just wondering if you felt the same about those examples to or if those looked readable?
e.g.
title.value.try { slugify(&1) }

For one argument blocks add the keyword ‘it’
[1, 2, 3].each { print it }
(maybe in addition to _1 &1 $1 or #1)

Any chances on getting this merged after all? That would be a candy... @asterite?

Any chances on getting this merged after all? That would be a candy... @asterite?


force:data:record:update returns generic error when validation rule fails

Summary
When using the force:data:record:update command, if the data violates a validation rule; the system returns Failed to update record with code FIELD_CUSTOM_VALIDATION_EXCEPTION. Fields: [] instead of the provided validation rule error message.
Steps To Reproduce:
Repository to reproduce: dreamhouse-lwc
NOTE: If your issue is not reproducable by dreamhouse-lwc, i.e. requires specific metadata or files, we require a link to a simple Salesforce project repository with a script to setup a scratch org that reproduces your problem.

sfdx:force:data:record:update

Expected result
When submitting invalid data, the resulting error message should contain the validation rule's error message.
Actual result
Failed to update record with code FIELD_CUSTOM_VALIDATION_EXCEPTION. Fields: []
System Information

If you are using sfdx
{
"cliVersion": "sfdx-cli/7.130.1",
"architecture": "win32-x64",
"nodeVersion": "node-v16.13.1",
"pluginVersions": [
"@oclif/plugin-autocomplete 0.3.0 (core)",
"@oclif/plugin-commands 1.3.0 (core)",
"@oclif/plugin-help 3.2.18 (core)",
"@oclif/plugin-not-found 1.2.6 (core)",
"@oclif/plugin-plugins 1.10.10 (core)",
"@oclif/plugin-update 1.5.0 (core)",
"@oclif/plugin-warn-if-update-available 1.7.3 (core)",
"@oclif/plugin-which 1.0.4 (core)",
"@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)",
"alias 1.2.0 (core)",
"apex 0.4.0 (core)",
"auth 1.8.0 (core)",
"config 1.3.0 (core)",
"custom-metadata 1.0.12 (core)",
"data 0.6.6 (core)",
"generator 1.2.1 (core)",
"info 1.1.2 (core)",
"limits 1.3.0 (core)",
"org 1.11.0 (core)",
"salesforce-alm 53.6.0 (core)",
"schema 1.1.0 (core)",
"sfdx-cli 7.130.1 (core)",
"source 1.6.2 (core)",
"telemetry 1.4.0 (core)",
"templates 52.6.0 (core)",
"trust 1.1.0 (core)",
"user 1.7.0 (core)"
],
"osVersion": "Windows_NT 10.0.19042"
}

Additional information

Hi @dalden1981 can you provide an example command used against the dreamhouse-lwc project that will return this error?

To recreate the issue in dreamhouse-lwc:

I added a validation rule. In my case I added "Name_Cannot_Start_with_X" on Account (formula LEFT(Name, 1) = "X").
Then I added an account sfdx force:data:record:create -s Account -v "Name=Test" -u dreamhouse
I noticed that it only happens on update, so I ran sfdx force:data:record:update -s Account -v "Name=Xavier" -u dreamhouse -i 001...

Received error "ERROR running force:data:record:update:  Failed to update record with code FIELD_CUSTOM_VALIDATION_EXCEPTION. Fields: []."
FYI, when I ran sfdx force:data:record:create -s Account -v "Name=Xavier" -u dreamhouse I got the error "ERROR running force:data:record:create:  Name cannot begin with X"

https://github.com/salesforcecli/plugin-data/pull/249

QA Notes:
✅  tested with multiple validation rules (only the first one shows up).
✅ fields is populated only when the error isn't top of page...otherwise it's an empty array []

Fixed in sfdx-cli/7.133.0

The fix is in the latest CLI release published today.  sfdx version 7.133.0


Unexpected Output

Informations

Qiskit version: 0.8.1
Python version: 3.7.3
Operating system: IBM Q Experience

What is the current behavior?
The current behavior is that 00 and 01 are being generated even though the superposition has been broken and hence 00 and 11 should be generated.
Output:  {'00': 5071, '01': 4929}
Steps to reproduce the problem
backend = Aer.get_backend('qasm_simulator')
c = ClassicalRegister(2)
q = QuantumRegister(2)
circuit = QuantumCircuit(q, c)
circuit.h(q[0])
circuit.measure(q,c)
job = execute(circuit, backend, shots=10000)
job.result().get_counts(circuit)

What is the expected behavior?
Since measurement has been done once superposition has been broken and hence 00 and 11 should be generated as opposed to 00 and 01. i.e Since measurement has taken place qubit should stay in the same state, which isnt happening here.

Hi @RohitMidha23, the code you posted would have a measure gate from q[0] -> c[0] and q[1] -> c[1]. Since your circuit only has an H-Gate on q[0], it is normal for the result to be either 00 or 01.
Judging from the question you posted in the Slack, did you mean to have the measurements be written as: circuit.measure(q[0], c[0]) and circuit.measure(q[0], c[1])?

If you did mean to have the measurements be written out as circuit.measure(q[0], c[0]) and circuit.measure(q[0], q[1]), then I am unable to recreate the issue. When I run your code with these measurements, I get outputs including only 00 or 11.

Hey @Matt-Stypulkoski yes I understood the mistake. My bad. Closing this issue now


Remove -j from lgtm build

The lgtm build seems to be hanging some times for an hour or two, which can then lead to the build timing out when it keeps going. Removing the -j option thinking this might be causing resource contention with the builds. Have done a successful test build using this config

[approve ci autest]

Did any of the lgtm PRs get picked into 9.0.x ? If not, maybe accumulate them all into an Umbrella Issue, and mark for Project 9.1.x ?

Did any of the lgtm PRs get picked into 9.0.x ? If not, maybe accumulate them all into an Umbrella Issue, and mark for Project 9.1.x ?

You picked some, not all. Looks like we would need:
#6373
#6371
#6363
#6362
#6358

https://github.com/apache/trafficserver/issues/6430
also pr #6429 has them all picked in for whenever we want it


Display the cargo and rustup home paths

During interactive installation, the user will see the cargo home
directory as well as the rustup home directory.  They will also see the
environment variables which control these paths.
Fixes #1907

Fixes #1907

CI builds are failing due to some windows-only hard link error.  Doesn't seem related to this change.
All errors look like this:
---- warn_about_and_remove_stray_hash stdout ----
thread 'warn_about_and_remove_stray_hash' panicked at 'called `Result::unwrap()`
on an `Err` value: Os { code: 1142, kind: Other, message: "An attempt was made to
create more links on a file than the file system supports." }',
src\libcore\result.rs:997:5

If you're okay with the content then I'd like to see the commits squashed, there's no need for a "grammar fix" or "spelling fix" commit.  Then it can merge.

@kinnison @rbtcollins

Spelling and grammar fixed
Commits squashed

Let me know if there's anything else needed.


Fixed #186: Cannot compile with recent boost (clang/gcc)

With boost version 1.66.0 the template parameters of basic_socket were changed and additional includes are needed.

Thanks!


util: add vaultAuthNamespace option for Vault KMS

The new vaultAuthNamespace configuration parameter can be set to the
Vault Namespace where the authentication is setup in the service. Some
Hashicorp Vault deployments use sub-namespaces for their users/tenants,
with a 'root' namespace where the authentication is configured. This
requires passing of different Vault namespaces for different operations.
Example:

the Kubernetes Auth mechanism is configured for in the Vault
Namespace called 'devops'
a user/tenant has a sub-namespace called 'devops/website' where the
encryption passphrases can be placed in the key-value store

The configuration for this, then looks like:
vaultAuthNamespace: devops
vaultNamespace: devops/homepage

Note that Vault Namespaces are a feature of the Hashicorp Vault
Enterprise product, and not part of the Open Source version. This
prevents adding e2e tests that validate the Vault Namespace
configuration.

Show available bot commands
These commands are normally not required, but in case of issues, leave any of
the following bot commands in an otherwise empty comment in this PR:

/retest ci/centos/<job-name>: retest the <job-name> after unrelated
failure (please report the failure too!)
/retest all: run this in case the CentOS CI failed to start/report any test
progress or results

/retest ci/centos/mini-e2e/k8s-1.21

/retest ci/centos/mini-e2e-helm/k8s-1.21

/retest ci/centos/mini-e2e/k8s-1.21
/retest ci/centos/mini-e2e-helm/k8s-1.21

Failed with #2264

Needs rebasing after #2349, CI jobs should succeed after that.
@humblec do you have any review comments?

/retest ci/centos/upgrade-tests-cephfs


Remove Request Docs button in the script editor due to various issues

The Request Docs button is partly responsible for layout overflow issues on narrow displays, such as #31133.
It also tended to attract spam and low-effort issues that were difficult to act upon. The call-to-action we have on missing property descriptions is probably sufficient for now.

Some very low quality issues that I assume might be the result of the "Request Docs" button:

https://github.com/godotengine/godot-docs/issues/3068
https://github.com/godotengine/godot-docs/issues/3085
https://github.com/godotengine/godot-docs/issues/3110
https://github.com/godotengine/godot-docs/issues/3218
https://github.com/godotengine/godot-docs/issues/3227
https://github.com/godotengine/godot-docs/issues/3233
https://github.com/godotengine/godot-docs/issues/3245
https://github.com/godotengine/godot-docs/issues/3253
https://github.com/godotengine/godot-docs/issues/3256

I think that's evidence enough that this button is not a good solution as is.

Can be merged after a rebase.

Still, we do need to make the godot-docs repo and its issue tracker discoverable for engine users, so an alternative might be needed.

Can you add a link to the docs tracker in the Help menu? Maybe rename the current "Issue Tracker" to "Report a Bug", and add the docs tracker as e.g. "Docs Feedback"? Not the best name, but not sure what to use.

Since we are adding things to "Help", maybe proposals repo should be mentioned as well?

Bump :)

Thanks!

Cherry-picked for 3.2.2.


LetsEncrypt automated certificate grabbing and renewal

Recommended on IRC, and I've been meaning to look at this for a while now.
<robogoat> Given it looks like there is some motion towards an http server on this thing in the form of a rest interface, it would be cool if autocert could be integrated for easy LE integration
<robogoat> https://github.com/golang/go/issues/17053
<dan-> Hmm, that'd definitely be cool
<dan-> The first thing that comes to mind with this is something along the lines of a separate command, like right now there's `mkcerts` for just creating self-signed certs, I'd be thinking an LE/cert info section in  the config and running something like `lecerts` to have it just request them through LetsEncrypt
<dan-> having it renew it automatically would be really cool (you can just have it grab new ones and then send the signal to rehash the ircd, but if it was built-in that'd be nice)

Closing this with our new LE docs in the manual

Sorry for intruding, just adding a few references.
Has been added in docs/MANUAL.md through 242dbfd72cb5b5a26de6afdd3e8db0119431efe6 on 2018-04-10 and probably refer to #118 and #231 as well.


Limit tooltip size

Is your feature request related to a problem? Please describe.
tooltip screenshot

Additional context
The size of my display is 1366x768, the tooltip's size was... 1366x768

That is a bit excessive.   How did you generate this tooltip?

That is a bit excessive.   How did you generate this tooltip?

It appeared when placing my mouse over the type in the DataType tree.

look like i have same issue: tooltip of edit function Signature  i wanted to check the size of datatypehovering over it : but truncated as well. cant see the last line indicating the size
here :

it get rapidly annoying when trying to fix datatypes...
may be a wrapping the tooltip with a JScrollPane  ?

The data type tooltips should be truncated to a reasonable length.
For those that may be unaware, the Data Types provider has a preview window that you can open, which is placed below the data types tree.  This window shows what you see in the tooltip and provides some navigation capability.

I havn't used hover/tooltips pretty much since the start for pretty much this reason


Scaling Traffic Volume

Creating to continue a conversation from #306.
I propose to add sliders that can be used to control the amount of traffic inbound over the various arrival fixes, as well as departures, on the fly. The user can simply adjust the sliders to achieve the traffic volume and flow that they want (eg. heavy over one fix, light over the others, etc).
This would really add some variety, and would give people the option to practice working just arrivals, or just departures, etc, and generally put them more in control of how they want to play.

@sixeyeco In response to your comment on the other issue (306):
I was picturing something more... simplified. I undersand there are multiple 'schedules' that define the traffic distribution, as well as airports having different numbers of radials, etc. Here's what I was thinking, in more detail:
[airport].arrivals is already an array that contains 'n' number of objects, typically, one for each arrival stream. So, I'm saying we would have a global slider for "arrivals" and a global slider for departures. Each of those could be expanded with a little arrow, revealing sub-sliders that allow you to specify the rate for each stream of a given airport, in case the user wants to get that specific. If not, the sub-sliders will just default to whatever is set in the [airport].json, and will be scaled up and down based on the global sliders. As for the 'random' vs 'cyclic' vs whatever else, I can't see that making a huge difference; I'd just leave it as it is set in the json.
I am no good with CSS or html; I'm only useful in js, python (and marginal in c++), so I do appreciate the help offer with all this. I don't want to assume, but it seems like it was very easy for you to mock up those sliders you linked to in issue 306-- when you get a chance, could you try to throw together a demo of the concept I described above? I think it would be really helpful for everybody to see it, and it would take me days (or weeks), and it would look ugly because I have no taste. lol :laughing:

Unfortunately, my experience with css and java is limited to hunt and wreck. Where I excel is taking someone else's work and screwing with it enough to make it look and function the way I want. I used MetroUI because of the features and because it has an MIT license.
But I'd be happy to cobble together a working mockup of what you're describing if someone else can make it actually adjust the settings.

@sixeyeco That'd be great! I think I can cobble together the connections. I've learned a lot about that part from looking around the codebase so I think I can cover that part.

You got it. I'm happy to see this implemented. I tried to get a drop down arrow to reveal additional options but I ran into issues. I tried tabs instead and met with success. Take a peek?

@sixeyeco Oh yeah, that looks good! I do think getting them collapsible instead of tabs is worth some extra research, which led me to fiddle around with [this]. I tried to apply the same logic to the sliders you provided, but haven't had success yet, though I will try again later. Great work though, I'm liking where we're heading here.

@erikquinn  Yeah, same thing here. Works awesome with text but as soon as I put some sliders in there it balks. I'll keep looking for a way to get it done. I have a few feelers out there.

@erikquinn [Still tweaking it but getting closer] (http://sixeyeco.github.io/atc/options-loader7b.html)

@erikquinn @sixeyeco what is the state of this issue? Also I would like to see your proposes for the sliders but the links are broken... :grin:

@patitoxd I backburnered it while I clean up some SID stuff. The concept is described above, and @sixeyeco had a really nice mockup of it... it would then just need to be hooked into .arrivals and .departures of the loaded airport with some js, and the game will change the spawn rates. Shouldn't actually be too complicated at all. You're welcome to take it over if you like?
@sixeyeco you probably just updated his branch recently and it removed the sliders. Hopefully you have them saved elsewhere somewhere? :worried:

@erikquinn Yes I really like the idea of it and will implement it. But it would be awesome to include the thougts and work you two did for this issue.
@sixeyeco so... du you still have this stuff laying around somewhere? :grin:

oops. sorry. was away for a bit. I'll get on it.

Thanks @sixeyeco :smile:
@patitoxd Interesting other idea that came to me-- why not base the slider values on a proportion of "real world acceptance rate" (as in the max. number of ac per hour an airport is able to accommodate)? eg. sliders go from 0% to 150%, based on that value. These properties can be added to the airport jsons:
  tfc_rates: {
    capacity: {arr: 60, dep: 100},
    typical: 51,
  }

...and then the sliders are set with 100% being at the "capacity" value, and scaled proportionally along the slider's range. When loading an airport, they would default to the "typical" value (in the above case, 85% arr and 51% dep). From there, users can go about making adjustments to the traffic if they like.
^ What do you think?

@sixeyeco @erikquinn This looks veeery sexy! (No really I love the design)
I preffer the popup option and would propose to put it into the line with all the other icons (if this isn't too much of a cluster fuck). Another option would be to insert these options into the ariport selection window. Which I like even more if I think about it...
@erikquinn Yes this is a great idea! It may also make easier to configure. Because with this relative way of setting the amount of traffic you may even keep the settings when switching from EDDH to KJFK because this relative factor of the traffic to the normal value wouldn't change (I have no idea if this makes sence). So you are on a small airport with a challenging amount of traffic (like 3x of the normal value), you switch to a huge one and keep your settings but you don't get overrun because of the relative way you have set your amount of traffic (it's not 3x but maybe 1.5x the normal traffic)...
Ok.. You see, I can't explain this in words. I will do a visual explaination abut what I'm trying to say. xD But not know as I'm occupied with stuff from school. I will eventually edit this comment... I will be back! :sunglasses:

@patitoxd Thanks! MetroUI is very sleek and slim. One thing I think needs to happen is that the css and js should be slimmed tremendously. We only need a fraction of the power that available.
As far as placement, the airport selection menu is already quite full (and getting more so). Perhaps it would be better to have it inside the cog settings menu?
My two cents: I envision normal being something like 40%. That way there's plenty of room for the novice and the experienced alike.
As far as making the changes global my opinion is that proficiency comes one airport at a time. We don't necessarily progress globally. If the settings were global (across all airports) then when I switch to a different one I'd have to reset the settings again. I suggest default at 40% for all airports unless set otherwise.

@patitoxd your post literally has me cracking up over here. lol I do follow what you're saying, and had a similar difficulty expressing my suggestion, which it seems was not described adequately, as it sounds like you and @sixeyeco are thinking about something slightly different than what I was trying to describe.
I'll try to clarify by linking it to stuff you guys said:

I envision normal being something like 30%. That way there's plenty of room for the novice and the experienced alike.

I agree: this is what the typical value would be set to. I am just suggesting it might make more sense to have the slider scale go from 0-150%, with 100% being the "real world capacity", so that leaves room for us to have either much more or much less traffic than they do. If you guys think it makes more sense to make "real world" something like 30% in order to keep the scale 0-100, I'd be alright with that, but think having 100% be exactly the real-world maximum pace is something that would make a lot of sense when we come to explaining it to the users.

So you are on a small airport with a challenging amount of traffic (like 3x of the normal value), you switch to a huge one and keep your settings but you don't get overrun because of the relative way you have set your amount of traffic

With what I'm saying, this wouldn't be the case, nor would I really want it to be... Say we're doing San Diego (188,000 ops/yr) at 90%. That would mean we are working just slightly fewer than the maximum number that airport is able to keep up with (called an "airport acceptance rate"). If I am efficient, I can keep up and avoid delaying any of the aircraft. If I turn it up to 100%, I have to be perfect to keep up. If I turn it up again to 110%, the rate that they spawn at is FASTER than the rate that they can land, even if I put them right at the minimum required spacing.
Therefore, let's turn it back down to 90% here at KSAN. It's "very busy", and I'm working about 30acph (aircraft per hour). Now let's change airports to LAX (636,000 ops/yr). [See Note 1] With 90% traffic at LAX, I will experience the same demand for efficiency as I did when it was 90% at KSAN. However, here at LAX, I will be working many more airplanes (~102acph).
Therefore, at the busiest and most complex places, it will be harder to become good enough to work traffic at "80%" or higher than it will be to do it at a smaller, easier airport. And only experts will be able to stay alive at 100%, but not even for forever.

proficiency comes one airport at a time. We don't necessarily progress globally. If the settings were global (across all airports) then when I switch to a different one I'd have to reset the settings again.

I agree with this completely. That is why I would want airports to always load with the "typical" traffic levels, and then I can adjust them to my liking. I would have to do so every time (which isn't a big deal). And if/when "scenarios" become a thing, the traffic levels could be written into the scenario.

Note 1: At this point, I would not want it to `"keep your settings"`,
but I would want it to reset to the `typical` rate: how busy the
airport usually is in reality.

@erikquinn I like the idea of the amount of traffic being able to pass the maximum amount of the actual airport. So a scale from 0% to 150% is an option I agree with. (One question though: where can we find this max acph data?)
For the initial value of the percentage: so we would have to set the initial value to a reasonable value which will be different for the different airports? This is the route I would use because as you said, I might handle 90% traffic in a small airport quite good but would just be not efficient enough for this amount of traffic on a bigger airport.
And thanks to the explaination of @erikquinn I now get why you want to use the initial value of the airport when loading it. And I agree. ^^
One Idea:
Later, when some kind of saving mechanism is implemented, we might store the traffic settings for the individual airports? (Sorry I just want to safe some of my settings so I dont have to do the config over and over again. Time is preciousssss :wink:)

Hey folks
I started working on this issue and read trough the documentation for the airports to understand how the number of aircrafts per hour is calculated for the different arrival types. When reading trough the documentation of the cyclic arrival type I got to some point where it doesn't makes sense:

The 'frequency' key is required and specified in aircraft
per hour as an upper and lower bound.

But it also says:

The 'period' key may be specified and sets how long a cycle is in minutes, if it is not set a cycle is 60 minutes long.

So shouldn't it be:

The 'frequency' key is required and specified in aircraft
per cycle as an upper and lower bound.

?

@patitoxd

One question though: where can we find this max acph data?

It could be inferred by the number of runways, reduced by airspace limitations, or undesirable runway arrangments (eg intersecting runways can't have a solid stream of arrivals/departures to/from both at the same time, etc). I've reached out to a guy who would set and adjust airport acceptance rates about how we can calculate them. For example, avg ldg spd 130kts, 3.5nm in trail on final yields a maximum of 37 arrivals per hour for that runway alone if it is used arrivals only. Math like this could get us close, but in reality it isn't always possible to get the theoretical maximum (wake turbulence adds additional miles on final, for example). Hopefully he can provide some useful material, otherwise I can draw up some guidelines so we can just "eyeball" it.

The 'frequency' key is required and specified in aircraft
per cycle as an upper and lower bound.

Yes, it looks like this is probably the correct interpretation. If you change the comments, just also include that if the cycle period is not defined, it is assumed to be one hour (just for clarity).

@erikquinn Yep we could do it in a calculative way. But maybe we don't even have to add these "planes per hour" properties. We could just take the current min and max values for the arrivals and departures as they seem to be in a reasonable range for most of the airports and scale them up or down depending on the traffic settings of the user.

Yes, it looks like this is probably the correct interpretation.

Then it should also be
"This will spawn an average of 35 aircraft per cycle"
instead of

This will spawn an average of 35 aircraft per hour

?
And finally: does any of you guys get the thing with the 'offset'? :see_no_evil:

We could just take the current min and max values for the arrivals and departures as they seem to be in a reasonable range

Fine by me for now. They will be updated later though :wink:
ref the offset, I'm not sure. There's some comments in zlsa.atc.ArrivalCyclic, but I am not quite sure how they work exactly. Generally speaking, the value of offset is used in wave and cyclic, but not random, and it seems to shift the middle of the "wave"/"cycle" forward that many minutes. I can't really make out what the arithmetic is doing though.

@patitoxd, @erikquinn, regarding the arrivals (cyclic in particular).  The frequency is not aircraft per cycle, it is in aircraft per hour.  This means the frequency key is the same thing regardless of the arrival type.
It's probably most useful to consider to the period value when looking at a wave arrival type.  If the arrival is configured with a frequency of 30 aircraft/hour and a period of 30 minutes then it will spawn two groups of 15 aircraft in an hour or one group of 15 every 30 minutes.  The opposite could be done, with a period of 120 minutes then one group of 60 aircraft will be spawned every 2 hours.
As an airport's capacity is generally determined in aircraft/hour it's useful to target some overall aircraft/hour with the combination of arrival entries.  The period and offset can then be tweaked independently of the frequency to create an overall arrival rate which is always playable over time but may have many more arrivals over a short period than can be landed during that period causing a temporary increase in the number of aircraft the controller must manage.
The random arrival type essentially sends a constant stream of aircraft although with some variation between any two aircraft.  The cyclic type is a middle ground between the constant stream which is random and the all or nothing which is wave.
offset is exactly as @erikquinn, described.  It shifts the middle of a wave or the peak of a cycle.  By default it is 0 or no shift.  This is useful so the airport designer can have a bunch of aircraft come from say the north east and the north west at the beginning of the game and then shift it to south and south east half an hour later.  This would be accomplished by having the north east and north west arrivals have an offset of 0 meaning they start off spawning at the maximum frequency, and have the south and south east arrivals have an offset of 30 meaning they start the game spawning at minimum frequency.

The ATC repository is being migrated to it's new home at https://github.com/openscope/openscope,
and thus, all issues are being closed. If this is still an issue with the latest version of the sim
(accessible at http://www.openscope.co), or is a feature you still think we are lacking,
please reopen the issue at the new repo.
Please note that the vast majority of these issues have been copied to the new repository, or else are covered by other issues created there. See the below screenshot for what it looks like when your issue is known in the new repo:

Thank you!
Closing this issue.


bug: CJS exports analysis reads directly from disk

I originally filed in https://github.com/nodejs/node/issues/50649 but upon reading the Loaders Roadmap, I think it may be more appropriate to be filed here. This is a bug report that will likely be fixed by the following Milestone 3 item:

[ ] Helper/utility functions to allow access to the CommonJS named exports discovery algorithm (cjs-module-lexer).

Reproduction
https://stackblitz.com/edit/stackblitz-starters-j9tcmc?file=index.mjs
The reproduction calls node --require ./require-hook.cjs index.mjs.
For the sake of the reproduction, require-hook.cjs completely overwrites the code of file.js. (In practice, tsx transforms the ESM export syntax to CJS exports)
But despite that, when importing file.js from index.mjs, the removed export  is still present.
This is happening because Node's CJS exports parser bypasses the CJS loader and directly analyzes the disk file. Seems this bug is acknowledged here.
How often does it reproduce? Is there a required condition?
Utilizing a CommonJS require hook to compile ESM syntax in a .js file in a CommonJS context, then importing the file from a .mjs file
What is the expected behavior? Why is that the expected behavior?
For Node to parse the named exports from the source retrieved by the loader
What do you see instead?
Node should parse the named exports from the source retrieved by the loader.
Additional information
This limitation is acknowledged in the source code as a TODO here:
https://github.com/nodejs/node/blob/a9b2535/lib/internal/modules/esm/translators.js#L421-L424
While it might be considered an edge case, I'm filing this issue to highlight its impact on tsx users:

https://github.com/privatenumber/tsx/issues/67
https://github.com/privatenumber/tsx/issues/334
https://github.com/privatenumber/tsx/issues/38

Well this seems indeed to be a duplicate of https://github.com/nodejs/node/issues/50649, and is hardly related to loaders, right? If you use the loaders API, it might help for this specific issue – but of course it has some limitations and would need some work (PRs welcome).
Closing as duplicate

The bug is with the ESM loader not properly detecting CJS exports (so I think it's kinda related to loaders...).
Given the Loaders milestones mentions improving CJS exports discovery, I felt like it may be worth moving the issue here. Didn't mean to open a duplicate issue. Anyway, I trust your judgement in triaging this.

The bug is with the ESM loader not properly detecting CJS exports (so I think it's kinda related to loaders...).

All bug reports go to the main Node repo; this repo is for feature discussion and design. And if the bug occurs when no hooks are registered, it's a core Node issue and not something related to this.

Supporting interception of the exports analysis as part of the CJS hooking sounds to me like a sensible design. Such hooking should use the CJS source load hook to do the exports analysis against that CJS source, and this hooking could also permit modifying the CJS exports detection algorithm.

Maybe the load hook could have an additional return property? So like in addition to source, for format: 'commonjs' it could also return the list of named exports (or whatever data cjs-module-lexer returns).

Supporting interception of the exports analysis as part of the CJS hooking sounds to me like a sensible design. Such hooking should use the CJS source load hook to do the exports analysis against that CJS source

That’s already what’s happening


Modify the File Source Example  and update the README.md

Add a filter usage example

Save subjects with scores greater than 90 per person to a file.

https://github.com/apache/rocketmq-streams/pull/173


Make edit link also work in index.md files

The current "Edit" button on the pages does not correctly link to the page when the page is a index.md or index.pug file.
This is because the logic to convert the current page url (url.here) back to a file on disk is pretty naive and implemented in the theme. It also does not handle custom from folder.
A better way to fix that would be to have norska pass the path to the original file directly in the rendering data.

Fixed thanks to an update in norska 1.4


Presentation cleanup

Description
-Added relog/add icon to DashboardChartItemfor relogging previous and favorite foods
-Fixed color of NutritionFacts submit button
-Implemented pagination on food searchResults
-SearchResults reset in local state on logging of new food item, (but not the text in the input)
-NutritionInfo reset in local state on logging of food item
-Added update button to input for editing DashboardChartItem, also autfocuses
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

Change Status

[ ] Complete, but not tested (may need new tests)

Checklist

[ ] My code follows the style guidelines of this project
[ ] My code has been reviewed by at least one peer
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] My changes generate no new warnings
[ ] New and existing unit tests pass locally with my changes
[ ] There are no merge conflicts

Skimmed it, looks okay. I presume this is functional locally?

Skimmed it, looks okay. I presume this is functional locally?

It does, I'll deploy to stage when I get home. Have to re-set up an Auth0 app for stage


stable/chart/mongodb no matches for kind ServiceMonitor

Describe the bug
When trying to enable serviceMonitoring for the mongodb chart it returns the no matches for kind ServiceMonitor even though things like Prometheus, Loki, etc. are installed. We mainly use terraform apply, but seems to be singled out to the helm install as well.
Version of Helm and Kubernetes:
Kubernetes V1.15.0,
Helm V2.15.1
Which chart:
stable/mongodb v7.2.10
What happened:
install of the chart fails due to it not finding any matches
What you expected to happen:
the install of the chart to be completed without any issues
How to reproduce it (as minimally and precisely as possible):
run helm install stable/mongodb --version 7.2.10 -f values.yaml --dry-run --debug , with prometheus, loki, etc. already installed.
Anything else we need to know:
this is the values.yaml I used to do this
metrics:     enabled: true     livenessProbe:         enabled: true     readinessProbe:         enabled: true     serviceMonitor:         enabled: true #switching this to false works, but true doesn't mongodbDatabase: someDB mongodbPassword: somePassword mongodbRootPassword: somePassword mongodbUsername: someUsername replicaSet:     enabled: false     replicas:         arbiter: 1         secondary: 1

As the indentation of the values.yaml matters, in order to reproduce your issue, can you confirm if the values.yaml you are using is the following?
metrics:
  enabled: true
  livenessProbe:
    enabled: true
  readinessProbe:
    enabled: true
  serviceMonitor:
    enabled: true #switching this to false works, but true doesn't
mongodbDatabase: someDB
mongodbPassword: somePassword
mongodbRootPassword: somePassword
mongodbUsername: someUsername
replicaSet:
  enabled: false
  replicas:
    arbiter: 1
    secondary: 1

In the same way, can you copy/paste the exact error you are obtaining? kubectl logs, kubectl describe or the error after helm install would be convenient to reproduce the issue.

yes, that is the value.yml I'm using, The full error:
Error: rpc error: code = Unknown desc = validation failed: unable to recognize "": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
  on modules/customer/mongodb.tf line 1, in resource "helm_release" "mongodb":
   1: resource "helm_release" "mongodb" {

This error is the same if I do it through the terraform apply and the helm install command

I am trying to reproduce the issue but I am not able to do it even using the same parameters you provided:
$ helm install stable/mongodb --generate-name -f newValues.yaml
NAME: mongodb-1578906157
LAST DEPLOYED: Mon Jan 13 09:02:39 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
** Please be patient while the chart is being deployed **

MongoDB can be accessed via port 27017 on the following DNS name from within your cluster:

    mongodb-1578906157.default.svc.cluster.local

To get the root password run:

    export MONGODB_ROOT_PASSWORD=$(kubectl get secret --namespace default mongodb-1578906157 -o jsonpath="{.data.mongodb-root-password}" | base64 --decode)

To get the password for "someUsername" run:

    export MONGODB_PASSWORD=$(kubectl get secret --namespace default mongodb-1578906157 -o jsonpath="{.data.mongodb-password}" | base64 --decode)

To connect to your database run the following command:

    kubectl run --namespace default mongodb-1578906157-client --rm --tty -i --restart='Never' --image bitnami/mongodb --command -- mongo admin --host mongodb-1578906157 --authenticationDatabase admin -u root -p $MONGODB_ROOT_PASSWORD

To connect to your database from outside the cluster execute the following commands:

    kubectl port-forward --namespace default svc/mongodb-1578906157 27017:27017 &
    mongo --host <IP_ADDRESS> --authenticationDatabase admin -p $MONGODB_ROOT_PASSWORD

$ kubectl get pods
NAME                                  READY   STATUS    RESTARTS   AGE
mongodb-1578905789-7bf5b7d5fc-n85kw   2/2     Running   0          9m11s

$ cat newValues.yaml
metrics:
  enabled: true
  livenessProbe:
    enabled: true
  readinessProbe:
    enabled: true
  serviceMonitor:
    enabled: true #switching this to false works, but true doesn't
mongodbDatabase: someDB
mongodbPassword: somePassword
mongodbRootPassword: somePassword
mongodbUsername: someUsername
replicaSet:
  enabled: false
  replicas:
    arbiter: 1
    secondary: 1

I was looking in GitHub and it seems there are open issues related to k8s itself where users have similar problems, can you take a look for example at this one? https://github.com/coreos/prometheus-operator/issues/1866


Update libbpf-rs and libbpf-cargo

Signed-off-by: Michal Rostecki<EMAIL_ADDRESS>

or nvm, we don't need that


Logo on home page too big

Our official logo, displayed on the 'home page' when launching the app is slightly cut to at the right side (both in Chrome on my laptop with Windows as in the Samsung browser on my S5)
When you click 'Up Next' you still see some part of the logo at the left side.

This was solved in the https://github.com/frontity/wordcamp-theme/issues/77 issue :)


Only allow attributes in model

How would you go about disallowing additional attributes in the payload that are not in the validator rules, please?
Thanks!

While validatorjs does not have internal support for this functionality, you can accomplish what you want with a bit of code after checking initial validation.

const Validator = require("validatorjs")

// data whicn includes attribute not in rule
let data = {
    test: "",
    name: "mike",
}

let rules = {
    test: "required",
}

let validation = new Validator(data, rules)

// post process after initial validation executed
for (const [key, value] of Object.entries(data)) {
    if (!Object.keys(rules).includes(key)) {
        validation.errorCount++
        validation.errors.errors = { ...validation.errors.errors, ...{ [key]: [`The ${key} field is not allowed.`] } }
    }
}

let pass = validation.passes() // true
if (!pass) {
    console.log("\nValidation Errors:")
    console.log(validation.errors.errors)
} else {
    console.log("Validation Passes")
}

Thank you!

While validatorjs does not have internal support for this functionality, you can accomplish what you want with a bit of code after checking initial validation.
const Validator = require("validatorjs")

// data whicn includes attribute not in rule
let data = {
    test: "",
    name: "mike",
}

let rules = {
    test: "required",
}

let validation = new Validator(data, rules)

// post process after initial validation executed
for (const [key, value] of Object.entries(data)) {
    if (!Object.keys(rules).includes(key)) {
        validation.errorCount++
        validation.errors.errors = { ...validation.errors.errors, ...{ [key]: [`The ${key} field is not allowed.`] } }
    }
}

let pass = validation.passes() // true
if (!pass) {
    console.log("\nValidation Errors:")
    console.log(validation.errors.errors)
} else {
    console.log("Validation Passes")
}

Thank you!

No problem 🤓


Wrong paths in index.html

Hi,
I just tried to use docma for the very first time, by using the following command docma -s app:src/app.js  -d doc/.
However when I opened the generated index.html file, I had a blank page.
When I opened Chrome's inspector, I saw that none of the file loaded (see following image)

All files failed with ERR_FILE_NOT_FOUND.
The generated index.html looked like this :

When I remove the <base href="/">, all js & css files loads, but jquery and fontawesome are failing (because they are missing https:)
And if I don't remove the base tag, I need to set all assets src to their absolute path on my disk (& still add the https: for jquery & fontawesome)
Seems like something's wrong
(using node 10.15.1 on Linux, & docma v3.2.2, zebra 2.3.1)

You should run an http server to test/view the generated SPA. You can use the built-in docma serve command or any other static files server.

After a lot of struggle, I finally managed to get it up and running via docma serve.
It wasn't that difficult, but I find that the explanations were pretty difficult to understand for a beginner..

Is it the wording in the docs? A missing example?
Pls let me know which part was difficult to understand so we can make it easier.


Random ETIMEDOUT

I am getting ETIMEDOUT in communication between servers, timeout is set to 5 seconds and request is retried 3 times. Sometimes it timeouts once, sometimes it timeouts 2 out of 3 retries and sometimes it will timeout 3 times (all 3 retries). This is not fault of the destination server because I've tested same route from different application written in Go at the same time and i get response in 2ms, no timeouts.

To make you issue meaningful I recommend you to add at least your platform/OS, OS version, Node version, request version.

@pyhedgehog
Then stranger you should get through all issues that mention ETIMEDOUT in this module, there is a lot of it and people get it on different platforms and different versions of node and request. So writing details you mention will not make it necessary more meaningful than it is now.
But hey here it goes anyway:
OS: Debian 3.16.7-ckt20-1+deb8u1
request: newest (2.74.1)
node: newest (6.4.0)


3rd Party RPC Provider Section

3rd party RPC section added at the bottom of the document.
Added ANKR RPCs with link to support channel.

This is not a priority for us to work on and I will close it for now. We can re-visit this topic later.

Closing in favor of https://github.com/ava-labs/avalanche-docs/pull/1098


Display group in label name when there is one

closes https://linear.app/linear/issue/USP-2041/update-zapier-integration

You did a release of this last month, yea?

You did a release of this last month, yea?

Two months ago, on 09/01.


Piping into another command - inshellisense does not work on that other command

Is your feature request related to a problem? Please describe.
I want to use Inshellisense on multiple commands when constructing more complex command line invocations that use pipes. For example
ls | cat -

should bring up the options for the cat command. But I don't get any options, just a list of filenames, which is useless, as I am piping into cat and don't need to supply a filename.
Describe the solution you'd like
ls | cat -

should bring up the options for the cat command

Thanks for the great example, I'm able to replicate this and will start working on a fix


Language Settings

Describe the issue
My OS is set to German. The UTM App has a Korean User Interface. How can I change it to English?
Configuration

UTM Version: Latest (AppStore)
OS Version: Big Sur 11.2.1
Intel or Apple Silicon? Apple Silicon

I can't reproduce this. My system:

UTM Version: Latest App Store (2.0.22)
OS Version: Big Sur 11.2.2
Intel or Apple Silicon? Intel
Locale: German (Germany)

As a workaround you could try adding English to your Bevorzugte Sprachen list in System Preferences, reboot and then see if the issue persists.


HOSTEDCP-1016: Make hostname required for service endpoints with type==route

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #HOSTEDCP-1016
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

@muraee for services that are not the API server, we previously allowed a route with no hostname because the route would get a hostname from the mgmt cluster router. This change would make that use case not possible anymore, is this intentional?

@csrwng that's right, this is according to the JIRA ticket which states For each Service we should validate that when type route then a hostname is set. I am not sure if the description is incomplete, or I misunderstood it cc @enxebre
But now that you mention it, if we do want to to validate all services, then we would have to change the cli as well, right?

if we do want to to validate all services, then we would have to change the cli as well, right?

Yes

@muraee for services that are not the API server, we previously allowed a route with no hostname because the route would get a hostname from the mgmt cluster router. This change would make that use case not possible anymore, is this intentional?

@muraee @csrwng don't take the jira desc as very rigorous, the intent was to capture an action item to review this api input once again and try to improve UX by narrowing down the allowed input to what we only want to support and prevent exotic / non supported input combinations. Then we can relax back based on particular assessed RFEs.
As part of this task it'd be good to also add a doc section describing the use cases we support.
For the one above in particular and I'm not aware of any use cases taking advantage of it, it might / might not interesting for self hosted so I'd be +1 to drop it.

/approve

/lgtm

/retest-required
/unhold


Add awkward workaround for Chronic bug

Resolves #180

Hi there! Thanks so much for submitting a pull request!
Let's just make sure together that all of these boxes are checked before we
merge this change:

[ ] The code in these changes works correctly.
[ ] Code has tests as appropriate.
[ ] Code has been reviewed by @JacobEvelyn.
[ ] All tests pass on Travis CI.
[ ] Rubocop reports no issues on Travis CI.
[ ] The README.md file is updated as appropriate.

Don't worry—this list will get checked off in no time!

Coverage increased (+0.03%) to 97.243% when pulling 8b287993522f4f415f0b1f78266394145afa13dc on past-tense into 9940d47672e2b45665bb266c74b4d87b1c9e61c2 on master.

Coverage increased (+0.03%) to 97.243% when pulling 8b287993522f4f415f0b1f78266394145afa13dc on past-tense into 9940d47672e2b45665bb266c74b4d87b1c9e61c2 on master.

Coverage increased (+0.03%) to 97.243% when pulling 8b287993522f4f415f0b1f78266394145afa13dc on past-tense into 9940d47672e2b45665bb266c74b4d87b1c9e61c2 on master.

Coverage increased (+0.03%) to 97.243% when pulling 8b287993522f4f415f0b1f78266394145afa13dc on past-tense into 9940d47672e2b45665bb266c74b4d87b1c9e61c2 on master.

Thanks so much for the code review! Just letting you know that it sounds like someone's rewriting Chronic and I'm waiting to hear back here on whether I can just release a gem containing the fix so we don't have to do this workaround. Unfortunately I'll be a bit hard to get ahold of over the next few days so this will probably not be fixed and released until next week sometime.

Coverage increased (+0.03%) to 97.239% when pulling a66d79d50ed81dc79aa433b4d0e0f470d726de3c on past-tense into 9940d47672e2b45665bb266c74b4d87b1c9e61c2 on master.

Coverage increased (+0.03%) to 97.239% when pulling a66d79d50ed81dc79aa433b4d0e0f470d726de3c on past-tense into 9940d47672e2b45665bb266c74b4d87b1c9e61c2 on master.

Coverage increased (+0.03%) to 97.239% when pulling a66d79d50ed81dc79aa433b4d0e0f470d726de3c on past-tense into 9940d47672e2b45665bb266c74b4d87b1c9e61c2 on master.

This is now fixed in version 0.33. Thanks so so much for all the help, @greyhillman!


 But it does not detect its line (11), because it's not written in the same case as in the words list (shit).

After this PR the line of SHIT is detected (11)

Hey @faissaloux 👋
Good spot, thanks for fixing this!
Are you able to look at the failing static analysis check? It just needs (string) removing as it's already a string. Once that's done, I'd be happy to merge this and tag a new release.
Thanks again!


Redundancy issue with some diagnosis definitions

EUPATH_0015130 is diarrhea diagnosis at discharge in ClinEpi, but it is defined as a diarrhea diagnosis in VEuPath.
EUPATH_0025044 is diagnosis of diarrhea in ClinEpi and is undefined in VEuPath.
EUPATH_0000036 is malaria-related diagnosis in ClinEpi, but it is defined as a malaria diagnosis in VEuPath.
EUPATH_00025162 is diagnosis of malaria in ClinEpi and is undefined in VEuPath.
So if we define the undefined terms in VEuPath based on ClinEpi usage, they will be the same as already-defined terms.
I suggest revising the definitions of EUPATH_0015130 and EUPATH_0000036 to match ClinEpi usage (discharge diagnosis); then we can define the other 2 terms as general diagnosis of diarrhea/malaria. But is there a better solution?

After discussion with Outreach, I suggest the following for EUPATH_0000036:
malaria-related diagnosis
A diagnosis that represents one of the following conclusions about a patient: that the patient has malaria, asymptomatic parasitemia, or no parasitemia.


spring-boot-version-upgrade-to-3.3.5

⏳ https://jenkins.fdp.osgp.cloud/view/SMHE-cucumber/job/gxf-smhe-cucumber-build/307/

upgrading issues

upgrading issues solved

⏳ https://jenkins.fdp.osgp.cloud/view/SMHE-cucumber/job/gxf-smhe-cucumber-build/308/

⏳ https://jenkins.fdp.osgp.cloud/view/SMHE-cucumber/job/gxf-smhe-cucumber-build/309/


Handling both a default starting state and 404 errors.

Hi there. I'd like to handle both a default state for the first page get and show a 404 error template if a url does not exist. I'm trying with
$urlRouterProvider.otherwise("/");
That solve my first problem but, of course, anytime an incorrect url is typed, ui-router load the starting state. Is there a way to handle those two cases separately?

+1

We will add an API for this soon.
In the meantime you should be able to use a function for otherwise that picks the URL to redirect to. It can check the ui router globals transition history to see if it is before any transitions have started


Token details missing when navigating via policy membership

User Story
As an Automate User, I should be able to open the details of any member of a policy, be it user, team, or token. That is true for users and teams, but a token displays with all fields empty, and an error.

Definition of Done
Can view token details when navigating via policy membership.
Demo Script / Repro Steps
Create a policy.
Add a token as a member.
From the members list of the policy, select the token to open the token details.

Could not repro. Let's get some time from @msorens this week to see if we can just close.

I concur. If it is, in fact, a real issue, I missed recording pertinent setup.


Textual definition update: GO:0002209 (typo)

GO term ID and label for which you request a definition update
GO:0002209
behavioral defense response
current definition: "A behavioral response seeking to protect an organism from an a perceived external threat to that organism."
problem is having two articles "from an a perceived external threat"

New proposed definition (genus-differentia pattern, plus additional information if needed)
"A behavioral response seeking to protect an organism from a perceived external threat to that organism."

Additional information
Thanks, Alex

Thanks for reporting this !


Begin testing models from the ONNX Model Zoo.

Progress on https://github.com/iree-org/iree-test-suites/issues/6.
A sample test report HTML file is available here: https://scotttodd.github.io/iree-test-suites/onnx_models/report_2024_09_17.html
These new tests

Download models from https://github.com/onnx/models
Extract metadata from the models to determine which functions to call with random data
Run the models through ONNX Runtime as a reference implementation
Import the models using iree-import-onnx (until we have a better API: https://github.com/iree-org/iree/issues/18289)
Compile the models using iree-compile (currently just for llvm-cpu but this could be parameterized later)
Run the models using iree-run-module, checking outputs using --expected_output and the reference data

Tests are written in Python using a set of pytest helper functions. As the tests run, they can log details about what commands they are running. When run locally, the artifacts/ directory will contain all the relevant files. More can be done in follow-up PRs to improve the ergonomics there (like generating flagfiles).
Each test case can use XFAIL like @pytest.mark.xfail(raises=IreeRunException). As we test across multiple backends or want to configure the test suite from another repo (e.g. iree-org/iree), we can explore more expressive marks.
Note that unlike the ONNX operator tests, these tests use onnxruntime and iree-import-onnx at test time. The operator tests handle that as an infrequently ran offline step. We could do something similar here, but the test inputs and outputs can be rather large for real models and that gets into Git LFS or cloud storage territory.
If this test authoring model works well enough, we can do something similar for other ML frameworks like TFLite (https://github.com/iree-org/iree-test-suites/issues/5).

Ping @zjgarvey ? Any high level feedback? I should have some time this week to address my own comments, but I'd like to prefetch any other feedback/discussion.

I'll take a look today!

Okay, I made a bunch of updates today and I'm happy enough with where this is now to merge it and start running it nightly.
Major changes:

Moved more util code from conftest.py to utils.py
Reworked metadata extraction and reference output generation to fully use onnxruntime, not onnx (Protobuf)
Imported more vision classification tests (still only f32)
Organized tests into a subfolder
Improved documentation and gave report generation a try (https://scotttodd.github.io/iree-test-suites/onnx_models/report_2024_09_17.html)

PTAL?

@ScottTodd , I don't have any pressing comments. The printout you shared was really easy to navigate and the code here feels like it will be painless to iterate on with updates. Please let me know when you feel like this is in a state to merge, and I'll take a final look.


Create Cloud Run deployment branch

What is the context of this PR?
This branch is used by new Cloud Run test pipeline in this PR.
How to review
Check if script and yaml file changes are all correct and variables are refactored so there are no hardcoded left.
Checklist

[ ] New static content marked up for translation
[ ] Newly defined schema content included in eq-translations repo

 Pipeline a Cloud Run environment (3 SP)

The main repo Readme needs updating as it still contains kubernetes instructions.

Updated both Readme files to reflect the changes, added new commands examples and new variables to the list.


Repeated "System: A resource failed to call end." errors around the moment of writing the a tiff file

We've been using this library since 2.0.0, and it's gotten us out of a few tiff-related scrapes with other libraries and frameworks! Hoping I can get this one annoyance fixed.
Version Information:

TIFF Java Version: 3.0.0
TIFF Java Source: Central Repository
IDE Name & Version: Android Studio 2021.3.1 Patch 1
Maven Version: (Studio's Gradle)
Java Version: 11
Platform & OS: running on Android OS 8-13, building on MacOS Monterey 12.6.1
Other Relevant Libraries: OpenCV, maybe? We use no other tiff-related libs in this app.

Expected Results:

Tiff file is created, added to and saves with no errors in the log

Observed Results:

Tiff file is created, added to and saves properly, but there are hundreds of lines of A resource failed to call end. errors within the space of a few clock ticks
How often does this occur? Every time the tiff file is added to or saved. Without adding or using the library our codebase doesn't make this error occur.

Output:

Any logs, errors, or output messages?

Other than the A resource failed to call end. errors, no extraneous logging seems to occur, even with all filtering of strings and processes off.

Steps to Reproduce:
It's not difficult to reproduce. The code follows the idiom for writing to a file in the README.md file pretty closely.

We create a TiffImage object

Then we create a few FileDirectory objects, set tagging and formatting properties, add a Rasters object to each representing a page's bitmap, and add each directory to the TiffImage with a call like tiffImageObject.add(fileDirectory)

Finally we save the tiff with a call to TiffWriter.writeTiff(file, tiffImageObject)

If needed I can put together a small example, but this style of code has produced this errors-in-the-log behavior over a few versions of this library, in two app codebases (one Java 11, one Kotlin), and of Android OS, Mac OS and Studio. I'm just reporting it now so as to try to be as clean as possible in this latest app's codebase.
Is there something non-obvious we should be closing, or perhaps some sort of threading or other resource-isolation practice we should be aware of? We're not changing screens or scopes in any way I would expect to subtly abandon or orphan objects.

I can't seem to reproduce the log using the README code in an Android test or through our Android tiff usage.
Did you try a strict mode policy yet to identify it?  Something like...
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
        .detectLeakedClosableObjects()
        .penaltyLog()
        .penaltyDeath()
        .build());

If you have a standalone small example or test known to cause it, that could help.


Fix newIdentificationNumber on L1 segment [WIP]

it looks like the newIdentificationNumber field in API is named incorrectly because of typo or bad copy-paste.
I'm not sure how to regenerate client code, though, make client changes a lot of files in pkg, but not pkg/client/model_l1_segment.go, for example. Suggestions?
Also, there's a question of backwards compatibility in case someone already used balloonPaymentDueDate for that field already.

@adamdecaf is code generator still being used for pkg/client? I see some changes from other PRs not reflected in it yet. I can change generated code by hand, of course.

Yea, I've fallen out of favor with keeping generated code in the repository. We can update it though, but with how often openapi-generator has broken the generated code's API it's annoying to keep breaking our users.

Thanks for fixing that JSON field. This seems like a small enough (and odd thing to not have been caught yet) to change on its own and just announce loudly in the release notes.

Codecov Report

Merging #171 (6d752a1) into master (693817e) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 6d752a1 differs from pull request most recent head 27ea924. Consider uploading reports for the commit 27ea924 to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master     #171   +/-   ##
=======================================
  Coverage   79.31%   79.31%
=======================================
  Files          16       16
  Lines        2258     2258
=======================================
  Hits         1791     1791
  Misses        283      283
  Partials      184      184

thanks for merging!


Separation2

I reorganized the repository into folders. This is based on the work that we did in the separate branch but I redid it on master. I also made sure that common is self contained and doesn't depend on code outside of common. In order to do this, I had to duplicate Configuration case class. I split it into Configuration and CmdlineConfig. They are the same except that CmdlineConfig has fields for backend and mode. Furthermore, I put all the capability checking stuff into the same folder as the typechecking stuff. I don't know if they should be further organized into separate folders.

Finally returning back to this. @rachitnigam I might be misunderstanding something but I don't think Scala supports having a single file in different namespaces. Scala does support this:
package org.myproject
package tests

However, this doesn't mean that the file is in two different namespaces. But rather that it is in the namespace org.myproject.tests. The reason to write this with 2 package statements rather than 1 is so that both things from org.myproject and org.myproject.tests are available in the file.
Here's a blog post about this: https://www.artima.com/scalazine/articles/chained_package_clauses_in_scala.html. This is from scala 2.8 so it's possible things have changed since then but I haven't found anything more recent.

Oh interesting! That setup does make more sense than a single file belonging in multiple packages.

Yo; what can I do to help get this ready to merge? Looks like the test runner just needs to get synced up (according to Circle), but then are we good to go? I can take a crack at that.

yes that should be it. Also could you verify the change that I made to get rid of two configs? To summarize, I just leave the backend as a string a little bit longer. I convert it to a proper backend right before we are going to use the backend rather than at command line parse time

OK, I got the test runner working again (and Circle seems to agree).
I liked the "move backend instantiation until later" thing, @sgpthomas, but I tweaked it a little: instead of literally being strings, I made a little "enum" (not really an enum) describing the possible backends. Should be a tad more type safe.
If this looks OK to @rachitnigam, let's merge this! Then @KarlMobed's new backend can hook itself in using the new style.

I even rebased to resolve conflicts with master. I hope you're happy, @rachitnigam. 😆


Remove dead code from daemon/daemon.go

In *Daemon.register:
			var err error
			cmd.ProcessConfig.Process, err = os.FindProcess(existingPid)
			if err != nil {
				logrus.Debugf("cannot find existing process for %d", existingPid)
			}

is dead code. We can rely on container.Pid without process start time anyway for killing processes.

I would like to work on it.

@toliaqat Ok, it's yours.

@toliaqat Next time you can just post comment #dibs and it will be claimed.

@toliaqat What's status here? Wanna give it to someone else?

#dibs Let me try again.


#165 login and register page is responsive now

issue #165

This pull request is intended to resolve the problem described in issue number #165
Both login and register pages are responsive now with suitable UI for smaller devices.
besides that I eliminated extra spaces in the footer
the nav is sticky now, and there is no need to add margin-top to all pages anymore

For showcase purposes, there are screenshots available

If you have any questions, please feel free to ask. Otherwise, please let me know if you are satisfied with the changes made by merging this PR. Thank you, skyDe

LGTM

@ItsRoy69 Hi, may I ask you a favor? I'd appreciate it if you could take a look at my Portfolio and other projects. Please let me know what you think about them, and if you like them, please give them a STAR. All public projects can be found in the PROJECTS section of my portfolio. Within that section, you can find live demo links as well as repository links related to each project.And if you like my project please mention other colleagues of these projects here to check my Portfolio , thanks thanks


🐛 [firebase_ui_auth] User unable to add photo to ProfileScreen page if registering via email and password

Bug report
Describe the bug
I was exploring using this package for a profile/account page and I'm satisified with it for google sign in, but if a user registers via email and password they don't have an option to upload their own photo.
Steps to reproduce
Steps to reproduce the behavior:

Register a user with the package with email and password
Navigate to the ProfileScreen page from the package
You will be unable to add a photo

Expected behavior
I expected a photo add button on the blank photo.

Thanks for the report. Seeing same behavior as reported.

/cc @lesnitsky

I'd love to help out and contribute, but I'd need a little guidance.

That one is a bit tricky, since firebase_auth does not allow changing profile photo URL (it comes from OAuth providers only), but we have plans on implementing firebase_storage related widgets, after we have those it would be possible to update the avatar with some additional configuration.