Allow specifying interface implements clauses for the static side of classes

Search Terms
class static side syntax interface type expression
Suggestion
Currently, you can only specify the static side interface of a class with a declaration. From the handbook:
const Clock: ClockConstructor = class Clock implements ClockInterface {
  constructor(h: number, m: number) {}
  tick() {
      console.log("beep beep");
  }
}

When I first wanted to do this (before looking at the docs), I tried to do it in this fashion:
class Clock: ClockConstructor implements ClockInterface {
  ...
}

And I was surprised to see that it didn't work. My proposal is to make this a valid syntax as it's more intuitive and understandable.
I believe that forcing class expressions conflicts with TypeScript's design goals:

Produce a language that is composable and easy to reason about.

Why use a class expression when there is no need for it? Why change your actual JavaScript logic for something that exists only in TypeScript and not in your production code.
Use Cases
Anywhere you need to set the interface of the static side of a class without having a need to specify it as an expression.
Examples
Take the example from the playground:
interface ClockConstructor {
  new (hour: number, minute: number);
}

interface ClockInterface {
  tick();
}

class Clock: ClockConstructor implements ClockInterface {
  constructor(h: number, m: number) {}
  tick() {
      console.log("beep beep");
  }
}

Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

Ref #14600
We discussed #14600 at length and agreed that the syntax static T in the implements list of a class would be a reasonable place to allow this:
interface X {
  x: string;
}
interface Y {
  y: string;
}
interface Z {
  z: string;
}

// OK example
class C implements Y, static X, Z {
  static x: string = "ok";
  y = "";
  z = "";
}

// Error, property 'x' doesn't exist on 'typeof D'
class D implements static X {
}

Why not static members in interfaces?
#14600 proposed the syntax
interface X {
  static x: string;
}

This is problematic for a couple reasons.
First, it seems to create a totally meaningless thing:
interface X {
  static x: string;
}
function fn(arg: X) {
  // arg has... no members?
}
// Is this a legal call?
// There doesn't seem to be any reason to reject it,
// since 'fn' can't illegally access anything that doesn't exist
fn({ });

Second, there would be no way to access a static member through an interface type that declared it!
interface X {
  static x: string;
}
function fn(arg: X) {
  // How do I get to ctor(arg).x ?
}

You would need to have some auxiliary keyword to turn an interface into the static version of itself:
interface X {
  static x: string;
}
// Syntax: ????
function fn(arg: unstatic X) {
  arg.x; // OK
}

Simply moving the static logic to the class syntax makes this substantially simpler, and (critically) allows classes to implement types that weren't written using the hypothetical interface I { static property: T } syntax.
Why implements static T, not static implements T ?
In the presumably-usual case of one instance and one static heritage member, this is substantially cleaner:
class WidgetMaker implements Factory, static FactoryCtor {
  // ...
}

vs
class WidgetMaker implements Factory static implements FactoryCtor {
  // ...
}

@RyanCavanaugh I understand your points and agree with all of them. But I don't understand what's the issue with my proposed syntax without the static keyword. I mean, instead of this:
class C implements Y, static X, Z { }

Why not this:
class C: X, Z implements Y { }

Your syntax could be read the correct way like this:
class C implements (Y), static (X, Z)

but due to the commas, it could also be read like this:
class C (implements Y), (static X), (Z)

which would make Z appear out of place. It could even be read like this:
class C implements (Y, static X, Z)

as if C implements Y, Z and a static X which makes no sense. I think the issue here is that the comma is used as both a separator for symbols and keywords.
My proposal has a clear separation of the static and instance sides:
class |C: X, Z| implements |Y, T| { ... }
------|static--------------|instance-----

Yours doesn't:
class |C| implements |Y, T|, static |X, Z| { ... }
------|static--------|instance------|static-------

I just think my proposal leaves less ambiguity.
Some other benefits:

No use of the static keyword. It was designed for usage inside the class body and if you avoid using it, you'll avoid assigning another TypeScript-only meaning to it
Members of X and Z are visually closer to C, which makes more sense since you'll be using C.memberOfX and C.memberOfZ
It's consistent with other keywords. You've got let foo: string and const bar: number. Adding class C: X {} simply follows that pattern
It's shorter

And to clarify, I'm talking about syntax only. No functional differences.

: in TypeScript always means "is of type", but implements has a different meaning ("is assignable to"). IOW the implied semantics of : are
interface P {
  x: number;
}
class C: P {
  static x: number;
  static y: number;
}
C.x; // OK
C.y; // Not OK; only members of P are visible

the same way that this works (disregarding excess property checks):
interface P {
  x: number;
}
const C: P = { x: 0, y: 0 };
C.x; // OK
C.y; // Not OK; only members of P are visible

I see. To clarify, would static act as a modifier? If I have:
class C implements Y, static X, Z { }

I should read it as "C implements interface Y, interface X as static, and interface Z" instead of "C implements interface Y and interfaces X and Z as static," right?
When I initially read your comment, I thought static would act like implements and you list items after it. Instead, it would act as a modifier to the items of implements?
So if I have an interface X that must be type-checked in both the instance side and the static side, I would do:
class C implements X, static X { }

Is that right?

I don't really follow Ryan's goals in his second post here.

it seems to create a totally meaningless thing:  // arg has... no members?

If you made an class with only static methods then you couldn't do much with instances of it either.

there would be no way to access a static member through an interface type that declared it

I don't think that's the point.  The reason I want to see static in an interface is to avoid needing to split a mix-in definition:
interface Widget {
  static create(): Widget;
  x: number;
}

class A implements Widget {
  static create(): A { ... }
}

function factory(clazz: {create(): Widget}): Widget {
  const ret = clazz.create();
  ret.x = 10;
  return ret;
}

This is cleaner than the alternative, where I'd have to have separate a WidgetConstructor interface and static implement it.  That feels clunky and leads to the potential confusing cases @hdodov lists a few posts back, where there isn't really a "right" way to visually parse the sequence of keywords.

@thw0rted the constructor and the instance are two completely separate entities. In JavaScript, the API of one is not connected in any way to the API of the other. Because they have different APIs, they probably function differently as well. You can't use a constructor as an instance and vice-versa. Therefore it makes sense to define their types with two separate interfaces.
Your example could be rewritten as:
interface Widget {
  x: number
}

interface WidgetCtor {
  create(): Widget
}

class A implements Widget, static WidgetCtor {
  static create(): A { ... }
  x: number = 1;
}

I personally think that's better.

You say they're not connected in any way, but you still write both constructor (static) methods and instance methods inside the same class { } block, right?  That's what I'm saying in my previous comment.  There's a certain parallelism in the single-interface version, one interface that describes (a portion of) one class, that's lacking in the two-interface version you describe.
As for the static create() method of let obj: Widget, can't I call obj.constructor.create() if I want to?  I'm not an expert in how ES6 classes differ from constructor functions with prototypal inheritance, but I can say that this at least works in Chrome and Node, whether or not it's "correct".

@thw0rted Notice these two lines in your code:
interface Widget {
  static create(): Widget;
//     ~~~~~~~~~~~~~~~~~~
  x: number;
}

class A implements Widget {
  static create(): A { ... }
  x: number = 1;
}

function factory(clazz: {create(): Widget}): Widget {
//                      ~~~~~~~~~~~~~~~~~~
  const ret = clazz.create();
  ret.x = 10;
  return ret;
}

This repetition is exactly what we want to avoid - you defined static create in interface Widget, and have no way to reference that declaration to define the shape of clazz.

Don't forget that classes are just syntactic sugar. In the end, all static members appear on the class (constructor) itself, while the instance methods appear in its prototype.

ES6 already has first-class support in modern runtimes.
// In Chrome dev tools console
class XYZ { static a(){return 1;} }
let x = new XYZ();
"" + x.constructor; // "class XYZ { static a(){return 1;} }"

It might just be syntactic sugar once you're down in the guts of the engine, but all the seams have been fully plastered over when viewed from the outside.  The whole point of ES6 classes is to stop the dichotomy of "one constructor and one prototype".
I don't follow your last paragraph about "where instance member x is expected". An instance of a class that implements an interface with static properties would not have those properties, because that's not what static means.  Maybe a more concrete example would clarify your concerns?

Ryan, I take your point about duplication.  You're saying that having a separate name for the static/constructor interface allows us to reference it easily in the function parameter type.  The cost of your solution is adding a new keyword for "implements static" or similar, which introduces the ambiguities discussed in comment 3 above.
What if instead we could make a conditional type that took an interface with static properties, and returned an interface with only the static properties except now they're not static?  I've never had the knack for the type math needed to make complex transformations in the type space -- I won't bother Dragomir with an at-mention again, but he knows what's up -- but maybe it's possible today.  If not, maybe adding type operators to make it possible would be a useful contribution to the language.  Imagine:
interface Widget { static create(): Widget; x: number; }
type StaticShape<T> = ✨ ; // magic!

type WidgetConstructor = StaticShape<Widget>; // === interface { create(): Widget }

function factory(clazz: WidgetConstructor): Widget { ... }

Bonus points if the magic can turn a class with constructor(x, y, z) into a new(x, y, z) property, which has been a sticking point for factory-pattern for a while, too.  Of course, since I'm hand-waving the hard part here, I recognize that this could be completely impractical, but I figured it's worth asking.  And if it works, it has the virtue of avoiding new, potentially-ambiguous keywords while closely mirroring the existing (static class method) syntax.

ES6 already has first-class support in modern runtimes.

Yes, and it does exactly what I said. When you compile your ES6 class to ES5, the resulting code is pretty much what the browser does with a non-compiled ES6 class. Quoting MDN:

JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.

What modern browsers offer is a way to alter the constructor's prototype without actually assigning to it in your code. It's just a syntactic trick.

The whole point of ES6 classes is to stop the dichotomy of "one constructor and one prototype"

No, their point is to improve the syntax of working with "one constructor and one prototype."

An instance of a class that implements an interface with static properties would not have those properties

Yes, but we were talking about a hypothetical obj which is an object that is Widget-like, not a Widget instance. If you cram both static and instance members in one place, you can't use them separately:
let widgetLike = {}
widgetLike.x = 'foo' // should error

let widgetConstructorLike = {}
widgetConstructorLike.create = 42 // should error type '42' is not assignable to type '() => Widget'

Could you show how you would implement the types of widgetLike and widgetConstructorLike with an interface like this:
interface Widget {
  static create(): Widget;
  x: number;
}

How do you tell TS that widgetLike should have instance properties, while widgetConstructorLike should have only static properties? You can't do it like this:
let widgetLike: Widget = {}
let widgetConstructorLike: Widget = {}

...because those are identical types. Separating the two sides solves this problem:
interface Widget {
  x: number
}

