TypeScript Bytecode Interpreter / Runtime Types

TypeScript currently solves a lot of issues with working with JavaScript today. From type checking itself, transpiling, to AST and language services for compilers, linters, and editors. The gradual and structural typings are unique in a way and it seems a perfect fit for JavaScript. However, two major aspects are currently unsolved: a runtime type aka reflection system and performance issues. Having types available in runtime enables use cases that currently are simply not possible and for which many hundreds expensive, complex, and unsexy workarounds have been built.
In this post I’d like to talk about the use cases and current state of runtime type solutions, a proposal for a full TypeScript runtime type system aka type reflection solution, and a bytecode interpreter with instruction set specification as a by-product that can potentially be used as alternative to the current type checker with performance improvements, and allows new adoption of TypeScript in completely new non-javascript environments.
Runtime Types
What does it mean to have runtime types? There are several levels of reflection systems that could be built. From very basic reflection like with emitDecoratoraMetadata to reasonable one that emits all types of functions, classes, to a more verbose one that emits interfaces, type aliases, and type functions, to very verbose ones that essentially annotate each variable + control flow analysis. What is necessary is defined by the use-case at hand. In a perfect world, we would have access to all types of all symbols (including variables), but that’s not necessarily possible or desired due to restrictions, like e.g. bundle size.
I categorise possible reflection systems in four levels:

Basic reflection of primitives: string, number, boolean, bigint, Date, classes.
Reflection of JavaScript symbols: class properties/methods, function parameters.
Advanced reflection of all TypeScript types: interfaces, type alias, type functions (conditional types, mapped types, index signatures, etc), generics, etc.
Perfect reflection of all variables and expressions, including control flow analysis.

Level 1 is already integrated in JavaScript itself via typeof.
Level 2 can be partially achieved by using either class decorators and emitDecoratorMetdata, or fully via schema declaration libraries. It means however a lot of additional boilerplate code and complexity.
Level 3 is currently not available. Although there are a few PoC transformers that try to extract the most basic type information, they are far from being able to reflect all TypeScript types and also impose substantial overhead.
Level 4 is somewhat unreasonable, very excessive, and has probably no use-case where level 3 is not already sufficient enough.
I consider level 3 the most reasonable and doable as it makes the whole TypeScript type system available in runtime in a way that supports all type expressions while not excessively emit too much reflection data for each and every variable or expression. This level is what this proposal is trying to achieve.
Demand
There are meanwhile a lot of libraries trying to solve this issue and making types available in runtime, in one way or another. Some provide basic type support, while other support additionally validation and database information, and a few support relatively complex type expressions (like union, intersections).
Here is a list of known libraries and their download count:

Name
Type
Use case
Downloads/Month

Total

76,619,220

joi
Schema declaration
Validation
16,764,980

yup
Schema declaration
Validation
13,644,252

zod
Schema declaration
Serializer/Validation
1,656,548

io-ts
Schema declaration
Serializer/Validation
1,897,544

ts-json-validator
Schema declaration
Validation
35,992

runtypes
Schema declaration
Validation
348,432

superstruct
Schema declaration
Validation
1,698,868

class-transformer
Class with decorators
Serializer
4,020,084

class-validator
Class with decorators
Validation
3,752,412

typeorm
Class with decorators
ORM
2,813,516

mikro-orm
Class with decorators
ORM
20,876

prisma
Custom DSL
ORM
1,072,260

type-graphql
Class with decorators
RPC/GraphQL
451,104

nest
Class with decorators
Dependency Injection
4,610,144

typescript-ioc
Class with decorators
Dependency Injection
46,216

InversifyJS
Class with decorators
Dependency Injection
2,248,848

angular
Class with decorators
Dependency Injection
11,660,628

trpc
Schema declaration
RPC
62,140

ow
Schema declaration
Validation
2,649,368

typebox
Schema declaration
Reflection
120,196

monocle-ts
Schema declaration
Reflection
685,848

typescript-is
Transformer
Validation
35,636

typescript-json-schema
Transformer
Validation/Reflection
6,323,328

State of 28. January 2022
There a many hundreds more that all re-implement a way to make types available in runtime. The space is defragmented quite a lot and APIs not streamlined. If they all would be able to use TypeScript types in runtime, they probably would.
Although it can be considered a good thing that types are erasable per default, it’s clear that types have value. And removing them destroys the value they have and makes it necessary to make them available again in an expensive way. The value depends highly on the project at hand. For many projects and people that value is so big that they create new libraries making the types available in runtime in one way or another, and invest in total many million dollars doing so. The value proposition is self-explanatory once you have a use case at hand that deals with types. TypeScript should thus provide an official way of making them accessible in runtime.
Considering the total download amount of 76mio downloads/month for these libraries compared to Typescript's 123mio download/month it shows a clear picture of the huge demand runtime types have. Including ajv which uses essentially json-schema draws an even more demanding picture, because json-schema could be in the JavaScript world replaced with TypeScript using this proposal. Although not the whole user base of ajv can be included in the calculate since a lot just consume an external json-schema or one that is shared with other non-JavaScript tech stack.
Workarounds
There are several ways to get runtime types. Some are much more complex than others. They differentiate in how much TypeScript types are actually expressible and available in runtime.
Classes with decorators
class User {
    @Property()
    id: number;

    @Property()
    username: string;

    @Property({type: 'array', elementType: String})
    tags: string[];
}

For more complex types like an array of strings, the type needs to be annotated manually.
The idea is that a decorator is used at a class property and emitDecoratorMetadata is enabled so that basic type information are automatically available in runtime. The overhead is substantial as a lot of code is generated for relatively little functionality. The functionality is not only limited in the type expressiveness (anything more complex needs to be annotated manually), but also other key functionality like circular imports are simply not supported and need a workaround usually called “forward reference” where an arrow function is used to defer symbol resolution, e.g.  forwardRef(() => MyType). There are other disadvantages like property and parameter names do not survive a minimisation process and functions/interfaces are not supported.
Custom DSL (domain specific language) with code generator
model User {
   id Number
   username String
   tags String[]
}

A code generator then generates TypeScript types. This has the obvious disadvantage of learning yet another type language and use for every change a code generator. This increases the project complexity and mental model enormously. Also, usually those DSL are much less powerful than TypeScript so that the expressiveness of types and the program suffer.
Schema declaration
Declaration of a schema happens usually via method chaining API.
const user = t.schema({
    id: t.number,
    username: t.string,
    tags: t.array(t.string),
});
type User = ExtractType<typeof user>; // {id: number, username: string, ...}

There are usually helper types included in such libraries to extract the declared type for the type system.
Transformers
Transformers parse the AST of the TypeScript source or Checker.ts types, and emit some way of runtime type information. That information could look like that:
class User {}
User.type = {
   id: {type: 'number'},
   username: {type: 'string'},
   tags: {type: 'array', element: {type: 'string'}}
}

This type of data structure can get big pretty fast and is not suitable for a big and complex code base. Its structure is very inefficient in terms of size and runtime overhead. Also, generics with type functions (conditional types, mapped types, etc) are not supported with such an arrangement. On the other side this is very user friendly as one can use simply write TypeScript without learning anything fundamentally new. It just works - which is a fundamental advantage.
Relevant Github Issues
There are many Github issues created in the TypeScript repository regarding runtime type data in one way or another. This also represents as a proof for further demand, beside the list above of projects that have actually invested tons of resources into making it happen.

https://github.com/microsoft/TypeScript/issues/3628 Discussion: (Reflective) Type Model
https://github.com/microsoft/TypeScript/issues/3060 TypeScript interfaces for Dependency Injection
https://github.com/MichalLytek/type-graphql/issues/296 Enhanced types reflection system
https://github.com/microsoft/TypeScript/issues/2902 Suggestion: Interfaces as string literals
https://github.com/microsoft/TypeScript/issues/9182 Feature suggestion: Compile-time reflection of string literal unions and enums
https://github.com/microsoft/TypeScript/issues/10576 Get type of generic type
https://github.com/microsoft/TypeScript/issues/11860 Design-type metadata for generic types
https://github.com/microsoft/TypeScript/issues/11861 Decorate all properties with type metadata in TypeScript
https://github.com/microsoft/TypeScript/issues/12605 [Proposal] Implement a way to emit json type information
https://github.com/microsoft/TypeScript/issues/12714 Make metadata available at runtime
https://github.com/microsoft/TypeScript/issues/11362 Proposal for complete reflection mechanism
https://github.com/microsoft/TypeScript/issues/12577 Provide more detailed metadata for decorators
https://github.com/microsoft/TypeScript/issues/19154 Emit metadata with union constituents
https://github.com/microsoft/TypeScript/issues/20887 TS Proposal : abstract class expression, generic metadata, constructor typing, abstract class decorators, abstract members decorators
https://github.com/microsoft/TypeScript/issues/21479 compiler option to emit interface symbols?
https://github.com/microsoft/TypeScript/issues/39966 Improve generation of reflection

All of these issues can be solved with the proposed solution. The list is not complete, but should indicate how broad the demand is.
Design Goals of TypeScript
TypeScript has several design goals that need to be considered before implementing a solution for type reflection. Strictly speaking there are three points that oppose a runtime type system, namely:

Impose no runtime overhead on emitted programs.

Emit clean, idiomatic, recognizable JavaScript code.

Use a consistent, fully erasable, structural type system.

TypeScripts design goals explicitely state in point 9 that type information should be erasable. With this proposal this goal is not defeated. It is and should still be possible to erase type information completely if the user has no need for them.
While goal 3 and 4 are one of the reasons for TypeScript’s success and fundamental a good thing, it’s inevitable to break or bend them in order to make types available in runtime. Runtime types create an overhead, although done correctly a very small one, it’s still an overhead. It has a cost. The cost can be justifiable, but still is a cost. This proposal tries to produce as little runtime overhead as possible. TypeScript types are not JavaScript and probably never will, hence any structure or bytecode emitted in JavaScript that represent TypeScript types will not be clean, idiomatic, and recognizable JavaScript code. It will be valid JavaScript though. However, since the trend goes to minimise and further optimise the generated JavaScript code from the TypeScript compiler up to a point of not being readable anymore, those points vanish more and more. A valid point is still though that emitted JavaScript should not contain unnecessary code that never will be used, so making the runtime types configurable and three-shakeable is crucial.
Use Cases
A lot of use cases can be found where runtime types could be a game changer regarding new functionality that currently is just not possible, regarding user experience improvements and code quality in general.
Serialization/deserialization
Even basic types like a class with date properties class {created: Date} need a proper deserializer to get the correct Date type back when deserializing JSON. Serialization to JSON and deserialize back to JavaScript objects is a core functionality that almost every application needs. A use case is receiving a HTTP request with a JSON body in a backend application and deserialize it correctly.
serialize<Date>(new Date(1234567890)); //'1970-01-15T06:56:07.890Z'

