feat(Algebra/QuadraticDiscriminant):  add discrim_eq_zero_iff_exist_unique

Adds the lemma discrim_eq_zero_iff_exist_unique which states that a quadratic function has a unique root if and only if its discriminant is zero.

Unfortunately we do not accept PRs from forks for CI reasons; please see our contribution guidelines to find out how to submit a contribution.
We definitely want this lemma or something similar to it, so please do not take this as a rejection of this work!


Non-string-literal conf(default) values are silently broken

Example code:
use structconf::{clap, StructConf};

#[derive(Debug,strum_macros::EnumString,strum_macros::Display)]
enum Lol {
    Qqq,
    Www,
}

impl Default for Lol {
    fn default() -> Self {
        Lol::Qqq
    }
}

#[derive(Debug, StructConf)]
struct ServerConfig {
    #[conf(help = "The public key")]
    pub public_key: String,
    #[conf(no_file, long = "your-secret", help = "Your secret API key")]
    pub secret_key: String,

    #[conf(section = "Planes", default = "100", help="timeout in seconds")]
    pub timeout: i32,

    #[conf(section = "Planes", default=Lol::Www, help="vvv")]
    pub vvv: Lol,
}

With default="Lol::Www" instead of default=Lol::Www it works OK.
But with unquoted value, it

Still require impl Default for Lol.
Explicit default value is ignored
Value becomes overrideable only from command line, not from file.

I expect non-string-literal default values either to work as expected or to fail at macro extend time.

With default="Lol::Www" instead of default=Lol::Www it works OK.

Yea I'm not sure if I can do anything about that. The attributes are parsed by the darling crate, which requires ". In my case it doesn't even compile without the quotes, so not sure what you mean with the list. I get the following error:
❯ cargo run --example showcase
   Compiling structconf v0.4.0 (/home/mario/Programming/structconf)
error: Couldn't parse attribute: Unable to parse attribute: expected literal
  --> examples/showcase.rs:15:17
   |
15 | #[derive(Debug, StructConf)]
   |                 ^^^^^^^^^^
   |
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for mo
re info)

error[E0599]: no function or associated item named `parse` found for struct `ServerConfig` in the current
 scope
  --> examples/showcase.rs:31:34
   |
16 | struct ServerConfig {
   | ------------------- function or associated item `parse` not found for this
...
31 |     let mut conf = ServerConfig::parse(app, "config.ini");
   |                                  ^^^^^ function or associated item not found in `ServerConfig`
   |
   = help: items from traits can only be used if the trait is implemented and in scope
   = note: the following trait defines an item `parse`, perhaps you need to implement it:
           candidate #1: `StructConf`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0599`.
error: could not compile `structconf`

To learn more, run the command again with --verbose.

Maybe it was some stale cache and full, nonincremental rebuild would have revealed the problem?

Yeah it must have been something else. Closing this then.


Mockoon DOWN

🚨 Service Alert: Check the details below
Monitor Details

Monitor Name: Mockoon
Incident Status: TRIGGERED
Severity: critical
Monitor Status: DOWN
Monitor Health Checks: 1
Monitor Failure Threshold: 1

Actions

View Monitor

[start_datetime:1732956660] [end_datetime:1732936980]

The incident has been auto resolved
Total downtime: 2 minutes


Memoize result for a given input

A great optimization, I believe, would be to memoize the source update results depending on the input.
Example:

Type "foo", takes 10s to compute.
Type "bar", takes 15s to compute.
Type "foo" again.

With the current prompter, the last "foo" would take another 10s.  With memoization, it would be instantaneous.
In terms of memory, I don't believe it's a big deal since prompters are short-lived objects.

Yeah, boolean toggle is the best solution here. But I'm somewhat cautious about setting it to T by default—seems like a potential foot-shooting behavior.
I mean, in case of Nyxt we can add a proxy source class with memoize-p set to T, but in the prompter itself I'd rather have it at NIL to not cause Heisenbugs downstream.

Fair enough, it's super easy to subclass prompter anyways :)


Bug in Bitwise operator

Describe the bug

In bitwise operator under hexadecimal number system i am not able to take input in alphabets

Screenshots

Hi, I want to work on this issue I will start working on it from 3rd April. I am a part of GSSoC'21.
Kindly assign this issue to me!
Discord Username : Abhijeet Sinha(P)
Discord Tag: #4018

Go ahead
Deadline 5 April,2021 11:59 PM IST

@sairish2001 kindly assign this issue to me under GSSOC'21

is this issue still open? can i work on this issue?
as deadline is over

@sairish2001 can I work on this issue?


What observation space/environmet were the pre-trained Atart DQN agents trained using?

Describe the bug
Unable to load the pre-trained Atari DQN agents because the observation space doesn't match the Atari environment observation space.
Code example
(Using the Space Invaders model copied from the trained_agents directory.)
env = make_atari('SpaceInvadersNoFrameskip-v4')
model = DQN.load('../../atari-models/SpaceInvadersNoFrameskip-v4.pkl')
obs = env.reset()

action, _states = model.predict(obs)
obs, rewards, dones, info = env.step(action)

plt.imshow(obs)
plt.show()

Error Message
ValueError                                Traceback (most recent call last)
<ipython-input-21-4057e0f0b223> in <module>
      3 obs = env.reset()
      4
----> 5 action, _states = model.predict(obs)
      6 obs, rewards, dones, info = env.step(action)
      7

~/miniconda3/envs/baselines/lib/python3.6/site-packages/stable_baselines/common/base_class.py in predict(self, observation, state, mask, deterministic)
    717             mask = [False for _ in range(self.n_envs)]
    718         observation = np.array(observation)
--> 719         vectorized_env = self._is_vectorized_observation(observation, self.observation_space)
    720
    721         observation = observation.reshape((-1,) + self.observation_space.shape)

~/miniconda3/envs/baselines/lib/python3.6/site-packages/stable_baselines/common/base_class.py in _is_vectorized_observation(observation, observation_space)
    647                                  "Box environment, please use {} ".format(observation_space.shape) +
    648                                  "or (n_env, {}) for the observation shape."
--> 649                                  .format(", ".join(map(str, observation_space.shape))))
    650         elif isinstance(observation_space, gym.spaces.Discrete):
    651             if observation.shape == ():  # A numpy array of a number, has shape empty tuple '()'

ValueError: Error: Unexpected observation shape (210, 160, 3) for Box environment, please use (84, 84, 4) or (n_env, 84, 84, 4) for the observation shape.

System Info
Describe the characteristic of your environment:

Stable baselines installed following README instructions in a isolated conda environment.

GPU models and configuration: single RTX 2070 GPU.

Python version: 3.6.8

Tensorflow version: 1.14

Hello,
Please look at the code or the documentation, you must use make_atari_env and VecFrameStack.

Thanks for the heads up! I hadn't clicked on the difference between make_atari and make_atari_env.


Flotato Apps not displaying correctly

Describe the bug
A clear description of what the bug is.
Apps created using “Flotato” do not display seperate icons in the touchbar, but do so in the actual dock.
How to reproduce
Steps to reproduce the behavior:
Create and open multiple apps with Flotato
Expected behavior
A clear description of what you expected to happen.
Seperate icons should display for seperately docked items
Screenshots
If applicable, add screenshots to help explain your problem.
To take a Touch Bar screenshot use the shortcut "shift + cmd + 6”
Twitter and Github are apps created using Flotato

Crashlog
If applicable, add crashlog to help me investigate your problem.
Not Applicable
Versions:

macOS version: 10.14.5
Pock version:  0.5.3

Additional context
Add any other context about the problem here.

flatato apps


xSQLServerConfiguration: Allow Multiple DB Instances on One Box

