Loop

Depends on #51. Adds a loop command, which just loops forever.
Since degenerate is like a tiny computer, I used computer terminology. The program is the sequence of commands that are being run, and the program_counter is the the index of the next command to run. On a physical CPU, the program counter (also called the instruction pointer) is the address of the next instruction to run.
I did cargo run square print loop and it just hung, so I added the verbose command, which toggles the verbosity level, and makes it print the command its running and the program counter. Then I realized that I just didn't resize first.
I need to add tests.

@terror Not ready to review, but it's shaping up to be a sweet little computer.

@terror What do you think about turning this into a proper stack-based language like forth?
For example, resize:10:20 would then be 10 20 resize and for:2 would be 2 for. I think that it would be more flexible, and we could add a bunch of powerful stack manipulation operators.

I'm actually also thinking that we should get rid of the Command type and just use strings. The primary reason we're using an enum instead of strings is to parse things like resize:1:2 into a strongly typed value. However, if we make everything stack-based, we don't need to do that, and we can keep things as strings, which will have some benefits: no need to parse anything, can just match strings with match arg { … }, and error messages will be better, since we can print out whatever the user typed.

@terror What do you think about turning this into a proper stack-based language like forth?
For example, resize:10:20 would then be 10 20 resize and for:2 would be 2 for. I think that it would be more flexible, and we could add a bunch of powerful stack manipulation operators.

100% down for that, besides the syntax, it would allow for the additions of stack operations such as rot, dup, over etc which could be nice to have. We could also just iterate over individual tokens and match on those instead of parsing them into a type

This is ready to go.  We should leave the stack stuff to another PR.

I also started using row col consistently. Even though nalgebra is column-major,  it always puts row first and column second when addressing and in function arguments.


Support application names with whitespace

@xaoseric mentioned that there is an issue.
This works for me:
% launch "PyCharm CE"
(...)
Selected candidate: "/Applications/Developer/PyCharm CE.app/PyCharm CE"

% launch "/Applications/Developer/PyCharm CE.app"
# Found "/Applications/Developer/PyCharm CE.app"

@xaoseric can you please give details?

Well, actually:

One small bug I did find is that if we do launch PyCharm CE it says that it can't find PyCharm. We need to do launch "PyCharm CE" for it to find that .app directory.

This behavior is correct. The name of the application is  PyCharm CE and you must give this string to launch as the first argument.


Catalog Views and integration with Service Manager

Description
Provide new UI for BTP Operator in the Busola where users can see Service Catalog.
Reason
We want to make BTP Operator user's lives easier and more convenient where they can see all of the available services in the Busola and then just provision some of them.
AC

[ ] 1) Direct integration with the Service Manager
[ ] 2) New BTP Operator UI in the Busola

Links

https://github.com/Peripli/service-manager
https://help.sap.com/docs/service-manager/sap-service-manager/sap-service-manager

Reference sharing:
apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: kyma-demo-instance-123
  namespace: develope
spec:
  serviceOfferingName: xsuaa
  servicePlanName: reference-instance
  parameters:
    referenced_instance_id: <shared service id>
---
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: kyma-demo-binding-123
  namespace: develope
spec:
  serviceInstanceName: kyma-demo-instance-123

Meeting notes and current arrangements (3.04.24)
Arrangements:

support operations as in Service Manager
create REST API similar to Service Manager API (OSBAPI)
allow to connect Service Instances and Service Bindings from Service Manager to the cluster (custom resources in the cluster should reflect instances and bindings in SM)

Limitations:

Service Manager context is limited to the scope of SAP BTP service operator client provided during Kyma environment provisioning

Future ideas:

allow update of the cluster ID

SAP BTP service operator recognises the following secrets for service instances:

default secret named sap-btp-service-operator in the centrally managed namespace (kyma-system)
secret for a different subaccount mapped to a namespace in the cluster with namespace's name as a prefix in the secret's name <namespace-name>-sap-btp-service-operator in the centrally managed namespace (kyma-system)
secrets named sap-btp-service-operator in other namespaces mapped to different subaccounts
arbitrarily named secret in the centrally managed namespace (kyma-system) connected to a different subaccount pointed in the ServiceInstance btpAccessCredentialsSecret field in the spec

PR introducing SecretProvider which fetches secrets with credentials for Service Manager:
https://github.com/kyma-project/btp-manager/pull/655

UI PR: https://github.com/kyma-project/btp-manager/pull/649

Adding Service Manager client: https://github.com/kyma-project/btp-manager/pull/674

Unit test for SM client service offerings: https://github.com/kyma-project/btp-manager/pull/703

Marketplace: ServiceOffering details + plans details Backend (Marcin)
Done in https://github.com/kyma-project/btp-manager/pull/717

Marketplace: Create CRUD Service Instances  Backend (Marcin)

Done in: https://github.com/kyma-project/btp-manager/pull/742

Service Bindings in SM client and Service Instances in API:
https://github.com/kyma-project/btp-manager/pull/735

To do (as of 16.07.24):

API: create, update, delete Service Instances
API: list, delete Service Bindings
API: tests
Frontend: Service Instances
Frontend: Service Bindings

Service Bindings API: https://github.com/kyma-project/btp-manager/pull/757

Service Instances API: https://github.com/kyma-project/btp-manager/pull/758

Service Bindings API extension and tests: https://github.com/kyma-project/btp-manager/pull/772

Meeting notes 31.07