deserialize<Date>('1970-01-15T06:56:07.890Z'); //new Date(1234567890)

Type casts
Type casts (x as string) in TypeScript are no real casts. They do not change anything in runtime. However, if the types are available in runtime, there could be a function that does actual type casting.
cast<number>('123'); //123
cast<Date>(1234567890); //Date(1970-01-15T06:56:07.890Z)

cast<User>({id: 0, username: 'Peter'}); //instanceof User

Validation
With types that add meta-data one can annotate models with validation information and use them in a validator to validate arbitrary data against very complex types. Type and actual data validation is then very easily possible.
interface User {
   id: number & Positive;
   username: string & MinLength<3>;
}

validate<User>({id: 3, username: 'Peter'}); //true
validate<User>({id: '3', username: 'Peter'}); //false
validate<User>({username: 'Peter'}); //false
validate<User>({id: -3, username: 'Peter'}); //false

validate<number & Positive>(3); //true
validate<number & Positive>(-3); //false

Validation can go as far as automatically validate each function argument and throw an error if invalid, like other language do it like PHP. It would be further possible to automatically resolve  overloaded functions to their correct implementation. Currently, this needs to be done manually.
Automatic type guards
Type guards need to be written manually, but with a runtime type system they can be generated on-demand automatically.
is<string>('123'); //true

interface User {
    id: number;
}

const data = JSON.parse(request.body);

if (is<User>(data)) {
    data.id; //number
}

Dynamic type computation
By supporting dynamic type computation, arbitrary type functions can be used in runtime to generate types based on runtime data. E.g. is it possible to construct an object literal based on a schema stored in a database, which can then be used for all other use cases outlined here.
Even generic types can be instantiated with arbitrary runtime types as arguments.
class Bag<T> {
    items: T[];
    add(item: T){ this.items.push(item) }
}

const stringBag = reflect<Bag<unknown>>(typeOf<string>());

API documentation
By having type information available in runtime, an API documentation tool can be generated on-the-fly without a build process (like typedoc).
Dependency Injection
Runtime types allow for the first time to write code/services against abstractions/interfaces instead of against implementations and auto-write them. Most DI container libraries use workarounds like using string/symbol identifier to abstract that away, which is not ideal. Also, many use decorators and emitDecoratoraMetadata which requires additional boilerplate code.
An example of dependency injection container with interface support could look like that:
interface Logger {
    log(...messages: any[]);
    warning(...messages: any[]);
    error(...messages: any[]);
}

class MyLogger implements Logger {
    //...
}

class Controller {
    constructor(private logger: Logger) {} //interface as dependency
}

const serviceContainer = new ServiceContainer([
     //since MyLogger satisfies the interface of Logger, it will be used
     //for dependencies that requested the Logger interface.
     MyLogger,
     Controller,
]);

Configuration system
By adding resolution information to computed types in the runtime type system its possible to resolve configuration values automatically in the easiest to use way possible.
class MyAppConfiguration {
   databaseUrl: string = 'mongodb://localhost',
   host: string = 'localhost',
}

class Service {
    constructor(
        private logger: Logger,
        private host: MyAppConfiguration['host'],
    ) {}
}