We have updated the MSFT_xSQLServerConfiguration.schema.mof file so the parameter SQLInstance is now a Key.
We have also updated the MSFT_xSQLServerConfiguration.psm1 file so the parameter SQLInstance is mandatory. (This fixed a broken unit test but really we should've done this ourselves for consistency...).
This proposed change allows the SQLServerConfiguration resource to configure multiple instances on the same box as every schema.mof file entry will be uniquely named.
This Pull Request (PR) fixes the following issues:
n/a

[x] Change details added to Unreleased section of CHANGELOG.md?
[x] Added/updated documentation, comment-based help and descriptions in .schema.mof files where appropriate?
[x] Examples appropriately updated?
[x] New/changed code adheres to Style Guidelines?
[x] Unit and (optional) Integration tests created/updated where possible?

This change is

Hi @OmarRizla, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;

The failing unit tests are nothing to do with our pull request...

Reviewed 1 of 2 files at r2.
Review status: 1 of 3 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

CHANGELOG.md, line 10 at r2 (raw file):

- Changes to xSQLServerRole
  - xSQLServerRole now correctly reports that the desired state is present when the login is already a member of the server roles

Please remove this line and the tests will pass. Double blank lines is not allowed by the test.
You can just push changes to your branch in your fork and that will automatically update this PR.

Comments from Reviewable

Thanks Johan
I'll do it tomorrow
Omar
Sent from my iPhone
On 1 Feb 2017, at 19:18, Johan Ljunggren <notifications<EMAIL_ADDRESS>wrote:
Reviewed 1 of 2 files at r2.
Review status: 1 of 3 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

CHANGELOG.md, line 10 at r2https://reviewable.io:443/reviews/powershell/xsqlserver/359#-Kbv5_2QQ_cUwUdsXJ8y:-Kbv5_2QQ_cUwUdsXJ8z:b-2t5zfc (raw filehttps://github.com/powershell/xsqlserver/blob/cd7a7a6545dc3d4b9bdf202f758a47b43857e9af/CHANGELOG.md#L10):

Changes to xSQLServerRole

xSQLServerRole now correctly reports that the desired state is present when the login is already a member of the server roles

Please remove this line and the tests will pass. Double blank lines is not allowed by the test.
You can just push changes to your branch in your fork and that will automatically update this PR.

Comments from Reviewablehttps://reviewable.io:443/reviews/powershell/xsqlserver/359

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/xSQLServer/pull/359#issuecomment-276752800, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQ6QKF2VvtiodSGMjY7Wi5n-rWc8zt5tks5rYNpogaJpZM4Lzwn2.

@OmarRizla Would you be so kind to go into Reviewable and Write 'Done' on the the review comments that you solved (only one so far). Then I can resolve the discussions.
In the PR description (first PR comment) you find a purple button that takes you to Reviewable. When you answered on all comments (drafts are save for each comment you type) you then click Publish at the top of the page. That will publish all your comments back to GitHub.
I will start the rest of the review as soon as I have a chance.
Thanks!

Done

Review status: 0 of 3 files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

Thanks for the speedy response...

Review status: 0 of 3 files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

Done
Thanks for the speedy response
Sent from my iPhone
On 2 Feb 2017, at 10:22, Johan Ljunggren <notifications<EMAIL_ADDRESS>wrote:
@OmarRizlahttps://github.com/OmarRizla Would you be so kind to go into Reviewable and Write 'Done' on the the review comments that you solved (only one so far). Then I can resolve the discussions.
In the PR description (first PR comment) you find a purple button that takes you to Reviewable. When you answered on all comments (drafts are save for each comment you type) you then click Publish at the top of the page. That will publish all your comments back to GitHub.
I will start the rest of the review as soon as I have a chance.
Thanks!

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/xSQLServer/pull/359#issuecomment-276919702, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQ6QKDaxZ4lBlBOTJ3vLAjEJMkhTAPhQks5rYa5ZgaJpZM4Lzwn2.

Reviewed 1 of 2 files at r1, 1 of 2 files at r2, 1 of 1 files at r3.
Review status: all files reviewed at latest revision, 5 unresolved discussions.

CHANGELOG.md, line 6 at r3 (raw file):

Updated xSQLServerConfiguration.schema.mof so SQLInstance parameter is now a Key. This allows for the use case scenario where there are multiple DB Instances on one box.

Please change to something like this:

BREAKING CHANGE: Resource can now be used to change configuration on two different instances on the same server. Now parameter SQLInstanceName is mandatory.

DSCResources/MSFT_xSQLServerConfiguration/MSFT_xSQLServerConfiguration.psm1, line 40 at r3 (raw file):

        [Parameter(Mandatory = $true)]
        [String]
        $SQLInstanceName = 'MSSQLSERVER',

Please remove the default value as it not necessary any more.

DSCResources/MSFT_xSQLServerConfiguration/MSFT_xSQLServerConfiguration.psm1, line 109 at r3 (raw file):

        [Parameter(Mandatory = $true)]
        [String]
        $SQLInstanceName = 'MSSQLSERVER',

Please remove the default value as it not necessary any more.

DSCResources/MSFT_xSQLServerConfiguration/MSFT_xSQLServerConfiguration.psm1, line 189 at r3 (raw file):

        [Parameter(Mandatory = $true)]
        [String]
        $SQLInstanceName = 'MSSQLSERVER',

Please remove the default value as it not necessary any more.

DSCResources/MSFT_xSQLServerConfiguration/MSFT_xSQLServerConfiguration.schema.mof, line 5 at r3 (raw file):

{
    [Key, Description("The hostname of the SQL Server to be configured")] String SQLServer;
    [Key, Description("Name of the SQL instance to be configured. Default is 'MSSQLSERVER'")] String SQLInstanceName;

Please remove the reference to the default value in the description as it not necessary any more.
Please change the type qualifier from Write to Key in the README.md for the resource.
Also in the README.md move the parameter SQLInstanceName so it is under the other parameters that are keys.

Comments from Reviewable

Review status: 0 of 4 files reviewed at latest revision, 5 unresolved discussions.

CHANGELOG.md, line 6 at r3 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

Updated xSQLServerConfiguration.schema.mof so SQLInstance parameter is now a Key. This allows for the use case scenario where there are multiple DB Instances on one box.

Please change to something like this:

BREAKING CHANGE: Resource can now be used to change configuration on two different instances on the same server. Now parameter SQLInstanceName is mandatory.

Updated Changelog.md appropriately...

DSCResources/MSFT_xSQLServerConfiguration/MSFT_xSQLServerConfiguration.psm1, line 40 at r3 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please remove the default value as it not necessary any more.

Done.

DSCResources/MSFT_xSQLServerConfiguration/MSFT_xSQLServerConfiguration.psm1, line 109 at r3 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please remove the default value as it not necessary any more.

Done.

DSCResources/MSFT_xSQLServerConfiguration/MSFT_xSQLServerConfiguration.psm1, line 189 at r3 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please remove the default value as it not necessary any more.

Done.

DSCResources/MSFT_xSQLServerConfiguration/MSFT_xSQLServerConfiguration.schema.mof, line 5 at r3 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please remove the reference to the default value in the description as it not necessary any more.
Please change the type qualifier from Write to Key in the README.md for the resource.
Also in the README.md move the parameter SQLInstanceName so it is under the other parameters that are keys.

Done.

Comments from Reviewable

Review status: 0 of 4 files reviewed at latest revision, 5 unresolved discussions.

CHANGELOG.md, line 6 at r3 (raw file):
Previously, OmarRizla (Omar Rizwani) wrote…
Updated Changelog.md appropriately...

Done.

Comments from Reviewable

Would you mind adding an example file for this resource? If so, please add the resource twice in the configuration so that it sets a configuration option in two different instances.
See folder structure and example template from an existing example
https://github.com/PowerShell/xSQLServer/tree/dev/Examples/Resources/xSQLServerLogin

Reviewed 4 of 4 files at r4.
Review status: all files reviewed at latest revision, 2 unresolved discussions.

CHANGELOG.md, line 6 at r3 (raw file):
Previously, OmarRizla (Omar Rizwani) wrote…
Done.

Please add that 'Parameter SQLInstanceName is mandatory' (that is the actual breaking change).

README.md, line 228 at r4 (raw file):

#### Parameters

* **[String] SQLServer** _(Key)_: The hostname of the SQL Server to be configured

Would you mind helping me add a full stop (.) to the end of each sentence in these descriptions?

DSCResources/MSFT_xSQLServerConfiguration/MSFT_xSQLServerConfiguration.schema.mof, line 4 at r4 (raw file):

class MSFT_xSQLServerConfiguration : OMI_BaseResource
{
    [Key, Description("The hostname of the SQL Server to be configured")] String SQLServer;

Would you mind helping me add a full stop (.) to the end of each sentence in these descriptions?

Comments from Reviewable

Added 1st draft of example...

Review status: 1 of 5 files reviewed at latest revision, 3 unresolved discussions.

CHANGELOG.md, line 6 at r3 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please add that 'Parameter SQLInstanceName is mandatory' (that is the actual breaking change).

Done.

README.md, line 228 at r4 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Would you mind helping me add a full stop (.) to the end of each sentence in these descriptions?

Done.

DSCResources/MSFT_xSQLServerConfiguration/MSFT_xSQLServerConfiguration.schema.mof, line 4 at r4 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Would you mind helping me add a full stop (.) to the end of each sentence in these descriptions?

Done.

Comments from Reviewable

Thanks for fixing an example! :smile: Just a few comments about style and then I think this is good to go as soon as the tests passes. Tests should pass after these comments are fixed I hope. :)

Reviewed 4 of 4 files at r5.
Review status: all files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

CHANGELOG.md, line 7 at r5 (raw file):

- Changes to xSQLServerConfiguration
  - BREAKING CHANGE: The parameter SQLInstanceName is now mandatory.
  - Resource can now be used to define the configuration of two or more different DB instances on the same server.

There is a white space at the end here, it makes the tests fail.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 3 at r5 (raw file):

<#
.EXAMPLE
	This example shows how to configure 2 DB Instances on the same server to have CLR enabled.

Tabs is used throughout the file.  Please change to use 4 white spaces instead of tabs.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 4 at r5 (raw file):

.EXAMPLE
	This example shows how to configure 2 DB Instances on the same server to have CLR enabled.
	The DSC configuration & data is compiled and run from a C:\Temp directory.

You can remove this line

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 5 at r5 (raw file):

	This example shows how to configure 2 DB Instances on the same server to have CLR enabled.
	The DSC configuration & data is compiled and run from a C:\Temp directory.

Please remove this blank line.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 8 at r5 (raw file):

#>

$configData = @{

Please change the Configuration data block to this:
$configurationData = @{
AllNodes = @(
@{
NodeName = 'localhost'
SQLInstances = @('CONTENT', 'DIST')
OptionName = 'clr enabled'
}
)
}

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 26 at r5 (raw file):

        foreach ($SQLInstance in $node.SQLInstances) {

			xSQLServerConfiguration ("SQLConfigCLR_{0}" -f $SQLInstance) {

Please change " (double quotes) to ' (single quotes).

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 37 at r5 (raw file):

}

Example -ConfigurationData $configData

Please remove this line (the test will run the actual configuration).

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 39 at r5 (raw file):

Example -ConfigurationData $configData

Start-DscConfiguration -Path "C:\temp\Example" -Force -Wait -Verbose

Please remove this line (this will be done through a integration test in the future).
Please end the file with a blank line (otherwise the tests will fail).

Comments from Reviewable

Cheers Johan
I'll fix this all on Monday
Omar
Sent from my iPhone
On 4 Feb 2017, at 10:28, Johan Ljunggren <notifications<EMAIL_ADDRESS>wrote:
Thanks for fixing an example! ? Just a few comments about style and then I think this is good to go as soon as the tests passes. Tests should pass after these comments are fixed I hope. :)

Reviewed 4 of 4 files at r5.
Review status: all files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

CHANGELOG.md, line 7 at r5https://reviewable.io:443/reviews/powershell/xsqlserver/359#-Kc7aAOZ8HIz9e5K-x0y:-Kc7aAOZ8HIz9e5K-x0z:b345a1e (raw filehttps://github.com/powershell/xsqlserver/blob/72bbd6b1fba135c0d77ec2709195145b209d8832/CHANGELOG.md#L7):

Changes to xSQLServerConfiguration

BREAKING CHANGE: The parameter SQLInstanceName is now mandatory.
Resource can now be used to define the configuration of two or more different DB instances on the same server.

There is a white space at the end here, it makes the tests fail.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 3 at r5https://reviewable.io:443/reviews/powershell/xsqlserver/359#-Kc7aRbMSsAScj6MWLBl:-Kc7aRbMSsAScj6MWLBm:b-q307pj (raw filehttps://github.com/powershell/xsqlserver/blob/72bbd6b1fba135c0d77ec2709195145b209d8832/Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1#L3):
<#
.EXAMPLE
This example shows how to configure 2 DB Instances on the same server to have CLR enabled.
Tabs is used throughout the file. Please change to use 4 white spaces instead of tabs.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 4 at r5https://reviewable.io:443/reviews/powershell/xsqlserver/359#-Kc7cHCTvEGxpyU6H6dw:-Kc7cHCTvEGxpyU6H6dx:b-sd0fbk (raw filehttps://github.com/powershell/xsqlserver/blob/72bbd6b1fba135c0d77ec2709195145b209d8832/Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1#L4):
.EXAMPLE
This example shows how to configure 2 DB Instances on the same server to have CLR enabled.
The DSC configuration & data is compiled and run from a C:\Temp directory.
You can remove this line

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 5 at r5https://reviewable.io:443/reviews/powershell/xsqlserver/359#-Kc7aavGHSlDrswR6-wj:-Kc7aavGHSlDrswR6-wk:br35j1z (raw filehttps://github.com/powershell/xsqlserver/blob/72bbd6b1fba135c0d77ec2709195145b209d8832/Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1#L5):
    This example shows how to configure 2 DB Instances on the same server to have CLR enabled.
    The DSC configuration & data is compiled and run from a C:\Temp directory.

Please remove this blank line.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 8 at r5https://reviewable.io:443/reviews/powershell/xsqlserver/359#-Kc7duwm1kZBIllHSfZH:-Kc7duwnjS9JeACD8nOw:b-ftmsho (raw filehttps://github.com/powershell/xsqlserver/blob/72bbd6b1fba135c0d77ec2709195145b209d8832/Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1#L8):
#>
$configData = @{
Please change the Configuration data block to this:
$configurationData = @{
AllNodes = @(
@{
NodeName = 'localhost'
SQLInstances = @('CONTENT', 'DIST')
OptionName = 'clr enabled'
}
)
}

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 26 at r5https://reviewable.io:443/reviews/powershell/xsqlserver/359#-Kc7dfLouRvWex9LfzAc:-Kc7dfLouRvWex9LfzAd:b-6q3o8 (raw filehttps://github.com/powershell/xsqlserver/blob/72bbd6b1fba135c0d77ec2709195145b209d8832/Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1#L26):
    foreach ($SQLInstance in $node.SQLInstances) {

                    xSQLServerConfiguration ("SQLConfigCLR_{0}" -f $SQLInstance) {

Please change " (double quotes) to ' (single quotes).

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 37 at r5https://reviewable.io:443/reviews/powershell/xsqlserver/359#-Kc7b4ta1cpQBm6Vl724:-Kc7b4ta1cpQBm6Vl725:b-4gkrbl (raw filehttps://github.com/powershell/xsqlserver/blob/72bbd6b1fba135c0d77ec2709195145b209d8832/Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1#L37):
}
Example -ConfigurationData $configData
Please remove this line (the test will run the actual configuration).

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 39 at r5https://reviewable.io:443/reviews/powershell/xsqlserver/359#-Kc7bBw3hD32-EemlhGk:-Kc7bBw3hD32-EemlhGl:b6qe3ui (raw filehttps://github.com/powershell/xsqlserver/blob/72bbd6b1fba135c0d77ec2709195145b209d8832/Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1#L39):
Example -ConfigurationData $configData
Start-DscConfiguration -Path "C:\temp\Example" -Force -Wait -Verbose
Please remove this line (this will be done through a integration test in the future).
Please end the file with a blank line (otherwise the tests will fail).

Comments from Reviewablehttps://reviewable.io:443/reviews/powershell/xsqlserver/359#-:-Kc7bYJAJfg-RPX2mSfl:b-2rsxti

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/xSQLServer/pull/359#issuecomment-277434133, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQ6QKKWV6TsaSMOp7RjL43EeaTxKkOB-ks5rZFLegaJpZM4Lzwn2.

Review status: 3 of 5 files reviewed at latest revision, 8 unresolved discussions.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 3 at r5 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Tabs is used throughout the file.  Please change to use 4 white spaces instead of tabs.

Done.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 4 at r5 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
You can remove this line

Done.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 5 at r5 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please remove this blank line.

Done.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 8 at r5 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please change the Configuration data block to this:
$configurationData = @{
AllNodes = @(
@{
NodeName = 'localhost'
SQLInstances = @('CONTENT', 'DIST')
OptionName = 'clr enabled'
}
)
}

Done.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 26 at r5 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please change " (double quotes) to ' (single quotes).

Done.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 37 at r5 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please remove this line (the test will run the actual configuration).

Done.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 39 at r5 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please remove this line (this will be done through a integration test in the future).
Please end the file with a blank line (otherwise the tests will fail).

Done.

Comments from Reviewable

Just one small change, then it is good to go!

Reviewed 2 of 2 files at r6.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 6 at r6 (raw file):

#>

$configData = @{

Please change the variable name to $configurationData.
This is so it is generic and can be found by the tests.

Comments from Reviewable

Review status: 4 of 5 files reviewed at latest revision, 1 unresolved discussion.

Examples/Resources/xSQLServerConfiguration/1-Configure2DBInstances.ps1, line 6 at r6 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please change the variable name to $configurationData.
This is so it is generic and can be found by the tests.

Done.

Comments from Reviewable

Reviewed 1 of 1 files at r7.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Thanks Johan...
Does that mean that the next release of xSQLServer may have those changes in it?
Omar

From: Johan Ljunggren<EMAIL_ADDRESS>Sent: 08 February 2017 16:55:01
To: PowerShell/xSQLServer
Cc: Omar Rizwani; Mention
Subject: Re: [PowerShell/xSQLServer] BREAKING CHANGE: xSQLServerConfiguration: Allow multiple instances on one box (#359)
Merged #359https://github.com/PowerShell/xSQLServer/pull/359.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/xSQLServer/pull/359#event-954173211, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQ6QKIt_KsgNnWvNue9OLttNaXEYYiPEks5rafNlgaJpZM4Lzwn2.

@OmarRizla Yes it does. For now you can download the dev branch. But when next version get released your changes will be in that release.
Thanks for contributing! Hope to see you here again! 😄

Great
Thanks for your help and patience Johan...
Omar
Sent from my iPhone
On 8 Feb 2017, at 17:32, Johan Ljunggren <notifications<EMAIL_ADDRESS>wrote:
@OmarRizlahttps://github.com/OmarRizla Yes it does. For now you can download the dev branch. But when next version get released your changes will be in that release.
Thanks for contributing! Hope to see you here again! 😄
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/xSQLServer/pull/359#issuecomment-278400466, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQ6QKCu5ficvZvrfPuuwxQV255hGSyhdks5rafvngaJpZM4Lzwn2.


unexpected error on kernel 5.11

Hi,
i am trying lgpio in python on ubuntu 21.04 with kernel 5.11 but i get 'unexpected error' when calling 'gpio_claim_output ()' function.
with kernel 5.8 lgpio it works

@amo93-2020
Thanks for the issue.  I have had a quick look and there does appear to be a problem.
I am not sure when I'll have time to look into this properly.  It may take a day or two.

I have looked a little bit more.  The /dev/gpiochip API has been broken by the introduction of v2 of the API.  To say the least I am not impressed.
It will probably take a day or so to judge the ramifications of the various API breaks.

thanks for the support!, hope you can update this soon

Just an update.  It'll be several more days at least before I prepare a new release, probably by Sunday at the latest.

@amo93-2020 Is this the error you are getting?
Traceback (most recent call last):
  File "/home/ubuntu/blink_test.py", line 14, in <module>
    lgpio.gpio_claim_output(h, LED)
  File "/usr/lib/python3/dist-packages/lgpio.py", line 773, in gpio_claim_output
    return _u2i(_lgpio._gpio_claim_output(handle&0xffff, lFlags, gpio, level))
  File "/usr/lib/python3/dist-packages/lgpio.py", line 461, in _u2i
    raise error(error_text(v))
lgpio.error: 'GPIO busy'

@joan2937 If you need help making updates I'd me more than happy to help 😄  - Although keep  in mind  I come from a blissful world of nodejs, web development. I. have never created programs like this so there will be some learning curve initially

@stephanrotolante
Thanks for the offer.
The problem at the moment isn't the code changes which need to be made, it's more to do with deciding if I want to deprecate parts of the existing lg API  to accommodate the changes to the /dev/gpiochip API or not.
I think I've come to the conclusion that I will incorporate the changes without breaking the existing lg API.
Given the way the kernel people have implemented the /dev/gpiochip API I can see there will be more breakages downstream (I can see /dev/gpiochip API2 being broken by /dev/gpiochip API3).

Perfect!
Now the library also works with the 5.11 kernel.
thank's for your job

I have looked a little bit more. The /dev/gpiochip API has been broken by the introduction of v2 of the API. To say the least I am not impressed.

Can you provide some detail as to what you found that was broken, as the uAPI v2 should not have altered the uAPI v1 at all.  That was certainly the intent and the change did not impact libgpiod nor any of the other libraries using the uAPI that I am aware of.
IIRC, there may've been some tightening up of the unused sections of the structs, which must now be zeroed, but that was unrelated to the introduction of uAPI v2.
I'm only running across this ticket now by accident, and it would've been good if you could've dropped us a line at the time, but I would still like to understand your problem.  To say the least...


Error when installing WSA on windows 11

Hi, during installation WSA I got into trouble and tried different ways. I am attaching an error screenshot. Thank you for your help.

Hey, I got this issue, and they way i solved it is to install WSA first from microsoft store then uninstalling it. It installs some framework. Then you can register moded wsa. If microsoft haven't roll out wsa in your country, you can just change the country in your setting and do a reboot.

Yeah, installing and uninstalling anything that needs the framework from the store will automatically fix any dependencies issues, doesn't have to be the exact same app either but its the easiest way to make sure

or you can pull the framework package separately and install it that way, its just a appx

or you can pull the framework package separately and install it that way, its just a appx

wow i didn't know that, can you tell me ho to do exactly? I am qute a noob in all this, but eager to learn...


For reading external trigger files, we need to give µMUX data a sub-frame rate

Original report by Joseph Fowler (Bitbucket: joe_fowler, ).

The number of rows in a µMUX LJH file is None. We need to treat that as 64 (or better, pass it on from Dastard), in order to understand the sub-frame timing of the external trigger time.
Idea: put that information into the string line that starts out the external trigger file. Yeah, that would be cool.

Original comment by Joseph Fowler (Bitbucket: joe_fowler, ).

Parse number of equiv rows from ext trig file
Fixes #263.


search bar is very white after i apply your materialfox

i dunno if this is a bug i hope sir you help me.
Screenshots

System info

OS: [e.g. ubuntu 18.4]
Firefox version: [e.g. 75]

Additional context
Add any other context about the problem here.

Hey, I also ran into this problem. In the meantime, you can try one of the two following options:

Use the Dark theme in Firefox (this should take away the white background color, tested on 78.0.2 - 64 bit - Linux)
If you go with the Default theme, you can edit the variables in line 151 of global/variables.css. This variable control the background color of the search bar when you type something into it. It is used in line 199 of urlbar/urlbar.css.

I would suggest option 1 since its the easier of the two.

This might be due to some differences in how the default Linux theme is styled in Firefox, causing some clashing colours. I'd recommend either using the light theme or the dark theme. I try to enforce the light theme even if the default theme is applied, and it seems like I'm enforcing some bits and maybe not other bits...
Will see if I can improve it once I have access to a Linux distro but I don't tend to do this very often.

Using the Dark Theme of Firefox works really well.

The only negative thing about using the dark them of firefox, is that most form boxes that I encounter are black. The text that I type in them is also black and so it's hard to make out what I type in. Does anyone know how to fix this?
Example of what I mean:


Document fern write-definition CLI command

̶̶f̶e̶r̶n̶ ̶i̶n̶i̶t̶ ̶-̶-̶o̶p̶e̶n̶a̶p̶i̶ ̶f̶e̶r̶n̶/̶a̶p̶i̶/̶o̶p̶e̶n̶a̶p̶i̶/̶o̶p̶e̶n̶a̶p̶i̶.̶y̶m̶l̶̶
̶^̶ ̶c̶r̶e̶a̶t̶e̶s̶ ̶f̶e̶r̶n̶ ̶w̶o̶r̶k̶s̶p̶a̶c̶e̶
fern write-definition
^ converts openapi workspace to fern definition

fern init --openapi is documented here https://buildwithfern.com/docs/spec/openapi
fern write-definition this is hidden in the cli help message because it's more for our own debugging. I think if we do want to make it public we should have a better command than fern write-definition

@zachkirsch fern convert ?


python311Packages.http-sfv: 0.9.8 -> 0.9.9, python311Packages.http-sf: init at 1.0.1

Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 283753 run on x86_64-linux 1

16 packages built:

python311Packages.http-message-signatures
python311Packages.http-message-signatures.dist
python311Packages.http-sf
python311Packages.http-sf.dist
python311Packages.http-sfv
python311Packages.http-sfv.dist
python311Packages.requests-http-signature
python311Packages.requests-http-signature.dist
python312Packages.http-message-signatures
python312Packages.http-message-signatures.dist
python312Packages.http-sf
python312Packages.http-sf.dist
python312Packages.http-sfv
python312Packages.http-sfv.dist
python312Packages.requests-http-signature
python312Packages.requests-http-signature.dist


Can't exploit data in grafana

Hi,
Seems that the keys are sent but they are not processed correctly by Influx. (influxdb-backend 0.6)
In my Grafana dashboard I have something like that where the dropdown is taking 10 sec to process :

Istead of having (like Graphite)
servers then choose the server I want data from, it just stores the entire key of all metrics sent.
A partial screenshot from the query SHOW SERIES:

This has nothing to do with this backend. It's an InfluxDB/Grafana problem:
http://docs.grafana.org/datasources/influxdb/:

"The InfluxDB 0.9.x editor is currently under development and is not yet fully usable."

Closing this because it's an Grafana issue.


Remove gfpgan_dir

gfpgan_dir is no longer needed because we are now installing gfpgan directly to the env. The user can just pass the path to the model file directly now using --gfpgan_model_path if they want to use a custom path for the checkpoint.

@lstein I want another review on this before I merge. Thank you.

I've made changes to how and where the gfpgan model files are handled in the current release candidate, and would like to hold off on this until those changes are merged into main and development. Shouldn't be more than another day, pending install testing.

are they being sent to models/gfpgan? I can change the paths to that

I've made changes to how and where the gfpgan model files are handled in the current release candidate, and would like to hold off on this until those changes are merged into main and development. Shouldn't be more than another day, pending install testing.

are they being sent to models/gfpgan/weights? I can change the paths to that

Yes, you should. Although I must already have done this in the release candidate because it's working :-). models currently looks like this:
models
├── clipseg
│   └── clipseg_weights
│       ├── rd16-uni.pth
│       ├── rd64-uni-refined.pth
│       └── rd64-uni.pth
├── gfpgan
│   ├── GFPGANv1.4.pth
│   └── weights
│       ├── detection_Resnet50_Final.pth
│       └── parsing_parsenet.pth
└── ldm
    └── stable-diffusion-v1
        ├── kl-f8-anime.ckpt
        ├── model-epoch09-float32.ckpt
        ├── model-epoch09-float32.sha256
        ├── place-ckpt-files-here.txt
        ├── sd-v1-5-inpainting.ckpt
        ├── sd-v1-5-inpainting.sha256
        ├── v1-5-pruned-emaonly.ckpt
        ├── v1-5-pruned-emaonly.sha256
        ├── vae-ft-mse-840000-ema-pruned.ckpt
        ├── wd-1-3-penultimate-ucg-cont.ckpt
        └── wd-1-3-penultimate-ucg-cont.sha256

@lstein Done. Updated to the new paths according to the folder hierarchy you posted. Think I changed it across the entire app. Just do a double check and it should be good to go.


Initial Setup

I haven't made any changes to how the inputs are made yet, this is the original class setup.
I still have to move over the interaction parts of the old interactionService, but I feel that those can be put into their own class for clarity.
As I am not sure yet what the different platform implementations will change, I am not 100% sure as to what should be part of the abstract base class and what should be only in the derived class. I assume that will become more clear as I continue to learn more about what is going on here.

Is this PR dead?

PR abandoned. Closing.


update ktlint markdown

Update ktlint markdown as ktlint repo has been migrated to pinterest

Codecov Report

Merging #299 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master    #299   +/-   ##
======================================
  Coverage    91.2%   91.2%
======================================
  Files          47      47
  Lines        2900    2900
======================================
  Hits         2645    2645
  Misses        255     255

Continue to review full report at Codecov.

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


After upgrading rancher server and Kubernetes the rancher server became unstable

What kind of request is this (question/bug/enhancement/feature request):
BUG
Steps to reproduce (least amount of steps as possible):
I was running the following setup:

Rancher 2.1.0
Kubernetes 1.11.3
Longhorn 0.3.3

I updated the components in this chronological order:

Rancher 2.1.0 > 2.2.1
Longhorn 0.3.3 > 0.4.1
Kubernetes 1.11.3 > 1.11.9

Result:

The rancher server became totally instable. Memory is zig-zagging from almost 0 to max (8 GB)
Websocket connections from rancher ui to the server were closed randomly after some seconds
Deploying workloads through the ui have large delays, if they deploy at all

Other details that may be helpful:
Server Logs:
[main] 2019/04/02 10:52:32 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/04/02 10:52:32 GRPC listening on :38245
[main] 2019/04/02 10:52:32 Probes listening on :42408
[main] 2019/04/02 10:52:32 Storage driver is ConfigMap
[main] 2019/04/02 10:52:32 Max history per release is 0
[main] 2019/04/02 10:52:32 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/04/02 10:52:32 GRPC listening on :46114
[main] 2019/04/02 10:52:32 Probes listening on :34759
[main] 2019/04/02 10:52:32 Storage driver is ConfigMap
[main] 2019/04/02 10:52:32 Max history per release is 0
[tiller] 2019/04/02 10:52:32 getting history for release monitoring-operator
[storage] 2019/04/02 10:52:32 getting release history for "monitoring-operator"
[storage/driver] 2019/04/02 10:52:32 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
[tiller] 2019/04/02 10:52:32 preparing update for monitoring-operator
[storage] 2019/04/02 10:52:32 getting deployed releases from "monitoring-operator" history
[storage] 2019/04/02 10:52:32 getting last revision of "monitoring-operator"
[storage] 2019/04/02 10:52:32 getting release history for "monitoring-operator"
[storage/driver] 2019/04/02 10:52:32 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
2019/04/02 10:52:32 [ERROR] AppController p-rl4d9/monitoring-operator [helm-controller] failed with : failed to install app monitoring-operator. Error: UPGRADE FAILED: the server is currently unable to handle the request (get configmaps)

[main] 2019/04/02 10:52:32 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/04/02 10:52:32 GRPC listening on :42118
[main] 2019/04/02 10:52:32 Probes listening on :46974
[main] 2019/04/02 10:52:32 Storage driver is ConfigMap
[main] 2019/04/02 10:52:32 Max history per release is 0
[tiller] 2019/04/02 10:52:32 getting history for release monitoring-operator
[storage] 2019/04/02 10:52:32 getting release history for "monitoring-operator"
Release "monitoring-operator" does not exist. Installing it now.
[tiller] 2019/04/02 10:52:32 preparing install for monitoring-operator
[storage] 2019/04/02 10:52:32 getting release history for "monitoring-operator"
[tiller] 2019/04/02 10:52:33 failed install prepare step: the server is currently unable to handle the request
2019/04/02 10:52:33 [ERROR] AppController p-rl4d9/monitoring-operator [helm-controller] failed with : failed to install app monitoring-operator. Error: the server is currently unable to handle the request

[tiller] 2019/04/02 10:52:33 getting history for release cluster-alerting
[storage] 2019/04/02 10:52:33 getting release history for "cluster-alerting"
Release "cluster-alerting" does not exist. Installing it now.
[tiller] 2019/04/02 10:52:33 preparing install for cluster-alerting
[storage] 2019/04/02 10:52:33 getting release history for "cluster-alerting"
[main] 2019/04/02 10:52:33 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/04/02 10:52:33 GRPC listening on :58487
[main] 2019/04/02 10:52:33 Probes listening on :40695
[main] 2019/04/02 10:52:33 Storage driver is ConfigMap
[main] 2019/04/02 10:52:33 Max history per release is 0
[storage/driver] 2019/04/02 10:52:33 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
[tiller] 2019/04/02 10:52:33 failed install prepare step: the server is currently unable to handle the request
2019/04/02 10:52:33 [ERROR] AppController p-rl4d9/cluster-alerting [helm-controller] failed with : failed to install app cluster-alerting. Error: the server is currently unable to handle the request

[main] 2019/04/02 10:52:33 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/04/02 10:52:33 GRPC listening on :54323
[main] 2019/04/02 10:52:33 Probes listening on :49488
[main] 2019/04/02 10:52:33 Storage driver is ConfigMap
[main] 2019/04/02 10:52:33 Max history per release is 0
[tiller] 2019/04/02 10:52:34 getting history for release monitoring-operator
[storage] 2019/04/02 10:52:34 getting release history for "monitoring-operator"
Release "monitoring-operator" does not exist. Installing it now.
[tiller] 2019/04/02 10:52:34 preparing install for monitoring-operator
[storage] 2019/04/02 10:52:34 getting release history for "monitoring-operator"
[storage/driver] 2019/04/02 10:52:34 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
[tiller] 2019/04/02 10:52:34 failed install prepare step: Could not get apiVersions from Kubernetes: the server is currently unable to handle the request
2019/04/02 10:52:34 [ERROR] AppController p-rl4d9/monitoring-operator [helm-controller] failed with : failed to install app monitoring-operator. Error: Could not get apiVersions from Kubernetes: the server is currently unable to handle the request

[tiller] 2019/04/02 10:52:34 getting history for release cluster-alerting
[storage] 2019/04/02 10:52:34 getting release history for "cluster-alerting"
[main] 2019/04/02 10:52:34 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/04/02 10:52:34 GRPC listening on :40363
[main] 2019/04/02 10:52:34 Probes listening on :58446
[main] 2019/04/02 10:52:34 Storage driver is ConfigMap
[main] 2019/04/02 10:52:34 Max history per release is 0
Release "cluster-alerting" does not exist. Installing it now.
[tiller] 2019/04/02 10:52:34 getting history for release monitoring-operator
[storage] 2019/04/02 10:52:34 getting release history for "monitoring-operator"
[tiller] 2019/04/02 10:52:34 preparing install for cluster-alerting
[storage] 2019/04/02 10:52:34 getting release history for "cluster-alerting"
[storage/driver] 2019/04/02 10:52:34 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
[tiller] 2019/04/02 10:52:34 failed install prepare step: the server is currently unable to handle the request
2019/04/02 10:52:34 [ERROR] AppController p-rl4d9/cluster-alerting [helm-controller] failed with : failed to install app cluster-alerting. Error: the server is currently unable to handle the request

[tiller] 2019/04/02 10:52:34 preparing update for monitoring-operator
[storage] 2019/04/02 10:52:34 getting deployed releases from "monitoring-operator" history
[storage/driver] 2019/04/02 10:52:34 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
[storage] 2019/04/02 10:52:34 getting last revision of "monitoring-operator"
[storage] 2019/04/02 10:52:34 getting release history for "monitoring-operator"
[storage/driver] 2019/04/02 10:52:34 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
2019/04/02 10:52:35 [ERROR] AppController p-rl4d9/monitoring-operator [helm-controller] failed with : failed to install app monitoring-operator. Error: UPGRADE FAILED: the server is currently unable to handle the request (get configmaps)

[main] 2019/04/02 10:52:35 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/04/02 10:52:35 GRPC listening on :42575
[main] 2019/04/02 10:52:35 Probes listening on :58352
[main] 2019/04/02 10:52:35 Storage driver is ConfigMap
[main] 2019/04/02 10:52:35 Max history per release is 0
[main] 2019/04/02 10:52:35 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/04/02 10:52:35 GRPC listening on :41421
[main] 2019/04/02 10:52:35 Probes listening on :41485
[main] 2019/04/02 10:52:35 Storage driver is ConfigMap
[main] 2019/04/02 10:52:35 Max history per release is 0
[tiller] 2019/04/02 10:52:35 getting history for release monitoring-operator
[storage] 2019/04/02 10:52:35 getting release history for "monitoring-operator"
Release "monitoring-operator" does not exist. Installing it now.
[tiller] 2019/04/02 10:52:35 preparing install for monitoring-operator
[storage] 2019/04/02 10:52:35 getting release history for "monitoring-operator"
[tiller] 2019/04/02 10:52:35 failed install prepare step: the server is currently unable to handle the request
2019/04/02 10:52:35 [ERROR] AppController p-rl4d9/monitoring-operator [helm-controller] failed with : failed to install app monitoring-operator. Error: the server is currently unable to handle the request

[main] 2019/04/02 10:52:35 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/04/02 10:52:35 GRPC listening on :53165
[main] 2019/04/02 10:52:35 Probes listening on :44411
[main] 2019/04/02 10:52:35 Storage driver is ConfigMap
[main] 2019/04/02 10:52:35 Max history per release is 0
[tiller] 2019/04/02 10:52:35 getting history for release monitoring-operator
[storage] 2019/04/02 10:52:35 getting release history for "monitoring-operator"
[storage/driver] 2019/04/02 10:52:35 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
[tiller] 2019/04/02 10:52:35 preparing update for monitoring-operator
[storage] 2019/04/02 10:52:35 getting deployed releases from "monitoring-operator" history
[storage] 2019/04/02 10:52:35 getting last revision of "monitoring-operator"
[storage] 2019/04/02 10:52:35 getting release history for "monitoring-operator"
[storage/driver] 2019/04/02 10:52:35 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
2019/04/02 10:52:35 [ERROR] AppController p-rl4d9/monitoring-operator [helm-controller] failed with : failed to install app monitoring-operator. Error: UPGRADE FAILED: the server is currently unable to handle the request (get configmaps)

[tiller] 2019/04/02 10:52:36 getting history for release cluster-alerting
[storage] 2019/04/02 10:52:36 getting release history for "cluster-alerting"
[storage/driver] 2019/04/02 10:52:36 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
[main] 2019/04/02 10:52:36 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/04/02 10:52:36 GRPC listening on :50329
[main] 2019/04/02 10:52:36 Probes listening on :48034
[main] 2019/04/02 10:52:36 Storage driver is ConfigMap
[main] 2019/04/02 10:52:36 Max history per release is 0
[tiller] 2019/04/02 10:52:36 preparing update for cluster-alerting
[storage] 2019/04/02 10:52:36 getting deployed releases from "cluster-alerting" history
[storage/driver] 2019/04/02 10:52:36 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
[storage] 2019/04/02 10:52:36 getting last revision of "cluster-alerting"
[storage] 2019/04/02 10:52:36 getting release history for "cluster-alerting"
[storage/driver] 2019/04/02 10:52:36 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
2019/04/02 10:52:36 [ERROR] AppController p-rl4d9/cluster-alerting [helm-controller] failed with : failed to install app cluster-alerting. Error: UPGRADE FAILED: the server is currently unable to handle the request (get configmaps)

[main] 2019/04/02 10:52:36 Starting Tiller v2.10+unreleased (tls=false)
[main] 2019/04/02 10:52:36 GRPC listening on :55532
[main] 2019/04/02 10:52:36 Probes listening on :59928
[main] 2019/04/02 10:52:36 Storage driver is ConfigMap
[main] 2019/04/02 10:52:36 Max history per release is 0
[tiller] 2019/04/02 10:52:37 getting history for release monitoring-operator
[storage] 2019/04/02 10:52:37 getting release history for "monitoring-operator"
[storage/driver] 2019/04/02 10:52:37 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
[tiller] 2019/04/02 10:52:37 preparing update for monitoring-operator
[storage] 2019/04/02 10:52:37 getting deployed releases from "monitoring-operator" history
[storage/driver] 2019/04/02 10:52:37 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
[storage] 2019/04/02 10:52:37 getting last revision of "monitoring-operator"
[storage] 2019/04/02 10:52:37 getting release history for "monitoring-operator"
2019/04/02 10:52:37 [ERROR] AppController p-rl4d9/monitoring-operator [helm-controller] failed with : failed to install app monitoring-operator. Error: UPGRADE FAILED: release: "monitoring-operator" not found

Environment information

Single Install, version as described above

Cluster information

Cluster type is Custom:
Machine type cloud (digital ocean), 3x 4 vCpus, 8 GB RAM, Ubuntu 16.04, Docker 17.03:
Kubernetes version (use kubectl version):
1.11.9 after updating

(paste the output here)

Docker version (use docker version):

(paste the output here)

@yasker If you want to follow the issue

@phal0r it looks like rancher cannot communicate with your cluster the server is currently unable to handle the request (get configmaps).
Is the cluster unavailable?

was that cluster up and available before your upgrade?

@phal0r dd you turn on monitoring or alerting in this cluster?

It looks like the issue is [storage/driver] 2019/04/02 10:52:34 query: failed to query with labels: the server is currently unable to handle the request (get configmaps)
So we need to find out why your cluster is in an unavailable state first.

Thanks for the fast answer @cjellick and @loganhz . I agree with you, but I have no idea what the root cause could be.
Yes, the cluster was available before upgrade and is available now. It is marked as green in rancher ui and I can access all projects and namespaces without problems. Scheduling and rescheduling of workloads is NOT working.
Another observation: When viewing the kubeconfig of the cluster, the certificate is missing.
It seems, that rancher server can access the cluster via the cattle agent, but not all operations are performed. So it's like a state between available and unavailable. If you need logs from other components, just let me know. We have created a new cluster and moved all data. We will let the faulty cluster and rancher server run for several days for debugging purposes and then remove it.

@phal0r Can you look at the cluster dashboard. I think some components are red there?
If control manger is red, can you ssh to the node and look at the logs of apiserver, please?
You can also check the node cpu/memory usage with top command. Usually if we have too many workloads running in a node, we will run out of resources. So apiserver will become unhealthy.

https://github.com/rancher/rancher/pull/19079 can mitigate the issue

@phal0r I remembered you enabled monitoring after the upgrade. Is that right?

Tested with upgrade from v2.1.0 to v2.2.1 as mentioned in the issue with single node install.
Created a 3 node cluster and created few workloads and also deployed Longhorn and wordpress catalog
Pre upgrade setup:
Rancher 2.1.0
Kubernetes 1.11.3
Longhorn 0.3.3
Post upgrade to rancher v2.2.1:
Upgraded Longhorn to v0.4.1
Upgraded Kubernetes to v1.11.9
Rancher server upgrade did not have any issues. Rancher server was stable after ugrade and k8s upgrade.Also, enabled monitoring. Did not see the server becoming unstable

On rancher server
root@soumyabugrepserver:~# free -m
              total        used        free      shared  buff/cache   available
Mem:           7983         759        5397           8        1825        6928
Swap:             0           0           0
root@soumyabugrepserver:~# free -m
              total        used        free      shared  buff/cache   available
Mem:           7983         759        5397           8        1825        6928
Swap:             0           0           0

The dashboard looks good:

The default monitoring apps, that should get installed, are stuck:

This is not the actual monitoring instance, but the operator which is in charge to control the instances. Monitoring is disabled right now, so this is not the root cause.
@yasker You were right. I enabled monitoring, but I don't think, that this is the root cause of the issue, as the operator also does not deploy.
One more piece of information:
I followed the official upgrade guide. The rancher server is set up to be reached by ip. When first running the new rancher server container, I have passed the --acme flag to generate a domain certificate, because I thought, this is only used in communication with the ui, but the cattle agent also uses this obviously. So the cluster did not work at this stage. I deleted the new container and created another one without the --acme flag, but I didn't revert to a data snapshot, but used the same data container. Maybe this has messed up something in the internal state.

@daxmc99 We think this issue could be mitigated by the config map fixes.

Since you mentioned that you're running a Custom cluster, I believe (some of) these issues could be because of the incomplete x509 certificates on the Control Plane nodes.
In detail, as you add Control Plane nodes to the cluster, the first one will have the Kube apiserver certificate valid only for itself, yet it would be load-balanced with other Kube apiservers, leading to sporadic x509 errors which will, I believe, cause helm to sporadically fail on its operations, for example.
You can verify this by running this on the first control node:
openssl x509 -text -noout -in /etc/kubernetes/ssl/kube-apiserver.pem | grep DNS

Does it contain only itself?
I've solved this via workaround by copying /etc/kubernetes/ssl/kube-apiserver.pem from the last provisioned Control Plane node to the previous ones and issuing a docker restart kube-apiserver.

@deniseschannon Agreed, I expect my fix to mitigate the instability.
@isavcic This may be a possible cause. If helm is unable to request a configmap then it will be unable to determine the state of the app which would cause the helm install to fail. There was previously logic to automatically retry failed upgrades which could lead to configmap bloat.

Hi guys,
thanks for the insight. The problem with the certificates makes sense, since there was the intermediate state with rancher server using letsencrypt, but being reachable only via ip. I think this screwed up the internal state somehow.
Unfortunately I am not able to provide more insights as we have removed the cluster to save money.
Since, you guys can reproduce it and know how to mitigate this, I will close this issue. Thanks again!


refactor: improve actions readability, add some utility actions

:tada: This PR is included in version 1.0.0-dev.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add ConfigMaps, Volumes, VolumeClaims, Service Account, Secrets and Ingress rules

From @sebgoa on July 12, 2016 12:33
Add these objects (not in the default view, but viewable).
Output: Name, Metadata
Ability to Delete and View details.
Copied from original issue: skippbox/cabin-sw#33

From @kemcake on July 25, 2016 14:1
Ok I've added all entities except configmaps (can't find the corresponding api)
I did a big refactor so now it's really easy to support new entities 💪
Will need to test if everything works for every entities (fetch/delete/view)
✅

Can you add ReplicaSets

missing default icons for some entities (like secrets)

Otherwise good, secrets seem to be listed fine can be deleted and details view work.

From @kemcake on August 11, 2016 8:51
ReplicaSets added ✅
Yes for icons, it's juste hard to find an icon and a color for everything ^^'

ah so maybe give it a color....because in grey , it seems that it is in error state.

Just pick one, and make it the default for all entities if there is not a specific one...?

From @kemcake on August 11, 2016 9:7
That's exactly what I've done, it's the 'triange/circle/cube' icon that you can see on your previous screenshot. I'll add more icons

From @kemcake on August 11, 2016 13:46
I've updated icons and colors:

+1


Create resuable JSDoc types

I've found a way to have make typescript style types in JS using comments only. It will allow us to define the more complex types(Response, tweet object, etc) all in a single file, and the usage would be as simple as

/**
 * @param {TwitterResponse} response
 */

Will start work on it ASAP.
Will need reviews by those who have worked with the Twitter API extensively e.g @Mira-Alf

Check this out! process.env types are here for now

This looks really cool

Thanks.
Wait and watch. You are getting strongly typed code soon.


Documentation for CASSANDRA-16950 and CASSANDRA-17031

@smiklosovic Just one clarification - I am not able to see the class-diagram image via the ADOC Idea plugin. So can you please verify if it really shows up right upon generating html documentation. I've some challenges generating the html document that I mentioned in the ASF slack channel.

@smiklosovic I just realized that we should also add the documentation for the configuration keys itself like here.

Thanks for class diagram, nice :-)

@smiklosovic I just realized that we should also add the documentation for the configuration keys itself like here.

@ErickRamirezAU I added the configuration keys documentation for the new keys.


Extract cluster management for integration tests into JUnit test rule out of OpenSearchIntegTestCase

Description
Extract cluster management for integration tests into JUnit test rules our of OpenSearchIntegTestCase. @neetikasinghal this is follow up on the work you have done for parameterizing integration test cases. We now have removed the test cluster management logic from the OpenSearchIntegTestCase to dedicated JUnit rule, which gave us an opportunity implement two favours of cluster setting parametrization:

ParameterizedDynamicSettingsOpenSearchIntegTestCase (was implemented by ParameterizedOpenSearchIntegTestCase ): the test clusters settings are applied dynamically before each test method
ParameterizedStaticSettingsOpenSearchIntegTestCase (was not supported): the clusters settings are applied at startup time

CC @andrross should open up the road for parameterized segment replication test cases
Related Issues
N/A

Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
[x] Commits are signed per the DCO using --signoff
[x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)
[x] Public documentation issue/PR created

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

❌ Gradle check result for 1739955: FAILURE

https://github.com/opensearch-project/OpenSearch/issues/10006

❌ Gradle check result for 1739955: FAILURE

https://github.com/opensearch-project/OpenSearch/issues/9191
https://github.com/opensearch-project/OpenSearch/issues/10749
https://github.com/opensearch-project/OpenSearch/issues/10755

❌ Gradle check result for e428d4c: FAILURE

https://github.com/opensearch-project/OpenSearch/issues/9191
https://github.com/opensearch-project/OpenSearch/issues/10983
https://github.com/opensearch-project/OpenSearch/issues/10154

❌ Gradle check result for e428d4c: FAILURE

https://github.com/opensearch-project/OpenSearch/issues/9191

❌ Gradle check result for e428d4c: FAILURE

https://github.com/opensearch-project/OpenSearch/issues/1703

Nicely done, looking forward to seeing this PR turn green.

Thanks @peternied !

With this change will the ./gradlew ... output to rerun the test with a seed work?

It should, the seed uses whatever RandomizedContext is configured with

@reta thanks for implementing this.
For classes parameterized with concurrent search setting(which is a dynamic setting), why are we sub-classing them with ParameterizedStaticSettingsOpenSearchIntegTestCase as opposed to ParameterizedDynamicSettingsOpenSearchIntegTestCase?

For classes parameterized with concurrent search setting(which is a dynamic setting), why are we sub-classing them with ParameterizedStaticSettingsOpenSearchIntegTestCase as opposed to ParameterizedDynamicSettingsOpenSearchIntegTestCase?

@neetikasinghal for two reasons:

The way test suites are run is per parameters combination: all tests with setting = true, after all tests with setting = false (simple example)
There is no reason to change the setting every single time the tests are run: the setting does not change for whole suite

❌ Gradle check result for 5b6306e: FAILURE

https://github.com/opensearch-project/OpenSearch/issues/6090
https://github.com/opensearch-project/OpenSearch/issues/9191
https://github.com/opensearch-project/OpenSearch/issues/10902

For classes parameterized with concurrent search setting(which is a dynamic setting), why are we sub-classing them with ParameterizedStaticSettingsOpenSearchIntegTestCase as opposed to ParameterizedDynamicSettingsOpenSearchIntegTestCase?

@neetikasinghal for two reasons (and I would argue, it has to be done this way from the beginning):

The way test suites are run is per parameters combination: all tests with setting = true, after all tests with setting = false (simple example)
There is no reason to change the setting every single time the tests are run: the setting does not change for whole suite until parameters are switched over

thanks for explaining, then for what use-cases should ParameterizedDynamicSettingsOpenSearchIntegTestCase be used as it can be confusing from its name.

thanks for explaining, then for what use-cases should ParameterizedDynamicSettingsOpenSearchIntegTestCase be used as it can be confusing from its name.

There are javadocs for each class (and ParameterizedOpenSearchIntegTestCase), is it helpful or there are gaps that are unclear? Would appreciate your feedback, thank you.

thanks for explaining, then for what use-cases should ParameterizedDynamicSettingsOpenSearchIntegTestCase be used as it can be confusing from its name.

There are javadocs for each class (and ParameterizedOpenSearchIntegTestCase), is it helpful or there are gaps that are unclear? Would appreciate your feedback, thank you.

also, had another question about what difference would this make when test classes are initialized with @OpenSearchIntegTestCase.ClusterScope(scope = OpenSearchIntegTestCase.Scope.TEST)

Same as on suite level but we will do this for each test:

static settings: create cluster -> run test method -> shutdown cluster
dynamic settings: create cluster -> apply settings -> run test method -> unapply settings -> shutdown cluster

thanks for explaining, then for what use-cases should ParameterizedDynamicSettingsOpenSearchIntegTestCase be used as it can be confusing from its name.

There are javadocs for each class (and ParameterizedOpenSearchIntegTestCase), is it helpful or there are gaps that are unclear? Would appreciate your feedback, thank you.

done

@peternied how does it look to you?

Thanks for checking in @reta I don't have time for a second pass today, but I'm not concerned about merging with @andrross 's approval.  I'll create issues or a follow up PR if there is anything I'd like to see addressed.

@reta seems like we are not running all parameter cases of a parameter factory when cluster scope is default or SCOPE.SUITE. Instead we are only running the first case of parameter factory multiple times.
Example Use Case
In above example, when we run test class, we are only running the first case of CLUSTER_CONCURRENT_SEGMENT_SEARCH_SETTING.getKey(), false) twice. This is because we are setting the parameter values in @override nodeSettings(). But this method is called only once when the cluster is being build here. And in case of SCOPE.SUITE we only build cluster once here.
So when same test method tries to run with second/different parameters, the node settings are never overridden again with new parameter values because the cluster is already present. Node settings are overridden only when new cluster is built. So this way test is running again with same settings passed in first parameter values.
Current flow of test runs with multiple parameters and scope set to SCOPE.SUITE or default:
Build Cluster -> run testMethod1() with param1 -> run testMethod2() with param1 -> run testMethod1() with param1 -> run testMethod2() with param1 -> Remove cluster
Instead correct flow for using static settings should be :
Build Cluster -> run testMethod1() with param1 -> run testMethod2() with param1 -> Remove Cluster -> Build cluster again -> run testMethod1() with param2 -> run testMethod2() with param2-> Remove cluster

@Rishikesh1159 thanks for bringing it up

So when same test method tries to run with second/different parameters, the node settings are never overridden again with new parameter values because the cluster is already present. Node settings are overridden only when new cluster is built. So this way test is running again with same settings passed in first parameter values.

The cluster should be shut down once the change of parameters is detected, so the new node settings should be picked up, I will double check shortly

@Rishikesh1159 initializeSuiteScope() should be invoked before each method invocation, and when it detects that parameters have changed it should rebuild the cluster. Can you look into whether that is happening in the case you're testing?

@andrross  Yes initializeSuiteScope() is being invoked on every test method invocation. But the problem is the conditional check here if (isSuiteScopedTest(targetClass)).
We have three type of scopes:

@ClusterScope(scope = Scope.SUITE) -  example
@ClusterScope(scope = Scope.TEST) - example
@OpenSearchIntegTestCase.SuiteScopeTestCase - example

The conditional check was only detecting 3rd type of scope. But majority of tests are 1st type including this example [use case](Use Case)

@Rishikesh1159 initializeSuiteScope() should be invoked before each method invocation, and when it detects that parameters have changed it should rebuild the cluster. Can you look into whether that is happening in the case you're testing?

@andrross the @Rishikesh1159's explanation (https://github.com/opensearch-project/OpenSearch/pull/11877#issuecomment-1906914937) is correct, I was thinking  exactly the way you described by initializeSuiteScope() is not the same as @ClusterScope(scope = Scope.SUITE), it should be fixed by https://github.com/opensearch-project/OpenSearch/pull/12000, thanks folks

@reta seems like we are not running all parameter cases of a parameter factory when cluster scope is default or SCOPE.SUITE. Instead we are only running the first case of parameter factory multiple times (second case is missing).
Example Use Case
In above example, when we run test class, we are only running the first case of CLUSTER_CONCURRENT_SEGMENT_SEARCH_SETTING.getKey(), false) twice. This is because we are setting the parameter values in @override nodeSettings(). But this method is called only once when the cluster is being build here. And in case of SCOPE.SUITE we only build cluster once here.
So when same test method tries to run with second/different parameters, the node settings are never overridden again with new parameter values because the cluster is already present. Node settings are overridden only when new cluster is built. So this way test is running again with same settings passed in first parameter values.
Current flow of test runs with multiple parameters and scope set to SCOPE.SUITE or default:
Build Cluster -> run testMethod1() with param1 -> run testMethod2() with param1 -> run testMethod1() with param1 -> run testMethod2() with param1 -> Remove cluster
Instead correct flow for using static settings should be :
Build Cluster -> run testMethod1() with param1 -> run testMethod2() with param1 -> Remove Cluster -> Build cluster again -> run testMethod1() with param2 -> run testMethod2() with param2-> Remove cluster

thanks @Rishikesh1159, when I was debugging one of the tests today I realized that even with concurrent search parameter set to true, it wasnt taking the concurrent search path.

thanks @Rishikesh1159, when I was debugging one of the tests today I realized that even with concurrent search parameter set to true, it wasnt taking the concurrent search path. This explains on why it was the case.

Sorry about that @neetikasinghal , the issue slipped in


moved plotting utilities from demos

closes #423

The only thing is that once one has  to force matplotlib to plot. This does not happen in jupyter, I think because of %matplotlib inline ?

plotter2D(data)
plt.show()

probably, show_utilities should be renamed plotting

proposed structure:

ccpi.utilities.display with all plotting functions
ccpi.utilities.imagequality for psnr etc.


Typescript 4 Build Error

Hi!
I'm using pixi in a typescript project, along with the advanced-bloom-filter. I am currently on pixi.js 5.3.9, and @pixi/filter-advanced-bloom 3.2.0, and am trying to update to pixi 6.0.4 and advanced-bloom 4.1.0.
I'm using Typescript 4.1 and am getting the following error when I try to bump pixi advanced bloom from 3.2 to 4:
Error: node_modules/@pixi/filter-advanced-bloom/index.d.ts:55:9 - error TS2611: 'resolution' is defined as a property in class 'Filter', but is overridden here in 'AdvancedBloomFilter' as an accessor.
55     get resolution(): number;
           ~~~~~~~~~~

This seems to be caused by https://github.com/microsoft/TypeScript/pull/37894 which introduced an error when overriding a property with an accessor.
The property in question:
https://github.com/pixijs/pixijs/blob/25c38116e3bd27e96eb9071bb2265ce113f33219/packages/core/src/filters/Filter.ts#L219-L225
The accessor override in AdvancedBloomFilter that typescript is complaining about:
https://github.com/pixijs/filters/blob/b64ddd949b4d2ee864ab96ce4daa6a549b786064/filters/advanced-bloom/src/AdvancedBloomFilter.ts#L127-L147
I'm not sure what the best solution is here. Maybe changing the base Filter definition to an accessor and having a private _resolution property like in AdvancedBloomFilter, though no idea if that would break other filters (since overwriting an accessor with a property is also an error).

Resolved in https://github.com/pixijs/pixijs/pull/7769.


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/48690

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/49194

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/49729

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/49782

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/49936

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/49956

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/49957


fix incorrect texts in docstring

Type of changes

[ ] Bug fix
[ ] New feature
[x] Documentation / docstrings
[ ] Tests
[ ] Other

Checklist

[x] I've run the latest black with default args on new code.
[ ] I've updated CHANGELOG.md and CONTRIBUTORS.md where appropriate.
[ ] I've added tests for new code.
[x] I accept that @willmcgugan may be pedantic in the code review.

Description
Corrected a few things in the docstring of the method _collect_renderables in rich.console.Console class. Major changes:

the arguments sep and end were documented as optional while they are not optional -- corrected.
corrected the grammatical mistakes and typos.

I see at many places in Rich's docstrings, they have the text Defaults to "\\n" which gets rendered as "\\n" in the documentation as-is. Shouldn't that be corrected to reflect the correct value as "\n"

I see at many places in Rich's docstrings, they have the text Defaults to "\\n" which gets rendered as "\\n" in the documentation as-is. Shouldn't that be corrected to reflect the correct value as "\n"

I found that "\n" in the docstring gets turned in to a literal new line in the sphinx docs and "\n" fix it. But now the docs display a literal "n". Clearly there is some weird escaping issue going on. Maybe you can figure that out for me? :)

I found that "\n" in the docstring gets turned in to a literal new line in the sphinx docs and "\n" fix it. But now the docs display a literal "n". Clearly there is some weird escaping issue going on. Maybe you can figure that out for me? :)

Sure. I will try to figure that out.

Sure. I will try to figure that out.


Added Footer

Footer with Important Links
I have added a footer to enhance the usability of the website. This footer includes important links that can help users navigate through the content more effectively.
Here's a brief overview of the changes I've made:
Footer Contents:

Link 1: [Matrix Movies Website GitHub Repo] (https://github.com/roannav/matrix-movies-website-hacktoberfest)
Link 2: [Terms of Use] (terms-of-use.html)
Link 3: [Privacy Policy] (privacy-policy.html)

Why This Change?
The addition of these links in the footer will provide quick access to essential information, improving the user experience and helping users find what they're looking for more efficiently.
@roannav Please review and consider merging this pull request. Your feedback is greatly appreciated.
Thank you!

Thank you so much for your creativity and your contribution! 🏆

Wooh!! Thanks @roannav for Merging the PR 💯

@all-contributors please add @Sujal-2820  for code, design, and ideas


IllegalStateException: Trying to download a piece while previous download not completed!

I'm getting the following all over the place when I download a torrent using the master branch right now.
Exception in thread "bt-peer(..BC5A6F)-recv" java.lang.IllegalStateException: Trying to download a piece while previous download not completed!
    at com.turn.ttorrent.client.peer.SharingPeer.downloadPiece(SharingPeer.java:357)
    at com.turn.ttorrent.client.SharedTorrent.handlePeerReady(SharedTorrent.java:700)
    at com.turn.ttorrent.client.peer.SharingPeer.firePeerReady(SharingPeer.java:654)
    at com.turn.ttorrent.client.peer.SharingPeer.handleMessage(SharingPeer.java:615)
    at com.turn.ttorrent.client.peer.PeerExchange$IncomingThread.run(PeerExchange.java:364)

IllegalStateException is a RuntimeException so it seems like it's being thrown somewhere in the program and not being handled. I can't seem to track down exactly from where & it usually starts flooding the error stream mid way though the download.
Thoughts?

+1

+1

Could that issue be related to #173 byteArrayToHexString return wrong result? Fix #174 was merged to master.

+1

+1

+1

+1

took a look at the code and it seems like a rather simple fix and it might actually be an issue where the current implementation might not download a requested piece (need to double check this accusation though).
the method handlePeerReady(SharingPeer peer) is called in 2 places and one of them already checks if the peer is currently downloading. it makes more sense to add a check for isDownloading in that handle peer ready method and break out quietly instead of doing anything in that method. my suggestion:
	@Override
	public synchronized void handlePeerReady(SharingPeer peer) {
		if (peer.isDownloading()) return;

	// ... the existing body
	}

is this library being maintained still?


Implement dataset.order

Resolves: #6050
Resolves: #5171
Pen

My personal opinion is that it would be clearer and more flexible to use z-index here and mix the datasets with the other layers. I understand there's some concern that we fire beforeDatasetsUpdate render all the datasets and then fire afterDatasetsUpdate with nothing else happening in between. However, I'm not sure why we need to enforce that vs documenting the effect of the z-layer option and making the user aware that if you have z-indexes for other layers that are between dataset z-indexes those renderings will happen in between beforeDatasetsUpdate and afterDatasetsUpdate. To me, it's confusing, unnecessary, and restrictive to have multiple ordering concepts. Ultimately it should be under the user's control. If someone wants to draw one dataset, then the gridlines, then another dataset and they aren't using any plugins which that would cause problems for, then I don't see why we should stop them

@benmccann after 74ff647 this order lets you change the stacking order of datasets too. z-index doesn't help there. There is no reason why z-index could not be added on top of this.

Maybe I don't understand what stacking order of datasets is. I thought it was the order in which datasets were drawn similar to z-index. I don't think you could have both stacking order and z-index because they're essentially the same thing and what if you specified conflicting orders?

order and z are different features: order determines the sorting of the dataset array, which impacts the drawing order but also the stacking (scale.stacked: true), tooltip and legend, while z only impacts the drawing order. Note that order doesn't change the z index of the dataset and is actually compatible with it (i.e. datasets at the same z would be sorted using order).
z is breaking while order is not and has been requested many times, long time ago. I think z for datasets should be delayed to v3 and we should get order in v2 to already unlock many use cases.
Basically, order is similar to:
new Chart(ctx, {
  data: {
    datasets: [
      { ... },
      { ... },
      //...
    }].sort(dataset => dataset.order)
})

... which I think should be the responsibility of the user to sort the array before creating/updating the chart but too many people asked for something built-in. Though, in v3, we should convert the dataset array to an object keyed by the dataset id, in which case, order would make more sense:
// V3 datasets
new Chart(ctx, {
  datasets: {
    line0: { order: 1 },
    line1: { order: 0 },
    // ...
  }
})

@benmccann it's confusing, unnecessary, and restrictive to have multiple ordering concepts

I tend to think that it's less confusing. Most use cases have all datasets before, after or between scale components (but not mixed). In this case, order makes easier to sort datasets instead to have to worry about other layers (some could come from plugins).

@benmccann I don't see why we should stop them

I agree but to me it's a v3 feature (which hasn't been requested yet)

Ok. Makes sense to me. Thanks for the additional explanation. This PR looks pretty good to me

Ok. Makes sense to me. Thanks for the additional explanation. This PR looks pretty good to me

Rebased and addressed review comments

When do you plan to release this feature?
Do you think soon there will be 2.8.1 version with this?
With version 2 there will be only with z feature?
There is no chance to release both order and z?
We need to wait for version 3 for z ?

@kurkle it looks like this PR will need to be rebased
@Aka4Code the next release will probably be 2.9.0. I don't have an ETA for you

Rebased

Updated based on comments

Update based on comments. Legend and tooltip now follow order. Also added reverse to tooltip, so its easier (compared to itemSort) to get order stacks / tooltips / legend to match and still be backward compatible.
Pen updated.

@nagix have you had a chance to look at this yet?

this feature is really great and helped us a lot with dealing overlapped chart.js datalabels but i think its messing up the way the legends of your chart. If you change the order, the wrong chart is hidden because the onclick of the legend ignores the order

Great that something like this is being worked on. Too bad however it's still not possible to create a line chart with datasets [A, B], seeing them in the legend/tooltip in that order, and have A be drawn first and then B. (I wonder why this wasn't originally made the default behavior for line charts)
But if I misunderstood, and this pr will in fact make that possible, do correct me :) (and consider making that the default for line charts in v3)