interface WidgetCtor {
  create(): Widget
}

let widgetLike: Widget = {}
widgetLike.x = 'foo' // error

let widgetConstructorLike: WidgetCtor = {}
widgetConstructorLike.create = 42 // error

The cost of your solution is adding a new keyword for "implements static" or similar, which introduces the ambiguities discussed in comment 3 above.

Actually, it doesn't introduce ambiguities. I simply misinterpreted Ryan's comment. The static keyword would be a modifier to a member of the implements list. It simply denotes that the implemented interface should be part of the static side. Example:
interface Foo { f: number }
interface Bar { b: string }

// Foo and Bar are forced on the instance
class C implements Foo, Bar {
    f = 42
    b = 'hello'
}

// Foo and Bar are forced on the constructor
class C implements static Foo, static Bar {
    static f = 42
    static b = 'hello'
}

To me, that's as clear as day.

their point is to improve the syntax of working with "one constructor and one prototype."

OK, I definitely just assumed what "their point" is and have no particular information to back it up.  If thinking of JS new-ables as having two distinct pieces is the right mental model, then so be it.

You can't do it like this:

let widgetLike: Widget = {}
let widgetConstructorLike: Widget = {}

See, to my eye that seems entirely obvious -- of course you can't just call them both Widget.  I think we're arguing over a pretty minor point-of-view issue.  I see a single dual-nature declaration as more natural, because classes are already dual-nature, and you see two single-purpose declarations as more natural because that allows for more flexible use.
That's what led me to the suggestion I made in my second comment this morning, addressed to Ryan, about how it would be nice to have a "magic" StaticShape conditional type.  But as I say, I don't know how to make it, or if it's currently possible, or if it's even feasible to eventually make possible.  And it would certainly be more complex for this use case (i.e. referencing the shape of the constructor function) than simply using two different interfaces in the first place.

OK, I definitely just assumed what "their point" is and have no particular information to back it up.

You should try to avoid that.

I see a single dual-nature declaration as more natural, because classes are already dual-nature

Yes, but classes are dual-nature because their sole purpose is to ease the developer in defining the constructor interface and the interface of the object it creates. TypeScript isn't interested in describing classes (as it should), it's interested in describing those two interfaces. This makes sense because classes are just a syntax tool that allows the developer to define everything in one code block, while the constructor and the instance contain the actual logic.

you see two single-purpose declarations as more natural because that allows for more flexible use

We can just agree to disagree, but the TS developers have to make a choice. Flexibility means handling more use cases, which in turn means TypeScript is more useful. Isn't this more valuable than saving a couple lines of code?

I came up with two more use cases that also cover generics and inheritance and revealed some more open questions. I was trying to encode some of Haskells monad-instances, to see how typesafe I can get them with TypeScript.
Just for reference, here is a simplified version of Haskells monad type-class:
class Monad m where
  pure :: a -> m a
  bind :: m a -> (a -> m b) -> m b

Naively, I started with:
interface Monad {
  pure (x: a) : Monad
  bind (f: (x:a) => Monad) : Monad
}

The pure-method is similar to a constructor; it should be static. So, I tried to split the interface into its static and dynamic parts:
interface Monad {
  bind (f: (x:a) => Monad) : Monad
}
interface MonadStatic {
  pure (x: a) : Monad
}

Next, I tried to implement the Identity-monad.
class Identity implements Monad {
  private value : a

  constructor (value: a) {
    this.value = value
  }

  static pure (x: a) : Monad{
    return new Identity(x)
  }

  bind (f: (x: a) => Identity) : Identity {
    return f(this.value)
  }
}

What's still missing is the static interface instantiation. However, the trick from the handbook does not work here, because MonadStatic is generic in a:
const Identity:MonadStatic = class implements Monad { /*...*/ }

So here we are. With the syntax proposed above, I think it should be possible to fully instantiate the identity-monad:
class Identity implements Monad, static MonadStatic { /*...*/ }

However, the signature of pure in the interface and implementation is still different. This is because the type-variable a is bound differently: once by the interface-declaration and once by the method-implementation.

Next, I tried to encode the Maybe-monad. The challenge here is that a Maybe offers two constructors. I implemented these as two classes. This made sense because the bind-method also behaves differently on either construction. The pure-method, on the other hand, belongs to neither of those classes. I moved it into a common parent-class. Let's fast-forward to the final implementation:
abstract class Maybe implements static MonadStatic {

  static pure(x: a) : Maybe {
    return new Just(x)
  }

}

class Nothing extends Maybe implements Monad {
  constructor () {
    super()
  }

  public bind (f : (x : a) => Maybe) : Nothing {
    return new Nothing()
  }
}

class Just extends Maybe implements Monad {
  private value : a

  constructor (value : a) {
    super()
    this.value = value
  }

  public bind(f : (x : a) => Maybe) : Maybe {
    return f(this.value)
  }
}

I think the separation of static and dynamic interfaces resolves rather elegant in this example.
However, that raises the question if child-class-constructors should inherit the properties of their parent's constructors. In my example, exposing Just.pure as a public interface would be undesired.

@vzaidman's suggestion seems to be the only working workaround. However, it will only work in scenarios such as this one: the static field does not depend on the type of Props or State and it's optional.
Having an equivalent of implements applied to static fields would come in handy in other scenarios:
The static field is generic
The getDerivedStateFromProps React used by React is static, but it does need the type arguments provided when MyComponent is defined.
class MyComponent extends React.Component<Props, State> {
  static getDerivedStateFromProps(nextProps: Readonly<Props>, prevState: State): Partial<State> | null { /* ... */ }
}

Currently, getDerivedStateFromProps can be of any type. This is prone to human errors.
The static field is mandatory
Imagine a server-side rendering architecture in which a component tells the server how its data dependencies should be obtained by using a static method.
import { getInitialData, withInitialData } from "another-react-library";

class Page extends React.Component<Props, State> {
  static async getInitialData(props: Props) { /* ... */ }
}

export default withInitialData(Page);

If we wanted to make the getInitialData field mandatory so that each component can be server-side rendered, there is no way to achieve that right now. I could imagine having a class that requires it.
interface SSR
 {
  getInitialData(props: P): Promise<D>
}

class UniversalComponent
 extends React.Component
 implements static SSR
 { /* ... */ }

Such a component would be forced to define what it needs in order to be server-side rendered.
class Page extends UniversalComponent<Props, State, Dependencies> {
  // Required now!
  async static getInitialData(props: Props): Promise<Dependencies> { /* ... */ }
}

Here's my two cents:
I wish I could add static methods to my interfaces. The interfaces describe the API of an object. At the moment, that seems to be an instantiated class, however, when writing the interfaces and classes, we actually implement interfaces on classes, which are more akin to a messy mix of constructor and prorotype. A) Being able to write static methods inside a class alone is proof of that we cannot separate the two when working with class sugar.
From the docs:

In TypeScript, interfaces fill the role of naming these types, and are a powerful way of defining contracts within your code as well as contracts with code outside of your project.

B) I think that means that an interface is the description of the capabilities a class provides, which may include static methods - which we cannot declare with today's interfaces.
So, if we use A) and B) as a line of thinking, there's a mismatch. Which is why I would like to suggest a re-alignment between what classes provide and what interfaces provide - in the most intuitive way. Just let an interface look like a class declaration, with the class being the definition. It's something which was possible way back in other languages (C++) as well, and helps have a clear contract.
interface IA {
  static x: string
  n: number

  static foo(): void
  bar(): void
}

class A implements IA {
  static x: string = 'Hello';
  n: number = 42;

  static foo(): void {}
  bar(): void {}
}

Also, let's not forget that it is valid code to pass a constructor as parameter, which allows us to do quite a bit of useful stuff and might benefits a lot from having an interface with static declarations. That's also something which has to be included in such a contract.
function foo<T extends Object>(obj: { new(): T }, ...args: any[]) {
  const instance: T = new (obj.prototype.constructor.bind(obj, ...Array.from(arguments).slice(1)))();
  const constructor = instance.constructor;
  const typeName = constructor.name;

  // ...
}

There were some doubts about this suggestion, so let me address them:

// arg has... no members?

Yes, if there are no non-static methods declared then arg has no members. If that situation makes sense should, however, not be part of a discussion about a language's capabilities, since it leads to exactly this kind of highly hypothetical situation, which cannot be assessed at a language level. Maybe it does make sense for the logic? Maybe it increases the developer experience? No one can make any good argument without a concrete case, and then we are talking about a concrete case instead of the language, so let's not talk about it here.

// How do I get to ctor(arg).x ?

arg.constructor.x, which is valid code, and I needed it in several projects, which heavily make use of the type system to create a sound library usage (take a look at this project, for example)

// Is this a legal call?
// There doesn't seem to be any reason to reject it,
// since 'fn' can't illegally access anything that doesn't exist
fn({ });

No, it's not a legal call. {} does not implement the interface, so the type checker should reject it. fn cannot access arg.constructor.x, which is valid JS and valid TS, so there would be an obvious bug in TS if the above was allowed.

Another 2 cents (I apologize if that case was already discussed, at this point the discussion is too lengthy to be sure):
Being able to define static methods on an interface would also be useful when one tries to augment typings for a class they do not have control of, for example, an external library. For example, the declaration file of the library can have the following:
declare namespace A {
    class B { static init(opts: object) : B }
}

If one wants to add an override for the static init method in their code, it seems intuitive to use declaration merging. With interface this is currently not possible:
declare namespace A {
  interface B {
    //? Static members are not allowed here, and you can't merge classes
  }
  namespace B {
    //function init(kind: number): A; won't work as this is not the same as overloading
  }
}

This could be solved elegantly if static members could be defined on interfaces:
declare namespace A {
  interface B {
    static init(opts: { start ?: Date }) : B; //'static' modifier cannot appear on a type member
  }
}

How to work with typescript in the following scenarios? Is there any solution or workaround?

I had written an AOP framework to add AOP feature(I call it ability) into a class.
const createAbility = require('custom-ability')
class MyFeature {
  static coreAbilityClassMethod(){};
  coreAbilityMethod(){};
  additionalAbilityMethod(){};
}

const addFeatureTo = createAbility(MyFeature, ['coreAbilityMethod', '@coreAbilityClassMethod']);

class MyClass {
  someMethod() {}
}
// inject the static and instance methods to the MyClass.
addFeatureTo(MyClass);
MyClass.coreAbilityClassMethod();
const instance = new MyClass;
instance.coreAbilityMethod();

