Index signature is missing in type (only on interfaces, not on type alias)

TypeScript Version:  2.2.2
Code
interface IndexType {
     [key: string]: string;
}

interface doesNotWork {
    hola: string;
}
type doWorks = { hola: string };

let y: IndexType;

const correctA = { hola: "hello" };
const correctB: doWorks = { hola: "hello" };
//error should be assignable to y
const error: doesNotWork = { hola: "hello " };

y = correctA;
y = correctB;
y = error; //Index signature is missing in type 'doesNotWork'
y = {... error}; //workaround but not equivalent since the instance is not the same

Expected behavior:
The code should not result on a compiler error since the interface doesNotWork is equivalent to the type { hola: string }
Actual behavior:
Variable error of type doesNotWork can't be assigned to y

Same here for 2.3

Seeing this still in 2.4. Here's a playground repro.
This appears to be a bug considering implicit index signatures is listed as a feature of v2.0.

Any update regarding the issue? Still not fixed as of 2.4.2.
Playground

Just to fill people in, this behavior is currently by design. Because interfaces can be augmented by additional declarations but type aliases can't, it's "safer" (heavy quotes on that one) to infer an implicit index signature for type aliases than for interfaces. But we'll consider doing it for interfaces as well if that seems to make sense

@RyanCavanaugh Thanx for reasoning. Can I say as a rule of thumb to use 'type' for internal interfaces since I don't need augmentation and 'interface' for external to be able to augment ?

There are some other differences between type aliases and interface that might affect your choice - namely you can extend an interface but not a type alias. So it's not quite that simple, but as rules of thumb go it's not a bad one.

You can extend types through intersection types.
Is there anything I miss here?
// Interface
interface A { x: number; }
interface B { y: string;}

interface C extends A, B { b: boolean;}

var x: C = { b: true, x: 1, y: "" };

// Type
type TA = { x: number; };
type TB = { y: string; };

type TC = TA & TB & { b: boolean; };

var tx: TC = { b: true, x: 1, y: "" };

I have an example where this rule is inconsistent when casting to the expected indexed type:
interface MyInterface {
  a: number
  b: number
}

const doesNotWork: { [key: string]: number } = {} as MyInterface
// Index signature is missing in type 'MyInterface'.

const doesWork: { [key: string]: number } = {} as { a: number, b: number }

Playground link
What is it that is considered different about these that is preventing the first case? Note that this is occurring in 2.7 (see the playground link)

Thanks @patrickneugebauer - I had noticed those rules too, and have resorted to using type over interface in the common case, to allow building layers of type interactions without hitting walls of errors like these.
In my example, changing the interface to a type does indeed get around the error.

