T.constructor should be of type T

Given
class Example {
}

The current type of Example.constructor is Function, but I feel that it should be typeof Example instead. The use case for this is as follows:
I'd like to reference the current value of an overridden static property on the current class.
In TypeScript v1.5-beta, doing this requires:
class Example {
    static someProperty = "Hello, world!";

    constructor() {
        // Output overloaded value of someProperty, if it is overloaded.
        console.log(
            (<typeof Example>this.constructor).someProperty
        );
    }
}

class SubExample {
    static someProperty = "Overloaded! Hello world!";

    someMethod() {
        console.log(
            (<typeof SubExample>this.constructor).someProperty
        );
    }
}

After this proposal, the above block could be shortened to:
class Example {
    static someProperty = "Hello, world!";

    constructor() {
        // Output overloaded value of someProperty, if it is overloaded.
        console.log(
            this.constructor.someProperty
        );
    }
}

class SubExample {
    static someProperty = "Overloaded! Hello world!";

    someMethod() {
        console.log(
            this.constructor.someProperty
        );
    }
}

This removes a cast to the current class.

Also, for clarity, as discussed in #4356 it is logical based on the ES specification to strongly type .constructor property of an instance and the following is essentially equivalent valid ways of creating instances:
class Foo {
    foo() { console.log('bar'); }
}

let foo1 = new Foo();

let foo2 = new foo1.constructor();

Accepting PRs for this. Anyone interested? :smile:

I spoke with @ahejlsberg about this - we could type constructor fairly well just with a change to our lib.d.ts now that we have this types (in theory):
interface Constructor<T> {
  new (...args: any[]): T;
  prototype: T;
}

interface Object {
    constructor: Constructor<this>;
}

but there are two issues - we don't instantiate this types on apparent type members (as in, anything on object) correctly right now, and there would be a performance impact in making every object have a this typed member (it's constructor member). Additionally, this method doesn't capture the arguments of the constructor of the class (or its static members), so it could stand to be improved.

Additionally, this method doesn't capture the arguments of the constructor of the class (or its static members),

This was a dealbreaker for us since it wouldn't even address the problem in the OP. Wiring it up in the compiler the same way we do prototype seems necessary.

Can take a look, does

Removing from lib.d.ts:

interface Object {
    constructor: Function;

inferring/adding a "constructor" property/symbol with a type to the classType seem like the right thing to do?

Nevermind, it's a bit more involved then I thought. Attempt here in case helpful:
https://github.com/Microsoft/TypeScript/compare/master...jbondc:this.constructor
Think proper way involves changing ConstructorKeyword in getSymbolAtLocation()

As I mentioned in #5933, will this not be a breaking change for assigning object literals to class types?
class Foo {
	constructor(public prop: string) { }
}

var foo: Foo = { prop: "5" };

This is currently allowed, but with this issue fixed it should produce an error that the literal is missing the constructor property? If it didn't produce an error, then it would be allowed to call statics on Foo such as foo.constructor.bar() which would break if foo.constructor wasn't actually Foo.

Would this be possible to implement solely with the polymorphic this type that's a work in progress? Assuming typeof mechanics would work there as well, could the signature for Object.prototype.constructor be set to:
interface Object {
    constructor: typeof this;
}

The general problem we face here is that lots of valid JavaScript code has derived constructors that aren't proper subtypes of their base constructors. In other words, the derived constructors "violate" the substitution principle on the static side of the class. For example:
class Base {
    constructor() { }  // No parameters
}

class Derived {
    constructor(x: number, y: number) { }  // x and y are required parameters
}

var factory: typeof Base = Derived;  // Error, Derived constructor signature incompatible
var x = new factory();

If we were to add a strongly typed constructor property to every class, then it would become an error to declare the Derived class above (we'd get the same error for the constructor property that we get for the factory variable above). Effectively we'd require all derived classes to have constructors that are compatible with (i.e. substitutable for) the base constructor. That's simply not feasible, not to mention that it would be a massive breaking change.
In cases where you do want substitutability you can manually declare a "constructor" property. There's an example here. I'm not sure we can do much better than that.

Well, since the constructor, per spec (and after typescript compilation) is always the defined in the prototype, I don't see why it shouldn't be strongly typed. If people are hacking their prototypes manually, let them typecast their code. this.constructor should be the class definition, and  super.constructor the immediate super prototype definition, and so on.

I don't understand what's going on in this thread. Need to take it back to the design meeting.

Cant call static owerriden methods,  if i write Animal.run() this is code not use Cat.run owerriden method. i need write this.constructor.run() but it get compilation error.
class Animal {

	static run (){
		alert('Animal run')
	}

	run(){
		this.constructor.run() // compile error
		// if i write Animal.run() this code not use Cat.run owerriden method
	}

}

class Cat extends Animal {

	static run (){
		super.run()
		alert('Cat jump')
	}

}

let cat = new Cat()
cat.run()

solution
add keyword static for access to current static props, static will be alias for this.constructor in self methods, and alias for this in static methods
and code will be:
class Animal {

	static run (){
		alert('Animal run')
	}

	run(){
		static.run() // compile to this.constructor.run()
	}

}

class Cat extends Animal {

	static run (){
		super.run()
		alert('Cat jump')
	}

}

let cat = new Cat()
cat.run() // alert('Animal run') alert('Cat jump')

dangers
Static keyword to be used in the following standards and ES have  different semantics

static.run() isn't valid javascript, in all senses. using an imaginary keyword that looks like a global.
one thing is transpiling code that works in ES5, another thing is changing the input to a completely different output. await / async for example are in the spec, and the generated code just makes you able to use ES2016 today. the coffeescript dark days are now past at last.
Typescript does one thing and does really well: having plain JS strongly-typed.
they just need to fix the constructor to be strongly typed as well. I have no problem doing this.constructor.some() since using ClassDefinition.some() is awkward and makes inheritance a (even more) pain.

Has anyone figured out some kind of workaround for this yet?

Maybe use new keywords is better. For example:
In TypeScript:
class Foo {
  static base() {
    return 'FOO'
  }

  static foo() {
    return self.base()
  }

  static bar() {
    return static.base()
  }

  cfoo() {
    return self.base()
  }

  cbar() {
    return static.base()
  }
}

class Bar extends Foo {
  static base() {
    return 'BAR'
  }

  static more() {
    return parent.base()
  }

  cmore() {
    return parent.base()
  }
}

Expect executing result as follow:
Foo.base() // 'FOO'
Foo.foo() // 'FOO'
Foo.bar() // 'FOO'
Bar.base() // 'BAR'
Bar.foo() // 'FOO'
Bar.bar() // 'BAR'
Bar.more() // 'FOO'
const foo = new Foo()
foo.cfoo() // 'FOO'
foo.cbar() // 'FOO'
const bar = new Bar()
bar.cfoo() // 'FOO'
bar.cbar() // 'BAR'
bar.cmore() // 'FOO'

The three keywords self, static, parent means different access controls as follow:

self: access the constructor where the keyword is strictly
static: dynamic access the constructor according to the access context
parent: access the property of the super constructor of the constructor where the keyword is

The compile result is(omit useless codes):
(function (_super) {
  function _ctor() {}
  _ctor.foo = function() {
    _super.bar() // from parent.bar()
    _ctor.bar() // from self.bar()
    this.bar() // from static.bar()
  }

  _ctor.prototype.foo() {
    _super.bar() // from parent.bar()
    _ctor.bar() // from self.bar()
    this.constructor.bar() // from static.bar()
  }
})(function _super() {})

@acrazing as already discussed in this thread that is a bad idea and it is contrary to the design goals of TypeScript.
To understand why it is a bad idea, consider that static already has a meaning in ECMAScript and that this meaning may expand. What if TC39 adds support for precisely this feature? What if it adds the same syntax with a different meaning? What is static is endowed with a meta-property like new was with target?TypeScript, as a JavaScript superset, would need to implement the new behavior of static. This would break existing code.
That is one reason to not add new syntax in value positions. It breaks compatibility.

Possible workaround:
class Foo {
    'constructor': typeof Foo; // <-- this line here
    static method() { return 1 }
}
const foo = new Foo();
foo.constructor.method(); // Works
new foo.constructor(); // Works

Having an explicit opt-in isn't necessarily a bad thing either, since it makes it obvious that you're going to be using the .constructor property for something.
It seems a bit odd that the quotes are required, but just having constructor: typeof Foo will give you:
[ts] Constructor implementation is missing. if you have no constructor implementation, or
[ts] '(' expected.  if you do.
As a bonus, you can use this to implement static properties on interfaces:
interface I {
    constructor: {
        staticMethod(): number;
    }
    instanceMethod(): string;
}

class C implements I {
    'constructor': typeof C;
    static staticMethod() { return 1 }
    instanceMethod() { return '' }
}

If someone wants to make it work with prettier (which removes the quotes), wrapping around [] does the trick:
class C {
    ['constructor']: typeof C;
}

@ahejlsberg
Here we just wanna to use this.constructor to retrieve static member.
If it must add "constructor": typeof XXX to every class, it also seems too unnecessary.
Since this.constructor have some unavoidable type problem, can we add a new grammer for this.
For example:  this::staticMember compiles to this.constructor.staticMember.
Treat type of this::XXX as (typeof typeof this)['XXX']
Just like it in PHP: self::staticMember.
It also use :: in C++.

I agree with @k8w as introducing a new concept/keyword like constructof would be verbose!

Any progress on this?

I'm trying to call a static property from a Sequelize model as such:
const model = options.target().constructor as typeof Model<T>;
return model.count({ where });

options.target() return type is new () => T and T extends Model<T>
count is a static property of Model<T>, but I'm unable to type that cast properly. Any help would be appreciated.

Relevant ECMAScript proposal: https://github.com/rbuckton/proposal-class-access-expressions

It's true what @ahejlsberg's comment here about type incompatibility which will happen if every object has different types of constructor property.
However, after thinking for a while, I think we were providing a little less information than we could provide. Well, I will explain my idea for this issue.
constructor type information from the new operator
type Instance<T, P> = T & { constructor: P }

Instance<T, P> augments T type with the type information of constructor property. We can provide the information somewhere and I think the sweet spot is at the return value of the new operator. Look at the example below.
class Class1 {
  constructor(value: number) {
  }
}

class Class2 extends Class1 {
  constructor(value: string) {
    super(Number(value))
  }
}

let i1 = new Class1(100) as Instance<Class1, typeof Class1>
let i2 = new Class2("1") as Instance<Class2, typeof Class2>
//                       ^ this is what I propose: make this auto-magically happens

i1 = i2               // <-- error because incompatible constructors

let di1: Class1 = i1  // <-- let's reduce information that we have here
let di2: Class2 = i2

di1 = di2             // <-- not even an error happens here :)

This idea will solve the problem here but still allows for more specific typing if needed.
Sidenote
The behavior of returning T from new operator has been around there for a long time. I'm thinking about automagically reduce the information at assignment operation if the variable type not explicitly stated.
let s1 = new Class1(100)  // <-- ReducibleInstance<Class1, typeof Class1>
let s2 = new Class2("1")  // <-- ReducibleInstance<Class2, typeof Class2>

// s1.constructor.           <-- resolve to typeof Class1

s1 = s2   // <-- reduce s1 to Class1 before assignment only if signature is incompatible
          //     s2 is still typed as ReducibleInstance<Class2, typeof Class2>

// s1.constructor.           <-- now resolve to Function

Well, I'm not finished yet. This alone is not enough to solve the whole problem. Therefore, I'll propose another design idea.
Polymorphic typeof this type
I have an idea to create a new type named typeof this type which is similar to polymorphic this type but for the type of the class instead of for the instance. This is similar to @LPGhatguy comment here. I'll highlight some traits of my concept idea below.
Dissolve to typeof T from the outside
Like polymorphic this type which dissolves to T when accessed from the outside, polymorphic typeof this type dissolves to typeof T when accessed from the outside.
class Class3 {
  method1(): this {         // <-- type: this
    return this
  }

  method2(): typeof this {  // <-- type: typeof this
    return this.constructor
  }
}

let t1 = new Class3()
t1.method1()  // <-- type: Class3
t1.method2()  // <-- type: typeof Class3

Resolve currently available members of the class type from the inside
Like polymorphic this type which resolves currently available members when accessed from the inside, polymorphic typeof this resolves currently available static members of the class.
class Class4 {
  static staticProp1: number
  prop1: number

  method1() {
    let obj = this              // <-- type: this
    // obj.                        <-- resolve prop1, method1

    let cls = this.constructor  // <-- type: typeof this
    // cls.                        <-- resolve to staticProp1, etc
  }
}

class Class5 extends Class4 {
  static staticProp2: number
  prop2: number

  method2() {
    let obj = this              // <-- type: this
    // obj.                        <-- resolve prop1, prop2, method1, method2

    let cls = this.constructor  // <-- type: typeof this
    // cls.                        <-- resolve to staticProp1, staticProp2, etc
  }
}

Don't resolve any construct signatures from the inside
Reason: child's construct signature is allowed to be incompatible with parent's construct signature. We don't have enough information to figure out the signature of the final constructor at the moment.
class Class6 {
  constructor(readonly value: number) {
  }

  method1() {
    new this.constructor(17)  // <-- Error TS2351: Cannot use 'new' with an ...
  }
}

class Class7 extends Class6 {
  constructor(value: string) {
    if (typeof value !== "string") {
      throw new Error("value must be a string")
    }

    super(Number(value))
  }

  // method1() {
  //   new this.constructor(17)  <-- this expr. will break the rule if allowed
  // }
}

Provided by this type
Since we're not changing the type of Object.prototype.constructor, we have to provide access to this feature. I'm thinking about putting this on this type.
class Class8 {
  method1() {
    // this.constructor.   <-- resolve to typeof this
  }
}

let it1 = new Class8()
// it1.constructor.        <-- resolve to Function

Motivating Problem to Solve
My actual problem is I want to create an extendable class that leverages immutable fluent interface pattern. I took an example from TypeScript documentation here with a few changes.
class Calculator {
  constructor(readonly value = 0) {
  }

  protected newInstance(value: number): this {
    return new (this.constructor as any)(value)   // <-- not type-safe
  }

  add(operand: number) {
    return this.newInstance(this.value + operand)
  }

  // ... other operations go here
}

let v = new Calculator(2)
  .add(1)
  .value

One of my objectives is I want to make this code more type-safe since the constructor's type signature is not checked yet.
It will be possible to resolve to resolve static members of the class from this.constructor attribute and to do type-checking on the constructor of the child class from the parent class using this idea by modifying the Calculator class above to be like this.
class Calculator {
  // ...

  protected newInstance(
    this: this & { constructor: { new(value: number) } },
    value: number
  ): this {
    return new this.constructor(value)
  }

  add(
    this: this & { constructor: { new(value: number) } },
    operand: number
  ) {
    return this.newInstance(this.value + operand)
  }

  // ... other operations go here
}

Every method which associates with the fluent interface will not be able to be called from an instance of the class which doesn't have the required signature.
class BrokenCalculator extends Calculator {
  constructor(value: string) {
    super()
  }
}

let v2 = new BrokenCalculator()
  .add(5)   // <-- this resolves to:
            //     ReducibleInstance<BrokenCalculator, typeof BrokenCalculator>
            //     (error: not compatible with required this by the method)

Thank you. I'm looking forward to hearing about this. I'm sorry for long post here.
I hope this idea will be able to solve our problems. 😃

Well, I'm not finished yet. This alone is not enough to solve the whole problem. Therefore, I'll propose another design idea.
Polymorphic typeof this type
I have an idea to create a new type named typeof this type which is similar to polymorphic this type but for the type of the class instead of for the instance. This is similar to @LPGhatguy comment here. I'll highlight some traits of my concept idea below.
Dissolve to typeof T from the outside
Like polymorphic this type which dissolves to T when accessed from the outside, polymorphic typeof this type dissolves to typeof T when accessed from the outside.
class Class3 {
  method1(): this {         // <-- type: this
    return this
  }

  method2(): typeof this {  // <-- type: typeof this
    return this.constructor
  }
}

let t1 = new Class3()
t1.method1()  // <-- type: Class3
t1.method2()  // <-- type: typeof Class3

Resolve currently available members of the class type from the inside
Like polymorphic this type which resolves currently available members when accessed from the inside, polymorphic typeof this resolves currently available static members of the class.
class Class4 {
  static staticProp1: number
  prop1: number

  method1() {
    let obj = this              // <-- type: this
    // obj.                        <-- resolve prop1, method1

    let cls = this.constructor  // <-- type: typeof this
    // cls.                        <-- resolve to staticProp1, etc
  }
}

class Class5 extends Class4 {
  static staticProp2: number
  prop2: number

  method2() {
    let obj = this              // <-- type: this
    // obj.                        <-- resolve prop1, prop2, method1, method2

    let cls = this.constructor  // <-- type: typeof this
    // cls.                        <-- resolve to staticProp1, staticProp2, etc
  }
}

Don't resolve any construct signatures from the inside
Reason: child's construct signature is allowed to be incompatible with parent's construct signature. We don't have enough information to figure out the signature of the final constructor at the moment.
class Class6 {
  constructor(readonly value: number) {
  }

  method1() {
    new this.constructor(17)  // <-- Error TS2351: Cannot use 'new' with an ...
  }
}

class Class7 extends Class6 {
  constructor(value: string) {
    if (typeof value !== "string") {
      throw new Error("value must be a string")
    }

    super(Number(value))
  }

  // method1() {
  //   new this.constructor(17)  <-- this expr. will break the rule if allowed
  // }
}

Provided by this type
Since we're not changing the type of Object.prototype.constructor, we have to provide access to this feature. I'm thinking about putting this on this type.
class Class8 {
  method1() {
    // this.constructor.   <-- resolve to typeof this
  }
}

let it1 = new Class8()
// it1.constructor.        <-- resolve to Function

Motivating Problem to Solve
My actual problem is I want to create an extendable class that leverages immutable fluent interface pattern. I took an example from TypeScript documentation here with a few changes.
class Calculator {
  constructor(readonly value = 0) {
  }

  protected newInstance(value: number): this {
    return new (this.constructor as any)(value)   // <-- not type-safe
  }

  add(operand: number) {
    return this.newInstance(this.value + operand)
  }

  // ... other operations go here
}

let v = new Calculator(2)
  .add(1)
  .value

One of my objectives is I want to make this code more type-safe since the constructor's type signature is not checked yet.
It will be possible to resolve to resolve static members of the class from this.constructor attribute and to do type-checking on the constructor of the child class from the parent class using this idea by modifying the Calculator class above to be like this.
class Calculator {
  // ...

  protected newInstance(
    this: this & { constructor: { new(value: number) } },
    value: number
  ): this {
    return new this.constructor(value)
  }

  add(
    this: this & { constructor: { new(value: number) } },
    operand: number
  ) {
    return this.newInstance(this.value + operand)
  }

  // ... other operations go here
}

Every method which associates with the fluent interface will not be able to be called from an instance of the class which doesn't have the required signature.
class BrokenCalculator extends Calculator {
  constructor(value: string) {
    super()
  }
}

let v2 = new BrokenCalculator()
  .add(5)   // <-- this resolves to:
            //     ReducibleInstance<BrokenCalculator, typeof BrokenCalculator>
            //     (error: not compatible with required this by the method)

Thank you. I'm looking forward to hearing about this. I'm sorry for long post here.
I hope this idea will be able to solve our problems. 😃

The problem is still necessary to resolve.
It's quite boring to write ['constructor']: typeof FooClass every time.
Solution must be simple. The following code inside a constructor or an instance method
...
   this.constructor
...

is always pointing to the its constructor class unless someone failed to assign Child.prototype.constructor = property by Parent class during inheritance.

Any news on this?

This would be nice to have! It's a very common case.

I was OK with adding field 'constructor': typeof ClassName but after upgrading to TS 3.5.1 I receive error Classes may not have a field named 'constructor'. It is really obtrusive that this issue is open for 4 years :)

@ayZagen Yeah, it's really frustrating that such a simple issue isn't solved after 4 years later. Somebody must op a PR to do that I think.

@ayZagen That error message was added in #31119 and relates to #31020
There seems to be an allowance for the version with brackets:
class A {
    ['constructor']!: typeof A // ! to avoid 'use before init' error in constructor
    static methodA() { }
    constructor() { this.constructor.methodA(); }
}

new A().constructor.methodA();

You can also use interface merging, which avoids both [] and !
interface C {
    constructor: typeof C
}
class C {
    static methodC() { }
    constructor() { this.constructor.methodC(); }
}
new C().constructor.methodC();

I can't remember if this was always the case, but it works with subclasses now too
class B extends A {
    ['constructor']: typeof B
    static methodB() { }
}

new B().constructor.methodA();
new B().constructor.methodB();

Most people want to read this.constructor.someProp, they usually don't want to call new this.constructor(...). Maybe the type checker needs to do two things:

When this.constructor is being called as new this.constructor(...), then in this case it should fail because of the substitutability problem (i.e. treat it as Function, because we don't know what a subclass constructor signature will be).
When reading properties, like this.constructor.someProp, treat is as a static access in the scope of the class where it is being accessed, don't treat it as Function. So if this.constructor.foo happens in the scope of class B, then treat this.constructor as typeof B.

This would prevent from having to write ['constructor']!: typeof B in every subclass.

The fact that the following works,
class A {
    ['constructor']!: typeof A
    static methodA() { }
    constructor() { this.constructor.methodA(); }
}

new A().constructor.methodA();

is weird because in JavaScript it is an error. Try it in Chrome console, without the types:
class A {
    ['constructor']
    static methodA() { }
    constructor() { this.constructor.methodA(); }
}

new A().constructor.methodA();

If I recall correctly, one of the goals of TypeScript is that types can be stripped to leave valid JavaScript, but that's not true in this case.

@trusktr that's not valid JavaScript and it's also not what TypeScript compiles to. This is what TypeScript compiles to:
class A {
    static methodA() { }
    constructor() { this.constructor.methodA(); }
}

new A().constructor.methodA();

that's not valid JavaScript

Thanks, I know. That's what I'm pointing out: it is invalid JS (with types) which converts to valid JS after compile.
I guess I'm just saying that it is strange and not obvious what the behavior should be. If I go by my JS knowledge (coming from JS to TS), then obviously I'd be wrong. I wouldn't have never thought to define the same property twice like.

I use this way for inherit class
export function bindConstructor<T>() {
  return <U extends T>(constructor: U) => {
    // noinspection BadExpressionStatementJS
    constructor;
  };
}

export interface BaseClass<T extends typeof BaseClass = typeof BaseClass> {
  constructor: T;
}

export interface BaseClassConstructor<T = {}> {
  new (...items: any[]): T;
}

export interface AnyConstructor<T = {}> extends BaseClassConstructor {
  new (...items: any[]): T;
}

@bindConstructor<BaseClassConstructor>()
export class BaseClass<T extends typeof BaseClass = typeof BaseClass> {
  constructor(...items: any[]) {}
}

interface ChildInterface {
  readonly Zero: number;
}

interface ChildConstructor<T = {}> extends AnyConstructor {
  new (...items: any[]): T;
  Two: number;
}

@bindConstructor<ChildConstructor>()
class Child<T extends typeof Child = typeof Child>
  extends BaseClass<T & AnyConstructor>
  implements ChildInterface {
  readonly Zero = 0;
  protected readonly One = 1;
  static Two = 2;
  protected static Three = 2;
}

@bindConstructor<ChildConstructor>()
class Son<T extends typeof Son = typeof Son> extends Child<T & AnyConstructor>
  implements ChildInterface {
  constructor(...items: any[]) {
    super(...arguments);
    console.log(this.Zero);
    console.log(this.One);
    console.log(this.constructor.Two);
    console.log(this.constructor.Three);
  }
}

another way:
export function bindConstructor<T>() {
  return <U extends T>(constructor: U) => {
    // noinspection BadExpressionStatementJS
    constructor;
  };
}

export type BaseType<U> = InstanceType<U & { new (...args: any): any }>;

export interface AnyConstructor<U extends {} = {}> {
  new (...items: any[]): U;
}

//export interface BaseConstructor<U extends typeof Base> extends AnyConstructor<U> {
//  create(...items: any[]): BaseType<U>;
//
//  new (...items: any[]): BaseType<U>;
//}

export abstract class Base {
  constructor(...items: any[]) {
    this.setup();
  }

  static create<U extends typeof Base>(this: U, ...items: any[]): BaseType<U> {
    return Reflect.construct(this, items);
  }

  setup(): void {}

  //noinspection JSMethodCanBeStatic
  type() {
    return Base;
  }
}

  interface YI {}

  interface YC<U extends YI = YI> extends AnyConstructor<U> {
    z(): string;
  }

  interface X {
    constructor: X;
  }

  abstract class X extends Base implements YI {
    xa!: string;
    xf!: string;
    xfr!: string;

    protected ef: string = 'ex';
    protected readonly efr: string = 'ex';

    protected get ea() {
      return 'ex';
    }

    type() {
      return X;
    }
  }

  @bindConstructor<YC>()
  class Y extends X {
    protected ef: string = 'ey';
    protected readonly efr: string = 'ey';

    protected get ea() {
      return 'ey';
    }

    static z() {
      return 'z';
    }

    setup(): void {
      this.xf = 'ey' === this.ef ? 'TRUE' : 'FALSE';
      this.xfr = 'ey' === this.efr ? 'TRUE' : 'FALSE';
      this.xa = 'ey' === this.ea ? 'TRUE' : 'FALSE';
    }

    type() {
      return Y;
    }
  }

Any hope for this feature? A long awaited "ergonomic" improvement.

I'm currently trying to do some type checking (anything really) to see an object extends a class.  One notable difference between classes and objects is the list of attributes on their constructor.
The following would be a functional way to tell if something was a class or not:
T extends {constructor: { defineProperty: any}} ? ProbablyNotAClass : ProbablyAClass

One thing that no one seems to have called out during this discussion is that there's a difference between T.constructor and T.prototype.constructor. T.constructor type is already accurate - it is the constructor function and not the class object, so it lacks things like static members. T.prototype.constructor is indeed just a reference to the class object, and this is where we have this type problem. Try this on TS Playground:
class EventModel {
  static prop = 1
}

console.log(EventModel.constructor, (EventModel.constructor as any).prop)
console.log(EventModel.prototype.constructor, (EventModel.prototype.constructor as any...

Playground Link

@dolsem in JS, the constructor function is the class object - class is just syntax to create a constructor function, with a .prototype property. Klass.prototype.constructor === Klass.constructor, in any well-behaved class.

T.constructor is the global Function object for classes (and functions in general), so T.prototype.constructor !== T.constructor, because T !== Function.

@ExE-Boss oops, you're right; i deleted my comment.

Finally
this is best solution
eval('this.constructor.staticFn()')

@Lugeen Then what's the reason you use TypeScript? Why don't you just use plain JavaScript?

eval(this.constructor.staticFn))

Isn't this better?
// @ts-ignore
this.constructor.staticFn()

@trusktr thank you , your answer is perfect solution .

I thought this can be implement if there's exact type

Every time I type (this.constructor as typeof MyClass).someStaticMethod() I scold the TypeScript with the last words. Optimized for stress?

I'd like to share my workaround, for referring static members in a convenient way.
But the newable signature is not working well.
type Constructor = new (...args: any[]) => any;

function TypedConstructor<S extends void | Constructor = void>(Super?: S):
    S extends Constructor
        ? {
            [K in keyof S]: S[K]
        } & {
            new <U>(...args: ConstructorParameters<S>): InstanceType<S> & { constructor: U }
        }
        : {
            new <U>(): { constructor: U }
        }
{
    return Super || Object as any;
}

// for base class, use TypedConstructor()<typeof [ThisName]>
class A extends TypedConstructor()<typeof A> {

    static staticA() { return 0; }
    protected static protected_staticA() { return 1; }

    constructor(x: number) {
        if (typeof x !== 'number') {
            throw new Error('Argument type error!')
        }

        super();
    }

    foo() {
        console.log(this.constructor.staticA()) // OK
        console.log(this.constructor.protected_staticA()) // OK
    }
}

// for inherited class, use TypedConstructor(Super)<typeof [ThisName]>
class B extends TypedConstructor(A)<typeof B> {

    static staticB() { return 'bbb'; }
    protected static protected_staticB() { return 'xxx'; }

    constructor(x: string) {
        if (typeof x !== 'string') {
            throw new Error('Argument type error!')
        }
        super(Number(x));
    }

    foo() {
        super.foo();
    }

    bar() {
        console.log(this.constructor.staticA()); // OK
        console.log(this.constructor.protected_staticA()) // OK
        console.log(this.constructor.staticB()); // OK
        console.log(this.constructor.protected_staticB()); // OK

        //new this.constructor(0)
    }
}

var a = new A(0);
var b = new B('1');
b.bar();

// Do not use `new` with `constructor`!
var c = new b.constructor('0') // Compiled, but will throw runtime error.

If we were to add a strongly typed constructor property to every class, then it would become an error to declare the Derived class above.

@ahejlsberg I noticed that the new.target pseudo-property is always typeof Foo when it appears in the constructor body of class Foo.
class Foo {
  constructor() {
    var s = new.target;
    // s: typeof Foo
  }
}

Is it possible that we might also treat this.constructor syntax as the way we do with new.target?

Any plans on picking this up. Seems like a real issue

@thetutlage I think we all can safely forget about it and move on.

Just ran into this. Not being able to call static members from instances is rather limiting.

Any progress?

we could type constructor fairly well just with a change to our lib.d.ts now that we have this types (in theory):

Did that ever work? I tested it but instead of Constructor<this> resolving to the actual type, it resolves to a plain Object, which makes it useless:
https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgMIHsQGcxQK4JjpQA8AKgHzIDeAsAFDLIgQDuyAFAHQ9xQDmWAFzI4IAJ4BtALoBKEWQDcDJgAco6ImHGqIC5fQC+DAPQnkAJQgg4AWwgATZAkw58hYsiLPXuAkSgyCBwAGlNzACMIBDg8LBQYkAByMGR0ADdoVihgSGQAG2AIrgcuMCxkAAtoCAZQSFhEFAB5CIAraNS6Rh9sPw9A4LARDD73AJIwSuAsCgNjegR8uCwKgA0ATRoVXrd-Yg5VPAjChGQAD2QAXmQABhDkI5PgM-Fru9ltnqYzZk1pkD8ZDiCBgHYLJhLTAQDifbpMSG+ZBQUHvFjsTYcKYzLjnB7YrBccSyAwI5C-ADKlXQeHyTiiyE2DwieFSM2QrQ6hB2iL6yNBACY0WwvNNCS4xvtBjgsWLcfi5cTSQiUWA8FAQPywMqFgslisKgBVeJQTbICDnSAgBzrLbw8nmED-UBAkFgowMCU4C5vG7oxkbAxe1JxaDnX3MEXG6CbINI0NQcOofLQ94J8NcKEsWEGYAwTjp8TJ1OgHBiJDofPR00bOE7L3ofIQLgp-gcABEAHF0OgnG10BF2ySGIZzfl4l9eVhG83Wx2ANIQCCqLxQcQunhcIcjhhAA

I just hopped into TypeScript and if it weren't for type assertions, this would've been problematic. What's the status on implementing this?

I just hopped into TypeScript and if it weren't for type assertions

Putting type assertions or ts-ignore everywhere is not exactly improving type safety. In the contrary, the type assertion might be forgotten after a refactor and then the wrong type still perpetuates itself through the system.
I think this is the biggest weakness of TypeScript I ever came across, it literally breaks/disallows every programmer to do proper OOP.

I agree; I don't feel comfortable using type assertions for this, but it's a short-term solution until something changes where I don't have to use type assertions.

May I ask why this never came to fruition despite being started in 2015?

@Vanilagy This is one of the reasons why I stopped to use TS. It's too useless for OOP programming. You probably should do this too. Over they years, instead of fixing existing issues M$$oft introduced a lot of unnecessary and unjustified complex feature into TS. Thi should be eventually marked WONTFIX and closed. I see no way this ever fixed.

@hinell I meeeeeeean, personally I've managed to use a lot of its OOP features without issue, I just didn't go all Java-style religious on it. The only thing I maybe missed over the years was the ability to mark a class as final. But this issue here, it really seems like such a small thing to fix compared to all the super-complex type logic they've added over the years.

@Vanilagy Yeah, I too managed to produce a half-assed codebase with tons of unnecessary decoys intended to make the code look important but nevertheless the TS is a waste of time. I feel more comfortable to use JSDocs for exported interfaces. Much cheaper. Best.

Alright then buddy + ratio

@hinell generally I find those who are closed to knowledge react in the way you are here. It's ok if you want to stick with Java, but there are a lot of people that use TypeScript daily and to great effect, and generally those who are actually familiar with the language (many of which are polyglots) are large advocates. This would be a nice issue to close, but let's try to be constructive with our feedback. Otherwise I would suggest go ahead and build whatever makes you happy with another language like Java, but let's keep this thread clean so it's helpful to the TypeScript team and the community.

@RobertWHurst Well, I used TypeScript since 2015 and you can even find a comment that was made by me YEARS ago. Devs aren't interested in solving actually important issues here so I think it should be ultimately dropped in favor of more friendly open source alternative. Currently, MS has locked up a lot of people to it. You choose what you like anyway!

@RobertWHurst Well, I use TypeScript since 2015 and you can even find a comment that was made by me YEARS ago. Devs aren't interested in solving actually important issues here so I think it should be ultimately dropped in favor of a more friendly open source alternatives.
At given pace of features they introduce it will soon grow out of proportion and make language completely infeasible to learn. Something that google did to angular.

@RobertWHurst Well, I use TypeScript since 2015. I've commented here already in 2018. Devs aren't interested in solving actually important issues here so I think it should be ultimately dropped in favor of a more friendly open source alternatives.
At given pace of features they introduce it will soon grow out of proportion and make language completely infeasible to learn anyway. Akin to what google did to angular.

@RobertWHurst Well, I use TypeScript since 2015. I've commented here way back in 2018 and as I can see devs aren't interested in solving actually important issues here so I think it should be ultimately dropped in favor of a more friendly open source alternatives.
At given pace of features they introduce it will soon grow out of proportion and make language completely infeasible to learn anyway. Akin to what google did to angular.

I just reached this discussion, so I wanted to share a clean type safe solution, so long as you don't mind an extra call:
Add this somewhere that you find convenient.
Object.prototype.static = function static(): any {
    return this.constructor;
};

declare global {
    interface Object {
        static<T extends NewableFunction>(this: InstanceType<T>): T;
    }
}

Then you can use static() just like how constructor should work:
class Parent {
  static staticMethod() { console.log('From parent'); }
  instanceMethod() {
    this.static().staticMethod();
  }
}

class Child {
  static staticMethod() { console.log('From child'); }
}

new Child().staticMethod();

At first I thought that just making this solution a getter withget static would give the intended behavior, but the type magic with the this: InstanceType<T> doesn't work on getters. If it did, we could just replace the declaration with get constructor and it would work.

To add on to the solutions, I've been doing this:
class SuperClass {
  get static() {
    return /** @type {typeof SuperClass} */ (/** @type {unknown} */ (this.constructor));
  }
}

class SubClass extends SuperClass {
   get static() { return /** @type {typeof SubClass} */ (super.static); }
}

You cannot do typeof this, as tempting as it sounds. You have to do typeof ${className}. From there, within an instance, call this.static.name and you'll get it like you normally word. (eg: this.static.observedAttributes, myObject.static.name). I use .static because IMO it's clearer than .constructor.

@Fryuni I tried your solution, since it looked the most promising, but I get an error when I try it:

And indeed when I inspect NewableFunction, it doesn't contain a new (...args: any): any signature or anything similar. Are you using a specific compiler configuration in your tsconfig.json that makes this work for you?

Hey @Evertt, sorry I was oversimplifying here when copying from our actual code without much care.
NewableFunction is to allow using instanceof properly.
For InstanceType we defined a Constructable, which frankly should probably be in the std lib for symmetry with InstanceType:
type Constructable = abstract new(...args: any[]) => any;

declare global {
    interface Object {
        static<T extends Constructable>(this: InstanceType<T>): T;
    }
}

Object.prototype.static = function(): any {
    return this.constructor;
};

In the few places where we used this (and we don't anymore), we actually assigned to a variable with the proper type, but it also works by passing a type argument:
class Parent {
  static staticMethod() { console.log('From parent'); }
  public instanceMethod() {
    const klass: typeof Parent = this.static()

    klass.staticMethod();

    // OR

    this.static<typeof Parent>().staticMethod();
  }
}

class Child extends Parent {
  static staticMethod() { console.log('From child'); }
}

new Child().instanceMethod(); // Calls the child static method

And those truly validate that the type is either the class or a parent of the class, as you can see here.
We later realized that this actually isn't sound because TypeScript only checks the prototype chain when the parent contains private or protected instance values/methods. If there are none, TypeScript treats the class as an interface and only checks that both classes have the same structure. See here.
This was part of a unrelated, but quite surprising discovery for us:
class Foo {}

function foo(value: Foo) {
  if (value instanceof Foo) return;

  // This is _not_ unreachable!
  throw new Error();
}

// This works
foo('something');

Which means you can create this level of blasphemy

@Fryuni ah that's too bad. The fact that you need to manually cast the return value of static() to typeof Parent already makes this method useless to me. I was hoping to find a way to write the interface for static() such that TypeScript would always be able to correctly infer its return type.

@Evertt The best solution so far was given here: https://github.com/microsoft/TypeScript/issues/3841#issuecomment-337560146

We were using the solution in https://github.com/microsoft/TypeScript/issues/3841#issuecomment-337560146, but now that we are using "strictPropertyInitialization": true in our tsconfig.json we have to add the definite assignment operator:
class C {
    ['constructor']!: typeof C;
}

the workaround i went with is to create a function that instantiates a class and modifies the constructor type:
type Class = new (...args: any[]) => any

type HasTypedConstructor<T extends Class> = InstanceType<T> & { 'constructor': T }

const New = <T extends Class>(class_: T, ...args: ConstructorParameters<T>): HasTypedConstructor<T> => new class_(args)

class Foo {
    constructor(public a: number) { }
}

const foo = New(Foo, 1)

foo.constructor // typeof Foo

playground

If someone wants to make it work with prettier (which removes the quotes), wrapping around [] does the trick:
class C {
    ['constructor']: typeof C;
}

As the new confused proposal "class fields as define properties" of ES2022 becomes TypeScript default behavior, we must write as following to avoid access-blocking to the prototype:
class C {
    declare ['constructor']: typeof C;
}

@TechQuery This issue didn't age well as I see. Now even more crowded, completely unnecessary keywords are needed.  This is going to break backwards compatibility again. This is crazy. I think TS needs to be replaced by more robust and sensible language.

the workaround is to give it a name, since anonymous things hurt debugging anyways.

The workaround is to drop TypeScript altogehter. We need better language. Read:

TypeScript is 'not worth it' Svelte switches to JavaScript and JSDoc
https://github.com/sveltejs/svelte/pull/8569

That should be a great concern and alarming to the TS team.
As well as this issue and the need to do horrible workarounds to do things that are considered the core scope of TS.
TS is there to make coding easier, not harder.
All the workarounds in thread are too ugly, forgive me if I offended anyone.

the workaround is to give it a name, since anonymous things hurt debugging anyways.

Giving it a name sometimes works. But often we want derived classes to be able to override the static method with their own implementations, and use that implementation.
var A = class {
  static answer(){ return 42 };
  lifeUniverseEverything() { console.log(`the answer to life the universe & everything is... ${this.constructor.answer()}`) }
}
var B = class extends A {
  static answer(){ return "6*9" }
}
(new B).lifeUniverseEverything() // => the answer to life the universe & everything is... 6*9

Nack on just saying stuff should be named. TypeScript should in general be capable of doing what JavaScript does. This is a useful & expected capability of the language that people should be able to use in TypeScript, without having to explicitly typecast stuff themselves.
The actual workaround is: (this.constructor as typeof A).answer(), but TypeScript should already know this & not need to be hinted like so.

(this.constructor as MyClass).myStaticMethod() is the workaround I've been using. Quite dislike it.
Here's an example use case:
var A = class {
        static answer(): any { return 42 };
        lifeUniverseEverything() { return (this.constructor as typeof A).answer() } // WORKAROUND HERE
}
var B = class extends A {
        static answer(){ return "6*9" }
}
console.log(`the answer to life the universe & everything is... ${(new B).lifeUniverseEverything()}`)
// => the answer to life the universe & everything is... 6*9

Being able to have virtual static methods is a super-powerful & super-useful capabillity! Wish it was better supported. Thanks, happy hacking folks.

@pinko-fowle Note that doing so regenerates the entire class, with the equivalent of
{
  new (...args: any[]): {[K in key of CLASS]: CLASS[K]},
  [K in key of typeof CLASS]: typeof CLASS[K],
} & typeof CLASS;

That makes a really gigantic file when you generate types since it's duplicating every since key. The more you extend the worse it gets. Something like HTMLElement has 100s of properties.

@Fryuni I can't get your example to work.
playground

@trusktr, there are three problems:
The first one is somewhat silly, but you need the export {} somewhere at the top level of the file for the declare global to work correctly.
Second, my solution cannot infer the type; just validate it. demonstration.
The last one I mentioned in this comment, when the class has no private instance members, any other class with a subset of the instance methods will be assignable to it. It worked for us because all our classes do have private members. demonstration

So this works...
class TSConstructorFix {
  /**
   * @type {{
   * <T1 extends typeof TSConstructorFix, T2 extends T1, T3 extends (Base:T1) => T2>
   * (this: T1,customExtender: T3):
   *  ReturnType<T3>
   *      & {
   *          new(...args: any[]): {
   *              constructor: {[K in keyof ReturnType<T3>]: ReturnType<T3>[K]}
   *          } & {
   *            [K in keyof InstanceType<ReturnType<T3>>]: InstanceType<ReturnType<T3>>[K]}
   *          }
   *      }
   * }}
   */
  static extend(customExtender) {
    // @ts-expect-error Can't cast T
    return customExtender(this);
  }
}

class Test extends TSConstructorFix.extend((Base) => class extends Base {
  static foo = 123;

  go() { return 0; }
}) {};

const t = new Test();
t.constructor.foo += 4;
t.go();

If you're willing to add extends TSConstructorFix.extend((Base) => class extends Base  after you class name (maybe a Regex).

@clshortfuse that'd be a fairly invasive change I think. Better to just const ctor = this.constructor as Foo in some spots I think.
@Fryuni Thanks, got it! Btw, export {} not needed if you tack the export onto one of your actual classes (that's what I had in my example).

the workaround is to give it a name, since anonymous things hurt debugging anyways.

Considering calling your parents and your friends in their full names. It's more explicit.

If someone wants to make it work with prettier (which removes the quotes), wrapping around [] does the trick:
class C {
    ['constructor']: typeof C;
}

This solution doesn't work when useDefineForClassFields is set to true in tsconfig.json (e.g. this is done in the default configuration for Vue) or target is es2020 or higher. Setting useDefineForClassFields to false will make it work. Won't wouch it won't break anything else.

As the new confused proposal "class fields as define properties" of ES2022 becomes TypeScript default behavior, we must write as following to avoid access-blocking to the prototype:
class C {
    declare ['constructor']: typeof C;
}

Factors than neccesiate using declare include:

having target set to es2020 or higher in tsconfig.json;
having useDefineForClassFields set to true (e.g. this is done in the default configuration for Vue).

Setting useDefineForClassFields to false will make the code work without declare. Can't wouch it won't break anything else.

Could someone please add it to TS Milestones for one of the upcoming versions
The issue is open for 9 years. And it deserves being addressed. Brief Stackoverflow review shows devs even started using ClassName.method notation instead of this.constructor.method thus bringing Divergent Change code smell into their projects to simply satisfy the typing
The solution above by @jwbth seems the most clear and concise.
It is just one line of code at the top. Not a big deal.
But it still has to be added and class name still has to be provided in two distinct places. If someone accidentally forgets to change one of them while changing the other, this could lead to very pleasant debugging experience.


Prepapre for 4.1.0 release with 2201.0.0

Description

Bump version to 4.1.0
Update Ballerina version to 2201.0.0 in Package.md
Regenerate Dependencies.toml with 2201.0.0
Add distribution = "2201.0.0" in Ballerina.toml

Security checks

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

@RolandHewage can u resolve the conflict?

Conflicts are resolved now


Tape teaspoon

In addition to https://github.com/elementalui/elemental/pull/64, here are Teaspoon selections as per @ericelliott's suggestion.
Made a different PR, though it contains most pretty much all commits of #64 plus changes for teaspoon.

Been holding off on selecting one of the test PRs for too long, but this looks really nice, so let's get on with it :grinning:
Thanks @nkbt, and nice find with Teaspoon @ericelliott!

\o/


Fix/37 and engprd 668

gradle-plugins/#37 In dev

I am getting an error locally when running the IT that dont run in CI
./gradlew :plugins:docker:base-image:integrationTest --tests "*DockerBaseImageMatrix"
* What went wrong:
Execution failed for task ':dockerBaseImageLockfile'.
> CSV line from script not valid: OK: 20 MiB in 20 packages

Sure enough its the first line of the CSV
    OK: 20 MiB in 20 packages
    apk-tools,2.14.4-r0,,aarch64
    bash,5.2.21-r5,,aarch64
    busybox,1.36.1-r10,,aarch64

I am getting an error locally when running the IT that dont run in CI
./gradlew :plugins:docker:base-image:integrationTest --tests "*DockerBaseImageMatrix"
* What went wrong:
Execution failed for task ':dockerBaseImageLockfile'.
> CSV line from script not valid: OK: 20 MiB in 20 packages

Sure enough its the first line of the CSV
    OK: 20 MiB in 20 packages
    apk-tools,2.14.4-r0,,aarch64
    bash,5.2.21-r5,,aarch64
    busybox,1.36.1-r10,,aarch64


Slideshow not starting after reload

How to reproduce

Select an album
Reload (Ctrl+R)
Click the start button

Expected behaviour
The slideshow starts.
Actual
The slideshow does not start.
The play button stays as is.
The menu item Diashow > Diashow starten (Slideshow > Start Slideshow) is disabled.

Was solved with #40


Project management

@AYapejian  do you want someone else to come alongside you to manage this project? it hasn't been touched an over 2 months, and it has a number of people trying to contribute. I'm not sure that i'm the best person for the job (not a programmer/don't know node, but i'd be willing to help out, or maybe someone else who has made a meaningful contributon to the project.
It just seems that more could e accomplished here than is currently happening.
Alternately, if you are not interested in continuing to maintain it, should the project be forked?

Thanks for the offer.  Anyone is welcome to fork the repo of coarse, that being said I haven't abandoned the project I've just been busy with other life priorities the past month or two.   Going to start wading through issues and PRs and try and catch up a bit in the next few weeks.  Stay tuned.
On the other ask, I'll have to look into breaking the project out of my personal repo if we're going to have multiple maintainers I think, I certainly am not against this it's just a matter of finding the time.  Let me see if I can get things back on track and then address this part afterwards if need be.

when you do look into this, it might be worth seeing if it can be added to the official home-assistant repository

Any news here, @AYapejian? The project looks quite dead at the moment, which is a pity. I think it would be beneficial to try and get new contributors on board.
Sure, everyone could just fork this project, but then a few months or a year down the line we'll probably have n+1 dead projects... And there would be more confusion for Node RED users having to decide which of those modules they should install.
Maybe you really could get this project under the HomeAssistant umbrella.


Feature Request to Possibly Host more than one DNS Zones on K8gb

There is a possible issue that we need to have Separate DNS Zones for different Datacenters to cater for people who can only run Active Passive and then also hvae the GLB
Example is DC1-us.k8gb.gb and DC2-us.k8gb.gb then also DC.k8gb.gb
The request is to add support to host multiple DNS Zones in K8GB and not just one zone

This is however not in the domain of GSLB anymore is it?
DC1-us.k8gb.gb and DC2-us.k8gb.gb will in no way have any global load balancing strategy applied to them as they are DC (Datacenter)/region specific.
IMHO this is not something k8gb should handle as this is not GSLB related, unless the scope of this project changes. DNS level "load balancing" is required for GSLB concerns but this feature seems to allow for a convenient way to configure DNS records for DC/region specific Ingress, with nothing to do with load balancing. I'm just concerned we are drifting away from the core responsibilities k8gb is meant to handle...

@donovanmuller Generally agree but I see it a little bit differently.
k8gb

create GSLB enabled dns record of e.g.  DC.k8gb.gb
It also creates DC-us and DC-eu following convention over configuration so the clusters/workloads behind  GSLB can be deterministically accessed directly bypassing LB strategy. Local DNS load-balancing is a nice side-effect of it.
No current Gslb spec modification required as again it will be convention only
This feature can be enabled/disabled in operator configuration

I disagree with point 2 in principal:

Local DNS load-balancing is a nice side-effect of it.

DNS is a poor local load balancer (TTL, no advanced strategies around least connection, etc.) and you can achieve the better results with other projects or configurations. If the main goal of point 2 is to make DNS automation easier, then that should be the responsibility of other projects/tools suited to that goal.

deterministically accessed directly bypassing LB strategy

This also implies that every Ingress resource could handle local load balancing independently, which is generally not the case. DNS would either point to a layer 4 load balancer (via a shared VIP potentially) in front of the ingress node IPs or the ingress nodes themselves but at an ingress controller level, not at an individual Ingress resource level.

@donovanmuller / @Zak-Anderson any objections I close this one? Seems out of k8gb scope in the end

@donovanmuller / @Zak-Anderson any objections I close this one? Seems out of k8gb scope in the end

@ytsarev happy to close from my side. I agree it's beyond the scope of this project.

@ytsarev happy to close from my side. I agree it's beyond the scope of this project.

@Zak-Anderson feel free to reopen if needed

@Zak-Anderson feel free to reopen if needed

Happy to close

Happy to close


codedeploy scripts

added necessary scripts for code deploy:
appspec.yml
/scripts/install_dependencies.sh
/scripts/build.sh
/scripts/reload_server.sh

looks good for now :)

"for now"
the shade is crazy

looks good for now :)

"for now" the shade is crazy

not off the hook until I'm sure you haven't broken main ;)


BatchTranslateDocumentRequest.Builder.setParent() should accept LocationName

Looking at the generated files, it looks like the BatchTranslateDocumentRequest object still only accepts strings:
https://github.com/googleapis/java-translate/blob/master/proto-google-cloud-translate-v3beta1/src/main/java/com/google/cloud/translate/v3beta1/BatchTranslateDocumentRequest.java#L1607
However, the public source protos have been updated:
https://github.com/googleapis/googleapis/blob/master/google/cloud/translate/v3beta1/translation_service.proto#L1195

Hi @Neenu1995, has there been any movement on this? Thanks!

Tried regenerating it manually. Same results. Could be an issue with the java microgenerator .
@vam-google Can you take a look please?

https://github.com/googleapis/java-translate/blob/master/proto-google-cloud-translate-v3beta1/src/main/java/com/google/cloud/translate/v3beta1/GetSupportedLanguagesRequest.java#L757
https://github.com/googleapis/googleapis/blob/master/google/cloud/translate/v3beta1/translation_service.proto#L394
Same thing is happening here. The generator may not be recognizing Location.

https://github.com/googleapis/java-translate/tree/master/proto-google-cloud-translate-v3beta1/src/main/java/com/google/cloud
Location is being generated in a separate package.

Once the translate team make the necessary proto changes and the cl is submitted to the third_party folder, the code will be automatically updated with the required changes in a few hours.
It might be best to keep the issue until the cl has been submitted.


Fixing x64 and Windows 10 startup issues

Fix for legacy version 2.6.3; solves touch input processing when running in x64 mode and fixes Windows 10 operating system check which incorrectly prevents processing of touch events.

Thanks! As the Toolkit is deprecated and no longer supported, I cannot merge this PR.


refactor: have default named component in each file

Based on our team's decision, we no longer require approval of the refactoring pull request. Instead, we will review and approve the refactoring once all changes related to a specific component have been completed.


Bigger triplestore

RDF4J handles ~100 million triples, but that is tiny when considering the size of biosamples & uniprot.

Other options would be

Blazegraph: used by Wikidata
Virtuoso: used by DBpedia

Also cannot properly secure rdf4j; can secure workbench but not underlying server.

Related to size/number of triples. UniProt pages (looked at so far) have an average of over 800 triples per page.

Virtuoso does not look like fun:
http://vos.openlinksw.com/owiki/wiki/VOS/VOSCentosNotes
Blazegraph:
doesnt seem to run on mac, but apparently works on linux
Both will need port forwarding...

cant find user management functionality in blazegraph docs: https://wiki.blazegraph.com/wiki/index.php

Angus and Imran both have recent experience with installing Virtuoso.

Done:

Installed virtuoso by compiling from source.
Loaded nq thru bulk loader.
Can see triples thru /sparql.

Still to do:

Programmatically access triplestore
Update data access layer to use virtuoso
Deploy access layer to both scraper & web app

Both test & prod using virtuoso


vscode variables and relative paths don't work for profile dir override

Expected behavior
doesn't work:

using ${workspaceFolder} should allow extension to function properly
relative path ./
works:
hard coding the absolute path work

Actual behavior
An error occured while initializing the dbt project: Runtime Error
Could not find profile named 'ethereum'
Steps To Reproduce

update profiles dir override value to ${workspaceFolder}
reload window
open dbt model

Log output/Screenshots

VSCode Version

Version: 1.73.1 (Universal)
Commit:<PHONE_NUMBER>f055b99068d3688932416f2346dd3b
Date: 2022-11-09T02:08:38.961Z (3 wks ago)
Electron: 19.0.17
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 22.1.0
Sandboxed: No

Operating System
macOS 13.0.1 (22A400)
dbt version
1.3.1
dbt Adapter
snowflake
dbt Power User version
v0.10.1
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Vscode doesn't provide the variables substitution logic as an API and there is no reliable library for parsing them.
If I remember correctly putting just a . works. I think you can't put a / at the end. See https://docs.getdbt.com/docs/get-started/connection-profiles#2-use-the-dbt_profiles_dir-environment-variable-to-change-the-default-location

I did add support for ${workspaceFolder} in 0.10.3.
Please reopen the issue if you have any issues.

Hi @mdesmet - it is still not working here having a workspace/project config like this:
    "terminal.integrated.env.windows": {
        "DBT_PROFILES_DIR": "./.dbt"
    },

moving the .dbt folder to ~ solved the problem so it looks like the DBT_PROFILES_DIR variable is not read correctly.


reporter: Replace the Xalan TransformerFactory with Saxon

The latest Apache Xalan 2.7.2 is 8 years old and does not support the
accessExternalDTD attribute that Apache POI requires, so switch to
the actively maintained Saxon TransformerFactory instead. Fixes #4830.
Signed-off-by: Sebastian Schuberth<EMAIL_ADDRESS>

Relevant reporter tests have been manually verified to succeed.


Update for creating multiple slides and passing props to each slide.

What's this PR do?
This PR allows creating multiple slide components while also passing along props with data regarding the user and current campaign to each slide.
How should this be reviewed?
Does the code 👀  reasonable?
Relevant tickets
Fixes #6721
Checklist

[ ] Tested on staging.

@DFurnes @deadlybutter

:ship:


classification or regression?

Thanks for your great work. As for the depth generation, you choose argmax of classification instead of weighed operation of regression. Does it increase the risk to predict a wrong depth range in the early stage? What do you think about the choice of classification and  regression in multi-view stereo.

Great question. Actually, the MVSNet uses regression and RMVSNet uses regression. And some other methods also have different choices. In our paper, we use a binary search pipeline so we naturally use classification. The possible risk of the wrong prediction is handled by ETB. If you want more discussion about the two kinds of methods, I recommend you to read the paper of this code UniMVSNet.


bug fix for loading cached stock data.

For screening on Monday morning before 9:15 for that reading cached data for last Friday. fixes #50

Hello @swarpatel23
I went through your code, the condition is only considering Friday to Monday transition.
However, we need a generalized solution for the following.
1. Suppose, the user is screening on any working day (Let's say 't') before 9.15 AM.
2. The script will look for stock_data_t.pkl which is unavailable.
3. So the script should look for previous trading session file stock_data_(t-1).pkl
4. If the file is available, use it as cache, else download regular data from API, screen it, and save cache as stock_data_(t-1).pkl at the end.

Updated Code in saveStockData and loadStockData method. For screening before 9:15 on monday, I am going back 3 days and trying to fetch Friday's cached data. For other days running before 9:15 going back for 1 day.


Merge pull request #1 from ICESAT-2HackWeek/master

updating from master

Added a simple script to plot location of data using a couple of methods.


Use final.

Coverage remained the same at 99.758% when pulling 02b9905c25652e24a661b31da47d6d5dcfe71e00 on arturobernalg:feature/final_simple into 6260581afc9d41a2821d0b535ba8097eaa3c3177 on apache:master.

The project enforces effectively final method arguments using PMD. Using the keyword adds no runtime benefit and visual noise to the source.

OK,
TY


Divi Module Development Questions

Hi there!
I talked to a salesperson yesterday regarding local development with the Divi theme, and he recommended I develop the website live. A couple of questions came to mind afterward.

How would I use a terminal to run Node.js commands? I want to develop modules with React but I'm unsure of how a terminal and a code editor would be used in WordPress itself.
 Just for clarification, I'm not referring to a website with just one page, but specifically, a SPA, where the website doesn't refresh if a different page is opened.
Am I able to use state-management tools such as Redux to share data across modules?

@El-Potato-Slayer Thanks for your interest in the Divi community :). Firstly, you don't need a live website to develop a custom Divi module; local development is in fact recommended. Please see the following:

how to develop a module
how to create a custom field for a module

Modules are just the building blocks you use to build your pages/posts. This has nothing to do. with whether the whole website is SPA or not.
The Create Divi Extension tool (this repo) has been created to help you set up a development environment ASAP for developing custom Divi builder modules.

Kindly let us know if you have other questions :).


*.drv is not valid

I saw this kind of error the third time, it only shows itself on Travis and in some other cases that I do not know understand

I am talking about this:

https://travis-ci.org/NixOS/nixpkgs/builds/48054896
error: cannot import ‘/nix/store/zapaadgbk6pbfbxdiq1pk6ax62dra3b0-nixui/default.nix’, since path ‘/nix/store/01rsibv0w4h8yhcm8fv0qfv0p3sw655v-nixui.drv’ is not valid, at "/home/travis/.nox/nixpkgs/pkgs/tools/package-management/nixui/default.nix":13:12

and this fixes it:
https://github.com/NixOS/nixpkgs/pull/5921
- nodePackages = import "${pkgs.path}/pkgs/top-level/node-packages.nix" {
+ nodePackages = import ../../../top-level/node-packages.nix {

Exactly the same error happened before with Zed, and there was the same fix.

in NixUI I am experimenting with configurations and I got the same error when this is set: nixpkgs.config.chromium.enablePepperFlash = true;
the code:
https://github.com/NixOS/nixpkgs/blob/9343f6f4612301f9954ada94252701a2304c271c/pkgs/applications/networking/browsers/chromium/plugins.nix#L89

      getNix = plugin: import "${plugin}/nix-support/chromium-plugin.nix";

and the error seems very similar:
while evaluating ‘getNix’ at "/home/matej/workarea/nixpkgs/pkgs/applications/networking/browsers/chromium/plugins.nix":88:16, called from undefined position:
cannot import ‘/nix/store/77vm2bqpphps5d8ij578iwp32a965ws2-chromium-binary-plugins-flash/nix-support/chromium-plugin.nix’, since path ‘/nix/store/jy2i9pjxmjwdnix8v0r1282gpd0l3wdn-chromium-binary-plugins.drv’ is not valid, at "/home/matej/workarea/nixpkgs/pkgs/applications/networking/browsers/chromium/plugins.nix":88:24

Probably on Hydra/Travis we never set nixpkgs.config.chromium.enablePepperFlash = true;, so it never gets there, therefore there is no error, building chromium or plugin separately works as expected.
I would really like to know what is going on, so I can fix it (at least this chrome plugin problem).

When you do "${pkgs.path}/bla", it will cause Nixpkgs to be copied to the Nix store. As a workaround, you can say "${builtins.toString pkgs.path}/bla" instead. However, there is really no reason to use pkgs.path inside Nixpkgs itself since you can use a relative path.

@edolstra  thanks for the explanation, and I fixed nixui, it was some other issue with configuration reading. Closing now.


Polyglot Fonts Added to Core and Other Modules by Default

Polyglot seems to add its fonts to core and other modules without setting it to do so.
Default Language is left blank.
Add Fonts to Module Settings is None.
Add Polyglot's Fonts to Core is not checked.
Using Foundry v10.285, the rune/fantasy fonts that Polyglot uses appear in the journal font list, and in modules like Dice So Nice.

Game System: Pathfinder 2E v4.0.3
Polyglot Version 1.8.1
Are you using Babele? No

It's supposed to remove the fonts when you toggle Add Polyglot's Fonts to Core off, try toggling it on and off to remove them altogether. That said, I can see why you wouldn't want this on by default and will change it to be off by default.

This has been closed, but is not fixed.
I still see Polyglot fonts in the journal and Dice So Nice, with "Add Polygot's Fonts to Core" unchecked.
I tried checking it, saving, unchecking, saving, and looking again, but the fonts were still in the journal and DSN.
Foundry 10.285
System PF2E 4.0.6
Polyglot 1.8.3
Babele no (what is this?)


Upgrade to ghc-lib-parser-ex-<IP_ADDRESS>

<IP_ADDRESS> released 2020-03-17

New module Language.Haskell.GhclibParserEx.GHC.Driver.Flags

Export Bounded instance for Language
(https://github.com/shayne-fletcher/ghc-lib-parser-ex/issues/30)

Thanks!


Self-hosted models on remote clusters, including on-demand from AWS, GCP, Azure, Lambda

New modules to facilitate easy use of embedding and LLM models on one's own cloud GPUs. Uses Runhouse to facilitate cloud RPC. Supports AWS, GCP, Azure, and Lambda today (auto-launching) and BYO hardware by IP and SSH creds (e.g. for on-prem or other clouds like Coreweave, Paperspace, etc.).
APIs
The API mirrors the HuggingFaceEmbedding and HuggingFaceInstructEmbedding, but accepts an additional "hardware" parameter:
from langchain.embeddings import SelfHostedHFEmbeddings, SelfHostedHuggingFaceInstructEmbeddings
import runhouse as rh
gpu = rh.cluster(name="rh-a10x", instance_type="A100:1")
hf = SelfHostedHFEmbeddings(model_name="sentence-transformers/all-mpnet-base-v2", hardware=gpu)

# Will run on the same GPU
hf_instruct = SelfHostedHuggingFaceInstructEmbeddings(model_name="hkunlp/instructor-large", hardware=gpu)

The rh.cluster above will launch the A100 on GCP, Azure, or Lambda, whichever is enabled and cheapest (thanks to SkyPilot). You can specify a specific provider by provider='gcp', as well as use_spot, region, image_id, and autostop_mins. For AWS you'd need to just switch to "A10G:1". For BYO cluster, you can do:
gpu = rh.cluster(ips=['<ip of the cluster>'],
                             ssh_creds={'ssh_user': '...', 'ssh_private_key':'<path_to_key>'},
                             name='rh-a10x')

Design
All we're doing here is sending a pre-defined inference function to the cluster through Runhouse, which brings up the cluster if needed, installs the dependencies, and returns a callable that sends requests to run the function over gRPC. The function takes the model_id as an input, but the model is cached so only needs to be downloaded once. We can improve performance further pretty easily by pinning the model to GPU memory on the cluster. Let me know if that's of interest.
Testing
Added new tests test_self_hosted_hf.py which mirror test_huggingface.py. Tests all pass on Lambda Labs (which is suprising, because the first two test_huggingface.py tests are supposedly segfaulting?). We can pin the provider used in the test to whichever is used by your CI, or you can choose to only run these on a schedule to avoid spinning up a GPU (can take ~5 minutes including installations).
WIP

[x] Introduce SelfHostedLLMs (and perhaps SelfHostedModel parent to remove duplication and introduce greater extensibility)
[ ] Add tutorials
[x] Implement chat-your-data tutorial with Self-hosted models - https://github.com/dongreenberg/chat-your-data

[ ] More testing to do

[ ] Refactor SelfHostedHuggingFaceEmbeddings to just be SelfHostedEmbeddings, and rename SelfHostedHFPipeline to SelfHostedLLM.

Something strange happened when I merged in the upstream, but we're all good. Tests all pass and added those tutorials!

Oh, didn't realize I need to update the poetry lock, doing that now.


Names of the terminals are no longer displayed

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

VS Code Version: 1.64.2
OS Version: Linux x64

Steps to Reproduce:

Open the terminal tab
Create a new terminal (so now we have 2 terminals)
Close the terminal tab without killing the terminals
Reopen the terminal tab

After the last update of VS Code, the names of the terminals are no longer displayed when I reopen the terminal tab.

Possibly related:  https://github.com/microsoft/vscode/issues/139868 and https://github.com/microsoft/vscode/issues/139276.

Fixes itself (refreshes) when you click on a terminal tab


set pod after migration

Description
This PR...

Fixes: #5971

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[x] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[x] Major
[ ] Minor
[ ] Trivial

Screenshots (if appropriate):
How Has This Been Tested?

tested in a nested environment
two pods in a zone
one cluster per pod
two hosts per cluster
systemVMs can't be migrated but won't be instantiated in disabled pods, so restart with cleanup of networks/destroy systemVMs takes care of the "migration"
userVM migrate fine and the pod in the vm record is updated
verified that the pod can be deleted after clearing it of VMs and hosts/clusters.

@blueorangutan package

@sureshanaparti a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 2540

@blueorangutan test

@blueorangutan test

@rohityadavcloud a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

Trillian test result (tid-3272)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 38338 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr5972-t3272-kvm-centos7.zip
Smoke tests completed. 92 look OK, 0 have errors
Only failed tests results shown below:

Test
Result
Time (s)
Test File

Migrated VM to host in another pod, and verified the new pod updated in the VM record.

Thanks @sureshanaparti @DaanHoogland @rohityadavcloud. The PR looks like it does automatically what I did manually to get past the issue, and the test case above confirms that the issue is resolved.


Verify-DNS-Functionality... Fixed the dcdiag syntax + others

Updated the dcdiag command to contain the proper characters as well as fixed the position of the / so that it would run properly without a syntax error. After making that update I found several other places where commands to be executed contained the markdown formatting that was ignored when putting text between the ` marks.
Honestly just didn't want someone else putting this extra text in the command like I did before I really understood what was going on, so figured I would fix it.

Hi @drewjanderson ,
Thanks for taking care of that. We, and future readers of this topic, appreciate it!
Thanks,
Corey


bug: Trying to open properties from blank area of a folder doesn't open window

Description
Read steps to reproduce for a clearer understanding.
Side note when right clicking a folder and opening properties it will open two windows of the same folder just clicked on.
Steps To Reproduce

Go to a folder
Right click empty space
Click properties
See window doesn't open

Steps to fix
?
Files Version
<IP_ADDRESS>
Windows Version
10.0.22621.675
Relevant Assets/Logs
Haven't been generated.

@yaichenbaum I identified the line of code to fix for this bug. However, it would be nice if the Show Properties command in the context menu corresponded to that in the action bar. It should be possible to open the properties from the quick actions when no element is selected. Is this the expected behavior?

Not currently but I don't see why it shouldn't be supported.


Remove fastcrypto: take 2

Applies on top of fix/integration and supersedes https://github.com/eqlabs/bullshark-bft/pull/37. Compiles, but haven't run the tests yet. I moved the changes from the former PR and applied some new ones where applicable.
Also, there's a change I didn't understand in the former PR - the narwhal.yaml one, so be extra vigilant about that bit.

I've managed to reproduce the CI failure locally; not sure what's up with test_determinism.


Change fpclassify() to std::fpclassify()

This fixes the compiler errors "'fpclassify' was not declared in this scope":
projection.cpp: In function 'void lonlat2tile(double, double, int, long long int*, long long int*)':
projection.cpp:25:32: error: 'fpclassify' was not declared in this scope
  int lat_class = fpclassify(lat);
                                ^
projection.cpp:25:32: note: suggested alternative:
In file included from projection.cpp:5:0:
/usr/include/c++/5/cmath:581:5: note:   'std::fpclassify'
     fpclassify(_Tp __x)
     ^
projection.cpp: In function 'void epsg3857totile(double, double, int, long long int*, long long int*)':
projection.cpp:77:30: error: 'fpclassify' was not declared in this scope
  int iy_class = fpclassify(iy);
                              ^
projection.cpp:77:30: note: suggested alternative:
In file included from projection.cpp:5:0:
/usr/include/c++/5/cmath:581:5: note:   'std::fpclassify'
     fpclassify(_Tp __x)
     ^
Makefile:84: recipe for target 'projection.o' failed
make: *** [projection.o] Error 1
make: *** Waiting for unfinished jobs....

Thanks!


Fix permanently disabled optimizations in CMake

Macro CHECK_CXX_COMPILER_FLAG() will not update optimization variables if those were already defined.

Why this was merged? Removed code just set default state of variables used in compilation.
If compiler flag is supported than variable is correctly updated (otherwise nobody included me would have no SSE support on cmake build).
So I would really like to see scenario where this code change solve problem.

Default is always false, no need to set explicitly.
If some place cannot set a flag without these lines, that place must be fixed.

Default is always false

The default seems to be empty (which is handled like FALSE).
Old cmake output with wrong values for HAVE_AVX etc.:
[...]

[...]
New cmake output (note the empty value of `HAVE_NEON`:

-- HAVE_AVX: 1
-- HAVE_AVX2: 1
-- HAVE_FMA: 1
-- HAVE_SSE4_1: 1
-- MARCH_NATIVE_OPT: ON
-- HAVE_NEON:
-- Link-time optimization: FALSE
[...]

I think it would be better to delay merging of new non-critical pull requests at least one day to allow comments by other contributors. In this case there was a build error which required a fix of course, but there might have been a better solution.

That cmake output code must learn how to print empty vars.

So I would really like to see scenario where this code change solve problem.

When doing a clean cmake build these variables were not set by CHECK_CXX_COMPILER_FLAG() macros. See here:
https://stackoverflow.com/questions/25451254/getting-cmake-check-cxx-compiler-flag-to-work/49297190#49297190

there might have been a better solution

What do you have in mind?


feat: behavior of the list and the cards has been modified

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 69.697%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
100

Relevant Lines:
131

💛  - Coveralls


Allow existing password to be used instead of generated one

It might be useful to allow users to specify the initial password for a seed.
This would allow migration from another password database.

True. I manually filled in .otp from my Keychain on my old Macbook. An argument to query for the password (rather than auto-generate) would enable a user to go track down the password and then properly enter/format that into the .otp file.

Oh. Maybe .otp could have a # option: ask as an configuration choice (in addition / alternative to a command line argument). Second, when prompting for a password,  could tell it to generate the password. Something like:
Password for $seed? [empty to create a new password] :
Thoughts/preference?

I was thinking that of a separate setup operation, e.g.
otp.py --init-password seed [--force]
This would check for an existing password, and if not found, allow the user to provide one.
Report an error if one was found and --force not used.
Also it could always prompt for a password if none exists; empty reply means generate.

How about --ask-password seed and it fails if a password is already present. Thus, no need for a --force solution.
I do like the idea the prompting, and then generate if [return] is pressed (rather than silent generation). (and maybe error if anything entered is less than (say) 10 characters)

I added --force to allow a user to correct a stored password.

Gotcha. I have an aversion to --force due to Subversion development when we grew --force options on many commands, each of which did something different. Eventually, we decided to deprecate --force and go with descriptive options like (say) --create-parents instead.
Given that, I'd suggest something like --update-password or just --update (and --ask) for command/control options.
Thanks!

Given that the password may not be recoverable if it is replaced, I think it would be best if it required an extra option to allow an existing one to be overwritten.


Testing ECONNREFUSED

When using nock one can test server http errors.
Is there any way to test request errors like ENOTFOUND or ECONNREFUSED using nock ?

You could use .replyWithError(err) to simulate that. You would have to create a mock error object with the .code attribute, etc.
I'm keeping this issue open, since I think nock could provide an easier way to reply with those types of errors.

@pgte like this:
			nock('http://ww.cantconnecttothis.addres/')
				.get('feed')
				.replyWithError({
					code: 'ENOTFOUND',
					errno: 'ENOTFOUND',
					syscall: 'getaddrinfo',
					hostname: 'www.skdhsdk.com'
				});

Doesn't seems to work.

I wrote a project that starts servers for this in Python: http://github.com/kevinburke/hamms
The easiest way is simply to connect to a port where nothing is listening. ETIMEDOUT you can generally use <IP_ADDRESS> and set a timeout, though I guess nock can just throw errors on its own if you want.

There's a problem with replyWithError: it doesn't support .delay option. I mean that mocked requests with replyWithError reply immediately with an error regardless of the delay value.

@1999 could you please create a separate issue for this?

@redben what's the status of this?

@filipedeschamps could you please elaborate?

@pgte I can also PR this if you think that's unexpected behaviour

@1999 PR is  welcome :)

@pgte sorry, I've just re-run tests and acknowledged that everything is okay. The problem was in old nock version used in webdriverio.

I'm closing this for lack of feedback. Please reopen if you have more info.

Sorry didn't pay attention to notifications.

For ECONNREFUSED, I ended up disabling nock and passing a url to the unit under test with a port that I know is closed (http://localhost:{closed-port} )
For ENOTFOUND i set the url to a random hostname.

So basically these two can be tested without nock. Thanks anyway !

Sorry didn't pay attention to notifications.

For ECONNREFUSED, I ended up disabling nock and passing a url to the unit under test with a port that I know is closed (http://localhost:{closed-port} )
For ENOTFOUND i set the url to a random hostname.

So basically these two can be tested without nock. Thanks anyway !


gomod: upgrade yaml package from v2 to v3

Close #2085.

Indentation issue is still there, but closed unmerged due to the lack of activity. We can create out own fork with fix, but I'm not sure whether we need one more dependant fork. The issue is not critical, IMO.


Adding Single Config File + Update DID-Method package to accept SideTreeNodeConfigurations as Parameter

This PR hooks up the config file inside the dashboard package to a single .env file.
Since NextJS is handling the loading of environment variables it is important to understand this part of the documentation: https://nextjs.org/docs/basic-features/environment-variables#exposing-environment-variables-to-the-browser
Any environment that has NEXT_PUBLIC_ at the start of its name WILL be loaded into the client.
If the environment variable does not include NEXT_PUBLIC_, it will only be available inside the Node.js environment. The keys in the config file will still come through on the client, however, their values will always be undefined.
It also updates the did-method package so the dashboard package can pass in the Sidetree Node Configurations vs loading from the JSON file.

Please ensure this will work with ganache / elem and not just the test node.

Hey @OR13! I have confirmed that the env file works with both ganache/element and the side tree test node.
While running both dev options I was able to successfully create a wallet, DID and resolve the DID. I could also see the transactions/operations.


This program blows up in jruby. I guess it's something in Celluloid::Conditions

I started fiddling with celluloid and i had this trouble with this little experiment.
#jruby version: jruby-<IP_ADDRESS>

  require 'rubygems'
  require 'celluloid/autostart'
  require 'pry'

  module Enumerable

  class ComutativeReducerActor
    include Celluloid

    def initialize enumerable, reducer
      @enumerable = enumerable
      @n_active_actors = 0
      @available_actors = []
      @reducer = reducer
    end

    def wait_for_reduction
      @condition = Celluloid::Condition.new
      Actor.current.async.reduce
      result = @condition.wait 9000000
      result
    end

    def reduce
      if @n_active_actors > 4
        return
      end
      if @enumerable.size == 1 && @n_active_actors == 0
<EMAIL_ADDRESS>        return
      elsif @enumerable.size >= 2
        pair = @enumerable[0..1]
        @enumerable = @enumerable[2..-1]
        @enumerable ||= []
        process_pair pair
        Actor.current.async.reduce
      end
    end

    def process_pair pair
      @n_active_actors = @n_active_actors + 1
      reducer = \
      if @available_actors.empty?
        SingleReducer.new pair: pair, reducer: @reducer, parent: Actor.current
      else
        a = @available_actors.first
        @available_actors = @available_actors[1..-1]
        @available_actors ||= []
        a.tap do |a|
          a.pair = pair
          a.parent = Actor.current
        end
      end
      reducer.async.reduce
    end

    def add_new_value value, actor
      @enumerable << value
      if (@enumerable.size / 4) > @available_actors.size
        @available_actors << actor
      else
        actor.terminate
      end
      @n_active_actors = @n_active_actors - 1
      Actor.current.async.reduce
    end
  end

  class SingleReducer
    include Celluloid
    attr_accessor :pair
    attr_accessor :parent

    def initialize pair: nil, reducer: nil, parent: nil
      @pair = pair
      @reducer = reducer
      @parent = parent
    end

    def reduce
      result = nil
      if @pair.size == 1
        result = @pair.first
      else
        result = @reducer.call @pair.first, @pair.last
      end
      @parent.async.add_new_value(result, Actor.current)
    end
  end

  def comutative_reduce &reducer
    reducer = ComutativeReducerActor.new self, reducer
    val = reducer.wait_for_reduction
    reducer.terminate
    val
  end
  end

  puts ([1,2,4,5,6]*100).comutative_reduce{|a,b|
    a * b
  }

Error:
E, [2015-09-19T21:20:12.406000 #46502] ERROR -- : Actor crashed!
ArgumentError: wrong number of arguments (1 for 0)
/Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/system_events.rb:6:in handle_system_event'     /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/actor.rb:123:inblock in initialize'
org/jruby/RubyProc.java:308:in call'     /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-essentials-<IP_ADDRESS>/lib/celluloid/internals/handlers.rb:38:incall'
/Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-essentials-<IP_ADDRESS>/lib/celluloid/internals/handlers.rb:20:in handle_message'     /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/actor.rb:283:inhandle_message'
/Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/actor.rb:156:in block in run'     /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/timers-4.1.1/lib/timers/group.rb:69:inwait'
/Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/actor.rb:152:in run'     /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/actor.rb:131:inblock in start'
/Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-essentials-<IP_ADDRESS>/lib/celluloid/internals/thread_handle.rb:14:in block in initialize'     /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/actor/system.rb:78:inblock in get_thread'
org/jruby/RubyProc.java:308:in call'     /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/group/spawner.rb:53:inblock in instantiate'
Celluloid::TaskTerminated: task was terminated
suspend at /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/task.rb:75
suspend at /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/task.rb:11
suspend at /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid.rb:139
wait at /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/condition.rb:58
wait_for_reduction at comutative_reduce_actors.rb:20
public_send at org/jruby/RubyKernel.java:1823
dispatch at /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/calls.rb:28
dispatch at /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/call/sync.rb:16
block in dispatch at /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/cell.rb:50
block in task at /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/cell.rb:76
block in task at /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/actor.rb:339
block in initialize at /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/task.rb:44
block in create at /Users/pedro/.rvm/gems/jruby-<IP_ADDRESS>/gems/celluloid-<IP_ADDRESS>/lib/celluloid/task/fibered.rb:14

Hello, I made very small changes to this program, and it runs on current JRuby <IP_ADDRESS>.
Here is the program I ran: https://gist.github.com/olleolleolle/ddd12626d8651b256531b97880334620
Changes made:

Removed the celluloid/autostart  which is represented by the automatically-enabled BACKPORTED mode
Rubocop auto-correct
assigned the result variable, and then putsing it

Output now:
I, [2017-02-25T19:53:30.368000 #4979]  INFO -- : Celluloid 0.17.3 is running in BACKPORTED mode. [ http://git.io/vJf3J ]
10498425511251795460213018874278345341399548969203826401953216956503410439129480752471812805408412727108818480063503708244128179108456693760000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000


Add a workaround for EmptyEndpointException with HealthCheckedEndpoint

Motivation:
Even if an EndopintGroup resolves the initial endpoints,
EndpointSelector could continue to return a null endpoint.
See https://github.com/line/armeria/pull/3978 for the details.
The bug has been fixed in Armeria but some users who use Armeria 1.13.4
could see EmptyEndpointException and difficult to apply a workaround.
Because a CentralDogma client creates a HealthCheckedEndpoint
internally that users can't access.
Modifications:

Wait for the initial endpoints before returning a new client.

Result:

You no longer see an EmptyEndpointException with your CentralDogma client.

There are new features in the master branch. Let me reopen a PR against 0.53.0 branch.


Cmd-P not opening preferences window

default is Ctrl+Alt+P.. I changed to Meta+P and command worked..


AeFTFace did not understand #newCairoFontFace

It seems I recently introduced this error:
AeCanvasTest
 ✗ #testFormSelector (0ms)
Instance of AeFTFace did not understand #newCairoFontFace
AeFTFace(Object)>>doesNotUnderstand: #newCairoFontFace
AeCanvas>>scaledFontForFace:size:
AeCanvasTest>>renderLigatureTextWithoutHarfbuzz
AeCanvasTest(AePixelMatchTest)>>actualForm
AeCanvasTest(AePixelMatchTest)>>newPixelComparison
AeCanvasTest(AePixelMatchTest)>>testFormSelector ...newPixelComparison
AeCanvasTest(TestCase)>>performTest
AeCanvasTest(AePixelMatchTest)>>performTest

It seems to be cause by a missing requirement in the Baseline (from cairo to freetype).
Why? Load in P12:
Metacello new
        baseline: 'Alexandrie';
        repository: 'github://pharo-graphics/Alexandrie:dev/src';
        load.

Get:
Warning: Package Alexandrie-Cairo depends on the following classes:
  AeFTFace
You must resolve these dependencies before you will be able to load these definitions:
  AeFTFace>>#newCairoFontFace

Fixed


[Bug]: Button "Remove" in Text-Color and Background-Color not working

What happened?
Hello!
Button "Remove" is not working. Also deselecting of Alignment.
See gif. Thanks!

Version
v17.5.1
Angular Version
v17
What browsers are you seeing the problem on?
Chrome
Link to reproduce
No response
Relevant log output
No response
Willing to submit a PR?
None

Should be fixed in v17.5.3


OTR failing intermittently

I'm experiencing crippling issues on 4.4.4 with 14.0.1 OTR against a server that had been previously working fine. Occasionally OTR will refuse to work with specific contacts even after rebooting the phone and repeatedly ending/starting new chats. The icon just spins forever and never responds

@eighthave that is related to you being offline/disconnected... they do need to be queued properly... the date is being nulled out when the send fails i believe. we should queue instead.

Seeing this with ChatSecure v14.2.1. If both contacts force encryption, it seems to work.


add Amplication

By submitting this pull request, I promise I have read the contribution guidelines twice and ensured my submission follows it. I realize not doing so wastes the maintainers' time that they could have spent making the world better. 🖖
⬆⬆⬆⬆⬆⬆⬆⬆⬆⬆
Amplication is an open‑source development tool. It helps professional Node.js developers develop quality Node.js applications without spending time on repetitive coding tasks.
Amplication auto-generates backend apps built with TypeScript and Node.js, and a client built with React.

https://github.com/sindresorhus/awesome-nodejs/blob/main/contributing.md

updated @sindresorhus


Correlation Mapping with FetchStrategy = JOIN does not work with joinable Correlation Result

Do you have some example code?


Research RAG

Considering that we are planning to implement some form of LLM-based search using RAG tech, we are looking to gain more knowledge into this technology, its capabilities and limitations.
Research goals:

Gain an understanding of RAG technologies
Get insight into capabilities and limitations of the technology
Overview of current technologies

Timebox: 16 hrs

Hey there , can I in any shape or form contribute to this research project?
Would love to work on this!

@havkerboi123 welcome to contribute to the project. Do you have specific ideas? Note: This is a research spike for implementing RAG functionality into the project.

I can help out on the research side , maybe I'll prepare a research document and share it with you? What do you say?

Dropped you a mail , let's discuss this further!


misc changes

What exactly does the PR do?
This allows you to add a default manager if the plugin manager is not found.
This adds a 100ms delay inbetween opening menus to prevent issues with multiple menus opened at the same time.
This changes the reflection to scan for inherited fields instead of just declared fields from a class.
Is there anything I need to consider when testing?
No, I have tested these all locally and with plugins using ryseinventory
If related to an error, please link it:
N/A
If possible, illustrate your PR with a small demo:
N/A
I agree with the following:

[ x ] The code runs without problems
[ x ] I myself have tested it
[ x ] The code was written by myself personally and not copied by anyone

I'll take a look at it this weekend. Thank you


Replacing images and adding some text on who uses Extend

Ignore the button that looks out of what. It should be fine when merged.
@woloski @tjanczuk updated images.