Dynamic inheritance and mixin library to inherits or mixin a class on run-time.
const inherits = require('inherits-ex/lib/inherits')
const mixin = require('inherits-ex/lib/mixin')
const isInheritedFrom = require('inherits-ex/lib/isInheritedFrom')
class Root {}
class A {}
class B {}
class MyClass {}
inherits(MyClass, [B, A, Root])
assert.not.ok(inherits(MyClass, Root)) // inheritance duplication
assert.ok(isInheritedFrom(MyClass, Root))

class Mixin1 {
  static sm1() {}
  m1() {}
}
class Mixin2 {
  static sm2() {}
  m2() {}
}
// clone all members of Mixin1 and Mixin2 to MyClass
mixin(MyClass, [Mixin1, Mixin2])
MyClass.sm1()
MyClass.sm2()

I would be very interested to see progress on this proposal and I think the implements static X syntax would be a great addition to the language.
Therefore could someone maybe point out which questions / concerns are still open regarding this proposal or if it might be time to try implementing a PR for this feature?
(not that I could do it ... sadly I have no knowledge of the TS compiler internals yet)

I love the implements static X solution, a bit of a mind bender, but makes perfect sense:
interface JsonFactory<T> {
  fromJson: (obj: JSON) =>  T;
}

class Book implements Item, static JsonFactory<Book> {
  static fromJson(obj: JSON) { return new Book(...); }
  get ItemName() { return `book titled: ${this.name}`; }
}

const books: Book[] =  [Book.fromJson({...}), Book.fromJson({...})];
const factories: JsonFactory<Item> = [Book, Pencil, Bookmark];

This is already great.
I wish we could make it in the same declaration, like so
interface JsonFactory<T> {
  static fromJson: (obj: JSON) =>  T;
  toJson: () => JSON;
}

// and then use it like this?
function makeItem(factory: static JsonFactory<Item>, rawItem: JSON) {
  const item: Item = factory.fromJson(rawItem);
  const jsonItem = item.toJson(); // 👌
  const json: never = factory.toJson(); // 🙅♂  not possible
  const item2: never item.fromJson({...}); // 🙅♂  not possible

  return item;
}

I wish we could make it in the same declaration, like so
interface JsonFactory<T> {
  static fromJson: (obj: JSON) =>  T;
  toJson: () => JSON;
}

// and then use it like this?
function makeItem(factory: static JsonFactory<Item>, rawItem: JSON) {
  // 👌  just fine
  const item: Item = factory.fromJson(rawItem);
  const jsonItem: JSON = item.toJson();

  // 🙅♂  not possible
  const json: never = factory.toJson();
  const item2: never item.fromJson({...});

  return item;
}

This does not replace implement static X though, it's just nice to have.

@KutnerUri there has already been a lot of discussion regarding static declaration on interfaces themselves and there are many issues with this which is why this solution was already declined.
Search a bit through older issues and you will find it

@olee I already showed in my comment that the issues in that post actually do not exist, which means putting statics in the interface will work.

@olee - ok. Let's start with implements static X

Are there anybody that's already on this? any help needed? I am interested in contributing.

I wish we could make it in the same declaration, like so
interface JsonFactory<T> {
  static fromJson: (obj: JSON) =>  T;
  toJson: () => JSON;
}

// and then use it like this?
function makeItem(factory: static JsonFactory<Item>, rawItem: JSON) {
  // 👌  just fine
  const item: Item = factory.fromJson(rawItem);
  const jsonItem: JSON = item.toJson();

  // 🙅♂  not possible
  const json: never = factory.toJson();
  const item2: never item.fromJson({...});

  return item;
}

This does not replace implement static X though, it's just nice to have.

Not sure how will the function be used though, would it be expecting
makeItem(JsonFactory)
// or
makeItem(new JsonFactory<...>())

I am wondering instead, if something like this is useful
// and we might then have to limit 'extend static' to just interfaces? not sure
function <T extends static JsonFactory>(t: T) {
   // how should we access the static interface here? should T now also contain the static side of the constraints?
   // for example now this is becomes valid and gets converted into the `T.fromJson()` turns into `t.constructor.fromJson()`?
   T.fromJson(...)
}

I know I'm a little late to the party here, but if the entire point of classes is syntactic sugar, then why are we throwing that away with interfaces, forcing them to be separate like this? Something that exists in my library includes both static and instance methods that need to exist on a class. It seems weird to require someone to both implements and implements static two separate interfaces if they're both inherently tied together.
In terms of getting the static type of an interface with static members, if I have an interface:
interface Serializable<T> {
  static deserialize: (serialized: string) =>  T;
  serialize: () => string;
}

It's actually quite trivial to get the static type if I wanted to use that as an argument of a function, I've actually done this several times.
function doThing(clazz: Serializable<{}>['constructor']) {
  // ...do stuff
}

This could be turned into a default generic type just like Parameters<T> and look something like this:
interface Serializable<T> {
  static deserialize: (serialized: string) =>  T;
  serialize: () => string;
}

function doThing(clazz: Static<Serializable<{}>>) {
  // ...do stuff
}

Currently the only way to get this to (somewhat) work is doing something like this:
interface SerializableStatic<T> {
  deserialize: (serialized: string) =>  T;
}

interface Serializable<T> {
  constructor: SerializableStatic<T>;
  serialize: () => string;
}

function doThing(clazz: Serializable<{}>['constructor']) {
  // ...do stuff
}

But doing this only type checks usage of a variables typed as Serializable and doesn't type check classes that actually attempt to implement it.
I just think that in terms of ease of development and readability it makes a whole lot more sense to have interfaces follow more closely how classes are modeled rather than creating this divide. It's not very often that I've needed statics on an interface, but every time I've (personally) needed them it's always been in association with other instance members where it makes no sense to ever implement just the static members or just the instance members. (Like the provided Serializable example here)

@Rodentman87 if you read the whole conversation and check this comment from @RyanCavanaugh above, you will see that there are various issues with having static properties on interfaces.
People keep bringing this up, but because of the fundamental flaws of that proposal it is a no-go.

@Rodentman87 if you read the whole conversation and check this comment from @RyanCavanaugh above, you will see that there are various issues with having static properties on interfaces.
People keep bringing this up, but because of the fundamental flaws of that proposal it is a no-go.

I did read the whole thread as well as all the other threads about this topic. My comment was addressing those exact issues that were mentioned there.

Oh yeah I saw you using static properties in an interface, but I didn't notice that you were actually referring to the issues of doing that.
Sorry

@olee I addressed all of @RyanCavanaugh 's issues in one of my comments above. If I am wrong, please correct me. So far, I do not see any problems holding this proposal back :)

If this feature in any way would be implemented, can we use the generic parameters to call the static methods? For example a common usecase will be the createInstance method like the code below:
interface Animal {
  static createInstance: () => Animal;
  print: () => void;
}

class Tiger implements Animal {
  static createInstance = () => new Tiger();
  print = () => console.log('Hey I am tiger!');
}

class AnimalFactory {
  static createAnimal<T extends Animal>(): T {
    let animal: T = T.createInstance();
    return animal;
  }
}

...
let animal = AnimalFactory.createAnimal<Tiger>();
animal.print();
...

Not sure how will the function be used though, would it be expecting
makeItem(JsonFactory)
// or
makeItem(new JsonFactory<...>())

yes, clearly it would be makeItem(JsonFactory, { ... }).
const instance = new JsonFactory();
const prototype = JsonFactory;
const factoryMethod = JsonFactory.fromJson;
const factoryInstanceMethod = instance.fromJson;

instance is prototype; // true
prototype is instance; // false
typeof factoryMethod; // "function"
typeof factoryInstanceMethod; // "undefined"