When getting the runtime type information of [Service.host](http://Service.host) its type information include the information that its type string was created via an index operator of MyAppConfiguration and 'host' so that there is a link to the configuration class itself. A service container can then auto-wire the configuration values.
HTTP router parameter matching
When dealing with HTTP route parameters, a lot of times there are placeholders and query parameters involved. Those are used to match a route from a list of all registered routes and automatically validated and deserialized.
class MyController {
   @GET('/user/:id')
   getUser(id: number) {
       //id is always automatically a number,
       //and route not found when :id is invalid
   }
}

Type safe RPC
There are many RPC implementations and possible transport encodings available to implement one: GraphQL, Protobuffers/gRPC, etc. With having all function types available in runtime, a library can use those information to automatically serialize parameter and deserialize/validate them in the backend.
//backend
class BackendController {
   registerUser(user: User): boolean {
   }
}

//frontend
import type {BackendController} from './backend';
const client = new Client<BackendController>('localhost');
const status = await client.registerUser(new User('Peter'));

ORM entities
ORM entities try to map relation tables or document collections to objects. For this a lot of meta-data is necessary to describe the table correctly: Primary key, auto-increment, index, unique, collation, constraints, foreign key, and more. With types that add meta-data it is possible to have those information at runtime available so that query builder, data mapper, and SQL migrations can work correctly.
class User {
    id: number & PrimaryKey & AutoIncrement = 0;
    email?: Email;
    image?: Image & Reference;
    constructor(
        public username: string & Unique & MinLength<3> & MaxLength<32>,
    ) {}
}

Type reflection
With a general type reflection API that allows to easily discover and navigate through types its possible for library authors to implement new use cases easily.
typeOf<string>(); //{kind: 'string'}

typeOf<Date>(); //{kind: 'class', classType: Date}

typeOf<User>(); //{kind: 'class', classType: User, types: [{kind: 'property', ...}]}

const user = ReflectionClass.from(User);
user.getMethods();
user.getProperties();
user.getProperty('id').type.kind; //ReflectionKind.number
user.getProperty('id').isOptional(); //boolean

Bytecode Interpreter
I thought a lot about how to actual emit and represent the type information in JavaScript without imposing too much initial runtime overhead (in terms of memory, parsing, and executing) and too much code size (bundle size is important). I asked myself “What could be the smallest possible encoding for types”? The obvious answer is a number, a simple byte. A string? A byte. A number? A byte. An array of numbers? Probably two bytes. A union of string|number? Multiple bytes arranged clever. An object with properties? Probably a lot of bytes. Having such an arrangement of raw bytes implies to have some kind of interpreter that reads them and constructs handy type objects, e.g. {kind: 'string'} instead of just having a simple number like 0, especially when the type is more complex.
Primitives
So, bytes encode a type. For primitive types like string, number, boolean, bigint, etc this is rather trivial. When giving each of them a unique number, then an interpreter can easily construct type objects. For example:
enum TypeOp {
    string = 0;
    number = 1;
    boolean = 2;
    bigint = 3;
}

In JavaScript itself, it can then be encoded just with an array of numbers:
const typeA = [0]; //string
const typeB = [1]; //number

And an interpreter can easily read them and construct a type. The interpreter aka processor is a stack based virtual machine. A very simple implementation could look like that:
type Type = {kind: 'string'} | {kind: 'number'} | {kind: 'boolean'} | ...;

function processor(bytes: TypeOp[]): Type {
    const stack: Type[] = [];

    for(const op of bytes) {
        switch(op){
            case TypeOp.string:
                 stack.push({kind: 'string'});
                 break;
            case TypeOp.number:
                 stack.push({kind: 'number'});
                 break;
        }
    }

    return stack[stack.length - 1]; //return last stack entry
}

processor(typeA); //{kind: 'string'}
processor(typeB); //{kind: 'number'}

This seems rather straightforward.
Who creates those number arrays? The compiler. A TypeScript transformers reads the AST and knows what AST node can be encoded to which TypeOp. This transformer is what I call the type compiler. It creates little byte programs that can be interpreted by a runtime stack machine. The compiler and processor are tightly coupled by a contract that precisely describes what byte ops are available and how they behave in the processor.
What about more complex types? Lets think about an array:
//introduce a new op for arrays
enum TypeOp {
    array = 4;
}

const typeC = [0, 4]; //string[]
//            ^ [string, array]

We introduce a new op array = 4, which has in its implementation defined to pop the last stack entry and use it as element type. Lets implement the op in our processor:
case TypeOp.array: {
    const elementType = stack.pop(); //pop last type from stack
    stack.push({type: 'array', elementType});
    break;
}

So, with the bytes [0, 4] (which is [string, array]) we get an object back of the structure:
{type: 'array', elementType: {kind: 'string'}}

because the first op 0 pushes {kind: 'string} onto the stack, and the second op 4 pops that type and pushes a new one using that type as its elementType.
As one can see, the op array needs at least one type on the stack or it will fail. This implies that the given bytes need to be valid. The compiler is responsible for creating a valid bytes array so that the processor never crashes.
Stack references and op parameters
When dealing with type literals, e.g. 'abc' a new concept in the bytes array arrangement is required. Lets first define a new TypeOp for literal:
enum TypeOp {
    literal = 5;
}

We need suddenly the string 'abc' somehow in our processor. A solution could be to just contain 'abc' in the array: ['abc', 5] But where do we know where to start processing ops then and how do we know to pick the first entry of the array? We need to introduce op parameters and an initial (input) stack frame for references.
We change the byte array structure to the following:
const typeD = ['abc', [5, 0]]; //'abc' literal
//                    ^ [literal, ref0]

Here two things changed: First the actual byte array of ops moved to the last entry of the array, and the op 5 has a 0 as parameter. The op 5 expects always an additional value behind it which it will read and then jump over. The read value (in this case 0) is then used as array index to access the actual literal value 'abc'.
We could call now this array of typeD a program. It has a memory with values and an actual program with ops.  Can be a string, number, boolean, bigint, or a reference to a class, function, or another program.
An implementation could look like that:
function processor(program: [...any[], TypeOp[]]) {
    const references: any[] = program.slice(0, program.length-1);
    const ops = program[program.length-1[;
    const stack: Type[] = [];

    //we switched from `for of` to a for loop
    //to be able to jump over an op via i++.
    for (let i = 0; i < ops.length; i++) {
        switch(op){
            case TypeOp.string:
                 stack.push({kind: 'string'});
                 break;
            case TypeOp.number:
                 stack.push({kind: 'number'});
                 break;
            case TypeOp.array:
                 stack.push({kind: 'array', elementType: stack.pop()});
                 break;
            case TypeOp.literal: {
                 //we increment i manually so that the parameter is not used
                 //in the next iterator of the loop (as its not an op)
                 const parameter1 = ops[i++];
                 const literal = references[parameter1];
                 stack.push({kind: 'literal', literal: literal});
                 break;
             }
        }
    }

    return stack[stack.length - 1]; //return last stack entry
}

processor(typeD); //{kind: 'literal', literal: 'abc'}

Stack frames: Classes and unions
For types like object literals, classes, or functions those op bytes arrangements are more verbose and a bit more complex, but follow the same pattern: There will be an op property and class that interact between each other, so that at the end the last op class reads the stack which contains only property types and constructs a type object {kind: 'object', types: properties}.
The array op pops only and always a single item from the stack. A class or an union op can however have an arbitrary amount of members, an arbitrary amount of types it needs to pop from the stack. There are two ways to encode this: Either by giving the class / union op an additional parameter that indicate how many stack entries it should pop or we can introduce stack frames, so that those two ops essentially always pop a whole stack frame. I chose to use stack frames so that previous operators can push an arbitrary amount of types onto the stack without hard coding the amount in the program itself. This makes it somewhat more dynamic.
First introduce new bytecode ops.
enum TypeOp {
    property = 6;
    class = 7;
    union = 8;
    frame = 9;
}

A program for representing a class and union could look like that:
const typeE = ['id', [1, 6, 0, 7]]; //class { id: number; }
//                   ^ [number, property, ref0, class]

const typeF = [[0, 1, 8]]; //string|number
//             ^ [number, string, union]

Then extend the processor to support stack frames and implement the new ops.
function processor(program: [...any[], TypeOp[]]) {
    const references: any[] = program.slice(0, program.length-1);
    const ops = program[program.length-1];

    //we don't have a single stack anymore, but many
    const stacks: Type[][] = [[]];
    let stack: Type[] = stacks[stacks.length-1]; //current stack frame

    for (let i = 0; i < ops.length; i++) {
        switch(op){
            //...
            case TypeOp.property: {
                 //this op has a parameter for its name
                 const parameter1 = ops[i++];
                 const name = references[parameter1];
                 stack.push({kind: 'property', name, type: stack.pop()});
                 break;
            }
            case TypeOp.class: {
                 //pop the whole stack frame.
                 //everything in the current stack is assumed to be a
                 //{kind: 'property'}
                 const types = stack;
                 stacks.pop();
                 stack = stacks[stacks.length-1];
                 stack.push({kind: 'class', types});
                 break;
            }
            case TypeOp.union: {
                 //pop the whole stack frame.
                 const types = stack;
                 stacks.pop();
                 stack = stacks[stacks.length-1];
                 stack.push({kind: 'union', types});
                 break;
            }
            case TypeOp.frame: {
                 //create a new stack frame.
                 //necessary for e.g. unions in the middle of a program
                 stack = [];
                 stacks.push(stack);
                 break;
            }
        }
    }
}

processor(typeE); //{kind: 'class', types: [{kind: 'property', name: 'id', type: {kind: 'number'}}]}

Type functions
Its all easy for primitive and simple types like outlined above. But as soon as type aliases, generics, type functions like conditionals, and mapped types are involved stuff gets much more complex.
When you think about those more complex types and type functions, it becomes obvious that TypeScript evolved to be an actual language on its own with variables, functions, arguments, that is Turing complete. It happens to be the case that the semantics of this language can easily be mapped in a stack machine with a few registers. All TypeScript types and type function can be represented in bytecodes that can run in a processor like shown above. Since TypeScript basically also supports variables and closures it’s necessary to use stack frames. Luckily we already introduced them for class/union. Also, mapped types and a few other types contain sub function calls, it’s necessary to introduce a (function) calling convention into the stack structure.
Inline other types
In order to implement inlining other types (functions) we have to introduce one new op:
enum TypeOp {
    inline = 10;
}

The inline op expects a single parameter pointing to another program.
const a = [[0]]; //type a = string;
//         ^ [string]

const b = [a, [10, 0]]; //type b = a;
//            ^ [inline, ref0]

The implementation of inline could look like that.
case TypeOp.inline: {
     //this op has a parameter for its program
     const refToProgram = ops[i++];
     const programToInline = references[refToProgram];
     const result = processor(programToInline);
     stack.push(result);
     break;
}

Note that this example uses a recursive implementation: This is not ideal and will lead to stack size exceeded errors with very complex types. It also does not support circular types or circular imports, but it should make it clear how it fundamentally works.
Once generic arguments are involved, it gets more complex pretty quickly. First the type with the generic type parameter has this information encoded in the program using variables/function parameters, which is a reserved stack entry of the current stack frame. The caller makes sure that this stack entry is correctly filled when calling the other type.
Variables
Type aliases with type parameters, mapped types, and infer introduce variables. Variables are slots on the stack with known address. To implement variables, we need to introduce a new operator that loads an address and pushes its value onto the stack. Also to not interfere with the way pop()’ing all types from a stack frames work, we have to make the stack aware of how many variables it contains. We set as convention that variables are placed always at the beginning of the stack frame and when pop()’ing a stack frame, those variables are excluded.
enum TypeOp {
    variable,
    loads, //2 parameters: frameOffset and stack index
}

An generic type alias would look like that:
type MyType<T> = T;

const program = [[variable, loads, 0, 0]];

type MyType<T> = T | string;

const program = [[variable, frame, loads, 0, 0, string, union]];
//`union` pops the whole frame, so we create one for it via `frame`.

The implementation of processor changes:
interface Frame {
    stack: Type[];
    variables: number;
}

function processor(program: [...any[], TypeOp[]]) {
    const references: any[] = program.slice(0, program.length-1);
    const ops = program[program.length-1];

    //we don't have a single stack anymore, but many
    const stacks: Frame[] = [{stack: [], variables: 0}];
    let frame: Frame = stacks[stacks.length-1]; //current stack frame

    for (let i = 0; i < ops.length; i++) {
        switch(op){
            case TypeOp.string:
                 frame.stack.push({kind: 'string'});
                 break;
            case TypeOp.number:
                 frame.stack.push({kind: 'number'});
                 break;
            case TypeOp.array:
                 frame.stack.push({kind: 'array', elementType: stack.pop()});
                 break;
            case TypeOp.literal: {
                 //we increment i manually so that the parameter is not used
                 //in the next iterator of the loop (as its not an op)
                 const parameter1 = ops[i++];
                 const literal = references[parameter1];
                 frame.stack.push({kind: 'literal', literal: literal});
                 break;
             }
            case TypeOp.property: {
                 //this op has a parameter for its name
                 const parameter1 = ops[i++];
                 const name = references[parameter1];
                 frame.stack.push({kind: 'property', name, type: stack.pop()});
                 break;
            }
            case TypeOp.class: {
                 //pop the whole stack frame, excluding variables.
                 //everything in the current stack is assumed to be a
                 //{kind: 'property'}
                 const types = frame.stack.slice(frame.variables);
                 stacks.pop();
                 stack = stacks[stacks.length-1];
                 stack.push({kind: 'class', types});
                 break;
            }
            case TypeOp.union: {
                 //pop the whole stack frame, excluding variables.
                 const types = frame.stack.slice(frame.variables);
                 stacks.pop();
                 stack = stacks[stacks.length-1];
                 stack.push({kind: 'union', types});
                 break;
            }
            case TypeOp.frame: {
                 //create a new stack frame.
                 //necessary for e.g. unions in the middle of a program
                 frame = {stack: [], variables: 0};
                 stacks.push(frame);
                 break;
            }
            case TypeOp.variable: {
                 //initialize with never
                 frame.stack.push({ kind: 'never' });
                 frame.variables++;
                 break;
            }
            case TypeOp.loads: {
                 //this op has two parameters.
                 //the offset to the stack frame from where to load a value
                 const frameOffset = ops[i++];
                 //and the index of the stack entry of that frame
                 const stackIndex = ops[i++];
                 const frameToReadFrom = stacks[stacks.length - frameOffset];
                 const value = frameToReadFrom.stack[stackIndex];
                 frame.stack.push(value);
                 break;
            }
        }
    }
}

To support passing arguments to an program with variables, the variable implementation could check an args array and read from it instead of setting it to {kind: 'never'}.
function processor(program: [...any[], TypeOp[]], args: Type[] = []) {

//...

case TypeOp.variable: {
    frame.stack.push(args[frame.variables] || { kind: 'never' });

//then call it via
processor(program, [{kind: 'string']);

The type compiler knows where to find a variable identifier and can correctly calculate loads call parameters.
Calling convention
A few type functions require to call sub functions of a program: mapped types, distributive conditional types, and conditional types. In JavaScript one could say they are blocks, but in this bytecode interpreter those blocks are compiled as sub functions.
type A<T> = {[P in keyof T]: T[P]}
//                           ^ T[P] is a function, called multiple types
//                           with 2 variables available in closure.

type B<T> = T extends any ? true : false;
//          ^ naked T means distributive conditional type
//            which turns it into a function called multiple times
//            for each T member (when T is an union)

type C<T> = string extends T ? true : false;
//                                    ^ false block is a function
//                             ^ true block is a function
//                             Those blocks are only executed depending on the
//                             result of the `extends` operator.

To make this work, we need 3 new ops.
enum TypeOp {
    call,
    return,
    jump
}

Since the type functions above have sub functions with closure (function in a function), those sub functions are embedded in the current program at the very beginning. jump with one parameter makes sure that the embedded sub functions are omitted initially, return marks the end of each embedded function, and call with one parameter (position of the sub function) triggers the calling convention (usually done internally and not emitted as op code)
type Map<T> = {[P in keyof T]: T[P]};

Before we can compile this type function in bytecodes, we need a few new ops:
enum TypeOp {
    keyof, //assumes/pops one entry from the stack
    indexAccess, //assumes/pops two entries from the stack

    //has one parameter: the ops address of the sub program
    //assumes pops one entry from the stack
    mappedType,
}

const program = [[
    //jump directly to `variable`, where the actual program begins
    jump, 10,

    //the sub function `T[P]`.
    //calling convention creates for each call a new stack frame,
    //hence frameOffset parameter for loads is 1.
    loads, 1, 0, loads, 1, 1, indexAccess, return,

    //main program start
    variable, variable, loads, 0, 1, keyof, mappedType, 2
]];

The mappedType pops an entry from the stack created by the keyof op and tries to loop over it. The loop calls for each entry of keyof the sub function at 2. The calling convention says that a “call” (to 2 in this case) creates a new stack frame and puts in its first stack entry the return address. Once return is called, the return address is read and the processor jumps to that address again. The mappedType op uses a registry to track at which position it currently is in order to know if another call to 2 is necessary or if the program can continue. It modifies for each iteration the second variable so that the sub function has the correct value when doing loads 1 1.
The implementation of all of these ops are a bit more complex and probably out of scope for this post. To implement the whole TypeScript type system there are a lot more ops required. Currently the instruction set contains over 81 ops. If the TypeScript teams decides that this approach is worth considering I’d love to document each and every op with example code like I did above.
Attach type information
Now after defining the representation of a type in runtime code, the next problem to solve is how to attach those information to actual JavaScript symbols like classes and functions.
The idea is that for classes and functions I get the full type information when the symbol is passed to a function.
function a(param: string): void {}

const type = reflect(a);
//{kind: 'function', parameters: [{kind: 'parameter', name: 'param', type: {kind: 'string}], return: {kind: 'void'}

To make this possible its necessary to attach the bytecode program to each function and class. I decided to choose to write it at a property called __type. So that emitted JavaScript could look like that:
function a() {}
a.__type = [[string, void, function]]; //correctly encoded though, e.g. [0, ...]

class User {}
User.__type = [[...]];

Interfaces and type aliases could be emitted with their name prefixed with something unique.
type MyType<T> = T | string;

const __ΩMyType = [[variable, loads, 0, 0, string];

This approach has as advantage that no global WeakMap is required and the program is GC automatically when the function or class is not referenced anymore. This however is limited to function and classes only. It’s not possible with this approach to annotate type information to object literal expressions or variables. Exporting type aliases and interfaces as const variables makes it possible to be tree-shakeable.
Why
Why is a bytecode interpreter proposed and not something more trivial like serializing a type as JavaScript objects? One can easily emit JavaScript objects that describe a type directly instead of introducing bytecode ops and an interpreter. For example:
const typeA = {kind: 'string'};

The reason I chose a bytecode representation is that the emitted JavaScript code is much smaller and allows dynamic type computation. The latter is not possible when the final computed type is serialized. Resolving generic type arguments also require some sort of runtime type computation and type checks in order to narrow a generic union down to the real passed argument. Also, serializing a complex class with many properties and all its attributes (visibility, readonly, initializer, optional) makes the emitted serialized objects huge and the bundle size too large. They also impose a greater runtime overhead cost in terms of execution and memory footprint. My goal was instead to design a format that has the fewest overhead cost possible and generate load only when the type is actually requested.
Encoding
The program bytes are encoded in printable ASCII characters, from the code range 33 upwards.
That means the program array structure from above
const typeA = ['a', [5, 0]]; //'a'
//                  ^ [literal, ref0]

Is actually encoded in JavaScript like that:
const typeA = ['a', '&!'];
//                   |^ String.fromCharCode(0 + 33) = '!'
//                   ^ String.fromCharCode(5 + 33) = '&'

This makes a complex type much smaller compared to the array number representation.
Type checking / Performance Improvements
The bytecode interpreter as currently designed and implemented only allows static types to be compiled. That means no inferred types or control analysis is implemented. Since it supports the extends type operator its able to check whether two types are compatible. This is currently limited to extends only and has not implemented more detailed type checks like all type variances.
However, by using such an architecture it would probably be possible compiling a whole TypeScript file into bytecodes and execute this in a very fast VM. That VM can be written in faster languages like C++/Rust and operate entirely on those bytescodes. By implementing error collection it would be further possible to collection validation errors in this VM which basically converts it into a very fast type checker.
This approach of compile a TypeScript file into bytecode, putting it as a binary file on disk, and run it on demand in an ultra fast VM enables probably much faster type checking and simplifies caching.
I say here “probably” because I’ve not tested it yet. If the TypeScript teams says its worth investing further I’d love to build a PoC for that. I’d implement the VM in C++ and convert the type compiler from a transformer to a standalone TS program that is based on the TS compiler AST.
Beyond the Stars
A bytecode interpreter, or rather an bytecode compiler and official spec of an instruction set for a virtual machine, could allow new ways of using TypeScript in non-JavaScript environments. For example could it be possible to define types in TypeScript and use them in cross-language environments for e.g. serialization and validation, equal to what JSON-Schema currently is used for. Concretely allows that to define types in TypeScript (a subset of TypeScript, essentially only the type system, not the JavaScript semantics) and have those types as single source of truth sitting in a .ts file. Other languages like go, C++, Rust, can read its bytecode and compute the type in their runtime allowing them to work with those types to e.g. create serialization or validation functions.
It would enable writing ORMs entities, JSON schema, ProtoBuffers, and many other DSL in TypeScript without having the full fledged TypeScript library or JavaScript as dependency.
One could go as far and argue that this instruction set and bytecode interpreter could be standardised and implemented in the JavaScript engines like v8 directly. Then based on that further ECMAScript features can be implemented (like overloaded functions, function parameter validation, and more). I think TypeScript is here to stay and making JavaScript itself more powerful on successful patterns TypeScript introduced is something the whole industry would appreciate.
Implementation Proof of Concept
I implemented most of the outlined use cases already in a library called Deepkit. It contains @deepkit/type for serialization/validation/type guards, @deepkit/orm for an ORM that supports classes and interfaces as entities, @deepkit/rpc that supports an fully type-safe RPC implementation with automatic serialization/validation, @deepkit/injector a dependency injection library that supports auto-wire, interfaces as dependencies, and more.
The current released version of these libraries use a custom type system based on classes with decorators, however I’ve rewritten and implemented almost all libraries onto the new runtime type system in the branch feature/autotype that works like described above. The core functionality is in this folder: https://github.com/deepkit/deepkit-framework/tree/feature/autotype/packages/type/src/reflection
It contains the type compiler (that generates the bytecode from the AST in a TypeScript transformer), the processor (the stack machine that processes the bytecode and generates types), as well as some handy reflection classes and type utility functions.
Some important characteristics of this implementation:

The bytecode is based on the AST, not inferred types. That means it generates bytecode that essentially mirrors actual type functions. For example a mapped type is compiled as actual mapped type, as a function with inputs and a loop. Not the actual type result is encoded in bytecode, but the type function itself. This makes it necessary to annotate types explicitly. It could be changed to support inferred types as well in the future. However, it’s not possible to reverse the bytecode back to the exact same TypeScript source.
The processor is a stack based virtual machine that supports circular types and uses an iterative interpreter instead of a recursive one, which makes it possible to have arbitrary complex types without running into a “Maximum call stack size exceeded” error.
Circular types are supported perfectly well. The resulting type object is then circular as well.
The implementation does not support yet everything: For example renaming properties in a mapped type via as is not supported yet. Also there are a few differences and not all types are exactly what TypeScript would emit, see for example: https://github.com/microsoft/TypeScript/issues/47048.

API
To get the runtime type information from a type, a function call is necessary. To arbitrary types typeOf<T>() can be used. For classes and functions there are two ways to get type information: Raw type objects and handy Reflection classes:
const type = typeOf<string>();
const type = typeOf<number>();
const type = typeOf<string|boolean>();

type a = {a: string, b: number};
const type = typeOf<a>();

class User {
   id: number = 0;
}

const type = reflect(User);
//{kind: 'class', classType: User, types: [...]}

const reflection = ReflectionClass.from(User);
reflection.getProperties();
reflection.getMethods();

The various Reflection* classes are inspired by other reflection APIs like the one of PHP. The code of those classes can be found here: https://github.com/deepkit/deepkit-framework/blob/feature/autotype/packages/type/src/reflection/reflection.ts
Compiler
The compiler can be found here: https://github.com/deepkit/deepkit-framework/blob/feature/autotype/packages/type/src/reflection/compiler.ts
It’s a rather complex transformer that needs access to various internal types from the TypeScript compiler API in order to get all necessary information.
All bytecode ops can be seen here: https://github.com/deepkit/deepkit-framework/blob/feature/autotype/packages/type/src/reflection/type.ts#L1976-L2141
Processor
The processor can be found here: https://github.com/deepkit/deepkit-framework/blob/feature/autotype/packages/type/src/reflection/processor.ts#L248
Caching
Types in this implementation are cached. The cache is attached to the bytecode array directly and only set when the program is not generic.
Type types
Type object information are simple objects that have all type information in a raw format. There is a big enum contain all ReflectionKind and for each type an interface that has a kind, additional type specific properties, and parent + other runtime information like type annotations.
export const enum ReflectionKind {
    never,
    any,
    unknown,
    void,
    object,
    string,
    number,
    boolean,
    symbol,
    bigint,
    ...
}

export interface TypeNever {
    kind: ReflectionKind.never,
    parent?: Type;
}

See https://github.com/deepkit/deepkit-framework/blob/feature/autotype/packages/type/src/reflection/type.ts#L21-L452
Reflection
Reflection is the heart of the implementation. Its API and tests can be seen here: https://github.com/deepkit/deepkit-framework/blob/feature/autotype/packages/type/tests/reflection/reflected/integration.spec.ts
Type decorators
In order to be able to implement certain functionalities like ORM and validation its necessary to annotate types with additional meta-data. For validation its validation constraints like minimum, maximum, minLength, etc. For ORM its meta-data like primaryKey, autoIncrement, reference, index, etc. TypeScript already supports branded types which can not directly be used here. Instead it uses a pattern almost identical to branded types but making the brand optional.
type PrimaryKey = {__meta?: ['primaryKey']};

class User {
    id: number & PrimaryKey;
}

In the reflection system, intersections with objects that contain a __meta property are handled in a special way. They expressions are stored at the type directly.
type a = number & PrimaryKey;

const type = typeOf<a>();
{
  kind: 'number',
  decorators: [
    {
      kind: 30,
      typeName: 'PrimaryKey',
      types: [{
        kind: 32,
        type: { kind: 25, types: [Array], parent: [Circular *1] },
        name: '__meta',
        optional: true,
      }],
    }
  ]
}

With those information at the type directly it’s possible to change the behaviour of certain types in an extendable way.
Serialization
Serialization examples can be seen in the tests: https://github.com/deepkit/deepkit-framework/blob/feature/autotype/packages/type/tests/reflection/reflected/serializer.spec.ts
The Serializer API itself is highly customizeable and the default serializer can be found here: https://github.com/deepkit/deepkit-framework/blob/feature/autotype/packages/type/src/serializer.ts#L1643
expect(serialize<Date>(new Date('2021-10-19T00:22:58.257Z'))).toEqual('2021-10-19T00:22:58.257Z');

Casts
Casts is nothing more than running the deserializer of the default serializer. It supports converting types that are convertable and throws if its not convertable.
https://github.com/deepkit/deepkit-framework/blob/feature/autotype/packages/type/tests/reflection/reflected/serializer.spec.ts#L210
expect(cast<string>('123')).toBe('123');
expect(cast<string>(123)).toBe('123');

expect(cast<number>(123)).toBe(123);
expect(cast<number>('123')).toBe(123);

expect(cast<Date>('2021-10-19T00:22:58.257Z')).toEqual(new Date('2021-10-19T00:22:58.257Z'));

Type guards
Type guards are an inherent part of serializers since union types need a type check in order to know which serializer function should be used. Its API and tests can be seen here: https://github.com/deepkit/deepkit-framework/blob/feature/autotype/packages/type/tests/reflection/reflected/typeguard.spec.ts
expect(is<number>('a')).toEqual(false);
expect(is<number>(123)).toEqual(true);
expect(is<number>(true)).toEqual(false);
expect(is<number>({})).toEqual(false);

Validation
Type guards are one part of validation. Content validation another. API and tests can be seen here: https://github.com/deepkit/deepkit-framework/blob/feature/autotype/packages/type/tests/reflection/reflected/validation.spec.ts
type Username = string & MinLength<3>;

expect(is<Username>('abc')).toBe(true);
expect(is<Username>('ab')).toBe(false);

Summary
I think this post is already too big, so I stop here, although there can be a lot more said about the bytecode interpreter, runtime types, and its possibilities.
If the TypeScript team considers this worth investigating further, I’d love to help to integrate this into TypeScript itself and make it a reality for all those users downloading solutions for that million times each month.
I understand if this feature is not in TypeScript's interest (as outline in its goals), however I think considering the shown demand in the industry and further described opportunities it might be worth either rethinking about the goals or at least support this undertaking with external partners/projects. Even if it will not be part of TypeScript officially it would help enormously if the Typescript team accepts this use case as valid and provide certain features (like making certain compiler APIs public or allowing transformers in tsconfig.json) and supports it in a way that it can be implemented in the best way possible.

That is an impressive write-up, but I have to question the purpose of opening yet another issue about a feature that has been explicitly rejected again and again by the TypeScript team.

but I have to question the purpose of opening yet another issue about a feature that has been explicitly rejected again and again by the TypeScript team.

As you can see the main discussion issue https://github.com/microsoft/TypeScript/issues/3628 has never been rejected and is still open, just like many other feature requests that although never confirmed neither rejected are still open. Also, this issue is not about a vague feature request, but a concrete implementation and analysis of the market demand plus a proposal for a bytecode interpreter which can be used for runtime types but also for other scenarios like performance improvements as well. So, quite different to anything seen yet, in terms of elaborateness, analysis, design proposal, and implementation demonstration. To even remotely compare this to any other issue regarding runtime types is mystifying to me.

This is awesome.  However, it is worth noting that there is an explicit language design non-goal to:

5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

I'm not on the TS team and am not the one making decisions about whether to leave issues open or close them, but if I had to wager on it I'd bet that this will be declined quickly, no matter how amazing it is.  We'll see, I guess.

@jcalz yes, indeed. I've written about that in the original post, and at the end. Getting a stance on that defines if and how this will be made available to the users. Doesn't have to be necessarily in TypeScript's core, its good enough if the TypeScript team decides to support the undertaking in other ways.

Sorry, I don't see where you acknowledged the explicit non-goal that essentially prohibits this endeavor in TS proper.  Looks like you mentioned goals 3, 4, and (checks notes) 9, but not non-goal #5.  I might have missed it though.

That's fine. I'm more interested in what the TypeScript team is saying about that and especially about the last paragraph of the original post. It's not a must-have to have this in TypeScript itself. However, there's not much value in sticking to years old goals that might be meanwhile obsolete due to market movements. So let's concentrate on making the use cases of packages that have 76mio downloads/month possible in better ways instead of finding ways against it and why it shouldn't even be considered in the first place due to abstract nice-to-have goals.

First off, this was a super fun and interesting read, so thank you for posting it. It's great to see people exploring what's possible, and this looks like a very promising project.
To cut straight to the point: Is this in scope for us, now? Still no. The absolute plethora of options in this space, both for native-to-TS options like io-ts and 3rd-party-to-TS like JSON schema validators, shows that there's a wide range of what people want in the space, and that many projects with different approaches are capable of delivering tools with value.
Regarding design goals - we're extremely committed to the erasability of the type system. Keeping the type system erasable is a very strong invariant that allows us to do other important things. One of the reasons we're able to make the type system more powerful and expressive from version to version is that we have the flexibility to e.g. change type inference at a particular position from { x: string } & { y: number } to { x: string; y: number } without worrying about breaking the runtime behavior of anyone's programs.
This isn't a theoretical concern: people already @ us about when we change declaration emit in ways that produce representationally-distinguishable but semantically-identical types. Taking this to the next level wherein one person's bug about a conditional type not immediately resolving becomes a breaking change in someone else's program, at runtime, in ways that are going to be much more subtle than type error vs not-a-type-error -- it's not a Pandora's Box we're keen to open.

@RyanCavanaugh note the last paragraph of the original post:

Even if it will not be part of TypeScript officially it would help enormously if the Typescript team accepts this use case as valid and provide certain features (like making certain compiler APIs public or allowing transformers in tsconfig.json) and supports it in a way that it can be implemented in the best way possible.

Would you recommend that @marcj flesh out these features into concrete suggestions and raise them in new issues (assuming such issues do not already exist)?  Or are those also out of scope?

like making certain compiler APIs public or allowing transformers in tsconfig.json

@RyanCavanaugh  I'd also like to highlight this ask. While "runtime types" indeed seems like a risky and "Out of Scope" feature to add to the default typescript build, why not let experiments happen outside the typescript tree? The community needs just a little bit of help. The upside is that a lot of useful innovation will happen that is otherwise not possible, and sometimes even discouraged today.

We do take API requests through issues and have added a fair number of functions to the public API surface upon being asked. Emit plugin support is also available and we'd take issues on things there if things are needed.
We don't support transform plugins in tsconfig.json because we think this operation should not be a risky one:
git clone somerepo
npm install --ignoreScripts
tsc

Why not support tsc --someRiskyOption so that people can customize their npm run build / yarn build? Also many of us use ts-loader and other build systems to invoke typescript. Transform plugins could be exposed via the programmatic API only, leaving tsc "safe by default".

I have to mention my project (not listed in the table above) tst-reflect.
I'm missing reflection in TypeScript(/JavaScript) because of Dependency Injection. TypeScript will never implement reflection, sorry to all of us, I'm just realist. So I've created my own quite huge reflection system.
And then I've build the Dependency Injection of top of that, see.
tst-reflect is based on custom transformer and it generates metadata about types, accessible by getType<SomeType>(): Type function. Instance of Type class is returned which contains quite a lot of methods to work with types.
Generic types supported!
It works with quite complex types, unions, intersections, enums, details about interfaces and classes (constructors, properties, methods, parameters, generic types, decorators,.. ) and much more.
Usage is inspired by C# reflection.
Here is REPL with example. Runtime Type, even runtime generic

Simplified version of that REPL.

function printClassInfo<TType>()
{
	const type = getType<TType>(); // <<== Here is the generic type used!

	if (!type.isClass())
	{
		return;
	}

	console.log("class " + type.name);
	console.log("full type identifier: " + type.fullName);

	const properties = type.getProperties();
	const methods = type.getMethods();

	console.log("Properties");
	console.log(
		properties.map(prop =>
			`${AccessModifier[prop.accessModifier]} ${Accessor[prop.accessor]} ${prop.name}: ${prop.type.name}
		).join("\n")
	);

	console.log("Methods");
	console.log(
		methods.map(method => AccessModifier[method.accessModifier] + " " + method.name
			+ "("
			+ method.getParameters().map(param => param.name + ":" + param.type.name).join(", ")
			+ "): " + method.returnType.name
			+ (method.optional ? " [optional]" : "")
		).join("\n")
	);
}

class Bar {
    foo: string;
    bar: any;
    toSomething(): void;
}

printClassInfo<Bar>();

Deserialization is the one thing that absolutely requires some runtime representation of compile-time types.
There are many different approaches to deserialization, but they all have the same general shape: type Parser<T, U, E> = (x: T) => ['ok', U] | ['error', E].
Perhaps having a simple standard type like this would help.
An advanced proposal could also include an API for composing these types: e.g. a standard operation for constructing a Parser<T, [U1, U2], E> out of Parser<T, U1, E> and Parser<T, U2, E>.

Ok, cool, was worth a try. Since runtime type information is out of scope and the others points weren't addressed, I assume there is no interest in any of this, so I'm going to close this one. Thanks for the fast feedback.

FYI, this TypeScript bytecode interpreter has now been released together with a full-featured framework that tries to utilise its potential to the fullest: https://deepkit.io/blog/introducing-deepkit-framework

I say here “probably” because I’ve not tested it yet.

For anyone reading this: This has been tested last year and a proof of concept high-performance type-checker has been built using the byte-code approach outlined in this issue which confirms this theory actually works. It can be found here: https://github.com/marcj/TypeRunner. It shows how it can speed up type checking by many hundreds to thousands of times.
I can not build it alone as it's too time-consuming. But if we could make it happen it would shape not only shape the future of TypeScript itself but the whole industry, bringing so many architectures to the next level, increase the Interoperability of many languages (replacing JSON schema with TS), and rendering so many transpilers (esbuild, SWC) obsolete.
We have meanwhile dozens of JS packages that make type information available in runtime in all sorts of bizarre ways. Together they have a staggering 180 million installs per month! Much more than TypeScript itself. I think it couldn't be more clear that people really want this.

@marcj Hey, still subbed to this thread. TypeRunner looks amazing. Do you plan on publishing a specification for the bytecode?

@sinclairzx81 not planned to make one, although I have a subset more or less standardised since they are used in backward compatible ways in Deepkit's runtime types since now two years.
What are you looking to solve/get with a specification of a bytecode that is capable of doing full type checking like done in TypeRunner? Please note that TypeRunner has also super-instructions for optimisation purposes, that are likely not needed in an official spec. It was also designed for a stack machine. Bytecode for a register machines would look very different, and it's not yet clear to me what type of machine would be suited best for something like TypeScript, or what abstraction of bytecode. Maybe a more low level bytecode is better that can then be JIT optimised depending on its use.

Hi All, so just banging my head around this issue.
Is really a shame that we don't have reflection when using typescript. so much effort put into strongly and correctly type everything and then all that info is lost at runtime 🥲.
Anyway from what I can see the biggest issue for the TS team is this:

Regarding design goals - we're extremely committed to the erasability of the type system. Keeping the type system erasable is a very strong invariant that allows us to do other important things.

Now, here's my idea for a simple API that could tackle this issue. It's straightforward and, I think, not too tricky to implement.
import { reflect } from 'tsc';

interface MyUser {
  name: string;
  age: number;
  address?: string;
}

const user = { name: 'John', age: 33 };

// 'reflect' is a special function provided by 'tsc' for runtime reflection
const userMetadata = reflect<typeof user>();

console.log('userMetadata.kind); // Outputs: 'interface' (or a similar kind identifier)

This way, we're not messing with TypeScript's design goals of keeping type information erasable, as const user is still part of the program.
To keep it simple, the object generated by reflect would be a serializable version of the TypeScript AST, just with all the type dependencies embedded in. So there is no need to emit anything beyond the user const (not ideal from a memory point of view but at least we have type metadata). From there, us developers can handle the emitted type metadata.
you could argue that the reflect is not really a Function but that would be solved by providing a type for it that does not allow anything other than call it.
Anyway just my two cents fro an elegant solution to the problem.  Unfortunately, I'm not a tsc compiler guru, so I can't whip up a pull request right now.


[SPARK-24337][Core] Improve error messages for Spark conf values

What changes were proposed in this pull request?
Improve the exception messages when retrieving Spark conf values to include the key name when the value is invalid.
How was this patch tested?
Unit tests for all get* operations in SparkConf that require a specific value format

Can one of the admins verify this patch?

ok to test

Test build #91270 has started for PR 21454 at commit f198f28.

cc @zsxwing @jiangxb1987

IIUC this PR print the config key in the error message if the config value(either default or get from the configMap) can't be cast properly. Personally I think it add some value to include this change. I only have some nits.

Test build #91270 has finished for PR 21454 at commit f198f28.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #91279 has started for PR 21454 at commit badbf0e.

Retest this please

LGTM

Test build #91279 has finished for PR 21454 at commit badbf0e.

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

Merged build finished. Test PASSed.

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

Test build #91315 has started for PR 21454 at commit c1b4d16.

Test build #91316 has started for PR 21454 at commit b7ff38f.

Test build #91318 has started for PR 21454 at commit 38ffa3e.

Test build #91315 has finished for PR 21454 at commit c1b4d16.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #91316 has finished for PR 21454 at commit b7ff38f.

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

Merged build finished. Test PASSed.

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

LGTM
Thanks! Merged to master

Test build #91318 has finished for PR 21454 at commit 38ffa3e.

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

Merged build finished. Test PASSed.

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


Climate : fixing internal server error when setting hvac mode

This pull request closes #57
Thanks to this comment from @davidsak in OpenWonderLabs/SwitchBotAPI#363 :

setAll with a decimal in the temperature parameter does not seem to work anymore but if called with an integer it does. So for instance, “20.3,5,2,on” does not work but “20,5,2,on” does.

When I force a int  cast on  target_temperature before sending the request, all hvac_set_mode commands seem to work.

This is a pretty dirty quickfix that will probably require to be cleaned.
It works for me because I only used round target temperature, but this will have some consequences for people using decimals.
I don't really know how to approach this in that case.

Hello @MrXANA91
As I mentioned in the issue https://github.com/OpenWonderLabs/SwitchBotAPI/issues/366 I have the same error sending a setAll command with a integer parameter.
What are the evidence that the problem is the float value?

Hello @MrXANA91
As I mentioned in the issue OpenWonderLabs/SwitchBotAPI#366 I have the same error sending a setAll command with a integer parameter.
What are the evidence that the problem is the float value?

Using this branch, several commands I tried to send :
2024-11-24 23:40:45.157 DEBUG (SyncWorker_15) [custom_components.switchbotremote.client.remote] Sending command setAll
2024-11-24 23:40:45.157 DEBUG (SyncWorker_15) [custom_components.switchbotremote.client.remote] Command payload {'commandType': 'command', 'command': 'setAll', 'parameter': '20,5,1,on'}
2024-11-24 23:40:45.157 DEBUG (SyncWorker_15) [custom_components.switchbotremote.client.client] Calling service https://api.switch-bot.com/v1.1/devices/****/commands
2024-11-24 23:40:45.982 DEBUG (SyncWorker_15) [custom_components.switchbotremote.client.client] Call service https://api.switch-bot.com/v1.1/devices/****/commands OK

2024-11-25 09:01:37.317 DEBUG (SyncWorker_7) [custom_components.switchbotremote.client.remote] Sending command setAll
2024-11-25 09:01:37.317 DEBUG (SyncWorker_7) [custom_components.switchbotremote.client.remote] Command payload {'commandType': 'command', 'command': 'setAll', 'parameter': '20,1,1,on'}
2024-11-25 09:01:37.317 DEBUG (SyncWorker_7) [custom_components.switchbotremote.client.client] Calling service https://api.switch-bot.com/v1.1/devices/****/commands
2024-11-25 09:01:38.264 DEBUG (SyncWorker_7) [custom_components.switchbotremote.client.client] Call service https://api.switch-bot.com/v1.1/devices/****/commands OK

2024-11-25 09:16:16.407 DEBUG (SyncWorker_15) [custom_components.switchbotremote.client.remote] Sending command setAll
2024-11-25 09:16:16.408 DEBUG (SyncWorker_15) [custom_components.switchbotremote.client.remote] Command payload {'commandType': 'command', 'command': 'setAll', 'parameter': '20,1,3,on'}
2024-11-25 09:16:16.408 DEBUG (SyncWorker_15) [custom_components.switchbotremote.client.client] Calling service https://api.switch-bot.com/v1.1/devices/****/commands
2024-11-25 09:16:17.383 DEBUG (SyncWorker_15) [custom_components.switchbotremote.client.client] Call service https://api.switch-bot.com/v1.1/devices/****/commands OK

And trying the exact same command you described here : OpenWonderLabs/SwitchBotAPI#366
2024-11-25 09:17:38.973 DEBUG (SyncWorker_19) [custom_components.switchbotremote.client.remote] Sending command setAll
2024-11-25 09:17:38.973 DEBUG (SyncWorker_19) [custom_components.switchbotremote.client.remote] Command payload {'commandType': 'command', 'command': 'setAll', 'parameter': '23,1,3,on'}
2024-11-25 09:17:38.973 DEBUG (SyncWorker_19) [custom_components.switchbotremote.client.client] Calling service https://api.switch-bot.com/v1.1/devices/****/commands
2024-11-25 09:17:40.108 DEBUG (SyncWorker_19) [custom_components.switchbotremote.client.client] Call service https://api.switch-bot.com/v1.1/devices/****/commands OK

During my first debugging attempts here, I tried to reset my developer tokens. Maybe doing this had an impact that went unnoticed until now?

Hello,
As per this comment, it seems, as you say, float number cause the error.
But looking at the climate class, target temperature step is set to 1.
How is it possible that we have float?

Hello,
As per this comment, it seems, as you say, float number cause the error.
But looking at the climate class, target temperature step is set to 1.
How is it possible that we have float?

Best guess is that by default, Home Assistant consider all temperature values as floats, including the _target_temperature. That's probably why any attempt to format this value as a string will display it as a float. The solution to cast that value as an int before sending the web request might not be as dirty as I thought it would be.
The thing is : target temperature step for this Climate component can be configured to be between 0.1 and 2 (with 0.1 minimum precision steps) (see config_flow.py ligne 85). Unfortunately from now on, any value except 1 and 2 as step values are no longer valid. I don't really know how to handle this.
Anyway, let me know what I can do to help having this fix merged as quickly as possible.

@KiraPC if it helps you, also the official Switchbot Cloud Integration has problems setting temperature. It works through the Switchbot App though


Create CONTRIBUTING.md.

There's no public CI yet so there's no CI section.
@nre-ableton ptal!

@nre-ableton I've updated this to a standardized one that just points to the Jenkinsfile. wdyt?

@mst-ableton I think we should probably link to the master blob


Run Foundation tests in parallel

Should be significantly faster than running them serially.

@swift-ci Please test


[ruff] - allow private variables for RUF006

Summary
Changes RUF006 to allow private vars.
I believe this is a reasonable addition, private declarations surely satisfy the underlying needs.
Test Plan
cargo test

I discussed this offline with @MichaReiser and I think I misunderstood what this PR was trying to do.
@diceroll123, the fixture snippet you've added looks like this:
import asyncio

def f():
    loop = asyncio.get_event_loop()
    _task = loop.create_task(main())

Ruff will indeed emit a RUF006 error on this currently, but it's not because it's a private variable. It's because the function could exit immediately after the loop.create_task() call, which will lead to the _task variable immediately being cleaned up since it's only a local variable. If you change your example to this, Ruff no longer complains about it:
import asyncio

def f():
    global _task
    loop = asyncio.get_event_loop()
    _task = loop.create_task(main())

I'm no longer convinced I agree with the change being proposed here. I think the bug that the rule is trying to protect you from applies just as much to tasks assigned to variables that start with underscores. Could you maybe give a little more detail about your motivation for making this PR?

Hm, good points all around.
The usage in my codebase that made me make this PR is deep within a forever-running async loop, so I suppose I overlooked what Alex has brought up.


Guide for a quick start is needed

Problem
There is no description and code example that shows where the middleware must / can be inserted into a Mezzio application.
Suggestion
The basic usage with adding middleware and creating the configuration can be described in a quick start guide. A new page and navigation entry is needed for this.

Closed with #26


Memcached sample for App Engine flexible environment

To fix: needs README added

OK, ready for review

👍


[2.0.14] Nodes not joining the cluster and waiting for ever

Since upgrade to 2.0.14 we've been consistently seeing the issue of one of the node not being able to join the cluster.(Have not tried this in 2.1.*)
Observation:

3 node setup with default configurations
Bring up two noes and once the re-partition is complete, bring up 3rd node
3rd node waits for ever getting the migration task from one of the node

Logs from one of such occurrences is here.
2015-09-06 19:16:55:308 WARNING Distributed server is not yet ONLINE (status=STARTING), reject incoming connection from /<IP_ADDRESS>:42037. If you are trying to shutdown the server, please kill the process [OServerNetworkListener]
2015-09-06 19:17:49:074 WARNING Distributed server is not yet ONLINE (status=STARTING), reject incoming connection from /<IP_ADDRESS>:50198. If you are trying to shutdown the server, please kill the process [OServerNetworkListener]
2015-09-06 19:17:55:286 WARNING Distributed server is not yet ONLINE (status=STARTING), reject incoming connection from /<IP_ADDRESS>:45294. If you are trying to shutdown the server, please kill the process [OServerNetworkListener]
2015-09-06 19:18:49:044 WARNING Distributed server is not yet ONLINE (status=STARTING), reject incoming connection from /<IP_ADDRESS>:53518. If you are trying to shutdown the server, please kill the process [OServerNetworkListener]
2015-09-06 19:18:55:280 WARNING Distributed server is not yet ONLINE (status=STARTING), reject incoming connection from /<IP_ADDRESS>:48606. If you are trying to shutdown the server, please kill the process [OServerNetworkListener]
2015-09-06 19:19:48:954 WARNING Distributed server is not yet ONLINE (status=STARTING), reject incoming connection from /<IP_ADDRESS>:56893. If you are trying to shutdown the server, please kill the process [OServerNetworkListener]

You can download the heapdump and threaddump, link below, when this was in play.
https://drive.google.com/folderview?id=0B-humU2jX9QOfnRSREdNcWo0S2x1Z2FuY0Y5aV9ocXJrX2U1eWN3Ny1QTmJSdGt4cDBrZjQ&usp=sharing
Dump is for the node that was waiting, did not take the dump of the serving node as it was responsive for other requests all along. If you need that as well, i can get the dump the next time this happens again.
Let me know if you need anything else to solve this!
On a side note, have observed something scary on a sunday evening in prod. 2.0.14, all the nodes were frozen without any activity. Logs not showing anything significant, the cluster had to be restored(read - multiple restarts) instantly and ppl did not get a chance to take mem and thread dump, i'm looking forward to the occurrence again and will provide the dumps for further debugging.
At the first go, it looks extremely similar to #4890

This issue should be fixed (like #4890). I'm closing, in case you experiment the same problem, please reopen/comment this.


Assign devices to servicing channels for Windows 10 updates - DIY Semi Annual Channel instructions don't work on 19H2

The current version of this page as of May 31, 2020 says:

To assign a single devices locally to the Semi-Annual Channel

Go to Settings > Update & security > Windows Update > Advanced options.
Select Defer feature updates.

However, on my system running Windows Enterprise version 1909 (OS Build 18363.836), it's not possible to "Select Defer feature updates" as that button or toggle isn't actually there. The closest analog (see English screenshot below) is an setting "A feature update includes new capabilities and improvements. It can be deferred for this many days: [enter number]".
Would you kindly take a look and correct this documentation page or the product as needed?

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

ID: f5400f8b-2ed0-7960-4e3d-2f3444be7e6b
Version Independent ID: 81bd37f4-301b-b5ab-cda2-972a72a31ae7
Content: Assign devices to servicing channels for Windows 10 updates (Windows 10) - Windows Deployment
Content Source: windows/deployment/update/waas-servicing-channels-windows-10-updates.md
Product: w10
Technology: windows
GitHub Login: @jaimeo
Microsoft Alias: jaimeo

I wonder if the whole "Assign devices to Semi-Annual Channel" section of the page, where the quoted instructions came from, is now both wrong and irrelevant, since Microsoft has eliminated the Semi-Annual Channel (Targeted) as noted in that section:

Due to naming changes, older terms like CB and CBB might still be displayed in some of our products, such as in Group Policy. If you encounter these terms, "CB" refers to the Semi-Annual Channel (Targeted)--which is no longer used--while "CBB" refers to the Semi-Annual Channel.

@metathinker .Sir are you from Microsoft ?.

This article is one of many that is about to be either rewritten or retired as part of a major overhaul of all this content. The table of servicing channels (in the first section) should be current, despite the UI mismatch you've identified. The note about naming changes has to remain because there are still corners of the operating system where you can come across the older terminology.
@arcarley can you advise on the UI mismatch reported here?

@metathinker thank you for helping improve MS Docs. This article has recently been updated. Please let me know if you still need assistance or if anything else needs to be changed in the document.

@Reeced40 In the latest version of this page, the text I quoted above is still unchanged, and it still does not match the actual Windows UI. In fact, the difference is even greater now.
Below is how the Windows Update Advanced Options page looks in Windows v. 20H1 build 19041.508. Now, there is nothing about deferring "Feature Updates" and "Quality Updates" separately, there is just one option to defer all system software updates until a specified date.
From your colleague @jaimeo's previous comment on June 1, I was under the understanding that this page was to go away entirely or at least be totally rewritten, but it seems pretty close to what it was back then.

@metathinker I just made edits to the document that haven't been merged into master. This change removes aspects of using the Settings UX.
Best,
Aria


Cannot copy to desired directory

In Windows it seems like Super Figure copies the template to the root folder that VSCode has opened, and not the directory of the tex file being edited.  So if I am editing file vscode-folder/latex-folder/file.tex then running Super Figure inside file.tex on text fig will copy the template to vscode-folder/fig.svg instead of vscode-folder/latex-folder/fig.svg.
I'm not sure if that's the intended behaviour, but I think it would make more sense for the template to be copied to the same directory as the tex file that's being edited.  Super Figure works as intended if your tex file is in the root of the VSCode folder, but not anywhere else.
I wonder if it's in the definition of ${dir}?

That's intended behavior, i opted to use the workspace folder as the relative directory for executing commands and copying files.
If you want to create an image, say in vscode-folder/latex-dir/images/fig, then it is simple as write it down as such, but you wouldn't be able to compile latex as usual, so i prefer to just open the latex folder in itself. Maybe i should emphasize that better in the README.
Well, it was easier to code in this way and more intuitive, at least to me, sorry but this is the way i would like things to work.

That's too bad.  I wonder how hard it would be to make the adjustment to copy the files into the directory of the tex file.  Doing so wouldn't interfere with its current functionality.

What can be done is a option for a relative folder, so if edit the tex file vscode-folder/latex-folder/file.tex and i would want to save the images to the folder vscode-folder/latex-folder/images/, then

That's interesting.  I'll try that out!

Try what? that's not a option at this time. Or are you gonna make a PR?
If not i will try and make time this next week and program this option.

I misunderstood - I thought you had already implemented this.  I won't be able to make a PR at this time since I am still grappling with how vscode extensions are built.


Significant performance boost by using compiled queries

fixes #45

Thanks, nice catch, without the fix the performance test would fail, and with the fix it passes. I won't release it just yet, there seems to be a problem with the query API that I want to fix first.

Thanks! I have created a v2.2.19 release with the fixes!


Icons are broken for me since latest update

The icons seems broken since the last update

Some are too small, some have a prepended letter and some have double icons
Seems like this commit has broken it
https://github.com/lambdalisue/fern-renderer-nerdfont.vim/commit/e472ea1b57c39a651fe0fee3907fbfc5ad296446

All plugins got update together. Will send more information when I find the time

@jclsn
It seems that this issue is environment-dependent, making reproduction very challenging. However, since the behavior of something that was previously working is now disrupted, we have changed the approach of the relevant feature of the nerdfont from opt-out to opt-in, as it goes against the plugin-providing policy. The fern-renderer-nerdfont.vim has been reverted to its original state.
Thank you for providing detailed feedback.

I can confirm that this fixes the issue. Seems like it really was just this one commit. Weird that I had to also reset nerdfont.vim before. Seems to work now though.
If there is anything I can test in the future, don't hesitate to ask!

I experienced the same padding issue as OP (and am also a powershell 10k user). Just wanted to add that the revert to fern renderer NF also fixed the issue in my case.


Google Spreadsheets API integration

Added an encrypted access token file for the Google Spreadsheets API access.
Added a bash script to decrypt the access file. This is a separate file from just adding to the GitHub Actions workflows so that there is less copy/pasted code.
Added jobs within GitHub Workflows to decrypt the access file using a GitHub secret.
Tests:
Bash script has been tested for functionality. It performs exactly as desired, providing an unencrypted version of the superuser_secret.

Codecov Report

Merging #42 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master       #42   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           23        23
  Lines          479       479
=========================================
  Hits           479       479

Flag
Coverage Δ

#unittests
100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 85d8cb7...f1f8903. Read the comment docs.

github's version of gpg is 2.2.4, which is not compatible with a commercial install of gpg, which is only 2.2.2.


AssetBundle?

I want to compile this and try it for myself but it seems I need a AssetBundle, it doesn't work properly.

The asset bundles for the master branch can be found in the download on Bonetome: https://bonetome.com/boneworks/code/168/
They are the files ford.ford and canvasbundle.canvas.
For the zombie-warehouse-stuff branch, an additional bundle is needed which was created by @maranarasauce .

Anyway to get that additional bundle?

gun.zip

Thanks!


running AppImage files isn't working

Issue description
I tried running an AppImage file using appimage-run, but was met with an error. After posting this at my config repo at https://github.com/tycho01/nix-config/issues/35#issuecomment-422048579, @BenBals reported running into an identical error using a different AppImage.
Steps to reproduce
$ appimage-run /drogon/dl/etcher-electron-1.4.4-x86_64.AppImage
/nix/store/01l9kmlwylfachsqavwln9wpzczx9pq5-appimage-exec: line 19: cd: /home/tycho/.cache/appimage-run/8ff36aec4053bad0c80186d87571dc6eac8ad0263d54befb3a5d5c0fa71297c3//squashfs-root: No such file or directory
/nix/store/01l9kmlwylfachsqavwln9wpzczx9pq5-appimage-exec: line 27: /home/tycho/.cache/appimage-run/8ff36aec4053bad0c80186d87571dc6eac8ad0263d54befb3a5d5c0fa71297c3/AppRun: No such file or directory

Technical details

[ ] Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

cc @tilpner who added appimage-run to nixpkgs (there's no listed maintainer).

I suspect this is the same issue as #45973 is attempting to fix.
If you tested it on your appimage and reported back in that PR, maybe someone will feel like merging it.

I just merged #45973. @tycho01 please check if that solves your issue.

Thanks!


How does php  file work like a website

Dear sir,
I want to create a project on search IFSC code on PHP, I have downloaded your file but I can't understand how to use php folder, please help me to create a project IFSC code finder with PHP.
Thanks
Amit

Hello Amit,
You can try with curl / guzzlehttp for making API requests In PHP.
Use the API endpoint https://ifsc.razorpay.com/ for fetch bank details.
Or use the official package composer require php-http/curl-client razorpay/ifsc
https://packagist.org/packages/razorpay/ifsc

Thanks for reply.
I not understood yet, i want to like this process on PHP
Add support for searching IFSC #41

First I have list of bank which I select
On selecting list I get states of bank
On Selecting State I get City of bank
On Selecting City I get branches of bank
On Selecting Branch I get details of branch

here are some examples of website

https://www.bankbazaar.com/ifsc-code.html
2.https://www.paisabazaar.com/ifsc-code/
https://bankifsccode.com/

Thanks
Amit

Search is currently not support on the API, but may happen in the future. Closing this for now.

There are collection of data where php script is just doing sorting function like this this ifsc code finder tool website.


Improve hyperlink formatting.

Use Markdown hyperlink syntax and remove extraneous square brackets.

@bgrainger : Thanks for your contribution to the Azure documentation! The author, @seanli1988, has been notified to review your proposed change.


Asset Crashing when decompressing.

UnityStudio stops responding with similar assets to this one. https://mega.nz/#!M8IQyZoJ!mWJjdWPJazN22QpLy2Ok2Tnb30SwI5D7djKhPuY8HGs

I tested it and couldn't find any issues.

Are you using Perfare’s build of Unity Studio?

I am using the build from commit cc74130ad450b742e33405d31f73d03e3a192e95

You can use debug mode to check for errors.
Besides, I tested the latest build version https://ci.appveyor.com/project/Perfare/unitystudio/branch/master/artifacts
also couldn't find any issues.


Easier (elegant) way to set chalk.styles in 2.0.0?

It's harder to get and set color styles in 2.0.0
In 1.x.x:
require('chalk').styles.blue.open = '\u001b[34m';
In 2.0.0: Pushed options into an ARRAY
require('chalk').blue._styles[0].open = '\u001b[34m';
Is it an expected change between v1 and v2?  The extra ARRAY seems unnecessary.
Thanks!

That's just an implementation detail. You shouldn't modify the internals.

If https://github.com/yarnpkg/yarn/pull/4482/files#diff-2e782def01f9e8121ea62a611401b8b9R31 is still an issue in Chalk, it should be fixed here, but you should first check if it hasn't already been fixed in v2.

Do you mean v2 implementation expected we could access  chalk.bold.close directly?

This was an issue in Windows that I submitted an issue for a while back and it has since been fixed - see Microsoft/WSL#2174.
Closing as this is no longer an issue (last message here occurred before the fix was pushed out).


In this picture the scope of classic administrators is not correct.

[Enter feedback here]
The scope of classic administrators is management group level, not subscription level as described in this picture.

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

ID: 11cda2e8-81c4-ab6a-371e-73506948488f
Version Independent ID: f18c9bf9-a0e7-ea07-144b-c2c7cedc8b6b
Content: Classic subscription administrator roles, Azure roles, and Azure AD roles
Content Source: articles/role-based-access-control/rbac-and-directory-admin-roles.md
Service: role-based-access-control
GitHub Login: @rolyon
Microsoft Alias: rolyon

@BraydonZhao Thanks for your feedback.
Assigning to content author @rolyon for  review.

Hi @BraydonZhao
Thanks for your feedback. Classic administrators apply only to subscriptions. For example, if you try to assign a Co-administrator at a management group scope, you see the following message:
"Co-administrators can only be added at the subscription level. Open Access control (IAM) for the subscription to add co-administrators"
Let us know if you have any additional feedback.
thanks

#please-close


MAPL won't build as static libraries if shared NetCDF libraries are unavailable

When building MAPL v2.7.1 as static libraries, shared NetCDF libraries are still required to prevent the build process to fail with the following messages:
[ 95%] Linking Fortran executable ../bin/pfio_server_demo.x
[...]/netcdf/4.7.4/lib/libnetcdff.a(nf_attio.o): In function `nf_put_att_text_':
nf_attio.F90:(.text+0xae): undefined reference to `nc_put_att_text'
[...]/netcdf/4.7.4/lib/libnetcdff.a(nf_attio.o): In function `nf_put_att_text_a_':
nf_attio.F90:(.text+0x17e): undefined reference to `nc_put_att_text'
[...]/netcdf/4.7.4/lib/libnetcdff.a(nf_attio.o): In function `nf_put_att_int1_':
nf_attio.F90:(.text+0x254): undefined reference to `nc_put_att_schar'
[...]/netcdf/4.7.4/lib/libnetcdff.a(nf_attio.o): In function `nf_put_att_int2_':
nf_attio.F90:(.text+0x324): undefined reference to `nc_put_att_short'
...

These errors are generated when building pfio/ executables, as the NetCDF::NetCDF_Fortran target created by FindNetCDF.cmake (https://github.com/NOAA-EMC/CMakeModules) only provides libnetcdff.a and does not include the remaining dependencies (netcdf.a and HDF5). This creates an issue when building with the UFS since shared libraries are not allowed.
While this problem should be addressed by making sure the NetCDF::NetCDF_Fortran target is created correctly, an alternative fix could be implementing an option to build all executable targets in pfio/ only if required (UFS does not require them). For example:
if (BUILD_WITH_PFIO_TOOLS)
  ecbuild_add_executable(
     TARGET pfio_server_demo.x
     ...)
  ...
endif()

Further investigation revealed that the ecBuild version of FindNetCDF.cmake was being used by find_package(NetCDF) instead of that from CMakeModules. This happened because CMAKE_MODULE_PATH is modified by the included esma.cmake script, and find_package(NetCDF) is called after include(esma).
This can be solved using the following CMake settings:
-DNetCDF_Fortran_EXTRA_LIBRARIES="`nc-config --libs`"

It might still be helpful to add a switch to prevent building unnecessary executables. However, this issue can be closed at this time.


3D Touch shortcuts

Added shortcuts for:

Search
Switch accounts

Note:
I haven't tried out the switch account item since i only have one account so @rnystrom please try that first.
#342

Want to look into #418 before merging this, @Sherlouk?

@BasThomas Honestly forgot I assigned that to myself, anyone is welcome to go for that one!
It would be nice to merge the two though!

This is really well done 😊


loss explosion

❓ Questions & Help

I am using Bert-CRF model to do Named Entity Recognition task. I am using the average of the last four layers as the input of CRF model.  But the loss will increase and become Nan in a few batches. Anyone meet that problem before? Any suggestions will be appreciated!

just because of a large learning rate


why there is no ext.js

Ext.js a also a famous front-end framework. I think the content in the front-end is not enough.

Create one then. Lists are created by the community.


feat: setup next-themes with theme-provider

TL;DR
Implemented dark mode and theme switching functionality, updated UI components, and improved layout structure.
What changed?

Added a ThemeProvider component for managing light/dark themes
Created a new Header component with navigation and theme toggle
Implemented a ModeToggle component for switching between light, dark, and system themes
Updated the RootLayout to include ThemeProvider and support dark mode
Replaced custom Button and Tooltip components with new UI components
Updated the main page layout and styling to support dark mode
Added new UI components like DropdownMenu

How to test?

Run the application and navigate to the main page
Verify that the new header is visible with navigation links and a theme toggle
Test the theme toggle functionality by switching between light, dark, and system themes
Ensure that the UI components and layout respond correctly to theme changes
Check that the main page content is properly styled in both light and dark modes

Why make this change?
This change enhances the user experience by providing a dark mode option and improving overall UI consistency. It also modernizes the codebase by utilizing more standardized UI components and implementing a flexible theming system. These updates make the application more accessible and visually appealing to a wider range of users, while also improving maintainability and scalability of the codebase.

#4  👈
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @kleva-j and the rest of your teammates on  Graphite


cloud resource with GPU

How does one use GPU resources in the cloud with this extension?

To run the model fine-tuning and inference in your remote Azure Container Apps Environment, make sure your subscription has enough GPU capacity. Submit a support ticket to request the required capacity for your application. Get More Info about GPU capacity
You can learn more from here

No activity for 2 weeks, closing this issue.
Feel free to comment or reopen, and we will re-investigate.