allow to set secret's name and namescape,
if secret's name is missing, use name from Service Binding. Allow user to provide proposed default value for secret's name (e.g. SB's name + random characters),
send empty values for clusterid, namespace, k8sname when creating SI/SB,
display the available secret with its name for Service Binding. If the secret is missing, let the user know and allow to create it in any namespace,
document questions to CIS team whether there is a way to update context (clusterid, namespace) for existing SIs and SBs (apparently it looks like created SI in K8s cluster cannot change the namespace without deletion of actual service instance).

Meeting notes 6.08.2024:

I have discovered a trouble some behaviour: If a service binding with the same name binding (just an example name that does not matter in the example) for both binding and secret exists then creating another service binding with the following request fails but binding is created despite the API error:
{
name: "binding-new-name"
secret_name: "binding"
secret_namespace: "default"
service_instance_id: "872fe846-569e-4e54-98de-04983e8ea194"
}

I have discovered a troublesome behaviour: If a service binding with the same name binding (just an example name that does not matter in the example) for both binding and secret exists then creating another service binding with the following request fails but binding is created despite the API error:
{
name: "binding-new-name"
secret_name: "binding"
secret_namespace: "default"
service_instance_id: "872fe846-569e-4e54-98de-04983e8ea194"
}

PR with the fix: https://github.com/kyma-project/btp-manager/pull/826

Testing results:

When adding new service binding, both name and secret name should have random suffix added. Right now only Secret name has it.

How to demo:

show 3 credentials in the Kyma cluster, two from SA_1 and one from SA_2 (show new UI, Busola and BTP Cockpit)
add new entitlement to one of the SA and show new UI that marketplace is extended with new offering (classes and plans)
show how to create SI
show how to create SB and secret in the given namespace
explain how thet looks like in the BTP Cockpit Service instances view (how to find which SM instance was used)


Proposal: foreach loop

The most common case of iterating an object is:
var object = {a:1, b:2, c:3};
for (var key in object) {
	if (!object.hasOwnProperty(key)) {
		continue;
	}
	var value = object[key];
	// do stuff here
}

and for arrays is:
var array = ['a', 'b', 'c'];
for (var i = 0; i < array.length; i++) {
	var value = array[i];
	// do stuff here
}

It would be very useful if TypeScript provide a simple foreach loop that can combine both of above.
Something like this (PHP style):
foreach (object as key => value) {
	// do stuff here
}

and for arrays:
foreach (array as i => value) {
	// do stuff here
}

Needed type of underlying for-loop should depend on the type of iterating variable.
If compiler cannot definitely determine variable type (whether it's an array or object) - it should use for..in loop and show a warning

in TS available next format of foreach loop expresion
let array = ["a","b","c"];
array["qwerty"] = 123456;
for(let val of array){
     console.info(val);
}
/// in console we will see something like "a", "b", "c", 123456

for(let key in array){
     console.info(key);
}
/// in console we will see something like 1, 2, 3, "qwerty"

I also hate the for loops in JS/TS, but I think that the problem is in ES/TC39 and not in TypeScript. Sometimes I just need the value in an array, so I use a for..of loop. But then, I find out that I need the index too, then I need to rewrite my for loop. Happens all the time for me.
I would rather just put an index variable in the current for..of loop:
for(let index, value of values) { ... }

What is wrong with?
let array = [ "a", "b", "c" ];
array.forEach((value, index) => { ... });

You cannot use this inside the function without additional complications.
And you cannot call forEach on objects

You cannot use this inside the function without additional complications.
And you cannot call forEach on objects

I was referring to @tinganho last use case.  I am questioning the value of adding something that is already functionally available and @tinganho says the "drawback" is sometimes needing the index and having to rewrite is code.
The fat arrow function will address the this scope complications.

@kitsonk same argument as all other syntaxes introduced in +ES6. Productivity and cleanness.  forEach can also not break a loop, continuing and go to outer loop with without dirty hacks.
I still think:
for(let index, value of values) { ... }

is easier than:
array.forEach((value, index) => { ... });

less punctuation tokens to type.

You cannot use this inside the function without additional complications.

That was the reason arrow functions were introduced; they don't introduce a new this value.

I also hate the for loops in JS/TS, but I think that the problem is in ES/TC39 and not in TypeScript.

Quoted for truth. We don't add non-ES control flow structures to the language, especially ones we hope might be addressed in the future.

Just brought the discussion to esdiscuss:
https://esdiscuss.org/topic/for-statement-with-index-and-value


Build magic on osx

Fix magic so that it can build on osx, albeit without X11.
This requires a patch, and is waiting on https://github.com/RTimothyEdwards/magic/pull/222, at which point we can remove the patch.

Thanks for working on this!


Abstract generic base class and model

I'm trying to implement a generic base class with a generic model prop but some shared logic among all subclasses (here the error getter):
import { computed } from 'mobx';
import { model, Model, prop } from 'mobx-keystone';

abstract class A<P> extends Model({
  value: prop<P>(), // Base class expressions cannot reference class type parameters. ts(2562)
}) {
  public abstract validate(value: P): string | undefined;

  @computed
  public get error(): string | undefined {
    return this.validate(this.value);
  }
}

@model('B')
class B extends A<string> {
  public validate(value: string): string | undefined {
    return value.length < 3 ? 'too short' : undefined;
  }
}

How would you implement this instead? Using the new ExtendedModel factory doesn't seem to help because I wouldn't be able to declare the generic prop and abstract validate method in A, so the error getter couldn't be implemented already in A.
Any help is much appreciated. :-)

Perhaps the generic model prop is not necessary (besides the fact that this cannot work anyway) because declaring an abstract model prop is only a typing issue, so the abstract prop could be declared as a regular class property. Something like this could be a potential solution:
import { computed } from 'mobx';
import { ExtendedModel, model, Model, prop } from 'mobx-keystone';

abstract class A<P> extends Model({}) {
  public abstract value: P;

  public abstract validate(value: P): string | undefined;

  @computed
  public get error(): string | undefined {
    return this.validate(this.value);
  }
}

type BValue = string;

abstract class _B extends A<BValue> {}

// Argument of type 'typeof B' is not assignable to parameter of type 'ModelClass<BaseModel<any, any>>'.
//   Type 'B' is missing the following properties from type 'BaseModel<any, any>': $, typeCheck, [typeSymbol], [modelTypeKey] ts(2345)
@model('B')
class B extends ExtendedModel(
  // Argument of type 'typeof _B' is not assignable to parameter of type 'ModelClass<_B>'.
  //   Cannot assign an abstract constructor type to a non-abstract constructor type. ts(2345)
  _B,
  {
    value: prop<BValue>(),
  }
) {
  public validate(value: BValue): string | undefined {
    return value.length < 3 ? 'too short' : undefined;
  }
}

But ExtendedModel doesn't support abstract base classes. So a poor version of an abstract class at least gets the typing right, but doesn't enforce the implementation of the "abstract" value property and "abstract" validate method
import { computed } from 'mobx';
import { ExtendedModel, model, Model, prop } from 'mobx-keystone';

class A<P> extends Model({}) {
  public value!: P;

  public validate(value: P): string | undefined {
    throw new Error('not implemented');
  }

  @computed
  public get error(): string | undefined {
    return this.validate(this.value);
  }
}

type BValue = string;

@model('B')
class B extends ExtendedModel(class extends A<BValue> {}, {
  value: prop<BValue>(),
}) {
  public validate(value: string): string | undefined {
    return value.length < 3 ? 'too short' : undefined;
  }
}

Would you say this general approach makes sense? And could ExtendedModel support abstract classes?

I just realized the $ property is missing the generic prop when declaring a regular abstract class property.

How about something like this
test("abstract-ish model classes", () => {
  function createA<P>() {
    class A extends Model({
      value: prop<P>(),
    }) {
      public validate(_value: P): string | undefined {
        return undefined
      }

      @computed
      public get error(): string | undefined {
        return this.validate(this.value)
      }
    }

    return A
  }

  @model("B")
  class B extends ExtendedModel(createA<string>(), {}) {
    public validate(value: string): string | undefined {
      return value.length < 3 ? "too short" : undefined
    }
  }

  const b = new B({ value: "hi" })
  expect(b.value).toBe("hi")
  expect(b.validate("ho")).toBe("too short")
  expect(b.validate("long")).toBe(undefined)
})

I actually started with a factory very similar to your suggestion, but I'm currently relying on the instanceof operator (b instanceof A) when using findParent(..., parentNode => parentNode instanceof A) (in my real application, A::value is not just a primitive type but another model which needs to find its nearest parent node derived from A).

Alternatively if you don't want a default implementation for validate you could do this:
test("abstract-ish model classes", () => {
  function createA<P>() {
    class A extends Model({
      value: prop<P>(),
    }) {
      public validate?(_value: P): string | undefined

      @computed
      public get error(): string | undefined {
        return this.validate!(this.value)
      }
    }

    return A
  }

  @model("B")
  class B extends ExtendedModel(createA<string>(), {}) {
    public validate(value: string): string | undefined {
      return value.length < 3 ? "too short" : undefined
    }
  }

  const b = new B({ value: "hi" })
  expect(b.value).toBe("hi")
  expect(b.validate("ho")).toBe("too short")
  expect(b.validate("long")).toBe(undefined)
  expect(b.error).toBe("too short")
})

About the instanceof thing, why not add a symbol property to the base class
const whatever = Symbol("...")

class A ... {
  [whatever]: true
}

// checking
parentNode => !!parentNode[whatever]

Or if you want to validate via instanceof that B is a valid instance of the string version of A then
test("abstract-ish model classes", () => {
  function createA<P>() {
    class A extends Model({
      value: prop<P>(),
    }) {
      public validate?(_value: P): string | undefined

      @computed
      public get error(): string | undefined {
        return this.validate!(this.value)
      }
    }

    return A
  }

  const StringA = createA<string>()

  @model("B")
  class B extends ExtendedModel(StringA, {}) {
    public validate(value: string): string | undefined {
      return value.length < 3 ? "too short" : undefined
    }
  }

  const b = new B({ value: "hi" })
  expect(b.value).toBe("hi")
  expect(b.validate("ho")).toBe("too short")
  expect(b.validate("long")).toBe(undefined)
  expect(b.error).toBe("too short")
  expect(b instanceof StringA).toBe(true)
})

https://github.com/xaviergonz/mobx-keystone/issues/2#issuecomment-523156145 could be viable solution, thanks!
About https://github.com/xaviergonz/mobx-keystone/issues/2#issuecomment-523158226: At least in my case I need to check whether b is an instance of any A, but that could be done using the symbol property as you suggested.
Would having ExtendedModel support abstract classes still make sense (and is it possible at all)?

It is possible, I'm just trying to figure out the proper typings to make it work without TS dying on me :)

Awesome :-)
Another related variant of the above is giving me some headache, too, where the entire set of model props is passed to the factory:
import { computed } from 'mobx';
import { Model, ModelData } from 'mobx-keystone';
import { ModelProps } from 'mobx-keystone/dist/model/prop';