mixing static JsonFactory and JsonFactory instance does not make sense:
function makeItem(factory: JsonFactory | static JsonFactory, raw: JSON) {
  if("fromJson" in factory) // is the static
    return factory.fromJson(raw);
  if("fromJson" in Object.getProrotypeOf(factory)) {
    // Object.getPrototypeOf(new A()) !== A. I did not expect that.
    return Object.getProrotypeOf(factory).fromJson(raw); // will throw exception and type warning
  }
  throw new Error('this is impossible type-wise);
}

@KutnerUri

maybe the problem is that there is actually no way of getting to the static methods from the instance? I'm surprised I can't find a way to do this in Javascript. But we are not trying to type the instances, we are trying to type the class itself.

In JS, you can use the constructor property:

@minecrawler - ah interesting.
Maybe this is what missing for typescript? Because right now instance.constructor is always of type Function.
So the corrected code would be:
function makeItem(factory: JsonFactory | static JsonFactory, raw: JSON) {
  if("fromJson" in factory) // is the static
    return factory.fromJson(raw);

  // (else) is the instance
  const ctor = factory.constructor; // infer as JsonFactory;
  if ("fromJson" in ctor) { // always true
    return ctor.fromJson(raw);
  }

  throw new Error("this is impossible type-wise");
}

I would love to see static members be available in interfaces as well. I read through a lot of this very long multi-thread dicsussion. I thought it was worth sharing a workaround that I whipped up. I haven't used it in the wild but it was a fun thought experiment to get right.
In this experiment I chose to make a trivial "Comparable" interface which declares functionality to compare two instances (static-side) or to compare "this" instance to another instance (instance-side). I purpousefully gave the two functions the same name. The general idea behind this pretty trivial use case is to define a static function that can be used to sort arrays (a static function can access private members) and leave the interface capable of declaring instance members.
In the code below I define the Comparable interface, then implement it with a TestScore class that wraps a student's test score, and finally have a little bit of trivial code that uses it.
/**
 * Experiment: static members in interfaces
 * GOALS:
 * Top Priority:
 * ✓ - Keep for instance-side interface
 * ✓ - Allow for static-side interface
 * ✓ - Allow constructor interfaces on the static side
 * ✓ - Compiler errors for incorrect implementation on either side
 * Moderate Priority:
 * ✓ - Both instance & static interfaces defined together
 * ✓ - Require minimal code to implement
 * Lower Priority:
 * X - Inherit documentation from parent (only works instance side)
 * ✓ - Syntax highlighting works well
 * X - Make it fool proof (there are a few quirks, see comments)
 */

/**
 * A comparable type with both static side and instance side interfaces.
 * @template TComparable The implementing class.
 * @template TTypeofComparable The typeof the implementing class.
 */
interface Comparable<
TComparable extends NewableFunction | Comparable<TComparable, any>,
TTypeofComparable extends (ThisType<TTypeofComparable> |
{
	// QUIRK 1: The use of the ThisType utility type on the above line is
	// there purely to make VS Code syntax highlighting behave nicely.

	//#region Static Side Interface
	// Constructor Signature(s)
	// If the implementer is not required to have a public constructor then
	// you can leave out the constructor signature(s),
	// or you may use ? to mark the constructor as optional.
	new?(...args:any[]):TComparable;

	// Static properties / methods
	/**
	 * The static compare function interface.
	 * Ensures that the implementer has a static compare function.
	 * @static
	 * @param a The first test score.
	 * @param b The second test score.
	 * @returns -1 if a got a higher score value, 1 if b got a higher
	 * score value, else 0 if the same.
	 */
	/* static */ compare(a:TComparable, b:TComparable):number;
	//#endregion
})>
{
	//#region Instance Side Interface
	// Instance properties / methods
	/**
	 * Compares this instances to another instance.
	 * Ensures that the implementer has an instance side compare function.
	 * @param other The instance to compare to.
	 * @returns -1 if this is less than other, 1 if greater than other,
	 * 0 if equal.
	 */
	compare(other:TComparable):number;
	//#endregion
}

// QUIRK 2: If you were to pass some other Comparable class instead
// of TestScore for both generic parameters, you won't get a complaint
// from the compiler, which makes sense
class TestScore implements Comparable<TestScore, typeof TestScore>
{
	public constructor(private readonly pct:number)
	{
		this.pct = pct;
	}

	// QUIRK 3: the static compare function's documentation
	// isn't inherited, which makes sense :)
	public static compare(a:TestScore, b:TestScore):number
	{
		if (a.pct  b.pct) return 1;
		else return 0;
	}

	public compare(other:TestScore):number
	{
		return TestScore.compare(this, other);
	}

	public getLetterGrade():string
	{
		if (this.pct >= 0.9) return "A";
		else if (this.pct >= 0.8) return "B";
		else if (this.pct >= 0.7) return "C";
		else if (this.pct >= 0.6) return "D";
		else return "F";
	}

	public toString():string
	{
		return this.getLetterGrade() + " " + (Math.floor(this.pct * 100)) + "%";
	}
}

// Imaginary usage
// Get some test scores
let scores:TestScore[] = [];
for (let i:number = 0; i < 10; ++i)
	scores.push(new TestScore(Math.random()));

let output:string;
output = "unsorted grades:";
for (let i:number = 0; i < scores.length; ++i)
	output += "\n " + i + ": " + scores[i].toString();
console.log(output);

// Sort them using the static compare function
scores.sort(TestScore.compare);

output = "sorted grades:";
for (let i:number = 0; i < scores.length; ++i)
	output += "\n " + i + ": " + scores[i].toString();
console.log(output);

I hope this workaround helps some folks. I created a playground with a more verbose version of it.
That said, I want to throw in my $0.02. I would prefer to see the interface declaration and implementation syntax be consistent with how statics are declared in classes and abstract classes.
abstract class Foo
{
  static bar:string;
}

This feels a little off (but I might be influenced by my experience working in C#):
interface ComparableStaticInterface<T>
{
  compare(a:T, b:T):number;
}
interface Comparable<T>
{
  compareTo(other:T):number;
}
class TestScore implements static ComparableStaticInterface<TestScore>, Comparable<TestScore>
{
  // static implementation of compare
  // instance implementation of compareTo
}

Near the top of this thread @RyanCavanaugh illustrated some issues he saw with this option:
interface Comparabe<T>
{
  static compare(a:T, b:T):number;
  compareTo(other:T):number;
}
class TestScore implements Comparable<TestScore>
{
  // static implementation of compare
  // instance implementation of compareTo
}

Rather than hash them all out, I'll just say- I agree, the idea of "unstatic" is no bueno, but i don't think there is anything wrong with using ":typeof SomeType" to get the static side of a type.

I have no preference one way or the other, but would love to have this feature. As a workaround, I currently write a "compile time unit test" of sorts:
interface Statics {
  doStuff(): string;
}

class MyClass {
  static doStuff() {
    return 'string';
  }
}

// eslint-disable-next-line @typescript-eslint/no-unused-vars
const _: Statics = MyClass;

It gets the job done, but it's kinda gross, between the stray variable, the linter complaining, and the after-the-fact-ness of assignability checking (rather than the up-frontness of an implements clause).

MyClass satisfies Statics; would be the preferred way of writing this.

MyClass satisfies Statics; would be the preferred way of writing this.

Uh, y'all, this actually works right now:
class A {
    static f(): number {
        return 1;
    }
}

class B {
    static g(): string {
        return "hi";
    }
}

interface HasF {
    f(): number;
};

A satisfies HasF;
B satisfies HasF; // Type 'typeof B' does not satisfy the expected type 'HasF'. Property 'f' is missing in type 'typeof B' but required in type 'HasF'.

So.... close the issue I guess?  🎉

So.... close the issue I guess? 🎉

Sounds like a nice workaround, I really want to play around with that now! However it looks like just that: a workaround. Not static declarations in an interface, as requested in the OP :(

The OP isn't actually about interfaces with static members, it's about assigning (the static side of) a class to a variable that's typed with an interface.  That's pretty much exactly what satisfies gives you, from my example.  It would be nice to be able to combine it on one line (class Child extends Parent implements SomeInterface satisfies StaticThing { ... }), but the current two-line version gets the job done.

since expr satisfies Type is an expression that evaluates to expr, the following also works, but looks a little strange.
const A = class {
    static f(): number {
        return 1;
    }
} satisfies HasF;

@1EDExg0ffyXfTEqdIUAYNZGnCeajIxMWd2vaQeP (very unwieldy username) note that this requires you to store the class in a variable. As I've said in my OP, this is already possible:
const Clock: ClockConstructor = class Clock implements ClockInterface {
  constructor(h: number, m: number) {}
  tick() {
      console.log("beep beep");
  }
}

The issue is about making this possible without unnecessary variable assignments. Your workaround, as you've said, is in fact a little strange, and the whole idea is to make this more intuitive and approachable, which it currently is not.

I just realized that my "working" example above leaves you with additional statements in the JS emit. Look at the output on that Playground link, you have "A;" and "B;" at the end. That also means you'll trigger "no standalone statements" linter rules.
Maybe we can just make class A {...} satisfies Foo legal and call it a day?

Maybe we can just make class A {...} satisfies Foo legal and call it a day?

It already is legal; see @1EDExg0ffyXfTEqdIUAYNZGnCeajIxMWd2vaQeP 's variant.
interface IAStatic {
    f(): number;
}

interface IA {
    a(): void;
}

const A = class implements IA {
    static f(): number {
        return 1;
    }

    a() {}
} satisfies IAStatic;

I played around with it. I'm not 100% happy with having two interfaces (one for static, one for instance), but being able to add proper types in a relatively simple manner is already very good.

Unfortunately, I'm not an expert on something low-level theoretical like that. My guess would be that one is a class (constructor) and the other one is a reference to a class (constructor). From my experience, they work interchangeably in practice.
To be honest, when writing code, I don't care that much about such things... I'm more worried about contracts and APIs being well typed and architected, which is why missing ways to put statics into an binding contract interfaces (as a trivial way to define the contracts) has always been a problem for me.
For the fun of it, I put the code into Babel and had it be transpiled to ES5 (in order to strip the class sugar). Both versions (assigning to a variable and defining the name directly) produce the same code (assign to a variable). However, if I had to manually write ES5 JS, I'd probably also make the difference:
// ES6+
const A = class {
    static f() {
        return 1;
    }
};

class B {
    static f() {
        return 1;
    }
}

// ES5
var A = function() {};
A.f = function() { return 1; };

function B() {}
B.f = function() { return 1; };

var is its own kind of beast (hoisting monster??), but iirc functions also used to be a hoisting mess. Today, we only use block-scoped declarations, so I don't think we would see any difference between A and B, even when writing
const A = function() {};
A.f = function() { return 1; };

function B() {}
B.f = function() { return 1; };

Correct me if I'm wrong, though!

Doesn't const A = class { ... } have different type-space meaning than class A { ... }? I learned to always prefer named classes over const assignments in this case, and I thought it was for a good reason -- though I couldn't tell you exactly why if you put me on the spot.

const A = class { ... } will have A.name === '' rather than A.name === 'A' as intended. That can have consequences when debugging (e.g. React likes to leverage function and class names for their dev tools and when making error messages), so you would need to repeat the name for both the variable and the class expression.

I think #32452 is a better solution for this issue. With that implemented this should automatically type checks:
interface I {
    constructor: { fn(): void; }
}

class C implements I {
    static fn(): void { }
}

It doesn't require any new syntax, and works as real JavaScript does: (new C()).constructor.fn === C.fn.
Except it's unclear how to extend interfaces with static part, maybe it will need this:
interface IA {
    constructor: { a: number };
}

interface IB extends IA {
    constructor: IA["constructor"] & { b: string };
}

Doesn't const A = class { ... } have different type-space meaning than class A { ... }?

class A declares both a value and a type (for the instances of A), var A = class {} only declares a value.
class A {}
let a: A;

const B = class {};
let b: B; // 'B' refers to a value, but is being used as a type here. Did you mean 'typeof B'
let bWorks: InstanceType<typeof B>;

Or you can
const B = class {};
type B = InstanceType<typeof B>;
let b: B;

I remember there is an issue for allowing any constructor-typed variables to act like a type, but I can't find it now.

MyClass satisfies Statics; would be the preferred way of writing this.
...
So.... close the issue I guess? 🎉

While this workaround does seem to work well for ensuring type safety, the ergonomics aren't great so I would not call it done.
Aside from the nonobvious and unusual place of declaration, the after-class-definition requirement means it's impossible to get autocomplete like you do with non-static methods and properties since the type checking is completely disconnected from the declaration. It also means any type errors are (1) dumped onto the same single line, (2) very far away from what actually caused the error, especially if the class is long, and (3) nested at least one level deeper than necessary, since the error message always talks about the class itself failing to type check before mentioning which fields are at fault. Lastly, the intent is obscured, since one would reasonably expect a requirement of the class's statics to be declared along with other requirements of the class -- that is, the implements clause, or near it.
In short: yes, it gets the job done, but getting there is unpleasant.

MyClass satisfies Statics; would be the preferred way of writing this.
...
So.... close the issue I guess? tada

While this workaround does seem to work well for ensuring type safety, the ergonomics aren't great so I would not call it done.
Aside from the nonobvious and unusual place of declaration, the after-class-definition requirement means it's impossible to get autocomplete like you do with non-static methods and properties since the type checking is completely disconnected from the declaration. It also means any type errors are (1) dumped onto the same single line, (2) very far away from what actually caused the error, especially if the class is long, and (3) nested at least one level deeper than necessary, since the error message always talks about the class itself failing to type check before mentioning which fields are at fault. Lastly, the intent is obscured, since one would reasonably expect a requirement of the class's statics to be declared along with other requirements of the class -- that is, the implements clause, or near it.
In short: yes, it gets the job done, but getting there is unpleasant.

I think going from
const A = class implements IA {
    static f(): number {
        return 1;
    }

    a() {}
} satisfies IAStatic;

to
class A implements IA {
    static f(): number {
        return 1;
    }

    a() {}
} satisfies IAStatic;

would probably address most/all of the concerns in the issue while hopefully not adding much compiler overhead and making the information available to autocomplete. I haven't looked much into the implementation here, but it doesn't seem like that big of an adaptation, especially considering the improved ergonomics it allows.

I think if we have to update the compiler to support a new syntax anyway, class A extends B implements IA satisfies IAStatic {...} is more ergonomic than class A extends B implements IA { ... } satisfies IAStatic.  Putting one of the three relationships after the declaration, likely several pages of code later, was already going to be worse.  The only advantage is that it can be used as a workaround right now....

I thinking have a static members in interfaces would be a great way.
@RyanCavanaugh  thinks it down below will create a totally meaningless thing:
interface X {
  static x: string;
}
function fn(arg: X) {
  // arg has... no members?
}
// Is this a legal call?
// There doesn't seem to be any reason to reject it,
// since 'fn' can't illegally access anything that doesn't exist
fn({ });

function fn(arg: X) {
  // How do I get to ctor(arg).x ?
}

But we still can create the same thing by class like that:
class X {
  static x: string;
}

function fn(x: typeof X) {

}

fn({}) // Argument of type '{}' is not assignable to parameter of type 'typeof X'.

function getX(x: typeof X) {
	// That is ok.
  return x.x;
}

So why typeof X can't not be an interface writen by ourselves ?
I think a interface with static members is a specific type definition for class just like typeof X ,which is not for other non-class object, so it could be treat as typeof X as well:
interface X {
  static x: string;
}

// Error, property 'x' doesn't exist on 'typeof A'
class A implements X {
}

// Type '{}' is not assignable to type 'X'
const a:X = {}

class B implements X {
  static x: string;
  //...
}

// ok
const a:X = A

//ok
const b:X = B

There still seems to be a shortcoming is the current suggested workaround:

Would this be fixed by the syntax change (not requiring a variable) and is there a way to work around this for now, or am I making some sort of mistake and this isn't an issue?

@gBasil

There still seems to be a shortcoming is the current suggested workaround:

Would this be fixed by the syntax change (not requiring a variable) and is there a way to work around this for now, or am I making some sort of mistake and this isn't an issue?

Your code has a bug, the correct return type of Test.parse() is InstanceType<typeof Test>:
interface TestDynamic {
	dyn(): void;
}

interface TestStatic {
	parse(): TestDynamic;
}

const Test = class implements TestDynamic {
	constructor() {}

	static parse(): InstanceType<typeof Test> {
		return new this();
	}

	dyn() {}
} satisfies TestStatic;

This issue has been open for about 5 years now, what's the status?

@Sebastian-Nielsen https://github.com/microsoft/TypeScript/wiki/FAQ#time-marches-on

@gBasil

There still seems to be a shortcoming is the current suggested workaround:

Would this be fixed by the syntax change (not requiring a variable) and is there a way to work around this for now, or am I making some sort of mistake and this isn't an issue?

Your code has a bug, the correct return type of Test.parse() is InstanceType<typeof Test>:
interface TestDynamic {
dyn(): void;
}
interface TestStatic {
parse(): TestDynamic;
}
const Test = class implements TestDynamic {
constructor() {}
static parse(): InstanceType {
return new this();
}
dyn() {}
} satisfies TestStatic;

it could be rewritten with satisfies keyword before class body:
class Test satisfies TestStatic implements TestDynamic { ... }


Handle Supply/Discharge Equivalencies

Many of these will want to be equivalent classes; worth a pass through the class hierarchy

@gtfierro Let me know if this helps.

Looking into handling supply/discharge equivalencies, it seems appropriate to make sure that the supply/discharge flavors are equivalent in the context of air handling systems.  However, I'm less clear on what the usual terms are for water handling systems: do people just talk about "chilled water supply temp", or is there a need for "chilled water discharge temp" as well? @corymosiman12 would be great to get your perspective on this

Hey @gtfierro - I have only heard of supply and return in the context of hydronic systems.  Somebody else would probably know better, but that's my $.02


[Bug Report]: RSV module validation fails when deployed with identity

Describe the bug
RSV deployment validation fails when system and user assigned identity parameters are added as input parameters.
Failure started with this pipeline run https://github.com/Azure/ResourceModules/actions/runs/3530599233 and consistent ever since.
Reproduced by adding identity parameters to the min test. The test failed the second time it was deployed, with the log output as below.
Identity has been removed from common module validation test by PR #2388, but kept in the module, since the failure does not appear to be related to a wrong implementation.
This issue is about further investigating on the bug and monitor overtime if the issue is temporary.
To reproduce
Add system and user assigned identity to any RSV test. Redeploy twice.
Code snippet
systemAssignedIdentity: true
    userAssignedIdentities: {
      '${resourceGroupResources.outputs.managedIdentityResourceId}': {}
    }

Relevant log output
Status Message: Identity operation for resource '/subscriptions/***/resourceGroups/ms.recoveryservices.vaults-rsvcom-rg/providers/Microsoft.RecoveryServices/vaults/***rsvcom001' failed with error 'Failed to perform resource identity operation. Status: 'Conflict'. Response: '{"error":{"code":"Conflict","message":"Request specified that resource '/subscriptions/***/resourcegroups/ms.recoveryservices.vaults-rsvcom-rg/providers/Microsoft.RecoveryServices/vaults/***rsvcom001' is new, but resource already exists. This may be due to a pending delete operation, try again later."}}'.'. (Code:FailedIdentityOperation)

@fblix @JPEasier, I'd suggest the same approach of issue #1543 : move the issue to blocked, reference the external blocking issue and test again once the blocking issue is closed

blocked by bicep Issue

To be followed up by RSV module owner


base image prompts should ask for which deps to add based on project type

When a user does a bsf init in a Go repo and they've opted-in for creating a base image, we should ask them -
"Would you like to add common Go dependencies(compiler, linter, debugger, etc)?(Y/n)"
If they say yes, we should add them to bsf.hcl.
Similar for other languages.
We already have the common dependencies listed here- https://github.com/buildsafedev/bsf/blob/13996a15ccc66cbf0c44f0b47c907f1c0567531a/cmd/init/config.go#L133
We just need to avoid generating the App modules when user has selected base image.

Hey, I would love to try out this issue.
Would you please guide me by providing more information about this?

Hey @utsab818 , I've assigned the issue to you. Feel free to start a thread over at discord if you have any questions or need help with it


java implementation of Enry

More info in https://github.com/src-d/enry-java/pull/2
Just review last commit, depends on #91
Can't assign, so: /cc @mcuadros @smola @mcarmonaa @abeaumont @ajnavarro
Missing:

[ ] CI stuff

@mcuadros deleted the license. It was a leftover after moving from enry-java to here.

Fully ready for review with CI passing and yadayada

Done @ajnavarro

Done @abeaumont

Merged. Thanks @erizocosmico !


CloudLink doesn't load on TurboWarp Desktop on Debian 11

It was working on normal TurboWarp...
TurboWarp Desktop

TurboWarp

Turbowarp Desktop doesn't support Websockets, for some reason.


Version 3.0 Iteration Plan

General proposal

[ ] Implementation of web interface & bind data with front-end using web-sockets
[ ] generate QR code on the web instead of the terminal since many users facing #21
[ ] display conversation on the front-end application.
[ ] Allow users to add API keys from the front-end application and store credentials in local DB.
[ ] Implement rate-limiting, include-sender, exclude-sender features for each AI model.

Definitions

rate-limiting determines how many requests a sender can send for a given number of times. for example: User X can send 10 requests per min. #23
include-sender allows sender only if 'include-sender' list contains the sender number
exclude-sender disallows sender if 'exclude-sender' list contains the sender number

Get Started
fork this branch to contribute.

Would try to work on this enhancement on my end :) great project

@levitco Thank you for showing your intention to contribute. Please tell us about your experience and how can you enhance this project.


HTML5 form validation: Firefox does not support validity.tooShort

There should be a mention that Firefox still fails to support minlength validation, which should result in a validityState.tooShort; bugtracker entry: https://bugzilla.mozilla.org/show_bug.cgi?id=932755

Already linked in the Resources tab of http://caniuse.com/#feat=input-minlength

Thank you for the information. Redundant information might still be helpful in this case.

Now also available at https://caniuse.com/#feat=mdn-api_validitystate_tooshort


Missing some settings after move

So we discovered only later that this scripts leaves a few things out which are quite important:
Tags are lost
Extensions are lost
Auto-shutdown settings are lost
Most importantly, the license type is lost. This can be a costly oversight, as our machines were using bring-your-own licensing, and with this script, switched back to included license. I believe it would be an easty change to include at least this setting in the script.

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

ID: 7eed234f-9a8d-4c1b-2368-fe4c8fbe8299
Version Independent ID: 876980d5-e42c-b070-c0a6-73ed3f2c91d1
Content: Change a VMs availability set
Content Source: articles/virtual-machines/windows/change-availability-set.md
Service: virtual-machines-windows
GitHub Login: @zr-msft
Microsoft Alias: zarhoads

Has there been any news on this?

@lonevvolf Thanks again for the feedback. Someone internally was working on a PowerShell script to try and catalog everything from the VM and then handle each piece, but I think they ran into some issues and had to set the work aside for a bit. I think we discussed switching over to editing the template for the VM instead of trying to script the move, as I think this will handle licensing and other issues more gracefully. Sorry this has taken so long :(

We are currently closing out long standing backlog in order to better determine which issues are still valid and which have been addressed. If you are still seeing a specific problem with this document please open a new issue so we can properly assign the feedback to the correct author and get it addressed ASAP.
#please-close


add a LinkedIn icon to the home page to replace the FB icon

Lily asked:

Please can you add a LinkedIn icon to the home page to replace the FB icon

I see that the Ghost Admin UI only supports Facebook and Twitter, so this will need to be hardwired into the theme.

I've added a custom setting linkedin_uri to the theme which will enable a LinkedIn icon in the navbar.


Set the is_free flag correctly on new credits.

Old behaviour was always setting the credit to free on edit.


Minor documentation issue in fieldValidation.js

Looks like the comment header was copied over from Login.js.

Fixed with https://github.com/bartonhammond/snowflake/releases/tag/0.1.3


insync headless 3.x

Is there a switch to insync_headless 3.x in the works? certain licenses don't work anymore with the 1.5 version..

https://github.com/forabi/docker-insync


Update README.rst

Unify URLs to Veles homepage.

You named it "unifying" URLs - but in other places (i.e. about view) we use codisec.com one :)

Fixed.


Implement distinct()

Hello, I'm trying to integrate django-querysetsequence with django-datatable-view (https://github.com/pivotal-energy-solutions/django-datatable-view)
When this component executes a search a NotImplementedError: QuerySetSequence does not implement distinct() error arrises.
So I would like to know if you plan to implement distinct in the future.
By the way, I fix it so when I use querysetsequence it doesn't use distinct, but of course, there are some duplicated results.
Thanks a lot for the help.
Mauro.

@mauroka I don't have any plans to implement distinct() at the moment, it's not needed for my application. I could definitely set aside time to offer guidance and review a pull request implementing this though!
The real downside is that there probably isn't a sane implementation besides just caching all the results, which makes it incompatible with e.g. iterator().

Hello @clokep, thanks for the response.
Let me see if I can manage myself with an implementation without using distinct(). In case I require it, I will implement distinct() with your help.
Thanks a lot.
Mauro.

Sounds great! Let me know if you have more questions.

@mauroka how did you fix the querysetsequence so that it doesn't use distinct?

@sanjeevjohal It probably depends on your specific application. I suspect this would be easier to implement now that the internals of QuerySetSequence are much simpler.

Thanks @mauroka.
@clokep I should add I'm still on v1.8 and have no plans to upgrade to v1.11 where you can now combine querysets using a union. I did try to use the set operator | but this didn't give me a union which I understand removes duplicates even after I deliberately made an attribute in both models different


add details about segments generator in README

since it confuses many people #67 #117 #141 #142 (also me when i first used), please add details about segments generator in README (for e.g. how to get more accurate execution time)

I agree. Can you check if the updated README in #144 is clear enough?


More granular offset tracking needed for super stream consumer

Is your feature request related to a problem? Please describe.
Right now using automatic offset tracking with super-streams, if there are remaining messages being delivered to a client of my application it is possible for the offset to be recorded ahead of where a client left off. This can happen because the client can close or lose connection while messages are still being delivered. This can cause the client to miss messages.
Describe the solution you'd like
I need more granularity in how the offsets are updated. Possible approaches I can think of are:

Exposing the manual offset tracking for the super stream consumer, so offsets for each partition can be managed by my application. Right now, it is only possible to use automatic offset tracking for the super stream consumer.
Flow control so that I can block receiving messages from the stream while waiting for consumer to complete receiving each message.

First option seems more desirable to me, though there would definitely be complexity with managing the offsets for multiple partitions.
Describe alternatives you've considered
This would be a lot simple with a single stream instead of a super-stream, though the ability to spread the load between multiple consumers is very desirable for us.
I also did look into writing my own super stream consumer managing the partitioned consumers myself, but the superStream field being private and unsetable on the SingleActiveConsumer struct prevents this. Exposing that would be another potential solution for my use case.
Additional context
No response

Hi @jsearles ,
It is already possible to store offset for each partition https://github.com/rabbitmq/rabbitmq-stream-go-client/blob/main/examples/single_active_consumer/single_active_consumer.go#L52
See the full example: https://github.com/rabbitmq/rabbitmq-stream-go-client/tree/main/examples/single_active_consumer

Maybe I'm missing something but the super stream consumer is only set to use automatic offset tracking. It can get ahead of my consumer since the message was delivered to my application (but not necessarily my consumer). I can manually update the offset to a higher offset, but not a lower one.
I'll poke around with this and see if this works, but it seems like it'd be stepping on the automatic offset tracking and once that got ahead of my consumer then there'd no way for me to set it to a lower offset.

@jsearles With this PR, https://github.com/rabbitmq/rabbitmq-stream-go-client/pull/323, you can set a manual commit (the default). Now, it is only more explicit.
By setting the manual tracking, you can do what you like with the API: err := consumerContext.Consumer.StoreOffset() you can store the current offset.
with  consumerContext.Consumer.StoreCustomOffset(xxx) you can store the offset you want.
Here you have everything you need to understand the partition:
	consumerContext.Consumer.GetName()
	consumerContext.Consumer.GetOffset()
	consumerContext.Consumer.GetStreamName()

It should be enough to handle the offset-tracking in all situations.
Here: https://github.com/rabbitmq/rabbitmq-stream-go-client/blob/main/examples/super_stream/super_stream_sac.go#L61. You can restart from the offset you decided.

Perfect - thanks a lot!


Tom Clancy's Splinter Cell - Bug Reports

Tom Clancy's Splinter Cell (SC1) runs on Unreal Engine 2 with a DirectX8 renderer. D3D8to9 will need to be used in order to have it hook into RTX Remix.

Remix Version: 0.2.0
D3D8to9 Version: v1.11.1
GPU: GeForce RTX 2070 Super
GPU Driver Version: 531.79
Game Build: Steam version, latest patch

Bug 1: Full-screen mode does not work correctly and will only run in 640x480.
The game is currently limited to a resolution of 640x480. If you try to run it at a higher resolution, the game will still appear in a 640x480 window with it partially cut off screen.
Under RTX Remix, Splinter Cell fails to handle full-screen mode correctly. Instead, the game changes the desktop resolution to match the in-game settings and opens in a borderless window even when full-screen is enabled in the configuration file. To avoid this issue, it is recommended to run the game with ThirteenAG's Splinter Cell Widescreen Fix.
The image below illustrates the issue where the game only shows a 640x480 window when attempting to run it at a 2560x1440 resolution without any fixes applied.

Logs generated for when the game is trying to run the game without any fixes.
d3d9.log
SplinterCell_d3d9.log
NvRemixBridge.log

Bug 2: Running SplinterCell.exe directly will not work, you must force load a level and specify your resolution in a batch file.
Attempting to run Splinter Cell normally will result in a black screen. Strangely, force loading into a level using a batch file fixes this even if the level is the Main Menu too. In the batch, you will want to force load a level and input the resolution you wish to run the game at.
SplinterCell.exe Menu\Menu.scl RESOLUTION=3840x2160

Bug 3: "Bloom" Effects stay on the screen and never update past the first frame.
Prior to moving the camera at all in the level. The scene looks fine, take note of the red emergency light on the right side.

The effect of the red emergency light stays stuck on the right part of the screen and never updates.

Logs generated from loading into this level and having the effects stuck on screen.
d3d9.log
SplinterCell_d3d9.log
NvRemixBridge.log

Bug 4: Bink Video FMV's do not currently render anything on screen and will keep the game on a black screen.
Splinter Cell uses Bink Video (.BIK) video files from RAD Game tools with most of them being 640x480 resolution.
Splinter Cell has video files that play when starting the game and prior to starting each level. RTX Remix will show a black screen when they are playing but audio can be heard. However skipping these cutscenes will not help, many times once loaded your screen will remain black.
For a workaround, it is necessary to rename/delete the "Videos" folder in the Splinter Cell directory so that the game no longer detects them and instead skips them.
Logs generated from watching the two intro Bink Videos then the game will become non-responsive.
d3d9.log
SplinterCell_d3d9.log
NvRemixBridge.log

Additional information about Tom Clancy's Splinter Cell
Splinter Cell offers two options for rendering shadows in the game, referred to as "ShadowMode" in the configuration files: "Shadow Projector" mode and "Shadow Buffer" mode. When playing with RTX Remix, it is possibly safer to use "Shadow Projector" mode, as it is a less demanding graphical option.
Shadow buffers was a technology from NVIDIA's GeForce 3/4 era which is now obsolete. Today's graphics cards cannot accurately render this mode without the assistance of a wrapper, such as dgVoodoo 2, which emulates a GeForce 4 Ti 4800.
There are two ways to switch your game to "Shadow Projector" mode:
Method 1:
System\SplinterCell.ini:
[D3DDrv.D3DRenderDevice]
ForceShadowMode=0
Method 2:
Add the launch parameter -shadowmode=projector to SplinterCell.exe.
If using ThirteenAG's Splinter Cell Widescreen Fix, System\Scripts\SplinterCell.WidescreenFix.ini
ForceShadowBufferMode = 0
The above bug reports are with "Shadow Projector" mode enabled.

@Joshhhuaaa can you report some changes or improvements over the last year?
I wanted to try rtx remix and im really suprised that i can not find a way to run it properly with splinter cell 1.

Hello! Will you please test this on the latest release and let us know if these issue persist? Thank you!

Hello! Will you please test this on the latest release and let us know if these issues persist? Thank you!

Hey, I've just started testing Splinter Cell again on remix 0.5, and good news, some of the minor issues to get the game started have been fixed from this post.

Bug 1: Full-screen mode does not work correctly and will only run in 640x480.
This bug still persists unfortunately, so I would highly recommend using ThirteenAG's Widescreen Fix as a workaround when playing the game, so you can use native resolution.
Also, Alt+Tab still isn't working in fullscreen either, if the game gets unfocused after starting, you usually have to restart the game. A workaround is while using ThirteenAG's Widescreen Fix, go into SplinterCell.ini and set StartupFullscreen to False. This will basically have your game running in fullscreen windowed and you will be able to refocus to the game.

Bug 2: Running SplinterCell.exe directly will not work, you must force load a level and specify your resolution in a batch file.
It seems that this bug has been fixed. I was able to launch the game using the executable without any issues on remix 0.5.

Bug 3: "Bloom" Effects stay on the screen and never update past the first frame.
It seems the game doesn't seem to have Bloom at all now, so the bug technically isn't here. Also, geometry is sometimes coming in and out, so you can see through walls, I don't recall that being an issue in prior versions.

A screenshot to compare with the original in the post. Notice the bloom is missing now and can't see through the window glass on the left.

Here is an example of the BSP geometry missing depending on the camera angle.

Bug 4: Bink Video FMV's do not currently render anything on screen and will keep the game on a black screen.
Additionally, this bug has been fixed. The FMVs before the main menu and for levels are functioning correctly with Remix hooked.

I didn't mention it in this post, but thermal vision was previously broken. A workaround was to use EmulateGF2Mode=1 (GeForce2 rendering) in SplinterCell.ini, which was worse visually but rendered thermal fine. However, remix 0.5 also seems to fix thermal vision, so this workaround should no longer be needed.


BC: Rename boolean methods of PlanSubscription

I propose the renaming of the following methods from PlanSubscription:

active() to isActive()
onTrial() to isOnTrial()
canceled() to isCanceled()
ended() to hasEnded()

This has two reasons:

It is a convention to have these kind of methods prefixed with is or has
The current naming interferres with the scope feature. I want to create a scope scopeCanceled() which will be used like this:

$canceledSubscriptions = Subscription::canceled()->get();

I can not do that currently because of the canceled() method. This will be called instead of the scope.
This is a BC break.

I agree, can be added for v2.
Thanks!


lang: change client_accoutns visibility

This will allow defining accounts structs in separate files. Usage is still complicated but at least make it possible (maybe mod scheme should be changed in the future?).
Usage example:
use serum::{__client_accounts_dex_accounts, DexAccounts};

#[derive(Accounts)]
pub struct Initialize<'info> {
    dex: DexAccounts<'info>,
}

This will allow defining accounts structs in separate files. Usage is still complicated but at least make it possible (maybe mod scheme should be changed in the future?).
Usage example:
use serum::{__client_accounts_dex_accounts, DexAccounts};

#[derive(Accounts)]
pub struct Initialize<'info> {
    dex: DexAccounts<'info>,
}