@RafaelSalguero thanks a lot for posting this, at least I found the workaround in this post. @patrickneugebauer thanks for your cases. Indeed weird behavior with interfaces :(

Ran into this when trying to type a function argument that can have arbitrary keys but a known set of values. Unfortunately, the variable I was trying to pass into the function is generated from graphql-code-generator, so requires a bit more legwork than just changing an interface to a type manually. A quick workaround is to spread the variables before passing it in.
interface X {
    search?: string | null
}
const x: X = { search: "hello" }

function y(z: { [key: string]: string | string[] | null | undefined }) {
    console.log(y);
}

y(x) // Error
y({ ...x }) // Fine

Playground

This limitation also makes it practically infeasible to use a custom JSON type as a generic constraint for HTTP request libraries. Context: https://github.com/sindresorhus/ky/pull/80#issuecomment-460216040

How can I define a function that should receive an object where all the properties are string types?
I thought I could do:
type ObjectWithStrings = { [key: string]: string }
declare const requireObjectStrings: <T extends ObjectWithStrings>(object: T) => void;

However due to this issue, this won't work if the value I happen to pass in uses an interface type:
interface MyInterface {
    foo: string;
}

declare const myInterface: MyInterface;

// Error: Index signature is missing in type 'MyInterface'.
requireObjectStrings(myInterface)

It's easy to say that I should change the type definition from interface to type, but if this comes from a third party, there's not always the option to change the type definition. So is there a better way to define requireObjectStrings so I don't run into this limitation?

Rather than this:
interface MyInterface {
  foo: string;
}

Can you do this?
type MyInterface = {
  foo: string;
}

I'm not sure what part of your question is in the third party library, and what you control.

what part of your question is in the third party library

The type definition is defined by a third party (the type is code generated), so we can't change it from interface to type.

Maybe something like this will help you:
declare const myInterface: MyInterface;
const myInterface2: Pick<MyInterface, keyof MyInterface> = myInterface;

requireObjectStrings(myInterface2)

@OliverJAsh That's okay.
Without requiring index signature any other library can inject non string properties.
E.g.
// lib1.d.ts
interface MyInterface {
    foo: string;
}

declare const myInterface: MyInterface;

// lib2.d.ts
interface MyInterface {
    someNumber: number;
}

// index.ts
console.log(myInterface.someNumber); // Compiles fine

With index signature you get an error:
interface MyInterface {
    foo: string;

    [k:string]: string;
}

declare const myInterface: MyInterface;

interface MyInterface {
    someNumber: number;
}

console.log(myInterface.someNumber);

That's an issue for us as well

Why is this still not fixed?

It seems type will also report error on v3.6.0-dev.20190806, what means interface and type are at least consistent.

So still no suggested solution for @OliverJAsh's question? https://github.com/microsoft/TypeScript/issues/15300#issuecomment-484128015
I'm lost on how this problem can be solved while this issue is present

Maybe?
declare const requireObjectStrings: <K extends keyof T, T>(object: T & Record<K,string>) => void;

@OliverJAsh @JemarJones you can do something like this:
declare const requireObjectStrings: <T extends {[K in keyof T]: string}>(object: T) => void;

interface MyInterface {
  foo: string;
}

declare const myInterface: MyInterface;
requireObjectStrings(myInterface);

Of course, this workaround is annoying since you can't create a concrete type for it.

Is there a fix in place for this or is this ruled out as a design choice? @SeaRyanC
There are instances where we want to infer interfaces to more generic types. The vast majority of libraries out there prefer to use interface than types and in an instance where we'd like to infer them to more generic types, we can't make the conversion.
A lot of these implementations are classes implementing interfaces so I'm not sure exactly how to get the best of both using interfaces for classes to implement from -- and using utilities that
accept a more generic structure (while keeping compatibility).

I also encounter this pain. It is typically located at the boundary of the code: when sending data through API calls that just require plain JSON hashes (think of a GraphQL variables argument) but  this argument is typed for soundness checking in the Typescript code.
For now, I resort to the { ...x } trick of https://github.com/microsoft/TypeScript/issues/15300#issuecomment-436793742 but it looks hacky. It would be great to have an idiomatic way of handling this use case -- especially because it encourages the good practice of typing more precisely.

As others mentioned, the workaround from #15300 (spread into an object literal) does feel hacky, but I'm also unclear on how to accomplish something similar when working with an array of interface objects.
Maybe this is another reason to reconsider this design decision?

I just found myself in a very similar situation to the one described by @mcpatten (had an interface wrapped in a Promise<> that I wanted to widen) where it's not possible to use the spreading operator trick. For anybody that comes across this, the solution in this case is to use type instead of interface to define your types, as it's already been mentioned earlier in this thread.

To clearify: the problem is assigning from { x: string } to { [i: string]: string } is essentially dangerous in TypeScript world.
type GenericType = { [i: string]: string };
type SpecialType = { x: string };

const a = {
    x: 'str',
    y: 3,
};
const b: SpecialType = a;
const c: GenericType = b;

console.log(c.y.toUpperCase()) // Runtime Error

Playground
This code passes the compiler but throws runtime error(because c.y is not string but number).
And with interface, it can cause more confusing issue because of the extending feature.
interface GenericType {
    [i: string]: string;
}
interface SpecialType {
    x: string;
}
interface SuperSpecialType extends SpecialType {
    x: string;
    y: number;
}

const ss: SuperSpecialType = {
    x: 'abc',
    y: 3,
};
const s: SpecialType = ss; // Allowed
const g: GenericType = s; // Not allowed(currently)

Playground
If it is also allowed, it can cause bugs which hard to find. That's why it's not allowed(Right?)
The GenericType is actually NOT generic type of SpecialType. So the right way to solve is writing a type-guard, I think.
if (!isGenericType(s)) throw '';
const g: GenericType = s;

@acomagu From my understanding your argument is not so much about the specific behavior being discussed in this issue but against type widening, that is, allowing casts of concrete types into more generic ones. It is well understood that type widening worsens type safety but, nonetheless, typescript generally allows it, as it can be seen in the following code:
const concrete: 42 = 42;
const aBitMoreGeneric: 42 | 0 = concrete
const evenMoreGeneric: number = aBitMoreGeneric
const extremelyGeneric: any = evenMoreGeneric

So, if this kind of type widening, which removes all type safety, is allowed, why is casting a { x: string } interface to { [i: string]: string } not allowed (even though casting it to any is allowed)?  This leads us to the real problem that is caused by this behaviour: lack of consistency, a problem that manifests itself in three different fronts:

Why is type widening generally allowed in typescript but not in this specific case?
Why is type widening possible on types declared using type but not on those declared using interface?
If this behaviour is disallowed, why not provide an error message saying so (for example the typical one that says that two types are incompatible and casting one to the other requires an intermediate cast to unknown) insteadof the cryptic Index signature is missing in type?

All in all, you could make the design decision that type widening is bad, ban it, and then apply that consistently, banning all direct casts to any, or you could go and say that this case is an exception and then disallow type widening for both interface and type-declared types in order to make this more consistent, or you could even keep the current behavior and allow widening type but not interface, but replace the error message with one that is clearer. Whatever you decide to do, it seems better than the status quo.

@corollari The type 42 | 0 is a generic type of 42, but { [i: string]: string } is not generic type of { x: string }, I think. "A is a generic type of B" means "The all values acceptable for B can be also acceptable for A", right? But regarding { [i: string]: string } and { x: string }, there is counterexample, { x: 'str', y: 3 }.
{ x: 'str', y: 3 } is acceptable for { x: string } but not { [i: string]: string }. Because the former type DON'T defines the properties other than x but the latter type demands the all properties should be string. So { [i: string]: string } is not a generic type of { x: string }.
That's why the casting between these types is different than 42 | 0 and 42, or number. It's not widening.

Why is type widening possible on types declared using type but not on those declared using interface?

I'm not sure but I guess because interface can cause more complex problem like described at the my previous post.

If this behaviour is disallowed, why not provide an error message saying so (for example the typical one that says that two types are incompatible and casting one to the other requires an intermediate cast to unknown) insteadof the cryptic Index signature is missing in type?

Agree. More meaningful error message can be helpful for all.

@corollari The type 42 | 0 is a generic type of 42, but { [i: string]: string } is not generic type of { x: string }, I think. "A is a generic type of B" means "The all values acceptable for B can be also acceptable for A", right? But regarding { [i: string]: string } and { x: string }, there is counterexample, { x: 'str', y: 3 }.
{ x: 'str', y: 3 } is acceptable for { x: string } but not { [i: string]: string }. Because the former type DON'T defines the properties other than x but the latter type demands the all properties should be string. So { [i: string]: string } is not a generic type of { x: string }.

I see what you are getting at, if we assume that casting is transitive, then that property would be broken in your counterexample. But I think that assumption is false (just look at unknown casts such as 1 as unknown as string, clearly number cannot be casted to string, yet it can through an intermediate cast)
So, this gives us that:

{ [i: string]: string } is a generic type of { x: string }
{ x: string } is a generic type of { x: string, y:number } (using your definition, meaning that it's possible to cast one type to the other)
{ [i: string]: string } is NOT a generic type of { x: string, y:number }

I'm not sure but I guess because interface can cause more complex problem like described at the my previous post, around extends.

These same problems also occur with type:
type GenericType = {
    [i: string]: string;
}
type SpecialType = {
    x: string;
}
interface SuperSpecialType extends SpecialType {
    x: string;
    y: number;
}

const ss: SuperSpecialType = {
    x: 'abc',
    y: 3,
};
const s: SpecialType = ss; // Allowed
const g: GenericType = s; // Also allowed

Playground Link

@corollari I'm sorry, I couldn't fully understand your point. What does the "transitive cast" mean? as casting has ability to narrow the type forcely with danger(e.g. unknown -> string). But we are talking about implicit casting, right? { x: 'str', y: 3 } as unknown as { [i: string]: string } is possible, but it can't be done with implicit casting.

{ x: string } can be casted to { [i: string]: string } directly

This conversion is potentially dangerous. In my knowledge, TypeScript don't allow dangerous implicit casting.

These same problems also occur with type:

Oh, sorry, I didn't know that. Your pointing make sense, so the behaviors may have to be normalized.

@acomagu I was referring to the mathematical definition of a transitive property, which, when applied to type casting would look like this:
Casting is transitive if, given three types A, B and C such that A can be cast to B and B can be cast to C, A can be cast to C.
I can see how my previous explanation can be confusing, but what I was trying to convey is that, when talking about casting in general (without specifying implicit or explicit casting) there's already some cases in Typescript where that property is broken.
In any case, that's an argument concerning the discussion on whether casting from { x: string } to { [i: string]: string } should be allowed, whether that be through explicit or implicit casting (currently it's impossible through either). Personally, I'm not sure what's the best course of action here, as the problems that you've pointed out are very real but I can also see a need for this type of casts, so I don't think I can add much to the discussion. What I feel more strongly about is the inconsistency of the current state, which we seem to agree about.

Just to fill people in, this behavior is currently by design. Because interfaces can be augmented by additional declarations but type aliases can't, it's "safer" (heavy quotes on that one) to infer an implicit index signature for type aliases than for interfaces. But we'll consider doing it for interfaces as well if that seems to make sense

@RyanCavanaugh it wouldn't make sense without also breaking polymorhism, which is a cornerstone of OOP. All sub-interfaces should be type compatible with their common base interface to enable polymorhism. Although an interface may be type compatible with an indexed interface by way of inference, it doesn't necessarily mean that its sub-interfaces are type-compatible, because they may introduce additional properties of any type.
@RafaelSalguero consider the following interface:
interface ThisIsWhyItDoesNotWork extends doesNotWork {
    meaningOfLife: number;
}

It's a well-established OOP convention that expressions of type ThisIsWhyItDoesNotWork can be assigned where expressions of type doesNotWork can be assigned. Although doesNotWork is compatible with the index signature of IndexType, ThisIsWhyItDoesNotWork isn't. TypeScript can't determine at compile-time whether expressions of type doesNotWork are instances of doesNotWork or ThisIsWhyItDoesNotWork, so it can't allow doesNotWork expressions to be assigned where IndexType is expected.
You can fix this in one of three ways:

Use doWorks instead of doesNotWork
Introduce the same constraint into doesNotWork, allowing TypeScript to make the desired inference:interface doesNotWork {
    [key: string]: string;
    hola: string;
}

Extend IndexType:interface doesNotWork extends IndexType {
    hola: string;
}

I vote to close this issue.

I was having a similar problem trying to type a json supported structure.
interface MyJSON {
  [x: string]: number | string;
}
interface Body {
  a: number;
  b: string;
}
function callAPI(body: MyJSON) {
  .
  .
  .
}
const body: Body = {
  a: 1,
  b: 'some value'
}
fetchAPI(body) // Error

I was able to solve this by making the MyJSON interface accept symbols as keys as well.
interface MyJSON {
  [x: string | symbol]: string | number;
}

This makes sense but what's odd is that [x: string | number] and even [x: string | string] seem to solve the problem as well.

Sorry, might be little bit off-top, but i didn't get why this type inference works:
interface Foo { foo: string }

const x = { foo: 'stuff', bar: 1 }

// does not error out, but should ?
const foo: Foo = x

// errors out as expected
const foo2: Foo = { foo: 'stuff', bar: 1 }

@sepo27 x is structurally assignable to Foo, because Foo doesn't specify bar?: never.
foo2 errors out for convenience and productivity, not for correctness.
https://www.typescriptlang.org/docs/handbook/interfaces.html#excess-property-checks

I was having a similar problem trying to type a json supported structure.
interface MyJSON {
  [x: string]: number | string;
}
interface Body {
  a: number;
  b: string;
}
function callAPI(body: MyJSON) {
  .
  .
  .
}
const body: Body = {
  a: 1,
  b: 'some value'
}
fetchAPI(body) // Error

I was able to solve this by making the MyJSON interface accept symbols as keys as well.
interface MyJSON {
  [x: string | symbol]: string | number;
}

This makes sense but what's odd is that [x: string | number] and even [x: string | string] seem to solve the problem as well.

Symbol throws an error for me An index signature parameter type must be either 'string' or 'number'.ts(1023)

This limitation makes it impossible to provide type definitions for a method that accepts anything JSON-serializable without bugging users to use workarounds:
type JSONValue =
  | string
  | number
  | boolean
  | null
  | JSONValue[]
  | { [property: string]: JSONValue };

type Argument = {
  foo: JSONValue;
}

declare function takesArg(arg: Argument): void;

// ^-- library code
// =======================
// v-- user code

interface SpecialArgument {
  property: number;
}

declare const foo: SpecialArgument;
takesArg(foo)
//       ^-- error here, but should work

https://www.typescriptlang.org/play?#code/C4TwDgpgBAUgygeQHIDUCGAbArtAvAKCigB8oBnYAJwEsA7Ac0JKlqwFsAjCSp0jge34YIaWrxZYMGcfGTpsEANoBdcQG8oisJX6RKoAFzkqdesqOzUmHFAC+Abnz5QkKAEFK9dhFrAouKDUmADNBC0QrBUdbJwATCABjDDRKaGCsWgTgan5aKGA0AGsIMg96AAoU+iMy718ASiMAN35qWMd8AHpOqAA9AFp+qAxqDkoUkCgE-niuntwFxaXllYW5qCbBqCwybimZiCc6YG5gtAToOEgE6kxath8-IKJtXW5DCU5uaLjE5NT9rQKFBQvwjFdErcMPdHo4CsVSp5yqD6usiOi+ltuDpKFAABbcCAAGigHCwfjIeP4kliUAA7vxKIUgA

@AlCalzone I have the same problem, though not sure why you defined the "Argument" type like that. The current error you're getting is "Property 'foo' is missing in type SpecialArgument but expected in type Argument" which is expected. But if you change the "takeArg" function to accept a JSONValue, you would get the error "Index signature missing...." which I'm not sure how to go around.

Uhh, that was a mistake on my part. I'll update the example.

just came across this. Was using an interface as I wanted to extend another interface. Ran into this error, switched my interface to a type (type = { <my_type> } & <other_type>) and voila, fixed. It is not intuitive that this should error out 🤷

I do think some change is certainly worthwhile, as this issue seems to extend to Records. For example, ESLint recommends using Record<string, unknown> instead of object as a type. However, interfaces by default are considered incompatible with Record<string, unknown>, despite the fact that everything is supposed to be assignable to unknown.
Though not quite what I wanted to hear, I think steve-taylor's argumet earlier is valid. But if your object is expected to take virtually anything as a property's value due to the unknown, it doesn't make sense for interfaces to be incompatible. (Extension is a workaround, but it doesn't really make sense here.)
Interestingly enough, interfaces are assignable to Record<string, any>.
@steve-taylor any thoughts on this particular scenario? I'd think making interfaces assignable to Record<string, unknown> wouldn't break OOP.

Most people here seem to want to be able to assign types like type Point = { x: number, y: number } to type Dict = { [key: string]: number }. But, if I'm not mistaken, a Point just isn't a Dict: with a Dict, you're guaranteed that a number exists for all keys; with a Point, you're only guaranteed it exists for x and y.
It seems to me that the proper solution to this is to create a new kind of index type; call it FiniteRecord for example. Then an object of type FiniteRecord<string, number> would have the guarantee that all of its string properties would map to number values. Note that there would be no guarantee that the object would actually have any string keys at all.
Then, an { x: number, y: number } would be assignable to a FiniteRecord<string, number>.
FWIW, I think Partial<Record<K, V>> is very close to FiniteRecord<K, V>. However, you currently can't assign a { x: number, y: number } to a Partial<Record<string, number>>.

Most people here seem to want to assign types like { id: number } to { [key: string]: number }. But, if I am not mistaken, a value of type { id: number } just isn't a value of type { [key: string]: number }. The second type demands a value for each key, but a { id: number } only provides a value for the particular key id.
It seems to me that the proper solution to this is to introduce a new kind of index type; call it FiniteRecord. An object of type FiniteRecord<string, number> would have the constraint that all string keys that do exist on the object are associated with string values. However, no guarantee would be made that any keys actually exist.
Then, for instance, { id: 15 } would be assignable to FiniteRecord<string, number>.
FWIW, the type FiniteRecord<K, V> is pretty similar to a Partial<Record<K, V>>. However, partial records don't solve the problem being discussed in this thread..