function createA<P extends ModelProps>(props: P) {
  class A extends Model(props) {
    public validate?(_value: ModelData<P>): string | undefined;

    @computed
    public get error(): string | undefined {
      return this.validate!(this.$);
    }
  }

  return A;
}

Not sure how to make this work ...

Try changing ModelPropsToData to this["$"]

Doesn't help unfortunately - the main problem is Model(props) with this error:
Base constructor return type 'BaseModel<ModelPropsToData<P>, { 1: OptionalFlat<ModelPropsToData<P>>; 0: _Merge<OptionalFlat<_Pick<ModelPropsToData<P>, { [K in keyof P]: P[K]["$hasDefault"] & K; }[keyof P] & keyof P>>, _Pick<...>>; }[Implements<...>]> & Pick<...>' is not an object type or intersection of object types with statically known members. ts(2509)

Can't you do something like this?
  class Validable extends Model({}) {
    public validate?(): string | undefined

    @computed
    public get error(): string | undefined {
      return this.validate!()
    }
  }

  @model("B")
  class B extends ExtendedModel(Validable, { value: prop<string>() }) {
    public validate(): string | undefined {
      return this.$.value.length < 3 ? "too short" : undefined
    }
  }

  const b = new B({ value: "hi" })
  expect(b.value).toBe("hi")
  expect(b.error).toBe("too short")
  expect(b instanceof Validable).toBe(true)