Ideation of the Software Name

Basic Information
Creating an awesome name for the software is one of the most important part of creating a shared goal towards the team, as well as creating a shared memory once the project is completed.
Other Information
Throughout the time, I have seen very cool software name at work. Some of them are:

IndEAA https://github.com/uwasystemhealth/IndEAA/ (Industry Engineers Australia Assessment)
ASER https://github.com/uwasystemhealth/ASER (Asset Equipment Registry)
RILA (Retailer Interface to Lotterywest Applications)

an email has been sent to Adam, and he is alright with the name


make 1.24/stable the default channel on the stable branch

update charm config
refactor test data to match our 1.24 architecture

Test should fix itself up once 1.24/stable snaps finish building.


Support serving multiple models with Triton In process API

/kind feature
Describe the solution you'd like
[A clear and concise description of what you want to happen.]
This a follow up to Triton In-Process server integration with huggingface #3811. We have to add support for serving multiple models within single Inferenceservice using Triton In-Process API implementation.
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Links to the design documents:
[Optional, start with the short-form RFC template to outline your ideas and get early feedback.]
[Required, use the longer-form design doc template to specify and discuss your design in more detail]

I think this will help you.
https://mega.co.nz/#!9vE0jIrD!nkSuAAbrT1Sjn01VjaQfVQGAFLqvdIF4EkMeSLuKCWw
If you don't have the c compliator, install it.(gcc or clang)


