Release kubeflow-fairing package

/kind feature
Describe the solution you'd like
Since the pacakge name has been rename to kubeflow-fairing in the PR #359, use can install the pacakge 0.0.1 by
pip install kubeflow-fairing

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

@jlewi @abhi-g what do you think about the kubeflow-fairing package version? since the fairing 0.5.3 has been released in Pypi, is that release as  kubeflow-fairing 0.6 or  kubeflow-fairing 0.1? Thanks.

I would vote to go with 0.6 or 0.7; i.e. not reset the version back to 0.1 just because the package name changed.
I would also try to keep the version numbers in sync with kubeflow as long as we can. If that means we skip a major release (e.g. there is no 0.6) I think that's ok.

@jlewi OK, I'm going to release kubeflow-fairing 0.6 version, and relase 0.6.x for P1 or S1 issues. And will release 0.7 version with kubeflow 0.7 in sync. Thanks.
/assign @jinchihe
/cc @abhi-g

Hello @jlewi @abhi-g,
Kubeflow-fairing 0.6.0 has been released: https://pypi.org/project/kubeflow-fairing/
(python36) [root@jinchi1 ~]# pip install kubeflow-fairing
Collecting kubeflow-fairing
  Downloading https://files.pythonhosted.org/packages/d3/b2/348b73a2705f2bb789976feeba6aa086dbc6546c5c27019b15fc89498f41/kubeflow_fairing-0.6.0-py3-none-any.whl (144kB)
     |████████████████████████████████| 153kB 256kB/s
Requirement already satisfied: google-cloud-storage>=1.13.2 in /opt/kubeflow/python3/python36/lib/python3.6/site-packages (from kubeflow-fairing) (1.16.1)

......

Requirement already satisfied: wcwidth in /opt/kubeflow/python3/python36/lib/python3.6/site-packages (from prompt-toolkit<2.1.0,>=2.0.0->ipython>=5.0.0->ipykernel->notebook>=5.6.0->kubeflow-fairing) (0.1.7)
Installing collected packages: kubeflow-fairing
Successfully installed kubeflow-fairing-0.6.0
(python36) [root@jinchi1 ~]#
(python36) [root@jinchi1 ~]# pip3 show kubeflow-fairing
Name: kubeflow-fairing
Version: 0.6.0
Summary: Kubeflow Fairing Python SDK.
Home-page: https://github.com/kubeflow/fairing
Author: Kubeflow Authors
Author-email<EMAIL_ADDRESS>License: Apache License Version 2.0
Location: /opt/kubeflow/python3/python36/lib/python3.6/site-packages
Requires: azure, google-auth, cloudpickle, kubernetes, httplib2, numpy, future, google-api-python-client, oauth2client, boto3, setuptools, urllib3, google-cloud-storage, docker, six, tornado, requests, notebook
Required-by:
(python36) [root@jinchi1 ~]#

Thanks @jinchi
On Sun, Sep 15, 2019 at 11:39 PM Jin Chi He<EMAIL_ADDRESS>wrote:

Hello @jlewi https://github.com/jlewi @abhi-g
https://github.com/abhi-g,
Kubeflow-fairing 0.6.0 has been released:
https://pypi.org/project/kubeflow-fairing/
(python36) [root@jinchi1 ~]# pip install kubeflow-fairing
Collecting kubeflow-fairing
Downloading https://files.pythonhosted.org/packages/d3/b2/348b73a2705f2bb789976feeba6aa086dbc6546c5c27019b15fc89498f41/kubeflow_fairing-0.6.0-py3-none-any.whl (144kB)
 |████████████████████████████████| 153kB 256kB/s

Requirement already satisfied: google-cloud-storage>=1.13.2 in /opt/kubeflow/python3/python36/lib/python3.6/site-packages (from kubeflow-fairing) (1.16.1)
......
Requirement already satisfied: wcwidth in /opt/kubeflow/python3/python36/lib/python3.6/site-packages (from prompt-toolkit<2.1.0,>=2.0.0->ipython>=5.0.0->ipykernel->notebook>=5.6.0->kubeflow-fairing) (0.1.7)
Installing collected packages: kubeflow-fairing
Successfully installed kubeflow-fairing-0.6.0
(python36) [root@jinchi1 ~]#
(python36) [root@jinchi1 ~]# pip3 show kubeflow-fairing
Name: kubeflow-fairing
Version: 0.6.0
Summary: Kubeflow Fairing Python SDK.
Home-page: https://github.com/kubeflow/fairing
Author: Kubeflow Authors
Author-email<EMAIL_ADDRESS>License: Apache License Version 2.0
Location: /opt/kubeflow/python3/python36/lib/python3.6/site-packages
Requires: azure, google-auth, cloudpickle, kubernetes, httplib2, numpy, future, google-api-python-client, oauth2client, boto3, setuptools, urllib3, google-cloud-storage, docker, six, tornado, requests, notebook
Required-by:
(python36) [root@jinchi1 ~]#
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubeflow/fairing/issues/370?email_source=notifications&email_token=ACZ2UZTJSNNM7CXFL2IBJXLQJ4S2XA5CNFSM4IWP6VE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6YHJMA#issuecomment-531657904,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACZ2UZVSJ3SM6CEZRIUHIKTQJ4S2XANCNFSM4IWP6VEQ
.

The Fairing documentation in Kubeflow states that "Kubeflow notebook servers that are built from one of the standard Jupyter Docker images include Kubeflow Fairing and come preconfigured for using Kubeflow Fairing to run training jobs on your Kubeflow cluster." It seems however that it does so with an older version of Fairing, 0.5, and none of the examples work, modules have been renamed etc.

fair point Yannis. @jinchi should we update the dockerfile for Jupiter
Notebooks to install the latest release of fairing. The examples do work
with it.
On Mon, Jan 13, 2020 at 12:50 PM yantriks-edi-bice<EMAIL_ADDRESS>wrote:

The Fairing documentation in Kubeflow states that "Kubeflow notebook
servers that are built from one of the standard Jupyter Docker images
include Kubeflow Fairing and come preconfigured for using Kubeflow Fairing
to run training jobs on your Kubeflow cluster." It seems however that it
does so with an older version of Fairing, 0.5, and none of the examples
work, modules have been renamed etc.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubeflow/fairing/issues/370?email_source=notifications&email_token=ACZ2UZV3KQYQLGMTKYWMST3Q5THYNA5CNFSM4IWP6VE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI2HQAA#issuecomment-573863936,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACZ2UZRMRZ7F3M3CXUVNVFLQ5THYNANCNFSM4IWP6VEQ
.

I saw there is a PR to upgrade Fairing in Notebook image. https://github.com/kubeflow/kubeflow/pull/4645 thanks


Using JSONSchemaType seems a huge build hog

What version of Ajv are you using? Does the issue happen if you use the latest version?
<EMAIL_ADDRESS>Your typescript code

import Ajv, { JSONSchemaType } from 'ajv';
import addFormats from 'ajv-formats';

interface UserRequestBody {
  firstName: string;
  lastName: string;
  email: string;
  age?: number;
  address?: string;
  city?: string;
  zip?: string;
}

const ajv = new Ajv({
  coerceTypes: true,
  useDefaults: true,
  removeAdditional: true,
});
addFormats(ajv);

const userValidationSchema: JSONSchemaType<UserRequestBody> = {
  type: 'object',
  properties: {
    firstName: { type: 'string' },
    lastName: { type: 'string' },
    email: { type: 'string', format: 'email' },
    age: { type: 'number', minimum: 1, nullable: true },
    address: { type: 'string', nullable: true },
    city: { type: 'string', nullable: true },
    zip: { type: 'string', nullable: true },
  },
  required: ['firstName', 'lastName', 'email'],
};

const validateUser = ajv.compile(userValidationSchema);

export default validateUser;

Typescript compiler error messages
No compilation issues but build time increases drasticly, from around 1,5 secs to 11 secs
By using --generateTrace i discovered that is was related to UncheckedJSONSchemaType type.
Just changing to
import Ajv from 'ajv';
import addFormats from 'ajv-formats';

interface UserRequestBody {
  firstName: string;
  lastName: string;
  email: string;
  age?: number;
  address?: string;
  city?: string;
  zip?: string;
}

const ajv = new Ajv({
  coerceTypes: true,
  useDefaults: true,
  removeAdditional: true,
});
addFormats(ajv);

const userValidationSchema = {
  type: 'object',
  properties: {
    firstName: { type: 'string' },
    lastName: { type: 'string' },
    email: { type: 'string', format: 'email' },
    age: { type: 'number', minimum: 1, nullable: true },
    address: { type: 'string', nullable: true },
    city: { type: 'string', nullable: true },
    zip: { type: 'string', nullable: true },
  },
  required: ['firstName', 'lastName', 'email'],
};

const validateUser = ajv.compile<UserRequestBody>(userValidationSchema);

export default validateUser;

Describe the change that should be made to address the issue?
What can i do to assist or resolve this issue
Are you going to resolve the issue?
Not sure if i can help 🤷