Or if you really need validate to take the data as argument for some reason then
  class Validable extends Model({}) {
    public validate?(value: this["$"]): string | undefined

    @computed
    public get error(): string | undefined {
      return this.validate!(this.$)
    }
  }

  @model("B")
  class B extends ExtendedModel(Validable, { value: prop<string>() }) {
    public validate(value: this["$"]): string | undefined {
      return value.value.length < 3 ? "too short" : undefined
    }
  }

  const b = new B({ value: "hi" })
  expect(b.value).toBe("hi")
  expect(b.validate({ value: "ho" })).toBe("too short")
  expect(b.validate({ value: "long" })).toBe(undefined)
  expect(b.error).toBe("too short")
  expect(b instanceof Validable).toBe(true)

Or you can take a more functional approach while keeping the value computed
  interface Validable {
    validate(): string | undefined
  }

  function isValidable(obj: any): obj is Validable {
    return isModel(obj) && "validate" in obj && typeof obj["validate"] === "function"
  }

  const validationResults = new WeakMap<Validable, IComputedValue<string | undefined>>()

  function getError(obj: Validable) {
    let computedResult = validationResults.get(obj)
    if (!computedResult) {
      computedResult = computed(() => obj.validate())
      validationResults.set(obj, computedResult)
    }
    return computedResult.get()
  }

  @model("B")
  class B extends Model({ value: prop<string>() }) {
    public validate(): string | undefined {
      return this.value.length < 3 ? "too short" : undefined
    }
  }

  const b = new B({ value: "hi" })
  expect(b.value).toBe("hi")
  expect(isValidable(b)).toBe(true)
  expect(getError(b)).toBe("too short")

Or if you really need validate to take the data as argument for some reason then
  class Validable extends Model({}) {
    public validate?(value: this["$"]): string | undefined

    @computed
    public get error(): string | undefined {
      return this.validate!(this.$)
    }
  }

  @model("B")
  class B extends ExtendedModel(Validable, { value: prop<string>() }) {
    public validate(value: this["$"]): string | undefined {
      return value.value.length < 3 ? "too short" : undefined
    }
  }

  const b = new B({ value: "hi" })
  expect(b.value).toBe("hi")
  expect(b.validate({ value: "ho" })).toBe("too short")
  expect(b.validate({ value: "long" })).toBe(undefined)
  expect(b.error).toBe("too short")
  expect(b instanceof Validable).toBe(true)

I really like this approach! :-) Once you've figured out how to allow abstract classes to be passed to ExtendedModel, this is perfect.