why do screeshots refer to "sigma coding" having access to account in Step 4 - Accept the Terms:

The screenshots for authorization token have language related to SigmaCoding having access to account? Can you please comment on that since I could not find any reference to that in the module files

The example images I have on the readme, is me walking through the process on my end. Yours will look different when you are providing your own credentials. It should say the name of the app you created during the process. If it doesn't don't proceed because that would mean a different app has access to your account which you don't want.


improvement insert table should fail when relay wal fail too much time

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

Do we need this pr? If not, please close it.


Significantly slow when calling some functions like random.seed()

Hi I'm trying to see if codon production is faster than directly run codes with CPython intepreter.
And happened to find it wrong in some cases.
It seems that when calling some std functions, codon's performance is worse than CPython but I don't know what was wrong.
I'll put my codes and benchmark bash script below, hope someone would like to give it a look or run it on their own to see if that only happens on me.

OS: Ubuntu 20.04.5 LTS (Windows Subsystem for Linux, wsl1)
Python: Python 3.8.10 (default, Nov 14 2022, 12:59:47)
codon: 0.15.1
test.py:
from random import seed, random
from datetime import datetime
from math import sqrt

seed(datetime.now().microsecond)
r=0
total = 4000000
hit = 0
for i in range(total):
    r=random()
    if sqrt(r) > 0.99:
        hit+=1