Gotta change dozens of typings from interface to type because of this bug :(

With same problem here, just raising the topic

I encountered this today too, trying to provide a type definition for a library which accepts arbitrary records, and not wanting to change all my interfaces to types.
I hacked away a bit and here's what I came up with

type OnlyObjects<T> = T extends string | number | null | undefined | Array<unknown> ? never : T

// Ensure that type T is an object-ish 'type' or 'interface' which only has string keys, and ValueType values
type CheckRecord<T, ValueType> = OnlyObjects<T> & ({
    [K in keyof T]: K extends string ? ( T[K] extends ValueType ? T[K] : never) : never
})

// My record processor accepts record-y things string|number values
function recordProcessor<T>(data: CheckRecord<T, string|number>) {
    // This is fine.
    console.log(Array.from(Object.entries(data)))

    console.log(data['foo']) // This correctly fails - 'foo' might not be present

    return Array.from(Object.entries(data)) // Unfortunately, Return type is [string, unknown][]
}

The approach has a drawback which I was unable to fix: Inside a function which uses this, the values of data are considered to be unknown instead of string|number which is what I would prefer. I think that's probably solvable, but I don't need to solve it for my usecase since I'm adding types for an external library.
But overall, I think this 95% gets the job done. This lets you write functions which take objects with string keys and specified value types, without having to go and change all of your interface to type.
Here's a playground link with test cases.

Stumbled upon this today:
type MapObject = Record<string, unknown>;

interface ChartData {
    labels?: any;
    datasets?: any;
};

function f1(chartData: ChartData) {
    f2(chartData)
     // ^^^^^^^^
     // Error: Index signature is missing in type 'ChartData'
}

function f2(obj: MapObject) {}

Playground link: https://bit.ly/2IKwONz
To workaround it I do:
function f1(chartData: ChartData) {
    f2(chartData as MapObject)
}

Well... the fact "it works with types" is rather a bug than a feature.
Using this workaround is gonna lead to runtime errors, unfortunately.
type A = { a: number }
type B = { b: string }

type C = A & B

const c = { a: 2, b: 'coucou' }
const d: A = c

type E = { [k: string]: number }
const e: E = d

This compiles without any error.

I do think some change is certainly worthwhile, as this issue seems to extend to Records. For example, ESLint recommends using Record<string, unknown> instead of object as a type. However, interfaces by default are considered incompatible with Record<string, unknown>, despite the fact that everything is supposed to be assignable to unknown.
Though not quite what I wanted to hear, I think steve-taylor's argumet earlier is valid. But if your object is expected to take virtually anything as a property's value due to the unknown, it doesn't make sense for interfaces to be incompatible. (Extension is a workaround, but it doesn't really make sense here.)
Interestingly enough, interfaces are assignable to Record<string, any>.
@steve-taylor any thoughts on this particular scenario? I'd think making interfaces assignable to Record<string, unknown> wouldn't break OOP.

I totally agree with you bro, came from eslint's Record<string, unknown> recommendation as well.

I do think some change is certainly worthwhile, as this issue seems to extend to Records. For example, ESLint recommends using Record<string, unknown> instead of object as a type. However, interfaces by default are considered incompatible with Record<string, unknown>, despite the fact that everything is supposed to be assignable to unknown.
Though not quite what I wanted to hear, I think steve-taylor's argumet earlier is valid. But if your object is expected to take virtually anything as a property's value due to the unknown, it doesn't make sense for interfaces to be incompatible. (Extension is a workaround, but it doesn't really make sense here.)
Interestingly enough, interfaces are assignable to Record<string, any>.
@steve-taylor any thoughts on this particular scenario? I'd think making interfaces assignable to Record<string, unknown> wouldn't break OOP.

I totally agree with you bro, came from eslint's Record<string, unknown> recommendation as well.

Something that can help considerably with this issue is to use the following type:
export type Typify<T> = { [ K in keyof T ]: T[ K ] };

Now, if you encounter an issue similar to the one below, you will be able to get out of troubles:
type O1<T = any> = {
    [ K: string ]: T;
};

interface O2<T = any> {
    [ K: string ]: T;
}

interface A {
    a: number;
}

const a: A = { a: 1 };

const o1: O1 = a; // working
const o2: O2 = a; // working

const f1 = <T extends {}>(arg: O1<T>): T => undefined;
const f2 = <T extends {}>(arg: O2<T>): T => undefined;

const ret1 = f1(a); // Argument of type 'A' is not assignable to parameter of type 'O1<{}>'. Index signature is missing in type 'A'.ts(2345)
const ret2 = f2(a); // Argument of type 'A' is not assignable to parameter of type 'O1<{}>'. Index signature is missing in type 'A'.ts(2345)

const a2: Typify<A> = { a: 1 };

const ret21 = f1(a2); // working!!
const ret22 = f2(a2); // working!!