Not much can be done about it - everything has a price. JSONSchemaType is a complex type level transformation that converts your data interface to the type that JSON Schema should have. It's purpose is to simplify and speed up schema authoring (via code autocomplete) and to avoid mistakes - so it can save hours of debugging time. Depending on your data interface it can take some time to compile.
The good thing about it is that its completely optional - you can use ajv without using JSONSchemaType if compilation time is more important...

It might be worth submitting as an issue to TS - there might be some potential to optimise compilation there.

@epoberezkin wow, that was closed fast, maybe not advise it as best practice on the ajv site. Other question is there a type which you can use that just does the same as using the `"$schema": "http://json-schema.org/draft-07/schema#" in your json schema?
const scheme: JSONSchema = {};

The problem is was describing impacts everything in a normal typescript oriented build, vscode intellisense is also impacted when using @typescript/es-lint. I am guessing there is something that can be optimised, maybe something recursive. maybe related to https://github.com/Microsoft/TypeScript/issues/3496#issuecomment-128553540

is there a type which you can use that just does the same as using the `"$schema": "http://json-schema.org/draft-07/schema#" in your json schema?

There is SomeJSONSchema - is it what you are looking for?

I am guessing there is something that can be optimised, maybe something recursive.

The type indeed has to be recursive, and I don’t see any ways to simplify it - TS is not very optimised for complex type transformations…

This wouldn't be much of an issue if it was just a build time issue but @tommarien is right that it essentially makes your IDE unusable. Users will get put off by this. I have a very powerful Macbook and it slowed down the TS compiler in VS Code to a snail 🐌

Hi all,
I added the following validation with ajv ^8.6.0 and ajv-formats ^2.1.0. It has a drastic impact on typescript speed in Visual Studio Code.
const schema: JSONSchemaType<AnExampleIncomingDto> = {
  type: 'object',
  properties: {
    name: { type: 'string', maxLength: 100 },
    email: { type: 'string', format: 'email' },
    about: { type: 'string', maxLength: 1000 },
    startDate: { type: 'string', format: 'date' },
    endDate: { type: 'string', format: 'date' },
    requirements: { type: 'string', maxLength: 1000 },
  },
  required: [
    'name',
    'email',
    'startDate',
    'endDate',
    'requirements',
  ],
  additionalProperties: false,
};

export const validate = ajv.compile(schema);

The validation works great, and build time isn't much a problem since that happens in CI and already can take multiple minutes. Meanwhile, Visual Studio Code, the small validation with typescript above, takes drastically longer to bring up autocompletes and tooltips. Somewhere on the order of between 5 and 25 seconds.
I was surprised by this behavior and did not expect it.

see https://github.com/ajv-validator/ajv/issues/1667#issuecomment-874009078 - looks like it's the issue with TS 4.3+


What happens if two dependencies need different versions of a transitive dependency?

Seeing that Haxe modules use a Java-style global package namespace makes me concerned that we may be out of luck if dependency A depends on C 2.0.0 but dependency B depends on C 3.0.0.
Is there a solution for this?

In such a case, you cannot use A and B in the same build. That's not even a haxelib problem, but one inherent to all types being global in Haxe.
The solution is to resolve the conflict by using conditional compilation to either make A forward compatible or B backward compatible, e.g.:
package liba;

import libc.C;

class A {
  static public function foo() {
    #if (libc < 3) C.oldMethod() #else C.newMethod() #end;
  }
}

Or make adapters (which liba will use instead of calling into libc directly):
package liba;

#if (libc < 3)
  typedef C = libc.C;
#else
  abstract C(libc.C) {
    public inline function new() this = new libc.C();
    // put the remaining interface here
  }
#end

In some cases you may need the adapters to be full blown classes, but most of the time abstracts will do without adding runtime overhead.
For some platforms it's also reasonably simple to split the build into two parts, where one uses liba and the other libb, in such a way that the interface between the two parts is free of types from libc.

@back2dos confirms my suspicions, since Java has the same problem AFAIK.
I don't guess Haxe has any plans to eventually implement a Node.js-like module system that doesn't have this problem?

Also shouldn't package authors be advised to include the major version in the package name?  It's kind of the only way to proactively prevent dependency hell with a module system like this

I don't guess Haxe has any plans to eventually implement a Node.js-like module system that doesn't have this problem?