If you defin

This will allow defining accounts structs in separate files. Usage is still complicated but at least make it possible (maybe mod scheme should be changed in the future?).
Usage example:
use serum::{__client_accounts_dex_accounts, DexAccounts};

#[derive(Accounts)]
pub struct Initialize<'info> {
    dex: DexAccounts<'info>,
}

This will only work for rust clients. Account structs outside of lib.rs won't be parsed into the IDL right now.


Standard compliance: allow for multiple results

Why?
It seems like the standard supports multiple results.
What?

[ ] Check that it does.
[ ] If it does, replace result section in Func with List Type'.

Superceded by #21.


Relax the scope requirement for public fields

This is a TCK counterpart to the specification change that allows all pseudo-scoped beans to have public fields. It just updates the text in tck-audit-cdi.xml and fixes naming in the relevant tests.

@Ladicek shouldn't we add a test that verifies this for @Singleton?

We could, but it's not like we can ever be exhaustive. For normal scopes, we only test @RequestScoped, even though we could also test @ApplicationScoped easily :shrug:

We could, but it's not like we can ever be exhaustive. For normal scopes, we only test @RequestScoped, even though we could also test @ApplicationScoped easily 🤷

True, I only mentioned this as it is a notable difference from previous version of specification.
I'll leave it up to you