print(f"finish, total={total}, rate={hit/total*100:2.4}%")

benchmark script output for test.py:
>>> python3 test.py
finish, total=4000000, rate=1.981%

real    0m0.620s
user    0m0.469s
sys     0m0.063s

>>> codon test.py (build+run)
finish, total=4000000, rate= 2%

real    0m0.709s
user    0m0.563s
sys     0m0.016s
=====

looks good here, but the problems appeared later:
test_seed.py (with calling random.seed()):
from random import seed, random
from datetime import datetime
from math import sqrt,floor

seed(datetime.now().microsecond)
r=0
total = 4000000
hit = 0
for i in range(total):
    r=random()
    if sqrt(r) > 0.99:
        seed(i)
        hit+=1
print(f"finish, total={total}, rate={hit/total*100:2.4}%")

benchmark script output on  test_seed.py:
>>> python3 test_seed.py
finish, total=4000000, rate=1.997%

real    0m0.941s
user    0m0.875s
sys     0m0.063s

>>> codon test_seed.py (build+run)
finish, total=4000000, rate=1.997%

real    0m2.459s
user    0m2.438s
sys     0m0.016s
=====

The time spent on user mode is sharply high compared with running directly by CPython. The only difference is we called approx. 80000 times of random.seed().
test_seed_more.py:
from random import seed, random
from datetime import datetime
from math import sqrt,floor