Or you can take a more functional approach while keeping the value computed (this is probably the approach I'd take to avoid subclassing):
   const validate = Symbol("validate")
  interface Validable {
    [validate](): string | undefined
  }

  function isValidable(obj: any): obj is Validable {
    return isModel(obj) && validate in obj
  }

  const validationResults = new WeakMap<Validable, IComputedValue<string | undefined>>()

  function getError(obj: Validable) {
    let computedResult = validationResults.get(obj)
    if (!computedResult) {
      computedResult = computed(() => obj[validate]())
      validationResults.set(obj, computedResult)
    }
    return computedResult.get()
  }

  @model("B")
  class B extends Model({ value: prop<string>() }) {
    public [validate](): string | undefined {
      return this.value.length < 3 ? "too short" : undefined
    }
  }

  const b = new B({ value: "hi" })
  expect(b.value).toBe("hi")
  expect(isValidable(b)).toBe(true)
  expect(getError(b)).toBe("too short")

I see how this can work, but at least to me it looks quite verbose and things are a bit spread across multiple places and not so nicely grouped within a class. Would you only take this approach to work around the subclassing problem or do you consider this good practice in general?
Thanks so much for these insightful discussions, by the way! You've done a terrific job with mobx-keystone, I'm so much more productive with it than with MST.

I see how this can work, but at least to me it looks quite verbose and things are a bit spread across multiple places and not so nicely grouped within a class. Would you only take this approach to work around the subclassing problem or do you consider this good practice in general?

I just like it because I like to avoid subclassing as much as possible, but that's just personal preference :)

Thanks so much for these insightful discussions, by the way! You've done a terrific job with mobx-keystone, I'm so much more productive with it than with MST.

Thanks! That's the whole point of the project :D

I think #12 resolves this issue. Feel free to close it if you agree.

True! closing

Well actually reopening until I add better docs with the new patterns

When an abstract model class is extended in a factory function, Typescript infers the property's type as any although it should be possible to infer the actual type:
abstract class Base<T> extends Model({}) {
  public abstract value: T
}

function ExtendedBase<T>(defaultValue: T) {
  abstract class ExtendedBaseT extends Base<T> {
    public abstract value: T
  }

  return class extends ExtendedModel(ExtendedBaseT, {
    value: prop<T>(() => defaultValue)
  }) {}
}

class MyModel extends ExtendedBase('val') {}

const m = new MyModel({})
const v = m.value // type: any

However, without using an abstract class, type inference works fine:
abstract class Base<T> extends Model({}) {
  public abstract value: T
}

function ExtendedBase<T>(defaultValue: T) {
  class ExtendedBaseT extends Base<T> {
    public value!: T
  }

  return class extends ExtendedModel(ExtendedBaseT, {
    value: prop<T>(() => defaultValue)
  }) {}
}

class MyModel extends ExtendedBase('val') {}

const m = new MyModel({})
const v = m.value // type: string

Any idea what is causing this problem?

It is because sadly in typescript there doesn't seem to be a way to infer the generic of abstract classes, so it is downcasted to any (it is possible with non abstract classes, that's why it works then)
There's a somehow ugly workaround though:
return class extends ExtendedModel(ExtendedBaseT as AbstractModelClass<ExtendedBaseT>, {
if the original class type is passed directly to the argument (rather than rely on infer) it will be picked up correctly.

This is the core problem btw:
function classFactory<T>() {
  class CS {
    x!: T
  }

  type InstanceViaNew<T> = T extends { new (...args: any[]): infer R } ? R : never
  type InstanceViaProto<T> = T extends { prototype: infer R } ? R : never

  type CS1 = InstanceViaNew<typeof CS>["x"] // ok, T
  type CS2 = InstanceViaProto<typeof CS>["x"] // not ok, any :(

  abstract class ACS {
    x!: T
  }

  type AC1 = InstanceViaNew<typeof ACS>["x"] // not ok, never (because abstract classes have no new) :(
  type AC2 = InstanceViaProto<typeof ACS>["x"] // not ok, any :(
}

Just opened a TS issue: https://github.com/microsoft/TypeScript/issues/35576

I think I've found a more or less decent workaround while TS adds support for that:
https://github.com/xaviergonz/mobx-keystone/pull/70
Basically the only requirement is to wrap the abstract class passed to ExtendsModel in a call to "abstractModelClass". It was made a requirement so people are not left wondering why sometimes it will work and sometimes it won't, but it is a small breaking change.
Therefore your example would be fixed with:
return class extends ExtendedModel(abstractModelClass(ExtendedBaseT), {
What do you think?

I think it's a good workaround until Typescript fixes the underlying problem. Thank you very much for your efforts, as always! :-)
Do you think it makes sense to open a separate issue about this problem with a reference to the TS issue you opened to track progress on this matter and remove the workaround again when it's not needed anymore?

Good idea, just created the issue :)
The workaround should be out now in v0.28.0

Closing since abstractModelClass is not needed anymore and there are docs about generics and inheritance


Adding Storage libraries for automated patch release enrollment

Description
Adding Storage libraries for automated patch release enrollment

/check-enforcer override


⚠ Bofrost.nl has degraded performance

In ed3e44c, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 1245 ms

Resolved: Bofrost.nl performance has improved in 6077661.


Latest package version occasionally throws exception when user name contains @ symbol

This problem is in an OC 1.3.0 app with UserProfiles package version 1.0.0. Using the package's ProfilePart on a custom content type, editing an existing profile throws an exception when the associated user's user name contains the @ symbol instead of +.
The app itself handles users with @ in user names and the profiles created via the sign up form are saved this way. Keeping the @ symbol in user names/emails over + would be much preferable here. I am aware one of the OC updates changed user names to use the + symbol instead, however this can still be changed in a startup by configuring IdentityOptions. Issue is configuring this locally does not affect the profile editor's behavior and the exception persists.

After publishing (Username field is also no longer displayed):

The following warnings/exceptions are produced by the process:
Microsoft.AspNetCore.Identity.UserManager|WARN|User validation failed: DuplicateEmail.
OrchardCore.ContentManagement.Display.ContentItemDisplayCoordinator|ERROR|IContentPartDisplayDriver thrown from Etch.OrchardCore.UserProfiles.Drivers.ProfilePartDisplay by ArgumentNullException System.ArgumentNullException: Value cannot be null. (Parameter 'user')
Full stack trace from OC logs:
OrchardCore.ContentManagement.Display.ContentItemDisplayCoordinator|ERROR|IContentPartDisplayDriver thrown from Etch.OrchardCore.UserProfiles.Drivers.ProfilePartDisplay by ArgumentNullException System.ArgumentNullException: Value cannot be null. (Parameter 'user')
   at OrchardCore.Users.Services.UserStore.GetUserIdAsync(IUser user, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Identity.UserManager`1.GetUserIdAsync(TUser user)
   at Etch.OrchardCore.UserProfiles.Drivers.ProfilePartDisplay.UpdateAsync(ProfilePart part, IUpdateModel updater, UpdatePartEditorContext context)
   at OrchardCore.ContentManagement.Display.ContentDisplay.ContentPartDisplayDriver`1.OrchardCore.ContentManagement.Display.ContentDisplay.IContentPartDisplayDriver.UpdateEditorAsync(ContentPart contentPart, ContentTypePartDefinition typePartDefinition, UpdateEditorContext context)
   at OrchardCore.ContentManagement.Display.ContentItemDisplayCoordinator.<>c.<<UpdateEditorAsync>b__9_0>d.MoveNext()
--- End of stack trace from previous location ---
   at OrchardCore.Modules.InvokeExtensions.InvokeAsync[TEvents,T1,T2,T3](IEnumerable`1 events, Func`5 dispatch, T1 arg1, T2 arg2, T3 arg3, ILogger logger)    at OrchardCore.Users.Services.UserStore.GetUserIdAsync(IUser user, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Identity.UserManager`1.GetUserIdAsync(TUser user)
   at Etch.OrchardCore.UserProfiles.Drivers.ProfilePartDisplay.UpdateAsync(ProfilePart part, IUpdateModel updater, UpdatePartEditorContext context)
   at OrchardCore.ContentManagement.Display.ContentDisplay.ContentPartDisplayDriver`1.OrchardCore.ContentManagement.Display.ContentDisplay.IContentPartDisplayDriver.UpdateEditorAsync(ContentPart contentPart, ContentTypePartDefinition typePartDefinition, UpdateEditorContext context)
   at OrchardCore.ContentManagement.Display.ContentItemDisplayCoordinator.<>c.<<UpdateEditorAsync>b__9_0>d.MoveNext()
--- End of stack trace from previous location ---
   at OrchardCore.Modules.InvokeExtensions.InvokeAsync[TEvents,T1,T2,T3](IEnumerable`1 events, Func`5 dispatch, T1 arg1, T2 arg2, T3 arg3, ILogger logger)

If this is intended behavior, is there a workaround perhaps?

@peterkeating would you be able to check this out?


[UserVoiceShow] Update about Plugin State

Will you be fixing UserVoiceShow? It would be helpful to know your plan on this.
If you don't plan to fix it we could find another dev to take it over.
Thank you!

Will you be fixing UserVoiceShow? It would be helpful to know your plan on this. If you don't plan to fix it we could find another dev to take it over.
Thank you!

Hi,
I will keep updating the plugins until this repo exist,
I am currently actively looking for a way to patch the modal window.

Thank you so much for fixing it!


Using FloodLight Camera, isEnabled() and isMotionDetectionEnabled() return the value directly instead of PropertyValue

Describe the bug
Using FloodLight Camera, isEnabled() and isMotionDetectionEnabled() return the value directly instead of PropertyValue
https://github.com/bropat/eufy-security-client/blob/0a602d328dbefb796bae3b69ccc9140c31254648/src/http/device.ts#L760
https://github.com/bropat/eufy-security-client/blob/0a602d328dbefb796bae3b69ccc9140c31254648/src/http/device.ts#L1233
To Reproduce
You need a floodlight camera
Expected behavior
These 2 functions should return PropertyValue. The guy who is facing this, removed me the shared access to the floodlight. So I can't dig on it.
Screenshots & Logfiles
[2021-08-23T09:29:31.588Z] DEBUG: ef/32061 on v1.0.0-rc.2: Found device T8210PXXXXXXXX Front of the House BATTERY_DOORBELL
[2021-08-23T09:29:31.588Z] DEBUG: ef/32061 on v1.0.0-rc.2: Found device T8420NXXXXXXXX Backyard FLOODLIGHT

[2021-08-23T09:29:49.530Z] DEBUG: ef/32061 on v1.0.0-rc.2: Front of the House Triggered GET Motion: { value: true, timestamp:<PHONE_NUMBER>000 }
[2021-08-23T09:29:49.531Z] DEBUG: ef/32061 on v1.0.0-rc.2: Backyard Triggered GET Enable: undefined
[2021-08-23T09:29:49.532Z] ERROR: ef/32061 on v1.0.0-rc.2: Backyard handleEnableGet Wrong return value

[2021-08-23T09:29:49.532Z] DEBUG: ef/32061 on v1.0.0-rc.2: Front of the House Triggered GET MotionDetected: false
[2021-08-23T09:29:49.532Z] DEBUG: ef/32061 on v1.0.0-rc.2: Front of the House Triggered GET Motion: { value: true, timestamp:<PHONE_NUMBER>000 }
[2021-08-23T09:29:49.532Z] DEBUG: ef/32061 on v1.0.0-rc.2: Backyard Triggered GET MotionDetected: false
[2021-08-23T09:29:49.533Z] DEBUG: ef/32061 on v1.0.0-rc.2: Backyard Triggered GET Motion: undefined
[2021-08-23T09:29:49.533Z] ERROR: ef/32061 on v1.0.0-rc.2: Backyard handleMotionOnGet Wrong return value

Versions:

Client version: 1.1.2
Node version: v14.17.5
Operating system: debian

Additional context
Add any other context about the problem here.

Maybe isEnabled() it's another thing. Because it return undefined

I wasn't aware that it will be deprecated. We're now using getPropertyValue and hasProperty.


Update readme

This updates the README.md to reflect the current state of the library.
What this changes:

Adds a Who created Resumable.js? section
Updates some code snippets/defaults
Updates explanations of some properties/functions
Removes some obsolete properties/functions and adds some missing ones
Adds documentation of the ResumableChunk class

I also moved the Events section behind the documentation of ResumableFile and ResumableChunk. That's why there is a big chunk of removed and added lines.
I think it makes sense to review the readme as a whole anyways. Maybe I missed something that we want to change.
I didn't document some of the properties and functions because of #23. Instead I added corresponding todos (// todo #23)  in the code.

@UniquePanda Did this PR go against the wrong repo?

@UniquePanda Did this PR go against the wrong repo?

Ah yes, sorry. Forgot to mention!
I really try to avoid this, but GitHub is making this unnecessary hard (by not allowing you to set a base branch for PRs that is in the forked repo and not in the upstream). 😄

No problem, just wanted to confirm this 👍


HHH-15329 Remove workaround for HHH-10382 in GetterFieldImpl

See https://hibernate.atlassian.net/browse/HHH-15329 for more info.
Cheers,
Christoph

Thanks a lot!


add a layer for soil and water conservation candidates

candidate filing ends July 6th

Soil-and-Water candidates even in the Albemarle district are elected on a per-county basis; so, these contests are best allocated to the county layer.


Doc question: need to create a Postgres database in order to run Clair container

It seems that a Postgres database  needs to be created first, otherwise, docker run gave errors:
docker run --rm -v /path/to/image-storage:/path/to/image-storage -p 6060:6060 -p 6061:6061 quay.io/coreos/clair --db-type=sql --db-path='host=postgresdb.example.com port=5432 user=admin password=adminPass' --update-interval=2h
E1117 18:56:31.908102 00001 quadstore.go:59] Couldn't open database at host=postgresdb.example.com> port=5432 user=admin password=adminPass': &pq.Error{Severity:"FATAL", Code:"3D000", Message:"database \"admin\" does not exist", Detail:"", Hint:"", Position:"", InternalPosition:"", InternalQuery:"", Where:"", Schema:"", Table:"", Column:"", DataTypeName:"", Constraint:"", File:"postinit.c", Line:"775", Routine:"InitPostgres"}

I created the database like so:
CREATE ROLE clair with LOGIN CREATEDB PASSWORD 'somepassword;
CREATE DATABASE clair;
GRANT ALL PRIVILEGES ON DATABASE clair to clair;

And then this works:
docker run --rm -v /path/to//image-storage:/path/to/image-storage -p 6060:6060 -p 6061:6061 quay.io/coreos/clair --db-type=sql --db-path='host=postgresdb.example.com port=5432 user=clair password=somepassword' --update-interval=2h
E1117 19:38:15.411549 00001 quadstore.go:319] Couldn't execute horizon: sql: no rows in result set
2015-11-17 19:38:15.412148 I | api: starting Health API on port 6061.
2015-11-17 19:38:15.412261 I | api: starting API on port 6060.
2015-11-17 19:38:15.412458 I | updater: updater service started. lock identifier: 35f76bb1-cfa4-4682-816c-591be9ca52b8
2015-11-17 19:38:15.432099 I | updater: updating vulnerabilities
2015-11-17 19:38:15.432135 I | updater/fetchers: fetching Debian vulneratibilities
2015-11-17 19:38:15.432196 I | updater/fetchers: fetching Red Hat vulneratibilities
2015-11-17 19:38:15.432396 I | updater/fetchers: fetching Ubuntu vulneratibilities

Despite the error from  quadstore.go:319, it does work.
Note that the container expects the database name is the same as the db user name, or you can pass in 'database=' in the connection string, which is undocumented.
Is it correct that, unlike 'bolt' db type,  a pre-existing sql database is required to run the  clair container?
This is great! Once I get it going I was able to insert layers for local images and get reports.

Hello,
Correct ! The database has to be present in the first place. However, the schema is then created by Clair itself at the first run. The error that you have is actually expected - everything is fine !
I will update the docs as soon as possible.
Note: Bolt is great for testing but as it uses a file lock, it is not possible to run multiple Clair instances on the same database. That is why PostgreSQL is the way to go for the distributed service.
Thank you.

Quentin, have you removed the ability to use bolt in the latest? It was great for testing/evaluation purposes.

@candita Hi. The Bolt backend was powered by Cayley and Clair doesn't use Cayley anymore for performance reasons. It is however possible to re-implement the Bolt backend using the Datastore interface.


Cannot use dropdowns in submodels

Actually, I have not tested if submodels work. But in list models it doesn't:
@model IList<MyModel>
// Snip form and section...
for (int i = 0; i < Model.Count; i++) {
        @s.FieldFor(m => model.Category).AsDropDown()
}

class MyModel {
    [ExistsIn("Categories""Item1", "Item1")] public string Category {get;set;}
    public List<Tuple<string>> Categories { get; set; }
}

This throws an exception:
ExistsIn: No property Model.Categories exists for looking up values for property Model.Category.

The problem is that ChameleonForms tries to lookup the referenced value from ExistsIn in the IList model, which of course doesn't exist.
This is version 1.2.0 from nuget.

A workaround may be to make the list a sub-property of the parent model. You will likely need to define the Categories property in the parent model as well though, which is a known issue as per https://trello.com/c/JNdQ3s9Y/141-using-existsin-on-a-nested-model-class-doesn-t-work.
Happy for anyone to come up with a fix to either.


Bump service version from 2.9.3 to 2.9.4

Changelog: https://github.com/gnosis/safe-config-service/compare/v2.9.3...release-2.9.4

Coverage remained the same at 99.759% when pulling c522178ddce77de31a4395974abbb3088694d214 on release-2.9.4 into 491416ea9560c0f751a68d7f9672c97ceeacf03a on main.


Add logger

related to #302

Checked every single file didn't miss the import. I added the missing dependencies on some files so they don't break and removed the old logger. Ran the server and a few processes and they seem to work fine. Great that we set a rotation for the logger I think it's fine. Good job! We can merge tomorrow. LGTM!!

Thanks for your review and fixing errors


Feat/2449 replace depfu with dependabot

Replaces depfu with dependabot.

closed https://github.com/stoplightio/elements/pull/2433


Unable to read binary format plist file

I  created a simple MacOS application from command line script by Platypus. I got the following error message when trying to use create-dmg to create a .dmg file.
/usr/local/lib/node_modules/create-dmg/node_modules/plist/lib/parse.js:68
    doc.documentElement.nodeName === 'plist',
                        ^

TypeError: Cannot read property 'nodeName' of null
    at Object.parse (/usr/local/lib/node_modules/create-dmg/node_modules/plist/lib/parse.js:68:25)
    at Object.<anonymous> (/usr/local/lib/node_modules/create-dmg/cli.js:57:23)
    at Module._compile (internal/modules/cjs/loader.js:736:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:747:10)
    at Module.load (internal/modules/cjs/loader.js:628:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:568:12)
    at Function.Module._load (internal/modules/cjs/loader.js:560:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:801:12)
    at executeUserCode (internal/bootstrap/node.js:526:15)
    at startMainThreadExecution (internal/bootstrap/node.js:439:3)

I ended up figuring it out that create-img fails due to the wrong format (binary instead of xml/text) of Info.plist in app's contents directory.  So I use plutil -convert xml1 Info.plist to convert the plist file to XML from binary. This solved the problem.
Is it an issue with create-dmg?

There is a $30.00 open bounty on this issue. Add more on Issuehunt.

Checkout the Issuehunt explorer to discover more funded issues.
Need some help from other developers? Add your repositories on Issuehunt to raise funds.

I have never seen an app with a binary Info.plist. I think we should just throw a more human-friendly error message about it.

@issuehunt has funded $30.00 to this issue.

Submit pull request via IssueHunt to receive this reward.
Want to contribute? Chip in to this issue via IssueHunt.
Checkout the IssueHunt Issue Explorer to see more funded issues.
Need help from developers? Add your repository on IssueHunt to raise funds.

@jhangyu Yeah, that's probably a good solution.


[SDA-6784] fix: path args need not to be explicitly set for interactive mode to ask about it

Related issue: https://issues.redhat.com/browse/SDA-6784
What
'path' arg was being check for explicitly set to accept interactive mode question
Why
'path' arg does not need to be explicitly set for the user to use it in interactive mode

/lgtm

/assign pvasant

/lgtm


PP: advise on users moving outside the borough or within (from one CPZ to another)

Comment from B&H: Cancelling old permits and next steps - We need to encourage customers moving within Brighton to surrender old permits - the patten does not cover this
could we think of the best place in the user journey where we could incorporate this advice?

@EUzkuraityte If not a digital permit, this would be good information to include in the letter that will accompany the permit itself. So maybe we should add a step for "send the user the physical permit"

Sounds good!

@kaydale What response is this waiting on?

@sanjaypoyzer It was waiting a response from me - to move it into ready to do.

lol ok

@EUzkuraityte Reading over this, I'm not really sure I understand why it's needed. Surely the old permit will be cancelled? Won't all permits be checked anyway?

@sanjaypoyzer if the LA has no integration between council tax and parking permit system then they wouldn't know that a user has moved and the used would continue using the parking permit until its expiry date. That's why need to let users know that they must inform the LA when moving out of the borough or within (if it affects the CPZ).

I'm not sure that's the best way of addressing that problem. It relies on people notifying the council that they have moved, which they aren't likely to do.
If the council is not able to integrate council and parking permits systems in any real way, they could manually search the permits system for the user's address when the user stops paying council tax. This is extra effort on the council side, but not as much extra effort as it would be on the user's side. (It's also the council's responsibility to make the service as little effort for the user as possible.)

Closing this issue for now to clean up the board, but feel free to re-open if you get extra justification.


Cloudtrail logs to cloudwatch

Send cloudtrail to cloudwatch log group to allow easier viewing and
searching of the cloudtrail logs.  Enable this for all accounts.
We setup a much longer log retention period for cloudtrail logs in
LogCentral account than the other accounts because LogCentral
is where the master cloudtrail bucket lives.
depends on https://github.com/Sage-Bionetworks/aws-infra/pull/294

@ahayden i've updated this PR to pass a much longer retention period to cloudtrail in LogCentral Account.
@xschildw !CopyValue is more like Sceptre's !stack_output_external, it allows you to get a copy of the cloudformation stack output/export values.


[SPARK-36362][CORE][SQL][TESTS] Omnibus Java code static analyzer warning fixes

What changes were proposed in this pull request?
Fix up some minor Java issues:

Some int*int multiplications that widen to long maybe could overflow
Unnecessarily non-static inner classes
Some tests "catch (AssertionError)" and do nothing
Manual array iteration vs very slightly faster/simpler foreach
Incorrect generic types that just happen to not cause a runtime error
Missed opportunities for try-close
Mutable enums
.. and a few other minor things

Why are the changes needed?
Some are minor but clear fixes; some may have a marginal perf impact or avoid a bug later. Also: maybe avoid future PRs to address these one by one.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Existing tests

Test build #141907 has started for PR 33594 at commit b4b0f4a.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46416/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46416/

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

Test build #141907 has finished for PR 33594 at commit b4b0f4a.

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

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

Merged to master for Apache Spark 3.3.0 only.

Oh, there are linter errors.
src/test/java/org/apache/spark/util/kvstore/DBIteratorSuite.java:[76] (sizes) LineLength: Line is longer than 100 characters (found 104).
Error:  src/test/java/org/apache/spark/network/crypto/AuthEngineSuite.java:[22,8] (imports) UnusedImports: Unused import - java.util.Arrays.
Error:  src/test/java/org/apache/spark/network/RpcIntegrationSuite.java:[308] (sizes) LineLength: Line is longer than 100 characters (found 107).
Error:  src/test/java/org/apache/spark/network/util/NettyMemoryMetricsSuite.java:[111] (sizes) LineLength: Line is longer than 100 characters (found 107).
Error:  src/test/java/org/apache/spark/network/StreamSuite.java:[27,8] (imports) UnusedImports: Unused import - java.util.Arrays.
Error:  src/test/java/org/apache/spark/network/StreamSuite.java:[112] (sizes) LineLength: Line is longer than 100 characters (found 107).
Error:  src/test/java/org/apache/spark/network/StreamSuite.java:[121] (sizes) LineLength: Line is longer than 100 characters (found 107).
Error:  src/test/java/org/apache/spark/network/StreamSuite.java:[130] (sizes) LineLength: Line is longer than 100 characters (found 107).
Error:  src/test/java/org/apache/spark/network/StreamSuite.java:[144] (sizes) LineLength: Line is longer than 100 characters (found 107).
Error:  src/main/java/org/apache/spark/unsafe/types/UTF8String.java:[909] (sizes) LineLength: Line is longer than 100 characters (found 104).
Error:  src/main/java/org/apache/spark/unsafe/types/UTF8String.java:[942] (sizes) LineLength: Line is longer than 100 characters (found 104).
Error:  src/test/java/org/apache/spark/unsafe/types/UTF8StringSuite.java:[403] (sizes) LineLength: Line is longer than 100 characters (found 101).
Error:  src/test/java/org/apache/spark/unsafe/types/UTF8StringSuite.java:[404] (sizes) LineLength: Line is longer than 100 characters (found 102).
Error:  src/test/java/test/org/apache/spark/sql/JavaColumnExpressionSuite.java:[63] (sizes) LineLength: Line is longer than 100 characters (found 102).
Error:  src/test/java/test/org/apache/spark/sql/JavaColumnExpressionSuite.java:[66] (sizes) LineLength: Line is longer than 100 characters (found 102).
Error:  src/test/java/test/org/apache/spark/sql/JavaColumnExpressionSuite.java:[68] (sizes) LineLength: Line is longer than 100 characters (found 102).
Error:  src/test/java/test/org/apache/spark/sql/JavaColumnExpressionSuite.java:[69] (sizes) LineLength: Line is longer than 100 characters (found 102).

I'll make a follow-up.

Here is the PR.

https://github.com/apache/spark/pull/33601