I could add a test for @Singleton as well, but @Singleton is not a bean defining annotation, so I would have to create a stereotype, and I'm just lazy...
OK, I will do it :-)

Done.


Removing Characters Resources causes the game to crash when the animal spawns in

I tried making the alien invisible like I did in my invisible aliens and Joes mod and it didn't work always when I do it the game crashes when I load in the map where I removed their resources

This is addressed in the upcoming release via support for editing renderable instance resources.


JSDoc not picking up exported enum properties

JSDoc is not picking up the properties of an exported enum
'''
/**

Alert type that is used to indicate the severity of the information
@readonly
@enum {number}
*/
export const ALERTTYPE = {
INFO: 1,
WARNING: 2,
ERROR: 3
};
'''

The code above will not result in the property not getting picked up by jsdoc, however if I simply remove the export they will get picked up by jsdoc

Software
Version

JSDoc
3.6.6

Node.js
12.16.1

npm
6.14.8

Operating system
windows 10

I'm also experiencing this issue.  Instead of allowing a compound exported statement, if you want to use jsdocs you are forced to first make the object then export it.
This also extends if you were to set any sort of Object.freeze() to it as well.


Add name mangling support for functions with a thrown error type

This covers all of mangling, demangling, remangling and printing. However, it does not yet cover runtime metadata.