This "problem" is far more common than you make it seem. It is the case in C (and C++ and Objective-C, C#, Python, PHP, Ruby, ...). JavaScript's module system is the outlier here.
Achieving the same in Haxe poses quite a few challenges (especially since Haxe is targeting a lot of platforms that have types in a global namespace).

Also shouldn't package authors be advised to include the major version in the package name? It's kind of the only way to proactively prevent dependency hell with a module system like this

The communities of many other languages seems to be able to cope with this, so let's not be so dramatic. If anything, Haxe's conditional compilation gives library authors an edge in maintaining compatibility with different major versions, not just for their dependencies, but also Haxe itself. That indeed requires more involvement, but it is certainly advisable. It not only mitigates the conflicts you speak of, but it does so in a way that avoids dumping multiple versions of the same lib into the generated output.

Yeah I see what you mean about the compilation targets, since I've just started looking into using Haxe I had mistakenly assumed that my deps would get bundled together if I output to another language, rather than being usable in a modular fashion.

The communities of many other languages seems to be able to cope with this

"Cope" would be a charitable way of putting some of the dependency hell I remember dealing with in Java/Maven...  Starting to work with JS felt like stepping into the future.

It not only mitigates the conflicts you speak of

Well, I think there's one caveat.  If C was recently upgraded to version 3 and I need a recent version of B that must rely on some new feature in C v3, but no version of A that supports C v3 has been released, I'm still out of luck right until A is updated right?

Starting to work with JS felt like stepping into the future. I'm always hopeful for tools to enable flourishing, not just coping.

Allowing the inclusion of parallel dependency trees (imagine C has 50 other transitive dependencies as any "good" npm module has) in the build does not only solve problems, it basically shifts them from devs to end users.
Enabling library authors to deal with different build configuration (dependency versions, Haxe versions, target runtimes) via conditional compilation is not mere coping. It adds quite a lot of wiggle-room, without impacting build size or speed.

If C was recently upgraded to version 3 and I need a recent version of B that must rely on some new feature in C v3, but no version of A that supports C v3 has been released, I'm still out of luck right until A is updated right?

Right. Although the primary role of major versions is not to add new features. It is to break or even remove existing ones, and that's precisely why in your scenario A needs to be updated for C@3. Adding features in major versions should be the exception (i.e. when a redesign is needed to make it even possible to add the feature).

That said, I don't think anybody would be strictly against this. But neither design nor implementation will be trivial and if you wish to pursue the matter, I would suggest going through haxe-evolution

Adding features in major versions should be the exception

Another way of putting this though, B could need to use a feature added in C v3.1.0, while A hasn't even implemented support for C v3.0.0 yet.

B could need to use a feature added in C v3.1.0, while A hasn't even implemented support for C v3.0.0 yet.

We can spend the next weeks walking through various hypothetical scenarios, but I don't see that it really matters.
The fundamental limitation of the approach you suggest is that it breaks down when the conflicting dependency is part of the dependents' APIs:
//<EMAIL_ADDRESS>package libc;

interface Constraint<T> {
  function test(value:T):Bool;
}

//<EMAIL_ADDRESS>package libc;

interface Constraint<T> {
  function matches(value:T):Bool;
}

// liba depending on<EMAIL_ADDRESS>package liba;

class A {
  static public function foo(foo:Foo):libc.Constraint<String>;
}
// libb depending on<EMAIL_ADDRESS>package libb;

class B {
  static public function bar(constraint:libc.Constraint<String>):Bar;
}

And boom, I can't pass constraints produced by liba to libb. In JavaScript it doesn't matter and if you're lucky the runtime types align just enough not to cause a crash. But that's hardly a solution to anything.
In a statically type language, this problem is immediately visible, as it should be. And it has further ramifications: in my own code that interfaces with both libs, how do I distinguish which version of Constraint I mean?
Interestingly, Deno seems to have a solution for importing different versions of the same type into the same module. Suppose we did the same, in the end as users of both liba and libb we'd be tasked with writing all sorts of glue code to wrap Constraint@2 in a Constraint@3 and vice versa, at which point I have to ask if it wouldn't be saner to just make a PR against liba to support<EMAIL_ADDRESS>At the end of the day, if we can will any solution into existence, the one I would prefer would be for library authors (with the support of their communities) to leverage Haxe's conditional compilation to support major version ranges, instead of inflating build time and size. And the good news is that once there is an adapter for exposing libc@3 via libc@2 APIs, not only liba can use it, but in fact anyone who wishes to migrate from libc@2 to libc@3.

Still, if you can propose a solution that doesn't come with a whole lot of other problems (such as the one I mentioned above) and can be implemented with sane effort, chances are it gets built. Insisting that it's impossible to live without while not putting anything actionable on the table will most definitely lead nowhere (except perhaps frustration).

I understand it seemed like I was insisting it's impossible to live with, really I was just looking for more acknowledgement that it's potentially a hassle, and supporting simultaneous dep versions can be easier to live with.
I know Node has downsides too, large amounts of code being one of them.  Things like your constraint example are a limitation of some Node libs (for example all components in a React tree have to use the same version of React).  I think it's impossible to support simultaneous versions and magically present the same object instance to library consumers, so it's not like any of us should expect that to be solvable.
Despite the disadvantages there have been plenty of cases where Node's advantages save me time (e.g. transitive dependencies on different lodash versions)
The idea of making PRs is not very satisfying to me because it can take more time and I've seen many PRs take a long time to get merged (over year for a simple PR to Apollo libs, for one of Sindre Sorhus' simple popular libraries I've been waiting a month).  The option then is install my own fork (also more time consuming than cases where installing multiple versions just works.) I wouldn't want to be up against that if I'm trying to add features to a company's product but keep anything from breaking.
The thing I don't know about is how much modification it would take to Haxe's resolution to support dep-specific transitive dependency versions placed in sub-haxe_libraries folder.
I don't imagine major blockers to output code though.  Haxe could append the version name to output minority-version packages like libc__v2_0_0 which is a valid identifier/package name in the target languages I'm familiar with at least.

Anyway, I realize I've gone on more than enough about this so I'll drop it.  It's wrong for me to assume without experience that things in Haxe would be as much of a pain as they were for me in Java since Java didn't have conditional compilation.


Updated install script and conda environments

There are outstanding problems with snakefood (which is still a Python 2 package), not parsing:
 raise ValueError("pipeline failed with %i errors" % len(ex.args)) from ex

in Control.py
Workaround so far is to skip this. I will revisit the cgat_conda_deps.sh script to handle this.

Trying to get snakefood on py3 here:
https://github.com/conda-forge/snakefood-feedstock/pull/3


Use ControllerAs syntax without $scope

Is it possible to configure and use this directive without depending on $scope in my controllers, since I am using ControllerAs syntax?
I'm reviewing code one of my colleagues wrote to get this wired up to a ui-grid and also provide sorting (all paging and sorting done on server side).  Here's what we have:
Controller:
function SubjectAreaListController($scope) {
    var vm = this;
    vm.page = 0;
    vm.perPage = 2;
    vm.clientLimit = 100;
    vm.sortParams = {};
    vm.gridOptions = {};
    vm.gridOptions.useExternalSorting = true;
    vm.gridOptions.columnDefs = [
            {field: "name", displayName: "Name", cellTemplate: "{{row.entity.name}}"},
            {field: "owners", displayName: "Owners"}
        ];
    vm.gridOptions.onRegisterApi = onRegisterApi;

    function onRegisterApi( gridApiIn ) {
        vm.gridApiCore = gridApiIn.core;

        vm.gridApiCore.on.sortChanged($scope, onSortChanged);

        function onSortChanged(grid, sortColumns) {
            if( sortColumns.length > 1) {
                sortColumns[0].unsort(); // only sort on one column at a time
            } else if (sortColumns.length === 1) {
                vm.sortParams = { sortCol: sortColumns[0].name, sortDir: sortColumns[0].sort.direction };
            }
        }
    }
}

Template:
<bgf-pagination
    page="vm.page"
    per-page="vm.perPage"
    client-limit="vm.clientLimit"
    url="'/api/subjectarea'"
    url-params="vm.sortParams"
    link-group-size="2"
    collection="vm.gridOptions.data"
    template-url="paginate-anything-template.html">
</bgf-pagination>

I'm not familiar with ControllerAs but I'm happy to review proposed code changes. Want to send a pull request with your idea? (Sorry for this short reply, I'm kind of overwhelmed with other projects right now but I do want to work with you to make the directive more convenient)

Thanks for the reply. I will see if i can prototype something.
The main issue is in my code above around the following line:
vm.gridApiCore.on.sortChanged($scope, onSortChanged);
I tried replacing $scope with this, vm, but it didn't like either.
controllerAs was added in v1.2, and allows you to define your controller like this:
In View:

    {{ vm.title }}
    {{ vm.anotherTitle }}

In Routes:
$routeProvider.when("/", {
    templateUrl: "main.html",
    controllerAs: "vm",
    controller: "MainController"
});

Then in your controller, you don't have to inject $scope, and instead use it like a normal javascript class constructor:
app.controller("MainController", function(){
    this.title = "Some title";

    //capture the current scope in a local var to be very explicit when dealing w/ closures, etc.
    var vm = this;
    vm.anotherTitle = "another title";
});

Pull requests are welcome. Until then I'm going to close this issue.


Update Manifest Author

PR Details
Updating the Sauce Labs manifest author to be the company rather than the individual developer who started the project.
Description
See above.
Related Issue

Checklist

[X] Changes follows the best practices from the given docs.
[ ] Updated CHANGELOG.md.
[ ] Ran unit tests locally.
[ ] Updated screenshots/sample logs if any.

@sweeneyskirt-sl - You will need to update your branch though since it's out-of-date with the base branch.

@sumo-apps-team - Please review and merge, thanks!


feature request: Better tolerance for missing fields in derived hydrate for forward-compatibility

If I have a struct TOld and add a field to my code to make TNew, I may want to hydrate a TOld into a TNew.
As a concrete example, if I add a new Option<X> field, (perhaps configurably) it should treat missing field as a None.
If I add a field that has implements Default I could also see it treating a missing field as that ::default().
Currently the Hydrate implementation for Option throws an Unexpected when a field is missing.
Quick notes:

There's lots of decisions needed in how the API could look for this
I think in general this kind of forward-compatibility should be doable if semantically TOld is a subtype of TNew (Liskov substitutable)
Thinking about forward-compatibility obviously raises the idea of push-safety / backward compatibility, which would suggest explicitly doing the opposite of #46 so old code could still read new documents. I believe changes are backward compatible if TNew is a subtype of TOld.

Does the missing= attribute address the migration problem?

...I just came back here to mea culpa after seeing it.
I'm going to say "kind of", because it's a subjective API decision, but I'll note that my naive expectation was that Option<X> would behave that way out of the box. Not sure of the right call.
Looks like the following little utilities work fine with missing= (?), which would ease the burden a little.
fn none<T>() -> Option<T> {
    None
}

fn default<T: Default>() -> T {
    T::default()
}


consider token# when calculating ETA

Problem: current ETA fluctuates rather wildly depending on the number of tokens in recent steps.
This:

Tracks and counts the time spent processing each step based on the token count. This can be plotted as a 1-dimensional polynomial over the sample token count, i.e. a constant time per step + time for each token.
Tracks the time to do an eval run, and includes the remaining eval time in the ETA (5745c41def6c37879fb36e7c72520336b8b91638).
Tidies up the log message a bit, including turning per-second values upside down if they are < 1.

The ETA displays the expected date if ETA > 1h.
To get an idea of just how accurate this is, here is step 14/193 of a recent run I did:
[2024-11-13 23:59:47.780] [INFO] [qlora-pipe] step:    13 /   193 loss: 2.1119 tokens: 37120
[706.82k / 10.24M = 0.0690] tok/s: 1089.175 s/it: 34.081 samples/s: 0.117
eta: 2h27m 2024-11-14 02:26:50

and here is the final step:
[2024-11-14 02:35:12.024] [INFO] [qlora-pipe] step:   193 /   193 loss: 2.0039 tokens: 47104
[10.24M / 10.24M = 1.0000] tok/s: 1157.641 s/it: 40.690 samples/s: 0.098 eta: 0s

Since then, I added 5745c41def6c37879fb36e7c72520336b8b91638 which tracks and takes into account the remaining time for evaluations, which is the main reason for the discrepancy in the above (there were 2 evals taking 1m43s each, i.e. 3m20s, so the updated ETA would be 2024-11-14 02:30:10). This gives a ~3.4% error in the early estimate.
Burden: TODO on why self.train_dataloader is not set.

I managed to break this code when I extracted it from my qol branch. I'll be back...


Fixed an infinite loop caused by force casting NSError to CocoaError

Cherry-picked from #5115 for 6.0.2
(cherry picked from commit bf7369a3909583c82f36b901917a92ea0d639a9f)

@swift-ci test


License?

Can you add a license? I'm interested in forking it and making a JAR library so it can be used in a public Gradle plugin.

Done. Please provide here a link to plugin when it will be ready as I am interested how it will be used.

Thank you! I'm still tinkering at this point. I'd like to see how far I can automate getting my source SVGs converted to usable drawable resources with a Gradle configuration object, sort of like how this other plugin I made works.

I have updated my plugin IconDivvy to include vector file processing (rather than create a separate plugin). It uses a cloned copy of svg-non-stop. It provides a Gradle task that takes a directory containing SVG files, applies your gradient fix, and then converts them into Android xml vector drawables, placed in the drawable directory in the project. So, you can set up your gradle build task to automatically include the latest changes to your source SVGs.


Add telemetry files to a .tar.gz

At a certain point, we can safely move previous telemetry into a compressed file. This will make it easier to move logs up into some kind of "cloud" for later processing.
This should just add every log file, apart from today's, into a .tar.gz. An optional cleanup parameter will cause rustup to delete the files that have been moved into the .tar.gz.
Since this isn't on the analysis path, this won't need any changes to that path. Long term, it might make more sense to do something more sophisticated where we compress data by week and produce a summarized view of the week... but this is enough for now.

Sounds good!

Last time we talked about this we were considering looking into Google Analytics instead of rolling our own backend, so this may not be necessary.
Of course using Google Analytics means that we wouldn't get any local analysis tools, which would be useful to individual developers.
Tradeoffs either way, but what's most important is getting something going.

I think that Google Analytics is probably the better long term route. I'll comment over on that issue as to why I think so.

We removed telemetry support quite a while ago.


adding a MOCHA_WORKER_ID environment variable, unique for each worker

Requirements

Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
All new code requires tests to ensure against regressions.

Description of the Change
This change addresses #4456. It adds a MOCHA_WORKER_ID environment variable that is unique for each worker, so that it may be used for by any test resources that need to use global resources (network ports, filesystem paths, etc.) but ensure that these are unique in order to avoid conflicts during parallel tests.
Alternate Designs
I considered using forkArgs instead of an environment variable, so that an ID may be accessed using process.argv[2]. I did not want to do this in case adding arguments was necessary for internal uses in the future.
Why should this be in core?
It is common for tests to use global resources like network ports, which can conflict during parallel testing. Without a feature like this in core, users would be left on their own to create a home-brewed solution (using filesystem files as signals, sockets that elect a leader in the cluster so that one process hands out all global data, a standalone cluster orchestration system), all of which add a lot of complication to writing tests. This would also be a difference when writing tests that run in series vs. parallel, as this concern would not exist (and potentially needs to be turned off) for test in series, and would add pain points when taking existing serial tests and having them run in parallel. This makes using mocha significantly less fun.
This feature takes that pain point away. For example, allocating ports would once again be trivial, using const port = 1234 + Number(process.env.MOCHA_WORKER_ID || 0).
Other parallel testing frameworks, like jest, already use this approach: https://github.com/facebook/jest/issues/2284
Benefits
This solves common pain points for developers writing tests.
Possible Drawbacks
Other than more complexity, I can't think of a drawback for the feature itself.
Since workerpool does not itself provide an option for worker-specific options or to execute code deterministically in a specific worker (only an option to add to the queue to execute on any available worker), I had to use a workaround in the implementation. This workaround could make internal updates more difficult and adds extra requirements to replacing workerpool if a need arises to use a different implementation internally. I personally believe that this tradeoff is worth it, though I am probably biased here.
Applicable issues

Enter any applicable Issues here.
#4456

Mocha follows semantic versioning: http://semver.org

Is this a breaking change (major release)? No

Is it an enhancement (minor release)? Yes

Is it a bug fix, or does it not impact production code (patch release)? No

I submitted this as a draft for now because I have not gotten a chance to write tests yet.
I am also interested in getting some feedback as early as possible in the PR process. Since workerpool does not have the option to add per-worker options, or even directly execute code on a specific worker, I had to get a little bit creative in the implementation.

Have you tried using the PID, e.g.:
const port = 1234 + Number(process.pid || 0)

The randomness of PIDs makes this undesirable to me. A PID can cause a conflict with an existing port being in use on the system, and this will not be consistent across test runs. I can run the tests successfully once, then get a conflict the second time, then run them successfully on the third, etc. A solution for this should be deterministic and repeatable (i.e. a parallel test run with 3 jobs will always get the numbers [1, 2, 3] every time, albeit not necessarily the same number for the same exact test each time).

For reference another use case where deterministic IDs would be desirable https://github.com/mochajs/mocha/issues/4456#issuecomment-844924184

superseded by #4813


Update 60-days-stale-check to prevent it from closing issues on docs repo

Why:
Closes https://github.com/github/docs-content-strategy/issues/675

What's being changed:

The workflow already has exempt labels included, but the bot is still hitting and closing the issues. It could be because the exempt labels added in the workflow should not have space after , as per this README.
Removing space after , between exempt labels.
Check off the following:

[ ] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[ ] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

Update 60-days-stale-check.yml


Triggers are not scheduled in UTC

Triggers are scheduled in the org's timezone, not UTC.

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

ID: 2ea2c851-bd1e-cddc-b4d0-e9f4112b8565
Version Independent ID: 07c23fdd-14b5-985b-1c63-3f26f3a216ad
Content: Configure schedules to run pipelines - Azure Pipelines
Content Source: docs/pipelines/process/scheduled-triggers.md
Product: devops
Technology: devops-cicd-process
GitHub Login: @steved0x
Microsoft Alias: sdanie

Verified that they are UTC.


AudioManager#openAudioConnection() silently fails sometimes

I was getting a report that one of my shards were unable to join voice channels. I went ahead and tested this shard on another server, but it would repeatedly silently fail to join a voice channel. The same code works fine on other shards.
Code used:
AudioManager manager = guild.getAudioManager();
manager.openAudioConnection(targetChannel);

Restarting the shard seems to temporarily have fixed the issue. I haven't logged any debug info from JDA.
I am running on c97947157a

You say silently fail, but are you positive that you weren't being WebSocket ratelimited?

I didn't see anything in the log about being rate limited in any form. Besides, wouldn't that be affecting all shards if that was the case?

No. Websocket sharding is shard specific because it is websocket connection specific. 120 packets per 60 seconds. Starting an audio connection, moving to a different channel, changing selfMute/selfDeaf, or closing a connection all involve sending a packet over the MainWS. When the socket is ratelimited, these packets are queued and sent after the 60 seconds is over.

@Frederikam have you see this happen anymore?

Going to assume that this is not an issue. Reopen if you encounter the issue again.


Add Electron 7.0.0 prebuild

Electron 7.0.0 is the current stable version (while 8.0.0 is in beta)

@splix did you get it to build at all? Having this issue: #337

@baversjo unfortunately no, we just rewrote that part and have removed the dependency

Added in 1.6.1.


Add ability to send annotations as env vars automagically

for a gateway pod-annotations must also be set in the env.

Never mind - not cut yet.


backstage configure with helios pipeline

Feature Suggestion
We want to integrate backstage with helios pipeline. I have tried from past 2 weeks. I did not get, how it should work. There are 2 major configuration file.
helios-config.yml
build_commands:
- npm install --global yarn
- yarn config list --verbose
- yarn install
- yarn tsc
- yarn build
DockerFile
just standard docker file
I am not sure, If i am missing something. Please  help me on this.
Possible Implementation
Not Sure
Context
Adding backstage to helios Pipeline

What's the problem that you're seeing here? And what helios are you referring to? Need a little bit more information to help here :pray:


Add OpenGL ES Rendering

Versions:

ES 3.0

[x] Shader Generator
[ ] Rendering

OS Support:

[ ] iOS/tvOS
[ ] Android

I can help with android bit or my sample can give you good start https://github.com/sakrist/Swift_OpenGL_Example

Oh cool! The OpenGL renderer is already finished, but I'll definitely be able to use this as a reference for building Android platform support.


Quick fix 4lane t collesion (#456)

Removed TargetPose agent in 4Lane_t scenario as a first step quick fix, per discussion in #456

LGTM

LGTM


Automated cherry pick of #5480

Cherry pick of #5480 on release-1.44.
/cc  @enahum

/release-notes-none

/release-note-none


Start creating proper Documentation

Updated
README.md
Created
CHANGELOG.md

Going to merge this pull request in as-is. There are still additions and improvements to be done, but the project needs basic instructions.


feat: add error messages to error flashes

Pull Request

Proposed Changes

Closes #128

Add error messages to error flashes
Display error messages if error when creating, editing, and deleting mirrors

Readiness Checklist
Author/Contributor

[ ] If documentation is needed for this change, has that been included in this pull request
[X] run npm run lint and fix any linting issues that have been introduced
[X] run npm run test and run tests
[ ] If publishing new data to the public (scorecards, security scan results, code quality results, live dashboards, etc.), please request review from @jeffrey-luszcz

Reviewer

[X] Label as either bug, documentation, enhancement, infrastructure, maintenance, or breaking

Currently there is some handling in the create procedure to make a "pretty" message if one already exists:

This is the only error that has this, so is it worthwhile to do this for the other procedures or is that too specific/tedious because of the number of possible errors:

Currently there is some handling in the create procedure to make a "pretty" message if one already exists:

This is the only error that has this, so is it worthwhile to do this for the other procedures or is that too specific/tedious because of the number of possible errors:

@ahpook thoughts?

Hmmm. How many potential other messages are we looking at? The json barf is pretty ugly ...
Is the format predictable enough to extract the message field and pretty-print that with a generic "Failed to create mirror. Error was: " banner?

I'm not really sure how many, but I would guess that the name conflict one is probably the most common and that one is already covered.  I would imagine that the API is consistent and returns a message field though and that would be easy to add to the banner by itself.


administration.js 404 not found

If I activate this plugin it gives me a 404 error.
not created plugin folder in a public/bundle folder

How did you install the plugin? Did you use the release, or the 'Download zip' feature from Github?
You should use either composer (after which you will have to run your build script), or use the release zips. These release zips already contain the compiled javascripts.
The latest release zip can be found here: https://github.com/runelaenen/shopware6-two-factor-auth/releases/tag/v1.1.2


Paragraph Tag Size in Small Screen #26 Fixed

Issue #26 Fixed Now it works fine in both screen (Big and Small Screen)

Good job @9520prashant  👌


Remove offline indicator

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/40466
PROPOSAL: https://github.com/Expensify/App/issues/40466#issuecomment-2064155176
Tests

Switch to offline mode.
Create a group with two or more users.
Click on the header.
Navigate to the members page.
Verify that there is no offline indicator present in the members Right Hand Panel (RHP)

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Switch to offline mode.
Create a group with two or more users.
Click on the header.
Navigate to the members page.
Verify that there is no offline indicator present in the members Right Hand Panel (RHP)

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

I'm currently testing on mobile devices. I'll add screenshots shortly.

@neil-marcellini Hey, while testing, I noticed an inconsistency. We don't display the offline indicator on any other screen in the Right Hand Panel (RHP) on wide screens except for the members page. However, we are displaying the offline indicator on the members page for small screen devices.

@neil-marcellini Hey, while testing, I noticed an inconsistency. We don't display the offline indicator on any other screen in the Right Hand Panel (RHP) on wide screens except for the members page. However, we are displaying the offline indicator on the members page for small screen devices.

I'm not really sure exactly what you're talking about. Would you please provide reproduction steps for the inconsistency/bug, or describe it more specifically with links to the exact pages?

Please follow the testing steps on Android or iOS devices. You'll notice that the offline indicator appears on all screens of the Right Hand Panel (RHP). Now, repeat the same steps on wide screens (using Chrome or desktop).
Prior to this pull request, the offline indicator was only visible on the members page, which has been addressed in this PR.
The inconsistency lies in how we display the offline indicator on small screen and wide screen devices.

@neil-marcellini @parasharrajat Hey, let me know if you're still unclear about the inconsistency.

@Nodebrute I still don't understand because your description does not say what the actual result and the expected result is. Please describe the actual and expected result on production, and with this PR.
Please use this format.

Action Performed:
Break down in numbered steps
Expected Result:
Describe what you think should've happened
Actual Result:
Describe what actually happened

@parasharrajat good question, I think we can skip the C+ testing since it's a one line change.

@neil-marcellini I've checked multiple RHP screens, and this was the only one with the issue, which will be addressed in this PR.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to production by https://github.com/mountiny in version: 1.4.64-6 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Imcomplete Documentation - Want to Contribute

When using Flask-Session, I noticed that it doesn't cover available methods or provide complete examples of usage. I had to find a blog post of a user that used the session.pop() method to remove a key from session storage.
I would like to find out all available methods and contribute to the docs. Let me know how to do this, and I'll work on it.

AIUI, the session object provided by Flask-Session is API-compatible with Flask's built in flask.session object (after all, you access it in the same way, via flask.session).
Flask's own documentation states:

The session object works pretty much like an ordinary dict, with the difference that it keeps track of modifications.

... which is the hint look at https://docs.python.org/3/library/stdtypes.html#mapping-types-dict which is where the pop method (and others) are defined.
I think there's a case for improving Flask's own documentation. IMO, if there is an improvement to be made in Flask-Session's documentation, it should probably just explicitly state that Flask-Session's flask.session is API-compatible with Flask's flask.session object and link back to Flask's own documentation.

Happy to consider PRs, in either project, but this issue is too broad on its own so I'm closing it.


Error due to inconsistent code between Typescript nightly 4.2.0-dev.20210106 and<EMAIL_ADDRESS>

Bug Report

🕗 Version & Regression Information
Version 4.2.0-dev.20210106 and Version 4.2.0-dev.20210105

~⏯ Playground Link~
👨💻 actual tsconfig.json

Link with relevant actual tsconfig.json
💻 Code

🙁
code --install-extension ms-vscode.vscode-typescript-next
fnm default 15
fnm use default
yarn add -D typescript@next <EMAIL_ADDRESS>npm -g i typescript@next
yarn global add typescript@next
npm install -g npm@7
yarn global add yarn@latest
yarn global add npm@7
tsc --version
node --version
npm --version
tsc

🙂
code --uninstall-extension ms-vscode.vscode-typescript-next
fnm default 14
fnm use 14
yarn add typescript@latest <EMAIL_ADDRESS>npm -g i typescript@latest
yarn global add typescript@latest
npm install -g npm@latest
yarn global add yarn@latest
yarn global add npm@latest
tsc --version
node --version
npm --version
tsc

🙁 Actual behavior
when using  tsc --version; node --version
tsc: Version 4.2.0-dev.20210106
node: v14.15.4

when using  tsc --version; node --version
tsc: Version 4.2.0-dev.20210106
node: v15.5.1

🙂 Expected behavior
on the left Expected behavior on the right Actual behavior:

the breadcrumbs on top show the location in my system

the breadcrumbs on top show the location in my system

This one is line 30 in the related clone of the Definitelytyped node package...

This one is line 30 in the related clone of the Definitelytyped node package...

The lib changes were reverted in https://github.com/microsoft/TypeScript/pull/42230; DefinitelyTyped CI is clean today. Thanks!

The lib changes were reverted in https://github.com/microsoft/TypeScript/pull/42230; DefinitelyTyped CI is clean today. Thanks!


Slow startup on a cloud-hosted Hub

Description
We (well, @yuvipanda and team did the hard work) installed the LSP tools for a cloud-hosted hub I use to teach a ~1,200 student course this term. Unfortunately Yuvi and team found performance issues - this commit describes slow startup times.
In regular usage, I also noticed tab-completion being slower than usual, to the point where it interferes with the typing workflow (to save typing, tab completion really needs to keep up with ~ 70 wpm speeds, which means its latency cap should be very, very tight).
Eventually we disabled it as for us, smooth performance of the hub is critical. Yuvi may have more details perhaps.
I'm sorry not to have more specifics, but at least flagging it here for the team. In the long run I hope we'll be able to deploy this in production everywhere, as I'd love to teach students with these enhanced capabilities.
Thanks for the great work, btw!
cc @ellisonbg

Thanks for opening this. Do you have any reason to believe that the performance issues are related to the number of users in the deployment, or do you think that detail is unrelated to the root cause?

This previous issue seems to be describing the same problem: https://github.com/jupyter-lsp/jupyterlab-lsp/issues/796.
I think that the commit description is right: we are checking for installed language servers which takes time. It might take even more on Windows due to the expansion of the search path included in https://github.com/jupyter-lsp/jupyterlab-lsp/pull/731 (unreleased yet).
@yuvipanda, did you try to disable auto-detection of language servers with autodetect traitlet (docs) and specifying configuration of the language servers relevant to your course (I guess a Python LSP server + maybe markdown, but likely not all three Python language servers and a dozen of others more) via config files? The logic is in:
https://github.com/jupyter-lsp/jupyterlab-lsp/blob/b895b4ee1375c3d5f7d209ce36b4877d1185cde4/python_packages/jupyter_lsp/jupyter_lsp/manager.py#L122-L139
You might want to open a PR by changing the autodetect traitlet to Union([Bool, Set]) and if a set is provided only attempt to autodetect the servers from the list provided which would save you from adding custom configuration for those servers.
The autodetection logic is in:
https://github.com/jupyter-lsp/jupyterlab-lsp/blob/b895b4ee1375c3d5f7d209ce36b4877d1185cde4/python_packages/jupyter_lsp/jupyter_lsp/manager.py#L228-L288
While profiling would be needed, my educated guess is that:

few % is lost on entrypoints
much more is lost on server schema validation; some good caching would solve the issue but it may not help if you are booting from fresh image; maybe we could allow to disable the validation but that should be flagged as dangerous since it can lead to runtime errors if your specification gets modified later on.
as much or more time is spent on invoking is_installed check

Further, reworking these two lines could reduce the startup time penalty by up to 50% (probably less):
https://github.com/jupyter-lsp/jupyterlab-lsp/blob/b895b4ee1375c3d5f7d209ce36b4877d1185cde4/python_packages/jupyter_lsp/jupyter_lsp/manager.py#L119-L120
Since we could first find all servers and then filter that list to installed servers. Pull requests welcome :)
I answered on the completer topic in: https://github.com/jupyter-lsp/jupyterlab-lsp/issues/566

@ellisonbg don't think it's related to the number of users, they're fairly well isolated
@krassowski we did not turn it off, I think that would have helped with startup time for sure! Not sure it would have helped with the user lag tho. When we re-enable it,finding a way to constrain the servers it looks for seems the way to go. Alternatively, it would be nice if looking for servers doesn't block jupyter_server startup!

> Alternatively, it would be nice if looking for servers doesn't block jupyter_server startup!
Oh yes, that would be ideal. We should make it async but from a quick skim, it would be a potentially breaking change for the next major version, since frontends do not know that they need to await for initialisation and we only retry the relevant endpoint twice 10 seconds apart (so it should work on most machines but no guarantees):
https://github.com/jupyter-lsp/jupyterlab-lsp/blob/2a524df12da74227bd09316fe339f3a62d66aef2/packages/jupyterlab-lsp/src/manager.ts#L35-L36
And we would needed to communicate specs collection errors on client side too.

Thanks for the feedback  :heart_eyes: !
Thanks for reporting this rather than forking, or just badmouthing it elsewhere. As you note, a lot of folk have a lot of opinions on how this stuff should work for their specific use case, and for the most part, we've had to optimize for the single-user, multiple-launch experience. I've found "just" and "need" to come up very frequently, which have become some of my least favorite words in working on FOSS.
There are a ton of things at a managed hub level that would make this experience more fun, especially #184. I'd really love more sourcegraph-like features to work out of the box... but more about that later.
At any rate, lazy loading servers would move this from server startup to (probably) first opening of any document, as we wouldn't know in advance which mimetypes had servers.
Some thoughts:

all of the discovery and loading currently happens synchronously in LanguageServerManager.initialize

this could be deferred until the event loop has started (but before it was requested), and then be pushed to a thread, as most of those things are blocking
then the LanguageServersHandler.get could return a new version: 3 response which adds is_complete and logs

on the happy path, a client could "unblock" if the server it needs is ready when first requested
the "sad path" of not knowing would wait until everything discovery technique failed

slow autocomplete is almost entirely driven by the language server in question

for some language servers there are some tricks can be moved to the image build or postBuild equivalent

for jedi-based language servers, this script prepopulates the underlying cache

this cache is not really in a documented format, and is not appropriate for caching/packaging anyway

longer term, another fix is to build/package offline responses (#184)

this would be a whole separate set of executable configurations, as these almost never seem to be integrated directly into language servers
sadly, for python, the sourcegraph one has been been deprecated in favor of... their new "standard", the protobuf-based SCIP (cue XKCD link)

I cannot recommend adding this dependency to the jupyter stack, unless we move the whole shooting match there :stuck_out_tongue_closed_eyes:
however, this kind of mirrors the whole experience I've had with the "community-based" LSP experience

At any rate, I'll take a look...

@fperez @yuvipanda we released jupyterlab-lsp 4.0 which includes https://github.com/jupyter-lsp/jupyterlab-lsp/pull/882. Would you like to give it another try and see if the startup time is satisfactory now?


xarray.align Inflating Source NetCDF Data

What is your issue?
Hi there,
I've been experiencing a peculiar issue that I hope I could get some further insight on. Some background - I'm processing data from raw NetCDF with Xarray to be written to a Zarr store. The hope is that I can append new pieces of data as they are received.
The code is as follows:
First I write an empty Zarr store to prepare for incoming data. Each of the dimensions/coordinates are pre-populated with all known values.  Dimension w is one million in length. The others vary in length but are generally < 50
empty_ds = xarray.Dataset(
    coords=dict(
        a=(a), b=(b), c=(c), d=(d), e=(e), f=(f), g=(g),  h=(h), w=(w)
    ),
    attrs=dict(description=f"Dataset for {a[0]}")
)

ds.to_zarr('./zarr', compute=False, mode="w")

I then need to open individual NetCDF files, whose coordinates are a subset of those that exist in the Zarr store. As you can see below, the dataset is ~8MB per file.

I then perform an alignment between the Zarr store, which has all coordinate values, and the individual NetCDF files contents to make sure dimensions and coordinates match:
ds1 = xarray.open_mfdataset('data.nc')
zarr_ds = xarray.open_zarr(".zarr/")

a, b = xarray.align(zarr_ds, ds1, join="outer", exclude="h") #we exclude h because its the dimension we will append by
b.to_zarr("./zarr/", mode="a", append_dim="h")

These operations work, however the new aligned dataset b that I want to write to the Zarr store has blown up in size as a result:

And after writing back to the Zarr store, results in a large file, whose side should theoretically be ~8MB before compression.

Does anyone have insight as to why this might be happening? I've tried changing chunking settings when both opening and writing data, changing the dtypes of dimensions, etc. My hunch is that it has something to do with the dimension that is one million in length. For context, the data variable contains one million data points that correspond to the one million values of w. Thanks for the help!

Even without looking at the size of the data, the dimensions of the array seem to have grown a lot!
The size of the data seems consistent with that (i.e. 2*27*4*3/2*48*8MB=125GB, though not exactly 58GB, looking at the difference in the "Array Shape" between the two images)
Does looking at the values of the dimension that's grown to size 48 help — are those possibly different, even though you don't intend them to be, and causing it to be huge (but sparse!)?
Does that make sense?

The size of the data seems consistent with that (i.e. 2*27*4*3/2*48*8MB=125GB, though not exactly 58GB, looking at the difference in the "Array Shape" between the two images)

This would be correct if we added that many 8MB data sets, but we just added one! So I'd expect the entire store to be roughly that size (8MB) before compression since in the code example above we are just adding one data array to the Zarr data store. Would you be able to clarify this calculation 2*27*4*3/2*48*8MB=125GB ?

Does looking at the values of the dimension that's grown to size 48 help — are those possibly different, even though you don't intend them to be, and causing it to be huge (but sparse!)?
Does that make sense?

So the reason why all the dimension sizes have grown is because we initialize the Zarr with the set of all possibilities that the coordinates might be (read somewhere that this is what you should do - initialize an empty Zarr with the coords/dimensions you will need). Then what I figured I needed to do was align the dimensions of the .nc file with that of the Zarr store, so that when the data array is added the coordinates and dimensions line up - this is why we see the dimensions grow.
Is this the correct approach? I found the limitation/design of to_zarr() that allows you to only append to one dimension meant that if you want to append new data to a Zarr store, all dimensions/coords must pre-exist in both the Zarr store and individual DataSet that you'd like to append. This is what drives the decision to perform xarray.align.
Without aligning, I would get error messages that complained about dimension sizes being different. Thanks again for your help!

I think perhaps the region kwarg is a better solution than appending for your case: https://docs.xarray.dev/en/stable/user-guide/io.html#appending-to-existing-zarr-stores


NeoPixel_RGB limit

i have Ws2812b led grid, which has 256 per grid i have 4 of them, when i set nPixels from pixels sample it only lights first 256 it never goes onto next grid i also tried Adafruit_NeoPixel which works with rest of them but i prefer using pixels from this library any idea what might be wrong ?

Are the grids daisy-chained?  In other words, does this look like a single line of 1024 pixels?

yes, they are chained, https://www.amazon.com/dp/B0B773C9KS

Are you trying to set them all to the same color?  If so, I assume you are setting the size to 1024 (not 256).

yes i am setting 1024 and yes same color whatever comes from homekit

    pixel->set(color.HSV(h*p, s*p, v*p),nPixels);       // sets all nPixels to the same HSV color
problem seems to be with this line
    pixel->set(color.HSV(h*p, s*p, v*p), 1024);       // sets all nPixels to the same HSV color
so its example problem not lib it works now for me

esp32-wroom-32d, but as i mentioned above it was example problem

What exactly was the issue - a problem with the tutorial example?

What exactly was the issue - a problem with the tutorial example?

yes, i just replaced variable with 1024 and it works

Ah - I just figured out the issue.  In my tutorial example I define the nPixel variable as uint8_t, which means if you pass the parameter 1024 it will be converted to 256 (actually, it gets converted to zero, but when counting backwards you get the same result).
In the example if you change every instance of uint8_t nPixels to int nPixels it should work fine.  I'll update that in the tutorial going forward.
For example:
  NeoPixel_RGB(uint8_t pin, uint8_t nPixels) : Service::LightBulb(){

should become:
  NeoPixel_RGB(uint8_t pin, int nPixels) : Service::LightBulb(){

great good catch thanks for quick response


Movie Recipes Not Working With Latest Plex Agent

It seems that any movie recipes don't function correctly if the library they're pointing at is using the new Plex Movie Agent
When running the recipe python-plexlibrary can't see any movies in my overall movie library and just lists everything as missing.

same here, hope that is something that can be fixed

Yeah I'm seeing this issue too

With what version of Plex did this issue start? Can you confirm that links are created and are readable? Does it work with another agent? It sounds like an issue with the Plex agent not following links, not much we can do about it in that case.

It started around the 1.20.0.xxxx range but only on libraries that are using the new plex agent. Libraries that use the old agent even with the latest plex version still work fine.
The links are not created at all, plexpython can't see any movies in my main library to create links from.
Heres a pastebin of the output
https://pastebin.com/ZXY6uTSu
You can see that it lists 130 missing items that it doesn't think i have, which i can see theirs movies in there i definitely do, it just doesn't seem to be able to read the list of movies in my main library now that the library is set to use the new agent.

There's a couple of plex forum posts about this issue.
https://forums.plex.tv/t/new-plex-movie-agent-not-populating-imdb-tmdb-id-field-in-xml/618519
https://forums.plex.tv/t/new-plex-movie-agent-does-not-contain-imdb-info/618121
It's worth noting that I believe Plex has an update to its TV Shows agent in the works that would likely cause the same issue.

yeah is 100% the agent the one doing that, dont think adamgot will be able to do much.

One of the links above has a comment that mentions using the advanced settings on a library to use the legacy agent rather than the new one.  Everything seems to work fine once this has been set, although I refreshed the metadata on each library just to be safe.

One of the links above has a comment that mentions using the advanced settings on a library to use the legacy agent rather than the new one. Everything seems to work fine once this has been set, although I refreshed the metadata on each library just to be safe.

i may need to refresh the metadata .. because i still get no results

I commented here with a quick and dirty fix:
#90


No file matches path build/phpunit/logs/*.xml

Describe the bug
Hi,
I'm receiving the Warning

[!WARNING]
No file matches path build/phpunit/logs/*.xml

I am 100% that the report files exist at this path, but for some reason, this action is not finding them.
I cannot see where I am going wrong.
To Reproduce
I list the logs before hand, so I am sure they exist.
See screenshot below showing the action can't find any logs.
      - name: "Run Tests"
        run: docker/bin/test-parallel.sh

      - name: "List logs"
        run: Run ls -l build/phpunit/logs

      - name: "Test Report"
        uses: dorny/test-reporter@v1
        if: success() || failure()
        with:
          name: PHPUnit Functional Tests
          path: build/phpunit/logs/*.xml
          reporter: java-junit
          max-annotations: 0

Screenshots

Thankyou!

Hi @bendavies, what did you try to troubleshoot the issue you are having?

Hi @jozefizso
As above, i made sure the reports existed.
I also tried moving the reports to he CWD, but that didn't work either.
Do you have any suggestions?
Thanks!

This is definitely not a bug in the test-reporter.

Sure - I'm just trying to figure out what I'm doing wrong.
Thanks

fixed by specifying the absolute path, rather than a relative one.

i have working-directory set, did not notice that i needed to also set the [working-directory](https://github.com/dorny/test-reporter/blob/main/action.yml#L65) input for this action


Got a working UWP example using SpotifyAPI-NET, where to put it?

Hey @JohnnyCrazy ,
I've fiddled with your Lib for a bit now and got it to work for UWP - with a couple of con's atleast. But if I'm not mistaken for now it's the appropriate way of doing that for now. I made a repo with my example - if you want to you can link it somewhere in your examples/docs.
Here's the link: https://github.com/Saik19922/UWP_SpotifyAPI-NET_Example
Thanks for your work on the Lib so far, making my life easier ;)

Hi @Saik19922
I will have a look at it in the next days, maybe we can add it as another example in this repo if you're interested in it. Else, we can also put it in the docs :)

Sorry for the delay. I invested some more time into UWP with the upcoming release of v6 and the tight security model around localhost/loopback is making it impossible to create a local server for OAUth2 responses. The only way to run a local server is your way, but it is a lot of setup for a simple functionality.
But, protocol registrations to the rescue! UWP Apps can easily register so-called protocols, which allows other applications (like browser) to open the app with a specific uri (like spotifyapi.web.oauth://token/). This works fairly well and provides a nice ux. Custom protocol uris are also supported by spotify's redirect uris.

You can see a full example here https://github.com/JohnnyCrazy/SpotifyAPI-NET/tree/v6/SpotifyAPI.Web.Examples/Example.UWP (Note it's using v6 of the spotify api, but v5 can be incoporated in the same manner)
@Saik19922


Fix tests - Maintainability word

We should update all namespaces and class names as well.

You're faster than me :)

We should update all namespaces and class names as well.

Yes, I've merged #94 too fast :/

;P

:)
I've created issue #95

Yes, I've merged #68 too fast :/
I think is better to do this is another issue anyway.


Automatic mdBook Documentation

Following the lead of many Rust projects, I thought it would be nice if we adopted mdBook for the documentation and started generating most of the documentation automatically. The existing documentation was lacking in content, so I removed it (including manpage generation, but we can get that back later via mdBook).
The automatic generation is a bit strange, because we need to extract information from clap. So I've added a binary called uudoc which uses the same list of utils as the coreutils and writes HTML files to a docs/src/utils directory (which is in .gitignore). It's far from perfect, but it works surprisingly well already.
To generate the docs, you therefore need 2 commands:
cargo run --bin uudoc --all-features
cd docs
mdbook build

I've also written initial versions of an introduction and a page for the multi-call binary. The CONTRIBUTING.md file is also included. The layout is based on how The Cargo Book presents their options and flags.
To create the initial structure for the book, I used a little python script, which I've included here, so that we can refer to it later, but it isn't strictly necessary anymore.
A temporary hosted version can be found here: https://tertsdiepraam.github.io/uutils-docs/ (until we set it up in the CI)
Edit: Text above is updated to reflect the latest version.

note that we have also for the internal code:
https://uutils.github.io/coreutils-docs/coreutils/

maintained here:
https://github.com/uutils/coreutils-docs
(dunno why it hasn't been refreshed)

note that we have also for the internal code

That's a good point, but the purpose is different. This is meant to be more manual-style and user-focused, whereas the rustdoc documentation is developer-focused.
There is also https://docs.rs/uucore/latest/uucore/, which is the same as https://uutils.github.io/coreutils-docs/coreutils/.

By the way, @sylvestre, do you have the original (svg?) files for the uutils logo? I wanted to adapt it for the favicon and put it in the introduction.

By the way, @sylvestre, do you have the original (svg?) files for the uutils logo? I wanted to adapt it for the favicon and put it in the introduction.

it was before my time. maybe @Arcterus ?

This is the thread from when it was made.  I don't personally have them though, and I can't remember if we ever adjusted it afterwards.

Thank you!

excellent work, thanks :)

I love it, well done!
Can you add the generation & publication here?
https://github.com/uutils/coreutils-docs

I did it:
https://uutils.github.io/coreutils-docs/user/
updated daily :)


[Doc] correct ceph adoption prerequisites

update ceph rgw, rbd and nfs prerequisites steps in the adoption document.
Jira: https://issues.redhat.com/browse/RHOSPDOC-2135

Note to self: After this PR is merged, I need to copy the updated files downstream and republish the adoption guide.


"configure locale" is very technical

Today I was trying to find the action to change the language and was just searching for "language" and could not find it. I am not sure if "Locale" is something a user would typically search for. On Mac OS at least the setting is called "Language and Region" and on Windows 10 "Language".
I think we:

should call it "Change Language"
keep it english and not translate it

@dbaeumer fyi

+1 to chance this to Language. But lets wait until we do the Menu work and then change this once.

Maybe at least do the nls change for March, I think that is low risk and helpful.

@egamma what is your take on this?

I mean I can change the sting so that the UI says Configure Language. The json file would still talk about locale.

I opt to keep Configure Language to avoid any problem with Change Language Mode. In addition Change is currently hot. Configuring the language will never be.

OK. I fixed this for March and pushed to release/1.0.0.
Discussed the naming with @egamma  and we agreed on 'Configure Language'

:+1:


[stable/datadog] Align ENV var handling (avoid ranging through them to allow any K8S valid syntax)

Signed-off-by: Vincent Boulineau<EMAIL_ADDRESS>What this PR does / why we need it:
Use direct YAML block from user in .env instead of ranging through them.
Replaces #23067
Which issue this PR fixes
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/lgtm


Consistently use two dashes for long command line options.

This updates our usage of command line flags we control (MLIR flags and IREE flags) to use two dashes for long options. Short options (e.g. -o module.vmfb) and options for tools outside our control (e.g. -fsanitize=address) remain unchanged.
This is part of addressing a source of confusion explained in https://github.com/google/iree/issues/5931. Several of our tools have bad failure modes when receiving malformed flags (typos, extra spaces, overlooking implicit stdin, etc.). We can reduce the risk of user errors by being consistent across the project in how we use command line flags.

⚠ Bikeshedding ahead ⚠
Rationale
In general (across tools, languages, and platforms), command line tools use a mix of positional arguments and keyword arguments. Positional arguments use no prefix like - or -- and are parsed in the order they appear. Keyword arguments use some prefix (typically - or --) followed by the flag name then a separator (typically = or  ) and then the value.
Within keyword arguments, there are also "short" and "long" options. Short options are usually one letter versions of long options, and sometimes multiple short options can be mixed together. For example, see https://man7.org/linux/man-pages/man1/tar.1.html and equivalent commands like

tar --create --verbose --file etc.tar /etc
tar -c -v -f etc.tar /etc
tar -cvf etc.tar /etc

Not all tools follow that convention, and parsing can be made to be more forgiving, but internal consistency without a project is worth aiming for.
Other discussions:

What's the difference betwen the single dash and double dash flags on shell commands?
What's the difference between one-dash and two-dashes for command prompt parameters?

This change was generated via a mix of regex find/replaces and manual review. See each commit for more details.

Not sure what to do about the code owners reviewer recommendations here :)
How about if anyone has a particularly strong opinion one way or another, they make that known? I could also prune this change to only touch documentation files, exclude .mlir files, etc.

I don't have a strong opinion here. If you want me to stamp, I am happy to 😀

I don't have a strong opinion here. If you want me to stamp, I am happy to 😀

+1

just want to say thank you for this. you have no idea how many times I had to try - -- and positional args to get the right mix.

It would probably be worth it to make IREE's own (runtime) flag parsing be strict about single vs double dashes in keeping with everything except LLVM.

(I mean in a separate PR, that is)

Well trying to review this crashes Chrome

Reviewing one commit at a time may be easier. Each commit is basically one regex find/replace for patterns like:

-some-flag=value
-some-flag
-someflag
"-some-flag"

Personally, I wouldn't get into the inevitable flame war caused by proposing that this change in LLVM upstream.

Same :P

It would probably be worth it to make IREE's own (runtime) flag parsing be strict about single vs double dashes in keeping with everything except LLVM.

Agreed. https://github.com/google/iree/pull/6334 was a good (related) start there.

Reviewing one commit at a time may be easier. Each commit is basically one regex find/replace for patterns like:

The first commit crashed chrome for me :crying_cat_face: I can pull and review locally maybe if you actually want a human eyeball on this

Reviewing one commit at a time may be easier. Each commit is basically one regex find/replace for patterns like:

The first commit crashed chrome for me 😿 I can pull and review locally maybe if you actually want a human eyeball on this

Ah 😆. The first commit is the most mechanical/trivial but touches tons of generated test files. Up to you - I reviewed most of the diffs as I was making the changes (to avoid false positives), so a general LGTM on the intent of the PR and a sanity check through some of the diffs should be good enough IMO.

Great, thanks :D
Just synced past conflicts again and then I'll plan on merging once presubmits pass (except pylint)


Remove shortcut for option "--config" + Improve readme + Update dev dependencies

Q
A

Is bugfix?
❌

New feature?
❌

Breaks BC?
✔

Fixed issues
-

👍


Enhancment: Secure the release process

Hello
I am Hrittik and I am participating in Security Slam where the goal is to secure the Kubernetes projects with the help of #eddie-knight. Here you can find more details.
What would you like to be added:

[ ] Ensuring SBOMs are Generated by Kubernetes BOM or any other tools. SIG Release’s GitHub Action for bom can be helfpul
[ ] Ensuring SLSA Attestations are Generated when Possible. SIG Release has a GitHub action that will set Tejolote that can be used. [Example]
[ ] Add a new workflow which will generate openvex data on each release. The initial PR adds the OpenVEX data  https://github.com/kubernetes-sigs/gateway-api/pull/2683 for this repository. PR workflow can be automated using this [Example] for each release.

Why this is needed:
This will be helpful for having an automatic security position for the project artifacts and long-term health of a project. Eventually, we can work towards a better score on the OpenSSF Scorecard Report and CLOMonitor: https://securityscorecards.dev/viewer/?uri=github.com/kubernetes-sigs/gateway-api
Would love to discuss this with the maintainers and ship this changes if the community feels these are required.

:wave: This task was outlined and proposed by @puerco and SIG Release to be implemented across all subprojects. Please let @hrittikhere know if there is anything he can do to assist with normalizing the release process.

The CLOMonitor is live here: https://clomonitor.io/projects/cncf/gateway-api now


Container volumes - ContainerPath other than C: drive?

Is it possible to have other drives in container than C:?

Of course
docker run -it -v c:\new-data-volume windowsservercore cmd

works.

You should be able to get it work with below command: docker run -it --volume=d:\new-data-volume:c:\datavolume windowsservercore cmd

@rohitjaini  Well, that's not what I want.
In your example D:\ is in source (host) and C:\ is in destination (container).
My question is about opposite direction

We support mapping a whole second drive letter, but for now, not portions of it. So you can say
docker run -it -v d: windowsservercore cmd

and get a volume as drive D: in the container. But you can't write d:\data-volume or event d:\; it must be d:.

@jstarks Thank you for the explanation

Thanks @jstarks - I've added this to documentation.
https://msdnstage.redmond.corp.microsoft.com/en-us/virtualization/windowscontainers/management/manage_data?branch=data-drive-patch#mount-full-drive

@jstarks, @neilpeterson, @scooley, could you please clarify how non C drive volume mapping should work?
For example:
D:\> mkdir folder
D:\> docker run --rm -it -v D: microsoft/nanoserver:1709 cmd /c "dir D:"
 Directory of D:\

05/11/2018  11:29 AM    <DIR>          .
05/11/2018  11:29 AM    <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)  94,127,910,912 bytes free

When starting powershell in the container it fails with a following error:
Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed.
dir : Cannot find drive. A drive with the name 'D' does not exist.
At line:1 char:1
+ dir D:
+ ~~~~~~
+ CategoryInfo          : ObjectNotFound: (D:String) [Get-ChildItem], DriveNotFoundException
+ FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

So it looks like it just creates an empty drive D: inside container and does not provide any content from the host filesystem or this drive has problems with permissions to access it.
D:\> docker info
Containers: 4
 Running: 1
 Paused: 0
 Stopped: 3
Images: 11
Server Version: 18.04.0-ce
Storage Driver: windowsfilter (windows) lcow (linux)
 Windows:
 LCOW:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: ics l2bridge l2tunnel nat null overlay transparent
 Log: awslogs etwlogs fluentd gelf json-file logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 16299 (16299.431.amd64fre.rs3_release_svc_escrow.180502-1908)
Operating System: Windows 10 Pro Version 1709 (OS Build 16299.431)
OSType: windows
Architecture: x86_64
CPUs: 8
Total Memory: 63.97GiB
Name: munit-199
ID: LLWJ:P3CA:ITHO:GODJ:OCUX:R4LO:6ASW:FPGJ:RWX3:UT6D:L7ZR:7LG4
Docker Root Dir: C:\ProgramData\Docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: -1
 Goroutines: 30
 System Time: 2018-05-11T11:29:51.2341926+02:00
 EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

Hi folks, developer from the future here, digging deep into the past for an issue I'm currently having while trying to run a WS2019 container.
It's taken me a few hours of detective work to find this issue and the corresponding doc fix that was made in response to it - unfortunately that fix seems to have been lost in translation some time in the last 4 years, because the current persistent volumes doc at https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/persistent-storage doesn't mention this limitation.
My experience in practice, however, shows that it still exists. @jstarks - would you happen to know if there has been any progress made on this? I'm guessing it never quite had enough priority to be addressed, which is fine, but I'd been interested to find out if it's ever been looked at since.
At any rate, I will aim to submit a PR here that adds in a mention of the limitation sometime soon, work permitting.

@jstarks - it's been seven years.  please let us know if mounting works correctly yet, because it very much appears not to
@mwieczorek - please reopen this ticket; it should not be closed
@neilpeterson - help?  mounting drives?  really?


if/then/else applying wrong schema if target property is not present

Ajv version: ^6.0.0-rc.1
JSON Schema
{
  "$schema": "http://json-schema.org/draft-07/schema#",

  "type": "object",
  "properties": {
    "firstName": {
      "type": "string"
    },
    "countryOfBirth": {
      "type": "string",
      "enum": [
        "England",
        "Italy"
      ]
    },
    "cityOfBirth": {
      "type": "string"
    }
  },
  "required": ["firstName"],
  "if": {"properties": {"countryOfBirth": {"pattern": "^England$"}}},
  "then": {"required": ["cityOfBirth"]}
}

Sample data
{
  "firstName": "Emma"
}

Your code

var Ajv = require('ajv');
var ajv = new Ajv({allErrors: true});

function runValidation(inputSchema, submittable) {
  var validate = ajv.compile(inputSchema);
  var valid = validate(submittable);
  if (valid) {
    return { result: 'Valid!'};
  } else {
    return { result: 'Invalid: ' + ajv.errorsText(validate.errors)};
  }
}

Validation result, data AFTER validation, error messages
'Invalid: data should have required property \'cityOfBirth\', data should match "then" schema'

What results did you expect?
I would expect this object to be valid against the given schema.
The property countryOfBirth is not required, when it's present it's being evaluated correctly.  This happens even when multiple if/then/else blocks are in place, the schema applied in the one for the first if.

@fpenim The result is correct.
You need to add required: ['countryOfBirth'] to the subschema in “if” keyword for the schema to work as you expect. Without it, “if” passes validation when the property “countryOfBirth” is absent and the subschema in “then” requires that “cityOfBirth” is present.

Also, you could use const: 'England' instead of pattern.

Thanks 👍


Dishwasher plug off should set dishwasher to idle

Not going to do this, I didn't expose the button and having it trigger on "power off" events would mean it would stop notifying me as soon as the power is cut automatically.