I am dealing with this issue with using Mapped Types(https://www.typescriptlang.org/docs/handbook/2/mapped-types.html)
let's say I've got this interface
interface PaginationArgs {
  limit: number;
  offset: number;
  sort: Array<string>;
}

And I've got a selectorFamily as follows:
export const getData = selectorFamily<Array<Data>, PaginationArgs>({
  key: 'getAvailableData',
  get(paginationParams) {
    return async () => {
      const rawData = await someService.fetchData(paginationParams);
      const data = await rawData.json();

      return fetchedNotes;
    };
  },
});

Typescript will throw this error:
TS2344: Type 'PaginationArgs' does not satisfy the constraint 'SerializableParam'.   Type 'PaginationArgs' is not assignable to type 'Readonly<{ [key: string]: SerializableParam; }>'.     Index signature is missing in type 'PaginationArgs'.

and I added this generic type mapper:

type SelectorMapper<Type> = {
  [Property in keyof Type]: Type[Property];
};

export const getData = selectorFamily<Array<Data>, SelectorMapper<PaginationArgs>>({
  key: 'getAvailableData',
  get(paginationParams) {
    return async () => {
      const rawData = await someService.fetchData(paginationParams);
      const data = await rawData.json();

      return fetchedNotes;
    };
  },
});

Typescript will happy now. Hope this will help you all...

This is becoming problematic. A recent change in slonik made this issue resurface. It's preventing ergonomic transitions to a more typesafe approach without breaking changes.

The problem persists in Typescript 4.2 😞

Here's how we get around this:
export type IndexSignatureHack<T> = { [K in keyof T]: IndexSignatureHack<T[K]> }

https://www.typescriptlang.org/play?ssl=1&ssc=1&pln=12&pc=1#code/JYWwDg9gTgLgBAbzgYQMqoApQmAprYXAZzgF84AzbEOAcilwEMBjGWgWACgvcAPSWHBgBPPHACSAOwAmfVMADmkxjACuDABIsA1gB4AKgD44AXkRwA2gGk4wSXG25hECnH0BdAFwSZcxcrVNHQNrd2NSLi4KVUlWYAh7CkkACggAIwArbyQLR2FvIhgoOwUvOBjtSQgAd3tSAEpvADcIYGlECO5OZgTCuELhABtcbylZXnklFXVcLWY9NExsPAJiYzMELjhKBJgAdVxFAAsYbwBWAAYLgBouTqiUgeH6riA
You can verify that there is still type safety by changing the font weight from 500 to '500', for example.

Thanks @migueloller !! That indeeds solve the issue. But now I'm confused about a completely different issue 🙈 Your playground link doesn't use a conditional (as you posted in your answer). It's just:
export type IndexSignatureHack<T> = { [K in keyof T]: IndexSignatureHack<T[K]> }

and it works anyway! I can't understand how is TS solving this apparent infinite recursion. Could you explain that please?
(btw, I've just posted asking about a simplified version of that infinite recursion in stackoverflow)

@lgenzelis, ah yes, I adapted the utility type to be more robust by adding the conditional but forgot to update the playground. Without the conditional, it would fail, for example, passing it to React. See here. In that example, if you use the non-ternary version, then there will be type errors.

```ts
interface MyInterface {
  a: number
  b: number
}

const doesNotWork: { [key: string]: number } = {} as MyInterface
// Index signature is missing in type 'MyInterface'.

const doesWork: { [key: string]: number } = {} as { a: number, b: number }

type MyInterface= {
a: number
b: number
}
const doesNotWork: { [key: string]: number } = {} as MyInterface

Seems related, currently there's no way to enforce that object should have attribute values of specific type only.
Example: I want to define an abstract Table Row, basically any object limited to attribute values as primitive types. But it doesn't work
// Table row
export type Row = Record<string, string | number | undefined>

// User
interface User { name: string }
const jim: User = { name: 'Jim' }
const row: Row = jim // <== Error

@al6x, What about:
// Table row
type Row = Record<string, string | number | undefined>;

// User
interface User { name: string }
type UserRow = { [userProperty in keyof User]: string | number | undefined };
const jim: UserRow = { name: 'Jim' };
const row: Row = jim; // <== works

I assume it works because userProperty in keyof User is compatible with string.
The above IndexSignatureHack is one step better as each property has the correct type:
export type IndexSignatureHack<T> = { [K in keyof T]: IndexSignatureHack<T[K]> }

// Table row
type Row = Record<string, string | number | undefined>;

// User
interface User { name: string }
type UserRow = IndexSignatureHack<User>;
const jim: UserRow = { name: 'Jim' };
const row: Row = jim; // <== works

my workaround for an error
Type 'ISomeInterface' does not satisfy the constraint 'Record<string, unknown>'.
Index signature  is missing in type 'ISomeInterface'.(2344)
I used Omit utility type
Omit<ISomeInterface>, ''

What about this utility type?
export type IndexSignature<O extends object> = {
  [P in keyof O]: O[P];
};

interface IFooBar {
    foo: string;
    bar: number;
}

declare const foobar1: IFooBar
declare const foobar2: IndexSignature<IFooBar>

declare function fn(obj: Record<string, unknown>): void

fn(foobar1); // Error
fn(foobar2) // Work

Playground Link

I would rather request expected behaviour to be like for interfaces. Otherwise, types can break runtime (we will have different types in TS and runtime)
Playground link
Code:
type A = {str: string}
type B = A & {count: number}

const b: B = {str: 'str', count: 1}
const a: A = b
const c: Record<string, string> = a
const d: string = c.count

console.log(typeof d)
// "number"

What about this utility type?

@younho9 Also for deep recursive objects:
type DeepIndexSignature<O extends object> = {
  [P in keyof O]: O[P] extends object ? DeepIndexSignature<O[P]> : O[P]
}

interface Lar {
  coo: string;
  doo: string;
}

interface IFooBarCar {
  foo: string;
  bar: number;
  car: {
    lars: Lar[];
  };
}

declare const foobar3: IFooBarCar
declare const foobar4: DeepIndexSignature<IFooBarCar>

type RecursiveObj = string | number | boolean | RecursiveObj[] | { [k: string]: RecursiveObj }

declare function fn2(obj: RecursiveObj): void

fn2(foobar3)
fn2(foobar4)

Playground link

{ id: number } should be assignable to { [key: string]: number | undefined } but it isn't

@Nokel81
no, that's basic misconception even in javascript, there is a difference between inexistence of a property and a property being equal to undefined. ({}).nonExistingProperty === undefined is of course true, but still, proper type system should see a difference between for example optional property of type number and assinging undefined to that property (which TypeScript 4.4 introduced for real: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-4.html#exact-optional-property-types---exactoptionalpropertytypes ) because it may lead to runtime errors otherwise

Yes I know, sorry I meant that it should be assignable to Partial<Record<string, number>>. The use cases that I want this for is when I want to accept any object with that shape, since I generally will be acting on it via Object.entries and what not.

I believe I have created a solution to this problem, which seems to work well.
Currently, I am working on a typescript library, which needs to take in some data (unknown shape), JSON.stringify it and send it on its way. My problem was that when you pass a Date object to JSON.stringify, it will create a string representation of that date. But when you parse the string back, it will keep it as a string. This also applies to instances of classes and similar things.
I wanted users using my library to see an error when they pass an object with date property or something not JSON serializable. I googled a bit and found JSON type for typescript that works well. But I am running into this index signature is missing... error too. I cannot force users of my library to not use interfaces, or to wrap everything they pass in with the DeepIndexSignature generic as mentioned above.
My solution is straight forward, although I am not sure if it will work for every use case.
/**
 * JSON serializable object.
 */
export type Json = {
  [key: string]: string | number | boolean | Json | JsonArray;
};

/**
 * JSON serializable array.
 */
export type JsonArray = Array<string | number | boolean | Json | JsonArray>;

/**
 * Creates a new type, that mimics O exactly,
 * except replaces every unsupported value type by union of supported ones.
 */
type RestrictedObject<O, AllowedTypes> = {
  [P in keyof O]: O[P] extends AllowedTypes
    ? O[P]
    : Record<string, any> extends AllowedTypes
    ? O[P] extends Record<string, unknown> ? RestrictedObject<O[P], AllowedTypes>
    : AllowedTypes : AllowedTypes;
};

/**
 * Create wrapper for restricting objects by the Json type
 */
type RestrictedJsonObject<T> = RestrictedObject<T, Json[keyof Json]>

/**
 * Function that needs only JSON serializable objects
 */
function serializeData<T>(data: RestrictedJsonObject<T>): void {
    console.log(data);
}

interface CorrectInterface {
    a: string;
    b: number;
    c: {
        d: string;
        e: number;
    };
}

interface WrongInterface {
    a: string;
    b: string;
    c: {
        d: string;
        e: Date;
    };
}

const value1 = {} as CorrectInterface;
const value2 = {} as WrongInterface;

serializeData(value1);
serializeData(value2); // Throws TS error

You can see that I am able to pass in any object that matches the index signature, and it doesn't throw an error.
When I try to pass in the wrong object, it will throw an error. The last line of the error is index signature, but the line before states that Type 'Date' is not assignable to type 'Json' which I think will have to be enough. It is not the best developer experience, but it does its job.

Why is this not fixed yet? I have interfaces auto-generated by a third party library. Now how do I replace them with types, as some clever people advise?

我已收到你的邮件

我已收到你的邮件

Forever ago, @RyanCavanaugh said,

Because interfaces can be augmented by additional declarations but type aliases can't, it's "safer" (heavy quotes on that one) to infer an implicit index signature for type aliases than for interfaces.

Could someone walk me through why declaration merging matters again?  Imagine a world in which there were no errors in the following code:
interface Foo {
  a: string;
  b: string;
  c: string;
}
function yellProps(x: { [k: string]: string }) {
  Object.keys(x).forEach(k => console.log(x[k].toUpperCase() + "!!!"));
}
function bar(foo: Foo) {
  yellProps(foo); // currently an error, but imagine if it were not
  yellProps({ ...foo }); // currently okay
}

Now someone comes along and merges something unexpected:
interface Foo {
  d: number;
}

Wouldn't this just produce errors inside bar(), as expected?
function bar(foo: Foo) {
  yellProps(foo); // now it should be an error
  yellProps({ ...foo }); // currently error
}

Isn't that... good?  I mean, people who want this feature presumably would be happy with new errors appearing if merges happen.   Right now every attempted use of a non-index-signature-having interface in a place that needs an index signature is an error.  I'd think the removal of these errors would be worth the potential of some of them coming back due to merging.
So I'm obviously not seeing the argument that declaration merging matters... could someone spell it out for me?

Can we all agree on at least one fundamental concept here, given these types which I have made partial and readonly to eliminate any possible quibbles:
type Super = {readonly [_ in string]?: string}

interface Sub {readonly id: string}

There is no world in which Sub should not be assignable to super, yet this is a typescript error:
const sub: Sub = {id: '1234'};
const sup: Super = sub;  // TS2322: Type 'Sub' is not assignable to type 'Super'

So clearly there is a flaw in the current design. To what extent (removing partial or readonly) is another question.

Implicit index signatures are useful but unsound.  I don't see how partial/readonly affects the issue, and there certainly does seem to be at least one world in which Sub being assignable to Super results in unsafe behavior.  For example, SubSub is assignable to Sub but not to Super:
interface SubSub extends Sub {readonly age: number}

const subsub: SubSub = { id: "abc", age: 12 }; // okay
const sub: Sub = subsub; // okay
const sup: Super = sub; // okay?
sup.age?.toUpperCase(); // okay 💥 RUNTIME ERROR

This issue is about whether or not the usefulness of allowing implicit index signatures for interfaces outweighs the unsoundness.

Personally I think the usefulness does outweigh the unsoundness, just as it apparently does with implicit index signatures for type aliases:
type Super = { readonly [_ in string]?: string }
type Sub = { readonly id: string } // type, not interface
interface SubSub extends Sub { readonly age: number }

const subsub: SubSub = { id: "abc", age: 12 }; // okay
const sub: Sub = subsub; // okay
const sup: Super = sub; // okay
sup.age?.toUpperCase(); // okay 💥 RUNTIME ERROR

and just as it apparently does for "implicit optional properties" for all object types:
interface Foo { a: string }
interface Bar extends Foo { b?: number }
interface Baz extends Foo { b?: string }

const baz: Baz = { a: "", b: "" }; // okay
const foo: Foo = baz; // okay
const bar: Bar = foo; // okay
bar.b?.toFixed() // okay 💥 RUNTIME ERROR

And as I said above, I'm not sure I see how declaration merging matters, since merging can already cause existing code to error:
interface Here { a: string, b: number }
const here: Here = { a: "", b: 123 } // compiler error now
// ... later
interface Here { c: "HAHA" }

which presumably is a good thing, since merging in stuff that invalidates the developer's assumptions should result in errors where those invalidations occur.

@jcalz good point, didn't think of that example. Agree that the usefulness does outweigh the unsoundness.

@jcalz Aren't you cheating there when accessing sup.age? If you widen subsub to Sup or Super, then you should no longer have access to age. You should be using a type guard to get it back into a SubSub first before trying to access that property, right?

I summed up a model to understand this situation:
I assume that each ts type can be described by two sets, called the accept set and the offer set, each element of both sets is a ts object literal. A extends B if the offer set of type A is a subset of the accept set of B.
To describe these two sets, I created a small grammar, which I demonstrate below with some small examples:

examples

[]
Represents a collection with no elements in it

[{ }]
Represents a collection with only one object: {}

[{ x: 0 }]
Represents a collection with only one object: { x: 0 }

[{ x: string }]
Represents a collection containing all objects that satisfy the condition: there is only one key x, value is a subclass of string
Contains: { x: '' }, { x: undefined }
Does not contain: { x: 0 }, { x: '', y: '' }

[{ (string)*: 0 }]
Represents a collection containing all objects that satisfy the condition: there are zero or more keys, but keys must be subclasses of string
Contains: { x: 0 }, { x: 0, y: 0 }, { 0: 0 }({ '0': 0 }), { }

[{ (string - 'x' | 'y')*: 0 }]
Represents a collection containing all objects that satisfy the condition: key must be a subclass of string, not 'x' | 'y'

[{ (keyof any - 'x')*: 0, x: 1 }]
Represents a collection containing all objects that satisfy the condition: Must contain 'x': 1. Values for keys other than 'x' must be 0

type A {
    x: 0
}
// A <- [{ x: 0 }] // accept set
// A -> [{ (keyof any - 'a')*: unknown, a: 3 }] // offer set

I also summarized some common definitions:

common definitions
type O = object;
interface IE { }
// <-> [{ (keyof any)*: unknown }]

type TN = { [K in never]: unknown }; // == Record<never, unknown>
type TE = {};
// <- [{ (keyof any)*: unknown }]
// -> [{ }]

interface II { [K: string]: 0 }
// <-> [{ (keyof any - string)*: unknown, (string)*: 0 }]

type TI = { [K: string]: 0 };
type TMS = { [K in string]: 0 }; // == Record<string, 0>
// <- [{ (keyof any - string)*: unknown, (string)*: 0 }]
// -> [{ (string)*: 0 }]

interface IX { x: 0 }
// <-> [{ (keyof any - 'x')*: unknown, x: 0 }]

type TX = { x: 0 };
type TMX = { [K in 'x']: 0 }; // == Record<'x', 0>
// <- [{ (keyof any - 'x')*: unknown, x: 0 }]
// -> [{ x: 0 }]

Now let's go back to the topic. In the common definition above, the offer set [{ x: 0 }] of TX is a subset of the accept set of II, while IX is not. For example, the offer set of IX can contain { y: 123 }, which is not a subset of the accept set of II. Hence TX extends II, but IX extends II does not hold.
Note

The type of an object literal is the type of the corresponding type alias
// type of a is A
type A { x: 0 };
var a = { x: 0 } as const;

The above contents are all summarized in my experiments, and there may be errors in them.

@RyanCavanaugh is there any news on this issue? I would have thought it would have been resolved by now as many more complex things have been built and released already.

This issue is old enough to be in kindergarten by now. Has no consensus been reached or has it just been abandoned?

我已收到你的邮件

I believe that the current behavior of Interfaces is correct. Because I can not assign a type to a much wider type.
BUT behavior of Types is wrong.
Let's say I have an Interface A.
interface A {
  prop: string;
}

I can not assign A to Record<string, string> because the Record can have any other property.
Example:
const fn = (record: Record<string, string>) => {
  record.value1;
  record.value2;
  record.value3; // No errors here
}

So if I'll pass A to fn it is obvious that an error must occur.
Unfortunately at the moment, I can assign Type to Record without error. And I believe this is wrong behavior.
type TObj = {
  title: string;
}

const obj: TObj = {
  title: 'title',
};

const fn = (record: Record<string, string>) => {
  record.value1;
  record.value2;
  record.value3; // No errors here
}

fn(obj); // No error here, but it have to be

Like it or not, implicit index signatures are an intended feature of TypeScript.

@jcalz  Thank you for your comment. Yes, I see that this is intended feature but I bealeve it has wrong implementation.
I bealive the root of problem here is how Record<string, string> works.

If I can call any string property of the Record, like here:

// example 1
const fn = (record: Record<string, string>) => {
  record.value1;
  record.value2;
  record.value3; // No errors here
}

then It means that Record is "wider" than just object. We can call any string property of Record. So we can say that record has all possible string keys (in fact of course it has just a few props and it is impossible to have all possible keys).
Therefore,
according to Barbara Liskov principle we can not assign the object to the Record! But such a restriction makes a lot of people confusing, because assignment of the Object to Record intuitively looks good.
// example 2
interface IObj {
  prop: string;
}

const obj: IObj = { prop: 'string' };
const record: Record<string, string> = obj; // We expect this should work fine

So if we expect that such a assignment have to be correct then we have to agree that the Record is not "wider" type tyan IObj, therefore it should be impossible to call any string property on Record type.
So work with record should looks like:
// example 3
const fn = (record: Record<string, string>) => {
  if ('value1' in record) {
    record.value1
  }
  if ('value2' in record) {
    record.value2
  }
  if ('value3' in record) {
    record.value3;
  }
}

It is impossible to have an object with all possible string keys that's why code from example 3 looks more correct than code from example 1
To finalize:
Abviously that current types logic implementation has a problems and leads people to confusing. So I see two possible ways to fix it.

To accept that Record is "wider" than object. Then current behavior of Interfaces is correct. But behavior of Types is wrong and should be fixed.

To accept that Record is not "wider" than object. Then current behavior of Record and Interfaces are wrong and should be fixed.

in case it helps anyone, I just found a workaround for a slightly different situation where I hit the same underlying issue:
declare function foo<T extends Record<string, unknown>>(foo: T): void;

interface SomeInterface {
    bar: string;
}

const value: SomeInterface = { bar: 'baz' };

// does not work
foo(value);

// does work and is still typesafe
foo<Pick<SomeInterface, keyof SomeInterface>>(value);

and depending on the use case, I think it can be applied to the original issue:
interface IndexType {
     [key: string]: string;
}

interface doesNotWork {
    hola: string;
}
type doWorks = { hola: string };

let y: IndexType;

const correctA = { hola: "hello" };
const correctB: doWorks = { hola: "hello" };
//error should be assignable to y
// const error: doesNotWork = { hola: "hello " }; // this is the original type which fails below
const error: Pick<doesNotWork, keyof doesNotWork> = { hola: "hello " }; // this will work below

y = correctA;
y = correctB;
y = error; // no longer an error
y = {... error}; //workaround but not equivalent since the instance is not the same

Nice, @matgr1.
I've extracted it into a helper type: type IndexOptional<T> = Pick<T, keyof T> and can confirm that, in the above example, it works to do:
const error: IndexOptional<doesNotWork> = { hola: "hello " }; // this will work below
y = error; // no longer an error
y.things = "stuff" // can still accept arbitrary keys

@matgr1 @lobsterkatie
This is just a rough workaround.
Pick<SomeInterface, keyof SomeInterface> is just converting an Interface to the same Type and nothing more.
IndexOptional<Interface> - absolutely the same.
Those examples work because in Typescript Type can be assigned to Record<..., ...>. There are no other reasons.
As I explained above this is wrong behavior, because it contradicts to Liskov substitution principle
It is still unsafe (demo):
interface IObj {
  prop: string;
}
const obj1: IObj = { prop: 'string' };
// TS2322: Type 'IObj' is not assignable to type 'Record<string, string>'. Index signature for type 'string' is missing in type 'IObj'.
const record1: Record<string, string> = obj1;

type IndexOptional<T> = Pick<T, keyof T>
const obj2: IndexOptional<IObj> = { prop: 'string' };
// No error because now obj2 has "Type" typing, not an "Interface"
const record2: Record<string, string> = obj2;

// It is still unsafe
const fn = (arg: Record<string, string>) => {
  arg.someUnexistedProp;
  arg.anotherUnexistedProp;
  arg.anyOtherPropertyWhatEverYouWant;
  arg.stillNoErrorButWhy;
}

// You have obj2 with only one property? Yes!
// Can you use it in function with a lot of random properties? Yes.
// Is it safe? No!
fn(obj2);

@Webbrother Yes, TypeScript is intentionally unsound in places; implicit index signatures and unchecked indexed accesses are two of these places, and not really the subject of this GitHub issue.  This issue is just about whether or not interfaces should be granted implicit index signatures, with all the accompanying baggage, for better or worse.

@Webbrother - yes, I understand it's a workaround (and what it's doing). It's just now a slightly nicer-looking workaround. 🙂
And yes, exactly what @jcalz said (though he said it better and more concisely than I could have, so thanks for that, @jcalz!).

This issue is old enough to be in kindergarten by now. Has no consensus been reached or has it just been abandoned?

As I said above, before my preschooler was born 😅:

Just to fill people in, this behavior is currently by design

This has not changed.
Changing the behavior at this point would honestly be an incredibly disruptive breaking change without much concrete upside. For clarity, I'm going to close and lock this - interfaces should declare an explicit index signature if they intend to be indexed.


Renderer: Retrieve Text from Document

Implementing Proposal 2, Renderer: Retrieve Text from Document
Description
Replace the PDF text extraction algorithm by retrieving information from document accurately and efficiently.
To finish the task we need to implement the following function:
/// pdfJs.TextContentSource
pub struct TextContentSource;
pub fn reconstruct_text_information(&self, doc: &typst::doc::Document) -> TextContentSource;

Task list

[x] Create proposal
[x] run page.getTextContent() and replace all text content by point mapping.
[x] remove use of page.getTextContent()
[x] remove use of page.getViewport()
[x] remove use of pdf.getDocument

done by https://github.com/Myriad-Dreamin/typst.ts/commit/47aeb7deb4966b10536ae9a44658e786e764092d


Live

Spreadsheet 2018-01-07T03_53_49.xlsx

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/Add-CsSlaDelegates.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Expose apis for load_buffer() and save_buffer()

Migraphx has cpp and Python APIs for saving and loading serialized migraphx models after compilation - save() and load(), respectively. These apis save and load the serialized model from a file and internally call functions to save and load it from a (string) buffer. In this PR, I have added those internal functions to the cpp and Python API. This is useful in cases where a user may need to append metadata to the migraphx model before saving it to disk.

Please work on the CI failures.

Updated PR with some changes and fixes.

@aayushmaanjain Exposing load_buffer and save_buffer is a bit of more work  in API than expected. Do you still require this functionality exposed in API or have you found some alternate way?

@pfultz2 @kahmed10 @aayushmaanjain This  PR is ready for review.

Hi @umangyadav, unfortunately I no longer have access to ROCm resources. You should contact Shomy Sanyal or Abhinav Vishnu at AMD to follow up regarding the priority/necessity of this.
For context, I was using this branch to integrate MIGraphX into minigo. I was using the python API to save the model buffer and reading it using the C++ API. Both of these were working fine so I was able to integrate it. I could not find a workaround and was, thus, using my unmerged fork. I do not know if the condition has changed since.
I found a bug during testing in saving the buffer in cpp iirc that prevented me from completing the PR.
(cc:) @kahmed10 hopefully has more context based on our interactions.


Provider stops syncing after iOS wakes

Description
The provider stops receiving updates after iOS wakes from sleep.
Steps to reproduce the bug

Open a page in Safari on iOS
Check that you receive updates
Wait for the device to sleep
Wake the device
Updates are no longer received until the page is reloaded

Expected behavior
When the device wakes, if the connection was lost it should be re-established and re-synced
Environment?

operating system: iOS 16.6
browser: Safari
mobile/desktop: Mobile
Hocuspocus version: @hocuspocus/provider v2.2.3

Hi @garth, thanks for reporting this!
Unfortunately, I cannot reproduce it. Can you reproduce it here? https://tiptap.dev/editor
I opened the page on an iPad & Mac, set the iPad "lock screen" timeout to 2 minutes. After a bit more than 2 minutes, I saw the total number of connections reduce by one. When waking the iPad (after a few more minutes), it immediately (within 2-3 seconds) reconnected and synced again, both incoming and outgoing updates. I've also tried just manually locking the iPad, waiting, and then unlocking again - also worked.
I'm on 16.4 atm, will try to upgrade later and then check again..

I can confirm that https://tiptap.dev/editor loaded on an iPhone exhibits the same issue. After wake it no longer receives updates.
I'm pretty sure that Safari on iPad is less aggressive with resources than Safari on iPhone.
You don't need to wait for the device screen lock to timeout, you can manually lock the screen with the same effect.
I ran the Safari remote debugger and noticed that after wake there would be a console error about the web socketing being disconnected, so I added the following workaround which fixes the issue:
    provider.onClose = () => {
      setTimeout(() => {
        void provider.connect()
      }, 100)
    }

I not sure if the timeout is necessary, but it doesn't harm.

There was two reason for this case:

WebSocket in latest Safari does not emit onclose event when internet is turned off (wifi or cellular). And I test iOS15/16's WKWebView can stable reproduce. so it cannot trigger re-connect in HocuspocusProviderWebsocket.
Maybe we show emit close event by manual on iOS which version >= 15 for a workaround way.

setTimeout & setInterval on iOS15/16(safari or WKWebView) was not run correctly as expect,maybe for power saving.
so it caused checkConnection() cannnot call periodicly.
We can use rAF(requestAnimationFrame) to simulate setInterval (or setTimeout), this npm package wrapper that@essentials/request-interval

weird, can't reproduce it on ios17 public beta (iPhone 14 Pro). Thanks for providing your workaround!
Will check how I can reproduce this..

managed to reproduce it, indeed some weird bug causes onClose not being called. Workaround is underway...

@janthurau In the latest iOS v16, I'm consistently getting a socket closed error after wake. After adding the workaround the connection seems to be very stable. Maybe the issue you are observing is related to iOS v17?

I think if the setInterval in iOS16 will run as expect. even if the os sleep and wake, it will be work fine.
the following config can stable re-procudesetInterval was unreliable in iOS15/iOS16.

Config forceSyncInterval
Add debug logs with timestamp in forceSync() and checkConnection()

the logs timestamp was not correctly print as expect.
const socket = new HocuspocusProviderWebsocket({
    url: serverUrl + `${userRoomId}`,
    messageReconnectTimeout:18000,
    checkConnectionInterval: 6000, // a private config attribute in my forked provider branch
  })

  // Create a websocket provider
  const provider = new HocuspocusProvider(
    {
      websocketProvider: socket,
      token,
      name: `${userRoomId}`,
      document: doc,
      forceSyncInterval: 5000,
      broadcast: false,
    }
  );

iOS15/16 Safari or Webkit( WKWebView) maybe not update by Apple.
So use requestAnimationFrame to replace setTimeout in all platform maybe a practical solution.
Of course, consider old  browser or webkit mising requestAnimationFrame function, we should still use setTimeout/,fortunately @essentials/request-interval has do that.
https://github.com/jaredLunde/essentials/blob/1853a4d8eade1aadee7ac9e10c78e817a4972ebf/packages/raf/src/index.ts#L14C20-L14C20
let u = 'undefined',
  win = typeof window !== u ? window : ({} as any),
  p = typeof performance !== u ? performance : Date,
  now = () => p.now(),
  af = 'AnimationFrame' as const,
  Caf = 'cancel' + af,
  Raf = 'request' + af,
  raf: Raf = win[Raf] && win[Raf].bind(win),
  caf: Caf = win[Caf] && win[Caf].bind(win)

if (!raf || !caf) {
  let lastTime = 0
  raf = (callback: FrameRequestCallback) => {
    let curr = now(),
      next = Math.max(lastTime + 1000 / 60, curr)
    return setTimeout(() => {
      callback((lastTime = next))
    }, next - curr) as any
  }
  caf = (h) => clearTimeout(h)
}

@garth I've just released v2.3.1 - can you check if that solves your issue? It will take some time, but eventually the connection should reset and fully establish again. If that works in general, I'll see if we can somehow detect the broken socket in a faster way (depending on the configured timeouts, with the default it should take like 20 seconds now).


Convert HTML part to React

It's always nice when you move from html to React because it's always faster, but remember that you'll always introduce possible bugs.

i want to contribute to your project !Thanks

@Shubhamtribhuvan8 yes please take it up!

I haven't thought much of bounty but it's a fun project, so you could take it up if interested!

Your offer is incredibly generous, and I'm truly grateful for the opportunity. The prospect of a bounty makes this project even more appealing. I'll dedicate time to carefully assess the requirements and plan the next steps and I'm committed to delivering a successful project. Thank you!


Terraform CRs stuck in Initializing status

Running v0.015.1 version.
Problem

We see that couple CRs are stuck in Initializing state. The only way so far we've found so far to reconcile these stuck CRs is by restarting  tf-controller pods. (We see this even when CPU and memory utilization on nodes is not too high)
When it is stuck in Initializing state, we see no logs from tf-controller on these CRs which indicates they are not being reconciled
tf- controller concurrency is at 192 and qps and burst are below

 kubeAPIBurst: 1000
 kubeAPIQPS: 500

Are there any metrics we should be looking to understand the load on the controller why this might be happening and what we can do to alleviate the problem ?

We have the formula to approximate the capacity here which would help:
https://github.com/flux-iac/tofu-controller/discussions/281


User balance won't load

Opening an issue to an artist that can't seem to see balances when logging on kodadot
Was reported by dvekukolki on telegram( who is in touch with said artist)
Address: 15kVXAMrNzgb4KmbqUsocgM54bdMVQq2TcBNYdLXDf6GWH42

Artist says that balances stays the same as image above and won't load.
User also tried with vpn on and off

When I try to mock this address, it works well to load the balance. It should be a VPN issue.


Increase spacing between teamcards in /teams

Increase spacing from 1 to 2 to make each cards more distinct.

Can I work on this issue?


update_deps: make --clean-repo switch work in all cases

--clean-repo right now will raise an exception if the repository
directory was not present.  This makes it work in all cases.

So say the docs:

LGTM. I don't thing shutil.rmtree() throws other useful errors except to inform the user that the directory they are attempting to delete doesn't exist, but might be good to verify this before telling it to ignore all errors.

The docs say:

If ignore_errors is true, errors resulting from failed removals will be ignored; if false or omitted, such errors are handled by calling a handler specified by onerror or, if that is omitted, they raise an exception.

Testing shows the only errors that are produced by shutil.rmtree() under normal system operation are:
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/bb'
NotADirectoryError: [Errno 20] Not a directory: '/tmp/ee'
PermissionError: [Errno 1] Operation not permitted: '/tmp/ff'

All are ignored if ignore_errors is True.  The cases NotADirectoryError and PermissionError will both subsequently error out during Clone() or Fetch(); so the only change in behavior is if the directory doesn't exist.

Sounds good.  Thanks for checking.


Create SECURITY.md

Creating security.md as this is required for some organizations to use this third-party library to be in compliance with security standards.

Can we please get a review?

I now added a SECURITY.md file to master branch.


chore(popover-list-beta): Added popover-list-beta component

✅ Closes: COMUI-3184
There is a separate ticket to get the arrow to show: COMUI-3210

Changes look good to me 👍  , I spotted one edge case  see image below,

The target element still seems to display when the for element is gone from the screen or div. But it will dissapear after a few more pixels.  I was thinking its something related to the offset. If its not an easy change I am happy to approve anyways :)

Changes look good to me 👍 , I spotted one edge case see image below,

The target element still seems to display when the for element is gone from the screen or div. But it will dissapear after a few more pixels. I was thinking its something related to the offset. If its not an easy change I am happy to approve anyways :)

@gavin-everett-genesys it looks like this issue is not present in firefox but it is in chrome. Good catch, I'll look for a fix.

Changes look good to me 👍 , I spotted one edge case see image below,

The target element still seems to display when the for element is gone from the screen or div. But it will dissapear after a few more pixels. I was thinking its something related to the offset. If its not an easy change I am happy to approve anyways :)

@gavin-everett-genesys it looks like this issue is not present in firefox but it is in chrome. Good catch, I'll look for a fix.

@gavin-everett-genesys Doesn't look like this is an easy change after all. There's another ticket to add the arrow so maybe this offset issue can be tackle in that ticket?


Doc needed about theming colors

Inspecting html I discovered that Patternfly is used.
Please can you provide some hints in docs to change colors globally in keycloakify-starter?
https://www.patternfly.org/design-foundations/colors

I see now the Patternfly is quoted in Account Theme only in https://docs.keycloakify.dev/account-theme/single-page

Hello @GioviQ,
Yes, PatternFly is the CSS framework used by RedHat for building all their UIs, and since Keycloak is a RedHat product, it naturally uses PatternFly as well.
However, most developers customizing Keycloak themes prefer to use other, more widely adopted solutions instead of relying on PatternFly. That being said, overriding PatternFly's colors is still a good approach, and there isn’t anything specific to Keycloakify that would complicate this. You can simply refer to the official PatternFly documentation for guidance.
For example, to change the theme colors, you can do something like this:

And here’s what the result will look like:

I don't know why but in my case overriding css variables does not work.

My two first screenshot are from the starter repo, all I did was adding the main.css file and import it.

I am aging, I don't see well anymore, there was a "-" missing in variables names. Sorry.

Haha not problem!
You should give ChatGPT a try, this is how I got the answer:

Thanks
Next step trying to understand how to add missing italian translations to Account UI Single-page... 😫


[T2A2][T15-A1] Leow Zheng Yu

Ready for Review

Please change the title according to my comment in #441. Make sure you use the correct title next time.

Hi, I see my title as [T2A2][T15A1] Leow Zheng Yu already. Can I know where is the wrong title please?

@zhengyu92 it should be [T2A2][T15-A1].

@zhengyu92

Good job in improving SLAP for the main method to improve code quality.
However there are more ways that could be explored too (eg. common refactorings that were covered in class). Do give them a try when you have time.
A reminder for the tab issues with Eclipse.
Good to commit each time for each distinct change (for this time is each refactoring).


Infinitely adding items to queue, even after bot is stopped.

📝 Description
I have decided to include two similar issues in the same gh-issue here.
When adding a playlist to the bot and the bot then leaves (using e.g. /leave), the bot continuously adds the requested playlist songs. Another issue here is that any YouTube mix-playlist breaks the bot, since it is a infinite generating playlist. Therefore it adds infinite amount of songs.
🪜 Reproduction Steps
Issue 1 (bot continuously adds items to the queue even after leaving):

use /play <YouTube playlist link>.
use /leave
Bot continues to add the playlist to the queue.

Issue 2 (Infinite YouTube mix-playlist):

use /play <YouTube mix-playlist link>. (Only shows 25 videos in the YouTube sidebar - Take a look at the notes below)
Queue gets filled infinitely by the above playlist.

Notes:
YouTube playlists use list=PLxxxxxxxxxx as an parameter.
YouTube mix-playlists use list=RDxxxxxxxxxx as an parameter.
YouTube mix playlists will be different from person to person after the first song. Due to every mix being different for each user. Typically mixes are recommended on the homepage and contains 25 songs, after a song has been played/skipped one new song will be added to the end of the queue.
ℹ Environment / Computer Info

Parrot version: main@fcf933818a5e754f5ad4217aec8bfb16935d7442
Operating System:  ubuntu-server-22.04-arm

📸 Screenshots
No response

Fixes I have thought of myself, however this seems like some hacky ways and could properly be implemented in a better way.
Issue 1:
In play.rs, all QueryType::PlaylistLink handlers could be updated to check if an existing channel connection is established on the urls.iter():
for url in urls.iter() {
	let handler = call.lock().await;
	let cancel_playlist_addition = handler.current_connection().is_none();
	drop(handler);

	if cancel_playlist_addition {
		// End command execution when no more songs should be added.
		return Ok(());
	}
...
}

Issue 2:
in youtube.rs, the function ytdl_playlist() we could the check the url for the mix list parameter list=RDxxxxxxxxxx in that case, we could add the arg "--no-playlist" to the yt-dlp command to discard the playlist and only query for the song specificed.


Integration with Gulp

How can i integrate this with my current gulp setup?
conf:
const Launcher = require('webdriverio/build/lib/launcher');
const path = require('path');
var wdajax = require('webdriverajax');
const wdio = new Launcher(path.join(__dirname, 'wdio.conf.js'));
...
gulp.task('e2e', () => {
  wdajax.init(wdio);
  return wdio.run(code => {
    process.exit(code);
  }, error => {
    console.error('Launcher failed to start the test', error.stacktrace);
    process.exit(1);
  });
});

I got this error:
[17:56:58] Using gulpfile ~/projects/adTag2/gulpfile.js
[17:56:58] Starting 'e2e'...
[17:56:58] 'e2e' errored after 397 μs
[17:56:58] Error: you can't use WebdriverAjax with this version of WebdriverIO
    at Object.plugin [as init] (/Users/marco/projects/adTag2/node_modules/webdriverajax/index.js:11:15)
    at Gulp.gulp.task (/Users/marco/projects/adTag2/gulpfile.js:170:10)
    at module.exports (/Users/marco/projects/adTag2/node_modules/orchestrator/lib/runTask.js:34:7)
    at Gulp.Orchestrator._runTask (/Users/marco/projects/adTag2/node_modules/orchestrator/index.js:273:3)
    at Gulp.Orchestrator._runStep (/Users/marco/projects/adTag2/node_modules/orchestrator/index.js:214:10)
    at Gulp.Orchestrator.start (/Users/marco/projects/adTag2/node_modules/orchestrator/index.js:134:8)
    at /usr/local/lib/node_modules/gulp/bin/gulp.js:129:20
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)
    at Module.runMain (module.js:592:11)

Although my version is higher than v3

I think it also does not work with v2. I will look into that though.

I pushed a new version (v2) which should work with webdriverio v4.


Consider more ways to obfuscate scalar constants

Currently spirv-fuzz only obfuscates scalar constants by replacing them with known uniform values.  But it could do various other things, e.g. a constant 10 could be replaced by (x - 30) if x is known to hold the value 40.
Some more adventurous things should be tried in due course.

@afd, that is related to the id synonym pass, right?
We can replace scalar constants with id synonyms whose values are equal to the constant value.
So, we will be able to use this to replace access chain indexes.

@andreperezmaselco An access chain id can indeed be replaced with a synonym, or can be obfuscated by the fuzzer pass that replaces ids with the values of known uniforms.
However, the pass that creates access chains is a bit boring: it only creates literal indices (which could then be replaced with equivalent ids).  It would be nice if, instead, it could create indices that are not necessarily literals, and that are clamped to be in-bounds.

@afd, got it.
So, it would be useful to use the TransformationEquationInstruction and TransformationReplaceIdWithSynonym classes to create more interesting indices, right?

Yes, that would be a good start.
What I can't decide is whether we should leave that to chance (the fuzzer passes that apply those transformations may just run and do something interesting in the right places), or try to direct this so that it is likely to happen.
The question of directing things vs. leaving them to chance is more general than this particular scenario so we should discuss it in depth.


Build failed when upgrading to newer React-Native version 0.71.2

Description
So I tried to update my existing react-native app (older version is 0.66.0) to the current version of react-native but now it was not working.
Give the below error when I am running my app.
`* What went wrong:
A problem occurred configuring root project 'CreekVista'.

Could not resolve all artifacts for configuration ':classpath'.
Could not find com.facebook.react:react-native-gradle-plugin:.
Required by:
project :`

Version
0.71.2
Output of npx react-native info
warn Package react-native-vector-icons contains invalid configuration: "dependency.assets" is not allowed. Please verify it's properly linked using "react-native config" command and contact the package maintainers about this.
warn Package rn-fetch-blob contains invalid configuration: "dependency.hooks" is not allowed. Please verify it's properly linked using "react-native config" command and contact the package maintainers about this.
info Fetching system and libraries information...
error Unable to print environment info.
Error: Command failed: wmic os get Caption
'wmic' is not recognized as an internal or external command,
operable program or batch file.
Steps to reproduce
`* What went wrong:
A problem occurred configuring root project 'CreekVista'.

Could not resolve all artifacts for configuration ':classpath'.
Could not find com.facebook.react:react-native-gradle-plugin:.
Required by:
project :`

Snack, code example, screenshot, or link to a repository
`* What went wrong:
A problem occurred configuring root project 'CreekVista'.

Could not resolve all artifacts for configuration ':classpath'.
Could not find com.facebook.react:react-native-gradle-plugin:.
Required by:
project :`

The above error  is saying that  'react-native-vector-icons' and 'rn-fetch-blob' packages contain invalid configuration and they are not linked properly .
Run "react-native config" command in the root directory of your project and verify linking of packages.

Could not find com.facebook.react:react-native-gradle-plugin:.

Can you share your android/settings.gradle file?

I am getting a similar error when building
Could not find com.facebook.react:react-native:0.71.2.      Searched in the following locations:        - https://dl.google.com/dl/android/maven2/com/facebook/react/react-native/0.71.2/react-native-0.71.2.pom

I am getting a similar error when building @cortinico
Could not find com.facebook.react:react-native:0.71.2.
     Searched in the following locations:
       - https://dl.google.com/dl/android/maven2/com/facebook/react/react-native/0.71.2/react-native-0.71.2.pom

same error i am getting.any solution?

I am getting a similar error when building @cortinico
Could not find com.facebook.react:react-native:0.71.2.
     Searched in the following locations:
       - https://dl.google.com/dl/android/maven2/com/facebook/react/react-native/0.71.2/react-native-0.71.2.pom

same error i am getting.any solution?

Hi, apply plugin: "com.facebook.react"   Add this line for =>  android/app/build.grade file.

apply plugin: "com.android.application"
apply plugin: "com.facebook.react"
---> android/app/build.grade

Sorry i didn't see your comment earlier, so here my settings.gradle file:
`rootProject.name = 'CreekVista'
include ':react-native-otp-verify'
project(':react-native-otp-verify').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-otp-verify/android')
include ':react-native-file-viewer'
project(':react-native-file-viewer').projectDir = new File(rootProject.projectDir, 	'../node_modules/react-native-file-viewer/android')
include ':rn-fetch-blob'
project(':rn-fetch-blob').projectDir = new File(rootProject.projectDir, '../node_modules/rn-fetch-blob/android')
// include ':react-native-vector-icons'
// project(':react-native-vector-icons').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-vector-icons/android')
// include ':react-native-vector-icons'
// project(':react-native-vector-icons').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-vector-icons/android')
apply from: file("../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesSettingsGradle(settings)
include ':app'
includeBuild('../node_modules/react-native-gradle-plugin')`

See below screenshot

Add same as above.
Clean build folder then run

Add classpath("com.facebook.react:react-native-gradle-plugin") in your build.gradle file.

Hey @Malik-Usman17
Your settings.gradle file looks correct. Could you share a reproducer?

Hey @Malik-Usman17 Your settings.gradle file looks correct. Could you share a reproducer?

Hello @cortinico thanks for the comment, and sorry didn't understand it about reproducer, what do you mean by that?

Add classpath("com.facebook.react:react-native-gradle-plugin") in your build.gradle file.

I already did it, but no luck

Hello @cortinico thanks for the comment, and sorry didn't understand it about reproducer, what do you mean by that?

I would suggest to read this page: https://stackoverflow.com/help/minimal-reproducible-example
Plus what I'm asking is to create a new project with npx react-native init and edit it so it fails in your same way. Put it on Github to that I can look into it

Add classpath("com.facebook.react:react-native-gradle-plugin") in your build.gradle file.

Would it be the same for kotlin?  Also, I have a slightly different build config as I am bringing in the RN project as part of an Android build.  Is that still the same configuration?

Add classpath("com.facebook.react:react-native-gradle-plugin") in your build.gradle file.

Would it be the same for kotlin? Also, I have a slightly different build config as I am bringing in the RN project as part of an Android build. Is that still the same configuration?

Yes

https://github.com/facebook/react-native/issues/36047#issuecomment-1446326701
Could not resolve all files for configuration ':android:classpath'
     Could not find com.facebook.react:react-native-gradle-plugin:.
     Required by: project :android

Running into this when adding the rn gradle plugin to dependencies

#36047 (comment)
Could not resolve all files for configuration ':android:classpath'
     Could not find com.facebook.react:react-native-gradle-plugin:.
     Required by: project :android

Running into this when adding the rn gradle plugin to dependencies

Add below line for settings.gradle file
includeBuild('../node_modules/react-native-gradle-plugin')

We have included the react-native-gradle-plugin and used the implementation("com.facebook.react:react-android")
But we are using the React Native module as a Android library.  Are there any docs that display how we should be changing our build files to accommodate the changes in 0.71.2?

But we are using the React Native module as a Android library. Are there any docs that display how we should be changing our build files to accommodate the changes in 0.71.2?

That's the upgrade helper:
https://react-native-community.github.io/upgrade-helper/?from=0.70.7&to=0.71.3
I'm also closing this as @Malik-Usman17 (the OP) is unresponsive.
Folks are commenting below diverging the discussion making it harder for us to follow through and to provide specific support. Please open separate issues if you're looking for specific support.


Unable to get jax.profiler to work on TPU in the latest version of JAX

Although I just encountered this error when using JAX 0.3.14, I have encountered the error for many times with various versions of JAX.
The cause of the error is obvious. jax.profiler depends on Tensorflow, while Tensorflow is not automatically installed when installing JAX in a new virtual environment. Therefore, jax.profiler will not work, and it shows this error:
2022-07-04 21:27:10.631029: E external/org_tensorflow/tensorflow/python/profiler/internal/python_hooks.cc:369] Can't import tensorflow.python.profiler.trace

It is not possible to resolve this issue by installing Tensorflow from pip directly, because the default Tensorflow version is not compiled with TPU support.
The only way to solve the issue seems to be compiling Tensorflow from source, but compiling Tensorflow from source results in another error.

This is the method I used to compile Tensorflow from source.
JAX version 0.3.14
Locate https://github.com/google/jax/blob/jaxlib-v0.3.14/WORKSPACE#L13. The line suggests that JAX 0.3.14 is compatible with Tensorflow commit d250676d7776cfbca38e8690b75e1376afecf58d.
Then, I compiled Tensorflow by this script:
#!/bin/bash
set -e
set -v
sudo rm -rf ~/.cache/bazel  # clear bazel cache (see tensorflow#55563)
export TENSORFLOW_SHA=d250676d7776cfbca38e8690b75e1376afecf58d
wget -nc https://github.com/tensorflow/tensorflow/archive/$TENSORFLOW_SHA.tar.gz
tar zxf $TENSORFLOW_SHA.tar.gz
rm -f $TENSORFLOW_SHA.tar.gz
mv tensorflow-$TENSORFLOW_SHA tensorflow
cd tensorflow
export BAZEL_VERSION=`cat .bazelversion`
sudo mkdir -p /usr/local/lib/bazel/bin
sudo wget -nc -P /usr/local/lib/bazel/bin https://github.com/bazelbuild/bazel/releases/download/$BAZEL_VERSION/bazel-$BAZEL_VERSION-linux-x86_64
sudo chmod +x /usr/local/lib/bazel/bin/bazel-$BAZEL_VERSION-linux-x86_64
rm -rf ~/.venv310
python3.10 -m venv ~/.venv310
. ~/.venv310/bin/activate
pip install -U pip
pip install -U wheel
pip install -U packaging
pip install -U keras_preprocessing --no-deps
pip install "jax[tpu]==0.3.14" -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
yes '' | python configure.py  # use the default settings
bazel build --config=tpu //tensorflow/tools/pip_package:build_pip_package
./bazel-bin/tensorflow/tools/pip_package/build_pip_package /tmp/tensorflow_pkg
ls /tmp/tensorflow_pkg/tensorflow-*.whl

However. I got this error:
2022-07-04 21:11:18.248361: F ./tensorflow/core/tpu/tpu_library_init_fns.inc:34] TpuEmbeddingEngineState_Create not available in this library.

I know that this error occurs when the libtpu version is not compatible with the Tensorflow version. Previously I always fixed it by recompiling Tensorflow from source. However, this time the error occurred when I was compiling Tensorflow from source, so I do not know what to do.
@skye

What are you trying to do with the profiler? You may not need TensorFlow installed to accomplish what you want to do and the Can't import tensorflow.python.profiler.trace error may be misleading. (Note that I was able to get rid of the error by just running pip install tensorflow).
I tried using jax.profiler.trace in a fresh Cloud TPU VM w/o TensorFlow installed and it worked fine. If you're using tensorboard or python -m jax.collect_profile, you'll need TF installed.

If you're using tensorboard or python -m jax.collect_profile, you'll need TF installed.

Yes, I am using tensorboard.

Note that I was able to get rid of the error by just running pip install tensorflow

I've just tried and this is true, but I still want to install the appropriate TPU version of Tensorflow.

If you just want to get the profiler to work, you only need the TensorFlow from pip along with tbp-nightly. I was able to capture a trace using the instructions here: https://jax.readthedocs.io/en/latest/profiling.html#installation. Do you need TPU-compatible TensorFlow for something else?

I compiled a CPU version of Tensorflow and it works. For my other Tensorflow projects I will create a different virtual environment.

@skye do we expect TF TPU and JAX TPU to play nicely here?

Not really. The only supported way to use TF in a Cloud TPU VM is to create a VM with a TF image (https://cloud.google.com/tpu/docs/run-calculation-tensorflow#create_a_vm_or_node_with_gcloud), although you can build from source if you know what you're doing like @ayaka14732 apparently does :slightly_smiling_face: , and even with this we don't support running TPU-enabled TF and JAX in the same process. So using regular CPU-only pip-installed TF is the best way to go for profiling, like Sharad does above.


Bug: Failed to deploy template from Deploy button on main page

Expected Behavior

Deploying to Azure is successfull.
Current Behavior

Deployment failed

Deployment template parse failed: 'After parsing a value an unexpected character was encountered: {. Path 'resources[3].properties.siteConfig.appSettings[8]', line 203, position 12.'. (Code: InvalidTemplate)
Steps to Reproduce

Context (Environment)
Portal version:
LoRaWAN Stack version:
Logs

Additional Information

Please add also the #558 with this issue.


Minor change to wording on project view page

The project creation form redirects to a project view, e.g.:
/en-gb/projects/applications/1/
The page message however says:
"Successfully submitted a project application. You may now want to create a system allocation request or RSE time request below, or add members to your project using the invite button."
This is slightly misleading currently, as it suggests that we're able to invite users. We could change this to something like:
"Successfully submitted a project application. You may now want to create a system allocation request or RSE time request below. Once the project has been approved, you will be able to add users to your project using the invite button."

Note: issue opened after closing #73


website url redirects to nothing

whenever an user click on the website url , it redirects to this page
Please resolve this problem as soon as possible

this isn't related to codebase,
heroku don't offers free deployment now,
so all previously free deployed links stops working and shows this err

#https://github.com/tapaswenipathak/Open-Source-Programs/issues/235#issue-1697821902``


clean up exchange adv restore test

Does this PR need a docs update or release note?

[x] :no_entry: No

Type of change

[x] :robot: Supportability/Tests
[x] :broom: Tech Debt/Cleanup

Issue(s)

#3562

Test Plan

[x] :zap: Unit test
[x] :green_heart: E2E

@ryanfkeepers could you please rebase this? :)


fix: typo in readme

note that the GitHub repo description has the same typo

Pull Request Test Coverage Report for Build 25

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

Totals

Change from base Build 24:
0.0%

Covered Lines:
1051

Relevant Lines:
1051

💛  - Coveralls

Rewrite htte and  focus on chinese doc only in latest three month. Thanks for your pull request.


Add AutoCorrect

[X] I have not changed the README.md directly.

https://github.com/huacnlee/autocorrect

Nice. Thanks for the addition. 👍


numix-gtk-theme: fix hash

Motivation for this change
Found this while doing a nox-review for another PR.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

@romildo The version 2.6.7 appears to have been released after you've submitted #30174: https://github.com/numixproject/numix-gtk-theme/tree/2.6.7 . Do you know why?

@orivej When I have submitted that PR the version 2.6.7 was already released and available in the github page. It seems that it has been rereleased a few days later.


[refactor-prompt] add token sendfrom

What current issue(s) does this address, or what feature is it adding?
Moved #623 forward by implementing sendfrom
How did you solve this problem?
write code + tests
How did you make sure your solution works?
add tests + make tests
Are there any special changes in the code that we should be aware of?
Yes.

I noticed that many wallet token <something have to validate the same parameters (token, from_addr, to_addr, amount) over and over again. I added a helper function and also changed wallet token send to use that function.
token_send_from() used to mix business logic + representation (representation meaning; printing and asking for prompt). I changed it to only do the test sending part of the business logic and not the representation. This allows others to re-use the function more easily.
I removed a bunch of tests that are now covered by the specific wallet token sendfrom  tests which I wrote before noticing the old tests were broken from changing the token_send_from()

Please check the following, if applicable:

[X] Did you add any tests?
[X] Did you run make lint?
[X] Did you run make test?
[X] Are you making a PR to a feature branch or development rather than master?
[] Did you add an entry to CHANGELOG.rst? (if not, please do)

Coverage increased (+0.04%) to 85.034% when pulling 5a9a7e5eded6d5ce989ef9c03a60048c584c4ba4 on ixje:token_sendfrom into 54183e258d23cbe6bf037e1b44cf72d5960b047f on CityOfZion:refactor-prompt.

Thanks both for the review 👍


MeanQuadraticDistance

Added the Measure Function
Added some Tests for the Measure Function
Closes #4

In order to also finish https://github.com/BeastyBlacksmith/Flase.jl/issues/6, you'd need to take a look at https://github.com/BeastyBlacksmith/flase/blob/master/src/Simulation/ClusterTimeSimulation.cpp and translate that to julia.
It would be insightful to compare the implementation of the finite simulations beforehand.


Why the number of views not the same as in other tools?

Rapport de Ticket
Description
Tools:

Emi
Top 100
Pageviews

Using these three tools for the date Jun 19th, 2024 does not give the same number of views of articles. E.g.: The page Jordan Bardella has 72236 views on Pageviews, almost the same on Top 100, but 60900 on Emi.
Comportement Attendu
Have nbr of views 72236 for page Jordan Bardella on Jun 19, 2024 on Emi
Comportement Actuel
Jordan Bardella has 60900 on Emi
Type de Problème

[ ] Bug
[ ] Demande de Fonctionnalité
[ ] Amélioration
[x] Question
[ ] Autre (veuillez spécifier)

Liste de Vérification

[ ] Ce problème n'est pas un doublon.
[ ] Toutes les informations requises sont incluses.

Merci !

Maybe this can be the answer?

Because of privacy reasons, pageview counts are given in a bounded format and are not reported for certain countries.
as stated in the doc.

I think there's no need to compare those tools. Emi gives views per country while others given views per project...
If there's no other comment, I think we need to close this.


Json generator

Generates aggregation/ post-aggregation JSON easily with algebraic expressions
For example:
Normal metrics: longSum(price), doubleMin(price)
Post Aggregation: (price/count)*100

Coverage increased (+0.007%) to 81.35% when pulling 95a2c1ea5c332daf08dd117e6671162a22153f20 on x4base:json_generator into a3f549bb9e55affc0da46dfe6f8a4b721905f716 on airbnb:master.

Coverage increased (+0.007%) to 81.35% when pulling a9d71ac1193fbd986f789082d65750ef7d300e9d on x4base:json_generator into a3f549bb9e55affc0da46dfe6f8a4b721905f716 on airbnb:master.

Closing old PRs that need rebase. Rebase and resubmit if you're still pursuing this


Add service_account.Credentials.with_claims

Resolves #129.

LGTM I suppose. It seems you want to eat the teeny cost of or {} every time, so it's all good?

It seems you want to eat the teeny cost of or {} every time, so it's all good?

The cost of that vs. the cost of copy/deepcopy is insignificant.
I'm going to update this to use deepcopy, but I'm finishing something else up first. Thanks for the review!


Is it possible to login and retry request when auth fails?

Hello.
I am wondering if next scenario is possible to implement:

request comes to proxy
target returns 401
in response handler separate login request is made
new sessionId is extracted from login request
retry request with new sessionId

Using request it could be done this way (some details ommited):
var server = http.createServer(function(req, res) {
	// request comes to proxy
	proxyRequest(req, res);
});

function proxyRequest(req, res) {
        var proxyReq = req.pipe(request.get(/*options*/));
	proxyReq.on('response', function(resp) {
		if(/*ok*/) {
			proxyReq.pipe(res);
		} else {
			// target returns 401
			// in response handler separate login request is made
			var loginReq = request.post(/*loginOptions*/);
			loginReq.on('response', function(resp) {
				// new sessionId is extracted from login request
				// retry request with new sessionId
				proxyRequest(req, res);
			});
		}
	});
}

Thanks.

I kinda simulated it by returning 302 until login request completes.


SharePoint Monitoring - Add Farm Health Test

Put this in, but then decided to remove it - it's not a great "monitoring test", so to speak


Debug function is overloaded as a boolean and causing crashes

Our service is crashing with this error:
api_server-v1.0.0.forever.log:    at null.<anonymous> (/var/www/groupahead-backend/node_modules/gpapi/lib/api.js:240:13)
api_server-v1.0.0.forever.log-    at wrappedCallback (/var/www/groupahead-backend/node_modules/newrelic/lib/transaction/tracer/index.js:321:23)
api_server-v1.0.0.forever.log-    at wrapped (/var/www/groupahead-backend/node_modules/newrelic/lib/transaction/tracer/index.js:155:28)
api_server-v1.0.0.forever.log-    at wrappedCallback (/var/www/groupahead-backend/node_modules/newrelic/lib/transaction/tracer/index.js:412:66)
api_server-v1.0.0.forever.log-    at wrapped [as _onTimeout] (/var/www/groupahead-backend/node_modules/newrelic/lib/transaction/tracer/index.js:155:28)
api_server-v1.0.0.forever.log-    at Timer.unrefdHandle (timers.js:307:14)```

It looks like the *debug* var both refers to the debug module, and the debug boolean passed to the main function:

https://github.com/dweinstein/node-google-play/blob/master/lib%2Fapi.js#L254

ah sorry about that. I don't often use the cache option TBH. can get that fixed in a jiffy

fixed in v3.2.1

:+1: Nice - thanks for the quick response time. You also saved me from creating the PR


md-tab touch device header scrolling

Bug, feature request, or proposal:
Feature Request
What is the current behavior?
On touch devices, it would be nice to be able to click and drag the tab header to horizontally scroll in addition to the buttons.
What are the steps to reproduce?
Any md-tab-group with enough mb-tabs to give the scrolling option. View in mobile environment. (Chrome dev tools works fine)
<md-tab-group>
        <md-tab>
          <ng-template mdTabLabel>
           Long header text 1
          </ng-template>
        </md-tab>
        <md-tab>
          <ng-template mdTabLabel>
           Long header text 2
          </ng-template>
        </md-tab>
        <md-tab>
          <ng-template mdTabLabel>
           Long header text 3
          </ng-template>
        </md-tab>
</md-tab-group>

What is the use-case or motivation for changing an existing behavior?
Tapping scroll buttons to scroll on mobile is not intuitive.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Feature does not exist as of Material beta 10

Tracked via #2209, PR is #6294