@swift-ci please smoke test

This was rolled into https://github.com/apple/swift/pull/69493


[RTM] Multi Threading for time communication

Answering issue number 3 #3

Is the code blacked ? If not please do it and I can accept the PR

Is the code blacked ? If not please do it and I can accept the PR

Yes the code is blacked.


Add release notes for typespec azure 0.48.0

No changes needing a change description found.

You can try these changes here

🛝 Playground
🌐 Website
📚 Next docs


Allow arguments of volume and pitch to be used for ADPCM player.

Right now, if I want a sound to play at a specific volume, I have to go the long winded way of doing:
audio.setADPCMVolume(40, 2);
audio.playADPCM(sound, 2);
This also means the channel 2 will stay at volume 40, forcing the user to either:

Always set the volume they desire for the sound effect or
Creating some timer-based channel volume resets to 100.

I think either enabling the user to designate the volume (and pitch maybe) while using playADPCM() could simplify the first option, while also the timed mechanism i spoke of can also be introduced to Tyra.
I believe it's a good idea as Tyra's meant to be a simple way to make PS2 games, and such an automatic volume reset (opt2) / consolidation of parameter setting (opt1) may simplify the process.

Not resolved in Tyra 2.0.0.
Its more a PS2SDK -> audsrv issue


Move standard search queries and functions to Standard API?

While investigating the issue with the search I noticed we have an API\Standard class that is mostly empty and all what I would think "standard" processing out in Search.php.
Since you @live627 did most of the refactoring, what would you think about the idea to move anything that is not used with "custom" APIs to the API\Standard class?

I haven't followed this project in over a  month so am a bit lost.
Do you mean moving the search related code from the controller to its own dedicated API file? Yes,  do it. That stuff does not belong in a controller anyway.

No problem, I haven't followed search in over a decade. xD
I was referring to the Search.php present in https://github.com/elkarte/Elkarte/tree/development/sources/subs/Search
It contains a lot of logic for which "if API doesn't support METHOD then DO QUERY/JOB", I was wondering if this "the DO QUERY/JOB" could/should be moved to the https://github.com/elkarte/Elkarte/blob/development/sources/subs/Search/API/Standard.php (Standard API).

In my eyes are both aproache wrong,
search depends very on the database.
The implementation/providing of queries and how to concat the search stuff could be part of the database layer.

I believe this one was completed


Add bypass-local-dns.yml to CI and test jobs

/azp run cpp - core

/azp run cpp - core

While it might make sense to preemptively double up and include this in archetype-sdk-client.yml we need to make some changes in eng/common for it to go into effect. This can merge today and we'll revisit if we see failures in CI that could be mitigated by adding this there.


Added workaround for prevent InteractiveAssemblyLoader misidentifying Unity as CoreCLR environment for 2022 or newer.

This fixes InteractiveAssemblyLoader not mistaking the CoreCLR environment for CSharpScript when using CSharpScript since Unity 2022.x and newer.
Because one of the external dependency packages, Microsoft.CodeAnalysis.Scripting, is distributed as a plugin and built-in, I have applied a workaround that is specific to the version of that package, 4.4.0.
Fixes #1.

@Creta5164 Thanks, appreciate the fix!

@mstevenson You should up to date package.json's version and CHANGELOG.md later!
Check links below.

https://docs.unity3d.com/Manual/cus-layout.html

https://keepachangelog.com/en/1.0.0/

https://docs.unity3d.com/Manual/upm-semver.html


unit tests use tas pipeline

Found some issue that may be stopping the pipeline from running :) ptal

Perfect, thanks a lot! I adressed everything you found :+1:

/retest

/retest

@JasonPowr,  could you review the PR again? :) I think all the remaining issues seen in the ci-pipeline are not related to my work - wdyt? :)

@miyunari This looks good to me, just one small thing, can you rebase this pr, the sbom-json-check task was recently removed in this commit: https://github.com/securesign/cosign/pull/245/commits/98d3f7e4e52836d993699b7b5ec17e72ded8bab9, this is due to the fact that the task is being deprecated, then I think you should be all good :)
https://github.com/securesign/cosign/pull/247/files#diff-73cfefa52edbf682c98b967f363b95a50608bb56f412d4c96acfddca4535c442R341


[Event Request] Report 1003 Post Invt. Cost to G/L - Test - OnBeforeCheckPostingSetup

Requesting a new Event Publisher on Report 1003 Post Invt. Cost to G/L - Test
Event
OnBeforeCheckPostingSetup(InvtPostToGLTestBuf : Record "Invt. Post to G/L Test Buffer";VAR HasError : Boolean;VAR IsHandled : Boolean)
Please set IncludeSender to Yes!
Code
LOCAL CheckPostingSetup(InvtPostToGLTestBuf : Record "Invt. Post to G/L Test Buffer") : Boolean
>>> New Code
OnBeforeCheckPostingSetup(InvtPostToGLTestBuf,HasError,IsHandled);
IF IsHandled THEN
  EXIT(HasError);

<<< New Code
WITH InvtPostToGLTestBuf DO
  IF "Invt. Posting Group Code" <> '' THEN BEGIN
    IF NOT InvtPostSetup.GET("Location Code","Invt. Posting Group Code") THEN BEGIN
      AddError(
        STRSUBSTNO(
          Text011,
          InvtPostSetup.TABLECAPTION,
          FIELDCAPTION("Location Code"),"Location Code",
          FIELDCAPTION("Invt. Posting Group Code"),"Invt. Posting Group Code"));
      EXIT(FALSE);
    END
  END ELSE
    IF NOT GenPostSetup.GET("Gen. Bus. Posting Group","Gen. Prod. Posting Group") THEN BEGIN
      AddError(
        STRSUBSTNO(
          Text011,
          GenPostSetup.TABLECAPTION,
          FIELDCAPTION("Gen. Bus. Posting Group"),"Gen. Bus. Posting Group",
          FIELDCAPTION("Gen. Prod. Posting Group"),"Gen. Prod. Posting Group"));
      EXIT(FALSE);
    END;
EXIT(TRUE);

In Our Solution we know Job locations, for these Job Lications we do not have a specific record in teh inventory Posting Setup. We define a record with a blank location code and then every possible Inventory Posting Group. So in this check report we also need to have the possibility to make that choise. As said we need to access some global functions, therefore we need the property IncludeSender set to Yes. Could you please add the requested Publisher?

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


[BUG] Heading in the Learn tab not clearly visible in the light theme

Describe the bug:  The heading in the "Learn" tab becomes unclear and hard to read when the light theme is active. The color palette used for the heading text doesn't provide enough contrast against the background, making it difficult to distinguish.
How are you going to fix it?:  I will update the CSS to use a more visible color for the heading text when the light theme is applied. This can be achieved by increasing the contrast between the text color and the background color, ensuring that the heading remains readable in both dark and light themes. For example, changing the text color to a darker shade like #333 or adjusting the background color for better contrast.

Do you think you can use the same navbar for all pages?

@codingkatty you want this to be fixed?
if yes let me know your preference i will fix it

Yes, it's going to add the quality of the contribution, if you want you can do it, or open another issue (someone else could also do that issue, it's your choice to whether do it or not)


RFE: dark mode button to toolbar

I rest my eyes in evening by using dark mode, and it would be convenient to have single press button to switch dark mode on/off.
I already asked for the theme to follow android/desktop mode, but I was told it would be too messy to implement and maintain. So how about this sort of a compromize? 😀

Cannot be done via CSS only, needs JavaScript. Perhaps in the fork some day, but as I don't personally switch between modes (dark mode always everywhere) I'm not interested in spending time to this right now. Will perhaps look for auto dark/light theme option later...