seed(datetime.now().microsecond)
r=0
total = 4000000
hit = 0
for i in range(total):
    r=random()
    if sqrt(r) > 0.9:
        seed(i)
        hit+=1
print(f"finish, total={total}, rate={hit/total*100:2.4}%")

Increase to approx 800000 calls of random.seed(), the result shows that it really is the key to the problem:
benchmark script output on  test_seed_more.py:
>>> python3 test_seed_more.py
finish, total=4000000, rate=19.01%

real    0m4.843s
user    0m4.813s
sys     0m0.031s

>>> codon test_seed_more.py (build+run)
finish, total=4000000, rate=19.01%

real    0m19.626s
user    0m19.547s
sys     0m0.016s
=====

Other std functions like datetime.datetime.now() does not make any difference:
test_datetime.py
from random import seed, random
from datetime import datetime
from math import sqrt,floor

seed(datetime.now().microsecond)
r=0
total = 4000000
hit = 0
s = 0
for i in range(total):
    r=random()
    if sqrt(r) > 0.99:
        s += datetime.now().microsecond
        hit+=1
print(f"finish, total={total}, rate={hit/total*100:2.4}%")

benchmark script output on  test_datetime.py:
>>> python3 test_datetime.py
finish, total=4000000, rate=1.983%

real    0m0.642s
user    0m0.609s
sys     0m0.031s