Images are displaying blurry.

I have used ngx-gallery library.Actually in thumbnail strip images are rendered beautifully but above thumbnail strip they  are not displaying well actually displaying blurry images. Can you please help me why it is happening?

Hi @kamleshpaliwal-tudip

maybe you are using to big images?
Are images in my demo also blured? https://lukasz-galka.github.io/ngx-gallery-demo/
Could you put your images into plunker demo https://plnkr.co/edit/D1tdBCeFo6L9tMOCOb9p?p=preview ?

I need example to work on fix.

I was having similar issues until I realized my images were being stretched.


[Bug] [Engine] When datasource is mysql, and colume name is one of the mysql  dafault key, like 'index', will have an error

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
need to support mysql default key word like 'time', 'timestamp', and 'index' etc
DataVines Version
dev
DataVines Config
no

Running Command
no

Error Exception
no

Engine Type
local
Java Version
8
Screenshots
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

可以再试一下，给 字段加上了 ``


Clean up deletion of Secrets related to the old logging stack

/area control-plane
/kind cleanup
The cleanup logic for the loki ServiceAccount was introduced in v1.39.0 and the cleanup logic for the old logging Secrets - in v1.42.0. I guess it should be safe to clean up the cleanup logic in v1.44.0.
Follow-up after https://github.com/gardener/gardener/pull/5279 and https://github.com/gardener/gardener/pull/5495
Release note:

NONE

/rebase

/retest


feat: ssh dockerd connectivity

:gift: Add connectivity via SSH tunnel to remote docker daemons.
Useful for instance when connecting to podman VM in macOS.

resolves #469

Just draft for now, need to decide what to do with https://github.com/matejvasek/sshdialer
Should I keep it as a library or just copy/paste code? what do you think?
Also the code from https://github.com/matejvasek/sshdialer will be used for https://github.com/buildpacks/pack/issues/1259.

For now this will work with:

pwd in ssh url e.g<EMAIL_ADDRESS>keys managed by ssh-agent
keys with standard names in ~/.ssh/ that are not protected by passphrase

@zroubalik or @lkingland  if you have some spare time could you please try this out on macOS?


Testing latest OTTR updates

Step 1) take a look at the docs here: https://github.com/jhudsl/OTTR_Template/wiki/How-to-set-up-and-customize-GitHub-actions-robots
Please comment on anything that isn't clear (or feel free to make edits to the docs directly)
Step 2) Send the changes to one of your courses. Go here: https://github.com/jhudsl/OTTR_Template/actions/workflows/test-send-updates.yml Then click Run Workflow dropdown menu. Type in the name of your repository you'd like to send the changes to. and Click the green Run workflow button
Step 3) Comment on any problems you encounter here! Thanks!

So far reading it quickly - it looks great! maybe adding a sentence to each check about what happens if you put no would be helpful? also maybe showing the code for that as well - since this isn't the default?

also subheadings for spelling check style code, and docker test like the other subheadings might help navigation

Looks great! A few thoughts below :)

Add file preview
Bulletize end of the intro section
Clarify a bit of language in render-preview
Add a screenshot?

Customizing Automation
By default, all automation steps and checks will run. But depending on the needs of your course, you can turn these on and off by going to the config_automation.yml file and switching options to yes or no.
✏ The config_automation.yml file looks like this:
# Formatting Checks (run at pull request)
check-quizzes: yes
url-checker: yes
render-preview: yes
style-and-sp-check: yes
...

✏ There are two main sets of automation steps and checks run:

.github/workflows/pull-request.yml : run upon opening a pull request
.github/workflows/render-all.yml: run upon changes being merged to the main branch

render-preview
render-preview: yes

After you open a pull request, a preview of the renders as they will appear after the pull request is accepted is run and linked to in a comment on the pull request ✏ [this sentence was a bit hard to read for me.. maybe rephrase?]. Upon each commit these previews will re-render and edit the comment with the latest render. These Github Actions are located in render-preview section of the pull-request.yml.
These previews do NOT incorporate any changes influenced by any changes to the Docker image if the Dockerfile is also updated in the same pull request.
spell-check: yes

Github actions will automatically run a spell check on all Rmd's and md's whenever a pull request to the main branch is filed.
Depending on your preference, you may find it easier to spell check manually on your local computer before pushing to Github.
It will fail if there are more than 2 spelling errors and you'll need to resolve those before being able to merge your pull request. Errors will be printed out on a GitHub comment on your pull request.
To resolve those spelling errors, go to this repository's Actions tab.
Then, click on the GitHub action from the PR you just submitted.
Scroll all the way down to Artifacts and click spell-check-results.
This will download a zip file with a TSV that lists all the spelling errors.
✏ _[maybe add a screenshot here?]

Thanks for these comments! I've incorporated them! https://github.com/jhudsl/OTTR_Template/wiki/How-to-set-up-and-customize-GitHub-actions-robots

Looks great! I found one word missing in the style check section that I added - but feel free to rephrase if you wanted something different:
https://github.com/jhudsl/OTTR_Template/wiki/How-to-set-up-and-customize-GitHub-actions-robots/_compare/b515a685b3375f8785779225523a1f7766845243...27eacff35e756df689164fd1ae905168629ffeb0

This is done!


Can't run MVC 6 grid under asp.net core

Followed by installation instructions but can't see gird on a page.
Nothing rendered.
Is there any way to diagnose installation process?

Yes, it's hard to detect sometimes as mvc core starts showing white page or no grid at all instead of throwing an error... I'm not sure how to debug that :slightly_frowning_face:

Well fixed by moving views in all places where I can,
So what work for me - move views to Shared\MVCGrid{allviews here}
You can close issue.


case sensitive file names

Preview is (most often?) case insensitive, but hosting can be case sensitive. A file attachment named AAPL.csv might be correctly resolved in preview and build, but fail in production.
I'd suggest we make preview and build case sensitive, or (maybe better) we lowercase all filenames.

I think this is your operating system (macOS) being case insensitive rather than preview and I don’t think we should do anything here. Forcing all files to be lowercase would likely cause other problems.

True, forcing all files to be lowercase is a bad idea (we don't want to have to rewrite scripts that expect to load a file called SoMeThInG.js).
I still think preview (or, and more importantly, build) should help the user catch the issue and break—rather than discovering it in production.
This might mean that we need to compare the list of actual file names ([aapl.csv] in this case) with the list of expected file names ([AAPL.csv])? Needs a bit of investigation.

Yeah we could do some validation during build since we have the full list of files then, and warn if the file cases don’t match what the operating system says when you readdir recursive.


Cursor set to 0:0 after opening a first file in session

Only once, only for first active file. Very minor


Browser Support/Compatibility

Not an issue (unless you consider requesting this in the README:), but I wasn't sure where to post this?I'm curious about the browser support/backwards compatibility with highland and also maybe some roadmap information?

Browser support: hopefully IE8+, but since Testling is currently broken (substack/testling#88) we have no real way of checking this at the moment.
A brief roadmap:

3.0: overhaul of streaming engine, fixing redirection
probably 3.1: ability to extend Highland streams with custom functionality
possibly 3.2: compatibility with Fantasy Land, _.nil back-propagation

For now, there is a grunt browserify:test-browser task that will browserify the tests so that you can manually run them in a browser. The contributions.md has more instructions.
I've only ever run these tests in the latest Firefox, though.

Thanks all! This is very helpful. Hopefully the testing issue is resolved.


Soot Crashes on Launch

Using Embers Rekindled and Soot 1.0, alongside Forge <IP_ADDRESS>13, Soot causes a crash before the game gets to the main menu.
Here is the pastebin: https://pastebin.com/4Q1FbKVe
Note that this is a modded environment using only Embers, Soot, and Forge.

I think Soot 1.0 is only compatible with Dev Build 2 which is only available on the embers github: https://github.com/EpicSquid/Embers/releases


Define webhook for cleared/new forts

We should define them somehow :)

there should be 3 different types:

edit
new
removal

there should be a Fort object:

type: pokestop | gym
name: str
description: str
image_url: str
lat/lon: float/float

Edit data should have:

edit_type: type | name | description | image_url | location
old: Fort
new: Fort

New + Removal data should have:

fort: Fort

there should be 3 different types:

fort_edit
fort_new
fort_removal

there should be a Fort object:

type: pokestop | gym  (extensible by 3rd parties)
name: str
description: str
image_url: str
location: { lat: float, lon: float }

Edit data should have:

edit_type: type | name | description | image_url | location
old: Fort
new: Fort

New + Removal data should have:

fort: Fort

if change_type = new: ... should be `new: Fort`
if change_type = removal: ... should be `old: Fort`
if change_type = edit: ... should be `old: Fort, new: Fort`


Seperate service logic from data

Data storage logic should be seperate from servicing logic.

Supports #3

Maybe implemented in code as #5


I'm looking for version rust-1.50.0

Since we are going from 1.45 directly to 1.51 (https://github.com/softprops/lambda-rust/pull/87/files) closing this.


Fix incorrect toggle buttons

Some of those are still Copy&Paste problems.
This PR:

Only cleans the legacy incorrect code, doesn't change or improve the "action" logic.
Remove the redundant $('.toggle.button').on('click'), now $('.show-panel.button').on('click') handles that kinds of buttons

Actually, there is only one correct "toggle button" in code, the one on the webhook page.
No need to backport.

Please resolve the conflicts

Conflicts have been resolved.


Refactor 'Raise ActiveRecord::ConnectionNotEstablished on calls to execute with a disconnected connection'

@mgrunberg Thought https://github.com/rails-sqlserver/activerecord-sqlserver-adapter/pull/903 looked good but could be refactored a little. Easier to make my suggestions this way rather than through comments.

It looks cleaner this way. Thanks for the help!


Feat/oauth/dummy impl test

added some docstrings and a vague attempt at auth, it's still p clumsy imo lol

Continuing with #4


use generell url parser.

Currently the code uses the same regex multiple times:
func get_authorization_host() -> String:
	var matches = url_regex.search(authorization_url)
	if matches == null: return ""
	return matches.get_string(1)

func get_authorization_path() -> String:
	var matches = url_regex.search(authorization_url)
	if matches == null: return ""
	return matches.get_string(6)

a better solution could be a "URL" class.
just a quick note:
class Url {
  port
  host
  path
  ....
  new() {

  }

  static fromString(url string) {
     // use regex to fill props
  }
}

I wonder why godot doesn't have such a class already.

@kanimaru I think, most of the time, it's not needed in game development. In which game do you need a URL parser? Okay yes, now it would be useful xD

All games with multiplayer support via REST? :D

Touché! xD but I think with the native Godot client you could use the full URL address without splitting it into host and path. So most of the time, nobody needs to split it.