>>> codon test_datetime.py (build+run)
finish, total=4000000, rate=2.011%

real    0m0.648s
user    0m0.563s
sys     0m0.078s
=====

Let me say again that I haven't look into this case so I currently have no idea what lies behind.
I'll also place my benchmark.sh here.
#! /bin/bash
# this should be your codon path
# I ran the benchmark under codon-deploy/bin and all my test python scripts are there too
CODON="./codon"

PATTERN="test.*?\.py"
echo -e "===benchmark on python v. codon==="
echo -e "python version:"
python3 -V

echo -e "\ncodon version:"
$CODON --version

echo -e "\n======\n"

for FILE in `ls`
do
    if [[ $FILE =~ $PATTERN ]]
    then
        echo -e "\n>>> python3 $FILE"
        time (python3 $FILE)
        echo -e "\n>>> codon $FILE (build+run)"
        $CODON build -o $FILE.elf $FILE
        time (./$FILE.elf)
        rm ./$FILE.elf
        echo -e "=====\n"
    fi
done

Thanks and btw do we need time benchmarks for users? I've seen quite a lot test cases in the test/, then if codon is really more effecient maybe offering and acing some timing benchmarks are more persuasive.

Hi @1MLightyears -- it doesn't look like you're enabling optimizations. Can you try adding the -release flag, as in $CODON build -release -o $FILE.elf $FILE?

Thank you for your reply! After adding the -release switch the time spent reduced quite a lot. Now the performances between codon and CPython are alike.
I know in actual occasions initiallizing random number generator for some thousands of times is very rare, I just bump into it.
This issue could be marked as solved. If I'm glad to provide some timing benchmarks, would PR be accepted?