Some way to express a non-null / non-undefined any would be nice

While updating the various .d.ts to have | null and | undefined, I came across some typings that use any but don't allow null or undefined.

Object.defineProperty:
/**
  * Adds a property to an object, or modifies attributes of an existing property.
  * @param o Object on which to add or modify the property. This can be a native JavaScript
  * object (that is, a user-defined object or a built in object) or a DOM object.
  * @param p The property name.
  * @param attributes Descriptor for the property. It can be for a data property or an accessor
  *  property.
  */
defineProperty(o: any, propertyKey: PropertyKey, attributes: PropertyDescriptor): any;

o and the returned value cannot be null or undefined.

Object.setPrototypeOf:
/**
  * Sets the prototype of a specified object o to  object proto or null. Returns the object o.
  * @param o The object to change its prototype.
  * @param proto The value of the new prototype or null.
  */
setPrototypeOf(o: any, proto: any): any;

o and the returned value cannot be null or undefined. proto can be null but not undefined.

etc.

I think there is value in being able to express both "This can be any type including null and undefined" and "This can be any type excluding null / undefined", but there is no way to express the latter.

Seems conceptually similar to 'outersection' types, where you'd express it something like any - null - undefined, where you start with a type and 'subtract' other types from it.
That issue is closed as too complex but there's a comment about it from a recent backlog slog that says: "Revisit in context of type operators"

Yes, I remember, which is why I'm asking for a much easier form.

This issue is probably going to come up more often when code starts using --strictNullChecks. In that mode types like string and number will exclude null and undefined, but what about any? Does that still include null and undefined under strict null checks?
In a way, it would seem consistent under --strictNullChecks that any excludes null and undefined, and you would have to be explicit to include them, i.e. any | null | undefined. OTOH that seems like a logical contradiction of the special semantics of any.

Yes, --strictNullChecks is the context of this PR, and yes since nullability is via union types, any is allowed to be null and undefined.

Maybe a new builtin type name like some or something, where some | null | undefined  ≡  any

This type already exists. It's {}
declare function f(x: {}): void;

f(0);			// ok
f("");			// ok
f(true);		// ok
f({});			// ok
f(null);		// error
f(undefined);	// error

I don't think {} is the same thing at all. Using {} as the return type in the OP's examples have a very different meaning than any - null - undefined or however it could be expressed.

Beat me to it :) For reference, see https://github.com/Microsoft/TypeScript/issues/5451#issuecomment-152257673

{} would be the equivalent type from the input side.
On the output side, it would be string | number | boolean | object (note that object is unimplemented, see #1809)

Thanks. It's a bit wordy, but I suppose the set of primitive types is well-known.
Is there any reason to use {} over that for the input side?

For callback parameter type annotations, one may be preferable over the other depending on the scenario.

If function return types in .d.ts files are changed from any to string | number | boolean | object (for the purposes of excluding null or undefined as in the OP's examples), wouldn't that break a lot of user code? Type assertions would have to be added where they were previously unnecessary on any types. Not saying that's good or bad, just a big breaking change.

For return types, it's probably best to leave it as any. I'm not sure what use there is in saying "any but not null or undefined" since you're able to assign it to a non-null type anyway.

It would be self-documenting that it won't return a null. It may be useful for user functions as well that can return any object but never null, like a parse(input, rule): output function.

This would be only for documentation purposes as TS allows dereferencing any or assigning to non-null variables.
Ideas:

Should we rather annotate methods that may return null as any | null? This would be consistent with other types and OK for doc.
Is ! going to fly for types as well? It could be useful with generics like: function nonNulls<T>(array: T[]): T![]. If it does then maybe we should simply accept any!.

@Arnavion assuming #1809 is in, this request would be just a shorter name for string | number | boolean | object?

Yeah, I'll close this.

Although I don't think that having any! has a lot of value, I would point out that replacing any with string | number | boolean | symbol | object is not exactly the same.
It would be more correct to say setPrototypeOf(..): object (given #1809).
But doing so is a breaking change:
let x = Object.setPrototypeOf(a, Whatever); // : object
x.doSomething(); // Error: no .doSomething() on object. Ok with any.

let y : Sometype = Object.setPrototypeOf(a, Whatever);  // Error: Missing cast. Ok with any.

let z = <Sometype>Object.setPrototypeOf(a, Whatever);  // ok with both.

given that the current way to specify nullable types is T | null, T | undefined or T | null | undefined; the system is already verbose. so type Concrete = string | number | boolean | symbol | object does not seem too bad.
We have talked about a `!

@mhegazy I have no problem with verbosity, especially since (a) you can define aliases and (b) few APIs actually returns all kind of types. Quite often any are just unknown object shapes.
I was pointing out that any has one big difference to the union of all types: it is a special type that bypasses all compiler checks! This is why changing a return type from any to object is a breaking change, see the examples in my previous comment.
Personally I can live with any being unclear about nulls (it's not checked anyway) but if we want to support better documentation without introducing new type operators, I suggested previously that we start the habit of using any | null for nullables any and just any for the non-nullable ones.
Again, it won't change compilation but it can be seen as helpful from a documentation perspective.

I'm sorry if I'm not involved in the project enough to know whether this conversation is finished, but here's my take:
How about a new global that is an alias to string | number | boolean | symbol | object.
It will be updated to include new primitives, if/when any are added to the language (see recent addition of symbols).

I am using T | null | undefined and it seems to be working well :)

The following example, shows that string | number | boolean | symbol | object is not the same as any - null - undefined.
function f(p: string | number | boolean | symbol | object) {
    p.something // error
}

function f(p: any - null - undefined) {
    p.something // no error
}

If anybody wants to ingrain this pattern in to their development environment and company culture... here's how to do it. Use at your own risk. Also, maaaaaybe don't do this.
tsconfig.json
{
    "compilerOptions": {
        "typeRoots": [
            "global.d.ts"
        ]
    }
}

global.d.ts
declare type actual = string | number | boolean | symbol | object;

😄 Function Overloads and Type Guards
This is in all likelihood what should used in the case that you want to have a non-null value. It gives you the appropriate intellsense listings, automatically casts values to the correct types within the guarded statements, and returns specific types instead of a "yeah I meant it could be a string, but it's usually a number" type. TypeScript will also prevent you from invoking the method with a: number and b: string, and vice-versa. Importing a specially declared type will solve the "but it really is a number | string," issue in a non-assuming manner.
import { numberOrBoolean } from "my-types";

function isNumber(x: any): x is number {
    return typeof x === "number";
}

function isBoolean(x: any): x is boolean {
    return typeof x === "string";
}

function combine(a: number, b: number): number
function combine(a: boolean, b: boolean): boolean
function combine(
    a: numberOrBoolean,
    b: numberOrBoolean
)
: numberOrBoolean
{
    if (isNumber(a) && isNumber(b)) {
        return a + b;
    }

    if (isString(a) && isString(b)) {
        return a && b;
    }

    throw new Error("overload declarations prevent this.");
}

😢 Global Type Declarations
If anybody wants to ingrain this pattern in to their development environment and company culture... here's how to do it. Also, don't do it. The only valid use case is better solved with function overloads.
app.ts
/// <reference path="<types>/global.d.ts"/>

<types>/global.d.ts
declare type actual = string | number | boolean | symbol | object;

For me, the use-case for any! is for type-documenting existing JS libraries.  If I'm documenting a library where there's a method that tries to deal with the input depending on its type, but assumes it will not be undefined/null, it really is begging for a concise way of saying "not undefined or null".

@Arnavion @RyanCavanaugh I think this should be reopened - there's another simple use case for the some idea, which isn't covered by object or {}: forcing consumers of a type or interface to handle a falsy value explicitly.
What we have to do currently:
interface State {
    message: any;
}

const thingThatUsesState = (state: State) => {
    if (state.message.text === "foo") {
         console.log("message text is foo");
    } else {
         console.log(JSON.stringify(state.message));
    }
};

in the above, state.message could be null or undefined, and TypeScript doesn't protect me against that by giving an error if I assume it's there. If we could do:
interface State {
    message?: some;
}

The compiler would highlight the bug in the code above and correctly force me to fix it like this:
const thingThatUsesState = (state: State) => {
    if (!state.message) {
        console.log("message is missing");
    } else if (state.error.message === "foo") {
         console.log("message text is foo");
    } else {
         console.log(JSON.stringify(state.message));
    }
};

Trying to attach a non-null assertion using the concrete union suggested above does not seem to be working. I'm trying to write a generic "normalize" function that will be executed on user input only if that input is defined:
type Defined = string|number|boolean|symbol|object;

interface ConfigurationPropertyDefinition<
    InputType,
    ResolvedType extends InputType
> {
    normalize?: {
        (value: InputType & Defined): ResolvedType;
    }
}

In a case where a property can be a string or a function that returns a string and is not required, the compiler emits a warning with a less than helpful message. InputType is string|() => string|undefined, so I would expect the intersection of InputType & Defined to be narrowed to string|() => string. However, the compiler emits an error with the following message:
Type 'undefined & Number' provides no match for the signature '(): string'.

@RyanCavanaugh

For return types, it's probably best to leave it as any. I'm not sure what use there is in saying "any but not null or undefined" since you're able to assign it to a non-null type anyway.

null-checks and undefined-checks!
That's one of the really really big points to using static analysis to begin with. any is flawed in that it's meaning is "do whatever" but in many contexts what we really want to say is "it's whatever [that's not null/undefined]" and it's really easy to use it like that.
I'd say this is a failure of english if nothing else. Same words but totally different meanings "it's a thing that exists" vs "this is not checked." This is terrible for code readability too.
This is the problem: "any = can be anything including null or undefined but will NEVER checks for it"
Consider this code:
get_db_entry(query, parseEntry);
function processEntry(err: any, entry: any) {
   entry['someKey'] = [];
   // ^ entry could very well be undefined here, typescript don't care
}

This is how we would like it to look:
get_db_entry(query, parseEntry);
function processEntry(err: any, entry: thing|undefined) {
   entry['someKey'] = [];
   // ^ Error: entry could be undefined
}

// or if we omit use just "thing" there then the error would be on get_db_entry
// because it's getting passed an incompatible function

There's no way to declare a "thing" type either, since you can't do recursive types. Note the [] there, that actually would result in some sort of never[] assignment error one way or another. It's nearly impossible to declare it with out treating it as a special case each time (which is at odds to you wanting to use any there to begin with).
Just want to also echo what was said earlier. We don't need over-engineered sophistication such as any - null - undefined. We just want a built-in thing type that's exactly like any except it doesn't allow null / undefined.

Since this thread comes up in google searches.
This is the best you can do to get at least some errors caught:
export type thing = { [key: string]: any };
export type anything = thing | undefined | null;

We just want a built-in thing type that's exactly like any except it doesn't allow null / undefined.

object | string | boolean | symbol | number ?

@RyanCavanaugh I can't see why object | string | boolean | symbol | number isn't a valid solution, or why defining that combination globally in a project is sub-par for those who want it.

@RyanCavanaugh @cwharris
Of course they're not the same thing.
export type thing = object | string | boolean | symbol | number;

function example1(d: thing) {
    d.someProp = 5;
// runtime/test.ts(4,7): error TS2339: Property 'someProp' does not exist on type 'thing'.
//  Property 'someProp' does not exist on type 'string'.
}

If you want to do janky stuff in the function body, just use a hidden implementation signature:
function example1(d: thing): void;
function example1(d: any) {
}

@srcspider "overloads" are a better solution to the case you presented, as @RyanCavanaugh shows. His example accepts an any, which sort of negates the benefits, but in general they communicates far more information to the compiler.
For the return type scenario, is { [key:string]: any } presenting you with an issue?

Wait, now I'm confused. Why does the following not present an error?
type thing = { [key:string]: number };

var foo: thing = {
    bar: null
};

I'm realizing now that a return type of { [key: string]: any } wont provide enough information to prevent indexing an undefined property - which makes sense, because the consumer doesn't have a contract for what properties will be provided on the return value, even though it will be guaranteed that none of those returned properties will have a value of null or undefined.
A better solution for this case is overloads / multiple signatures:
function operate(a: string, b: string): string;
function operate(a: number, b: number): number;
function operate(a: any, b: any): any
{
    if (typeof a == "string" && typeof b == "string")
    {
        return `${a} ${b}`;
    }

    if (typeof a == "number" && typeof b == "number")
    {
        return a * b;
    }

    throw new Error("invalid arguments");
}

var foo = operate(5, 6);
var bar = operate("5", "6");
var baz = operator(5, "x"); // error

@RyanCavanaugh again your solution is not solving the problem at all.
It's not a case of just the return type, or just the parameter, or just the call site, but rather a case of all of them put together. With a non-null/non-undefined any you can say "this parameter cant be empty", "this function never returns empty" and "inside this function this value is never empty" (and it's important for those to happen at the same time, not just be a "you can only opt-in to one of them" as with current solutions)
In any case, your example is no different then just having the any signature, isn't it? Since that will accept anything whatsoever, so why would the other signature affect it? I don't see the case where that example forces an error check.
Case
export type thing = object | string | boolean | symbol | number;

export function example(d: thing|undefined);
export function example(d: any) {
    d.someProp = 5;
}

Compiles To
"use strict";
exports.__esModule = true;
function example(d) {
    d.someProp = 5;
}
exports.example = example;

Expected
Error: d may be undefined
Actual
No error.
@cwharris see above example. I can understand where you're coming from but I care for catching null/undefined over other type related errors because the other type related errors can be seen though a lot easier then null/undefined.
For example, if I add example(undefined) at the end of the example above, then that still will not generate any errors. But it's very clear that it's not something the example function is suppose to handle.
Both you and @RyanCavanaugh have given examples that ignore that the implementation inside the function is free to ignore the constraint given the definition.
With regard to "jankiness", if possible I'll use generics to dynamically enforce, or whenever possible write the type (so long as the type information is actually not redundant to the process).
However there are plenty of cases where its very useful (and very practical) to have a not-nothing type. For example function doThing<T = NonNothing>(thing: T);. Or let value = 3rdPartyProvider(); firstPartyStuff(value); /* ...somewhere deep in firstPartyStuff... */ 3rdPartyConsumer(value) (ie. don't care what it is so long as it's not nothing). Or parseThing(userinput: NotNothing): InputErrors (ie. all checks for nothingness have to happen outside of the parseThing function). etc etc

In any case, your example is no different then just having the any signature, isn't it? Since that will accept anything whatsoever, so why would the other signature affect it? I don't see the case where that example forces an error check.

I made an error in judgement when using any as the type for the d parameter in the implementation of the operate function as it does not accurately portray the level of type checking available within the implementation's body. The implementation could just as easily be defined as...
function operate(a: string, b: string): string;
function operate(a: number, b: number): number;
function operate(a: number | string, b: number | string): any { ... }

This syntax effectively hides the implementation and type-checks only against the first two declarations - the compiler will present an error if you provide any argument combination other than two strings or two numbers. The type system is obligated to inform the consumer that the return value is strictly a string in the first case, and a number in the second case. It does not allow the consumer to believe the result is any or even string | number.
I believe that using this type of approach in conjunction with the strict compilation setting will give you two-thirds of what you are asking for - type checking of arguments as well as a specific return type (for both of which you are able to provide your own non-null non-undefined types).
I find this syntax to be cumbersome and unintuitive - genuine overloads are simply easier to read and understand, in my opinion, and they enforce type restraints on the provided arguments, return value, and within the implementation of each overload - a feature I believe is at the root of your interest/concern, if I understand you correctly.
Which brings me to...

... "inside this function this value is never empty"

I believe I understand what you are saying here. In other languages, such as C# for example, you can do the following:
public int Add(int a, int b) => a + b;
public string Add(string a, string b) => $"{a} {b}";

This in-so-much-as-it-matters (outside of assembly mismatch and reflection) forces the compiler to operate exactly as you'd expect. a and b are of either int or string within the two methods, respectively, and the body of those methods are required to respect that or suffer compile-time errors. This is the feature that is not currently available within TypeScript in any form whatsoever, aside from implementing multiple methods with different names - which is an API nightmare.
If I am wrong in thinking that this is the third (and potentially most important) feature you are describing, please correct me and ignore the rest of this comment.
Assuming the previous thinking to be accurate, I would like to provide a reason for why this feature does not currently exist in TypeScript and why it may not be a good idea to add that feature to this language specifically...
With the design principal that TypeScript is a super-set of JavaScript and transpiles directly to a given JavaScript version to be consumed be engines which support said version, let's go back to the operate example I provided and instead implement it using a hypothetical overload feature to how the resulting JavaScript might look.
// using hypothetical overload feature
function operate(a: string, b: string): string
{
    return `${a} ${b}`; // always checked to be strings
}

function operate(a: number, b: number): number
{
    return a + b; // always checked to be numbers
}

var x = operate("foo", "bar");
var y = operate(1, 2);

This guarantees:

The arguments are either string, string or number, number, respectively.
The return type is either string or number, respectively.
The parameters used within the methods are of the types declared in the method signature).

The resulting JavaScript could look a number of ways. Let's start by operating under the super-set design principal employed by Typescript, as defined by the Typescript design goals, specifically with regards to goals 7 and 8 - Preserve runtime behavior of all JavaScript code. and Avoid adding expression-level syntax..
function operate_string_string(a, b)
{
    return `${a} ${b}`;
}

function operate_number_number(a, b)
{
    return a + b;
}

var x = operate_string_string("foo", "bar");
var y = operate_number_number(1, 2);

This meets the requirement for both goals 7 and 8, but looks absolutely horrendous and arguably (if not explicitly) violates goals 4, 5, 7, and 11. So lets take a different approach...
function operate(a, b)
{
    if (typeof(a) == "string")
    {
        return `${a} ${b}`;
    }

    if (typeof(b) == "string")
    {
        return a + b;
    }

    throw new Error(...);
}

var x = operate("foo", "bar");
var y = operate(1, 2);

This arguably conforms to some of the goals, but presents serious, and perhaps unresolvable, problems for any types where typeof(obj) == "object". Additionally, it violates goals 3, 5, 7, 8. and, in a way, 9.
This is at least one reason why overloads don't exist in TypeScript - there is not a clearly defined way to implement overloads and remain a super-set of JavaScript. And for that reason, it may not be a good idea to implement overloads, which is presumably the only way we could enforce parameter types within the body of a function.

I can't figure out why { [key: string]: any }  isn't the right answer to @srcspider 's constraints. The function body says d.someProp = 5 in its body, which is manifest nonsense for the primitive types. TypeScript isn't obliged to provide built-in types which allow useless behavior.

I think the core of the issue is that people assume any == { [key: string]: any } | object | string | boolean | symbol | number | null | undefined, and that is not the case. any is given carte blanche - ignored by type checking altogether. It's a way to enforce explicitly declaring the type of all variables (a la noExplicitAny) even if it does not have a type.
TypeScript only works with types. It ignores anything which does not have a type. This includes any. any is a very good solution to a very hard problem, even if the naming is a bit weird (it implies that it is any of the built in types). any is a feature which could only be implemented as part of the TypeScript language.
What some people want is for the TypeScript team to spend time making a some type which is an actual type defined as any (see how this is confusing?) built-in type except any (which is not a type).
But instead of spending time compounding the any confusion by adding a some type, it looks like the TypeScript teams has decided to focus on features that can't be easy added without modifying the compiler.
Personally, I think some is a bad use of TypeScript's development resources. You can write your own some in 10 seconds, and things will just work out how you want them to. Plus you get to tell all your friends how annoying any is, and how it's the only type in TypeScript that isn't a type.
type isnt = any;
type some = `{ [key: string]: some } | object | string | boolean | symbol | number | null | undefined';
type kinda = some | { [key: string]: any };

Having a similar use case, I believe.
/** Traps if the specified value is not true-ish, otherwise returns the value. */
declare function assert<T>(isTrueish: T, message?: string): T & object; // any better way to model `: T != null`?

Essentially: A function that takes a value of type T, ensures that it is not false-ish (by throwing) and returning the value if it is true-ish. While the above solution with & object kinda works, it somewhat feels wrong and leads to warnings with other tools that don't like intersections that much, for example tsickle.

@dcodeIO
declare function assert<T>(isTrueish: T | null | undefined | 0 | "", message?: string): T;

declare const p: null | string;
const p2 = assert(p); // p2: string

Oh, thanks. Well, I guess I don't have a use case then and can just go with T | null on the parameter, yey :)

Here's a case where what I feel like I want is a "subtract undefined" operator, but maybe someone can enlighten me as to how else to do this properly:
interface IDataModel {
    sandwichType?: string;
    sandwich?: {
        name: string;
        type: IDataModel['sandwichType'] - undefined;
    };
}

Basically trying to acomplish:

sandwichType is an optional variable
sandwich is an optional variable
If sandwich DOES exist, its type property should be the type of sandwichType, but it's NOT optional

@rdhelms Conditional types (2.8) can help:
type RemoveUndefined<T> = T extends undefined | infer R ? R : T;
interface IDataModel<T extends string> {
  sandwichType?: string;
  sandwich?: {
      name: string;
      type: RemoveUndefined<IDataModel<T>['sandwichType']>;
  };
}

function takeModel<T extends string>(model: IDataModel<T>) {

}

// Errors
takeModel({
  sandwichType: "rye",
  sandwich: {
    name: "bob"
  }
});

@RyanCavanaugh
Ah whoops I didn't even process that you were talking about the future release of TypeScript. Any suggestions for how to workaround prior to 2.8 being released?

Nice - it actually looks like the new Exclude Predefined Conditional Type is exactly what I would want:
https://github.com/Microsoft/TypeScript/pull/21847
Will just have to wait for 2.8!

I have this related question - https://stackoverflow.com/questions/51236491/typescript-type-representing-everything-but-undefined
if someone wants SO points please take a look thx

We just want a built-in thing type that's exactly like any except it doesn't allow null / undefined.

object | string | boolean | symbol | number ?

type yourType = object | string | boolean | symbol | number;

function f():()=>yourType{
    return (window as any).returnAnyObj();
}
var res=f()
res.xxx=1 // error!

we just need  any object,  when use MemberExpression won't  throw error

maybe you can try use T extends null ? never : T, as follows:

Algebraic data type operators exist in TS. Exclude<T>, NonNullable<T> seemed nice, until I tried them with any, and they do work with any.
declare function f(x : NonNullable<any>)
declare const a : string | null

f(a) //works```

And by the way, object | string | boolean | number is bad form. Not to mention it's object | string | boolean | number | symbol | bigint as of comment. Each time a new primitive is added you need to update it.

I'm not sure if this would help, but at least this is a possible application:
type NotNil<T> = null extends T ? never : undefined extends T ? never : T;

export type HasValue<T> = { value: NotNil<T> };

const v: HasValue<number> = {
  value: 10
};

If you pass undefined or null to NotNil<T> it will resolve to never, but you cannot use any because undefined and null extend any, so NotNil<any> will resolve to never

interface State {
    message?: some;
}

@mmkal Seems to be related to #13195

type Nil = null | undefined;
type NotNil = Nil extends T ? never : T extends Nil ? never : T;

Try it out, it does not work. You'll find the appalling fact that NotNil<any> is now an alias of never. This is because any extends anything.

I know it's not the same thing, you won't be able to use any but you're guaranteed you need to specify a type which could not be null

I know it's not the same thing, you won't be able to use any but you're guaranteed you need to specify a type which could not be null
I appreciate that, however the title of this issue is explicitly non-nullable any.

any doesn't mean that the value can be of any type. It means "please disable all type checking thanks". It doesn't make a whole lot of sense to "disable type checking except for null checks".
To declare a variable that can be of any type you can use unknown. Sadly, you can't do NonNullable<unknown> because it's not a union type, so string | number | boolean | symbol | bigint | object seems to be the only way to do this right now.

I'm ok with doing string | number | boolean | ... as a workaround but is there some way to display a custom alias like Defined or Some in error messages instead of the full definition?
I'm working with generated code which contains lots of statements about things that are defined and the error messagages are extremely hard to read because such long definition. See https://github.com/maasglobal/maas-schemas-ts/blob/master/src/core/booking.ts for example.

I know this thread is for a non-null any specifically, but it would be really nice to have some sort of operator that prevents assignment of null/undefined to a variable without turning on strictNullChecks. I can't enable that in this codebase I inherited without rewriting everything. NonNullable<T> apparently doesn't do that.

With optional chaining, I think there is another use case?
const a: any = null;
const chained: string|null = a?.foo; // This should error
const nullable: Exclude<any, undefined> = a?.foo; // This should error
const neverNull: Exclude<any, null> = a?.foo;

Because an optional chained any is still any, a subsequent check on the assigned nullable parameter can make incorrect assumptions:
if (chained !== null || nullable !== null) {
  console.log(chained.length); // throws because chained is undefined
  console.log(nullable.length); // throws because nullable is undefined
}

Where if there was a non-null any, comparing the optional chained result to null can be caught at compile time:
if (neverNull !== null) {
  // always true
}


denim075.png and the icon used for 'Humanoid' error with a routePrefix

Steps to reproduce: set a route prefix in options.json such as
  "routePrefix": "test",

then connect to a dnd5e foundry world and open a character sheet, preferably a humanoid actor like Morthos (Tiefling Sorcerer). The denim background texture and that icon (at least) fail to load. The fix would seem to be using relative filepaths for those images, and any others that may have this issue.

Results obtained on foundry version 11.315, dnd5e 3.1.2 and a (slightly old) 3.2, no modules enabled

Duplicate of #3441


WIP Error subtypes for friendlier debugging

[DOCPLAT-3092] WIP Error subtypes for friendlier debugging - Workiva JIRA
Some helpful tips for a successful Apache Thrift PR:

Did you test your changes locally or using CI in your fork?
Is the Apache Jira THRIFT ticket identifier in the PR title?
Is the Apache Jira THRIFT ticket identifier in the commit message?
Did you squash your changes to a single commit?
Are these changes backwards compatible? (please say so in PR description)
Do you need to update the language-specific README?

Example ideal pull request title:
    THRIFT-9999: an example pull request title

Example ideal commit message:
    THRIFT-9999: [summary of fix, one line if possible]
    Client: [language(s) affected, comma separated, use lib/ directory names please]

For more information about committing, see CONTRIBUTING.md

I probably won't get around to doing this unless folks ask for it.


Large Transfer time in k-means with big number of clusters

Hi,
I run benchmark from https://github.com/h2oai/h2o4gpu/blob/master/presentations/benchmarks.pdf
I use 100 iterations, and different number of clusters. I see following picture
Timetransfer | Fit on GPU time, H2O, seconds
1.38588 | 9.23817
1.50101 | 12.5744
8.79409 | 20.1906
193.576 | 10.7283
For 100 clusters, I can see even less fit time (although, all 100 iterations were done for all cases), but TimeTransfer is very significant. It wasn't so big when I ran on Tesla P100 with cuda 8.0
I used nccl version, maybe I need nonccl?
Could you provide any advice, how can I reduce data transfer time for that case?
OS: Linux
Installed from https://s3.amazonaws.com/h2o-release/h2o4gpu/releases/bleeding-edge/ai/h2o/h2o4gpu/0.2-nccl-cuda9/h2o4gpu-0.2.0-cp36-cp36m-linux_x86_64.whl
Python 3.6
CUDA 9
GPU: 1x Tesla V100

Any chance to have this fixed?

@OlegKremnyov let me double check if that is still the case with the current bleeding edge version. Can you share the setup you ran your tests on?
@trivialfis have you maybe noticed similar issues (large time transfers)?

Truly sorry, I missed this one on mail.  I don't have a theory for this yet.


feat: support parsing the RENAME TABLE statements in the parser

I hereby agree to the terms of the GreptimeDB CLA
What's changed and what's your intention?
support parsing the RENAME TABLE statements in the parser
Checklist

[ ]  I have written the necessary rustdoc comments.
[ ]  I have added the necessary unit tests and integration tests.

Refer to a related PR or issue link (optional)
#723

@evenyag PTAL


Python 3.10 - DeprecationWarning: There is no current event loop

I'm not using pyzmq directly, but it's a dependency of other imports. I notice deprecation warnings being raised
/lib64/python3.10/site-packages/zmq/_future.py:499: DeprecationWarning: There is no current event loop
  f = future or self._Future()

That's referencing this code
https://github.com/zeromq/pyzmq/blob/6064159f44df3c6722b1d1b6af0cd69de83818b3/zmq/_future.py#L496-L498
Checking the docs, it looks like the deprecation was introduced in 3.10

Deprecated since version 3.10: Deprecation warning is emitted if loop is not specified and there is no running event loop.

More information is available here.
This is with pyzmq 24.0.1.

I don't believe this is pyzmq issue. It means that an async pyzmq call is being made outside an event loop, and the warning is being shown correctly, but it is highlighting a pyzmq line as the direct caller of the asyncio API, instead of the originating call, which is whatever code invoked the async method.
What package is using pyzmq in your case? That's where the deprecation should be reported.

I would disagree. A library should never propagate a deprecation warning. This is an indicator the the way the code is being called will break in a future release.
I think the root of this is the way the future is being created. It seems the code is effectively creating a future with asyncio.Future(). The side effect is this creates an event loop if a running one isn't found.
However, according to the docs referenced above, this should be done with asyncio.get_running_loop().create_future() which would raise a RuntimeError if there is no running event loop in found.
If the current behavior of creating a new loop if one does not exist is the intended behavior, it should be done explicitly by catching the RuntimeError and calling asyncio.new_event_loop()
By treating the warning as an error, I was able to get a stacktrace
  File "/lib/python3.10/site-packages/nbconvert/preprocessors/execute.py", line 86, in preprocess
    info_msg = self.wait_for_reply(self.kc.kernel_info())
  File "/lib/python3.10/site-packages/jupyter_client/asynchronous/client.py", line 16, in _
    msg_id = meth(self, *args, **kwargs)
  File "/lib/python3.10/site-packages/jupyter_client/client.py", line 742, in kernel_info
    self.shell_channel.send(msg)
  File "/lib/python3.10/site-packages/jupyter_client/channels.py", line 263, in send
    self.session.send(self.socket, msg)
  File "/lib/python3.10/site-packages/jupyter_client/session.py", line 855, in send
    stream.send_multipart(to_send, copy=copy)
  File "/lib64/python3.10/site-packages/zmq/_future.py", line 322, in send_multipart
    return self._add_send_event('send_multipart', msg=msg_parts, kwargs=kwargs)
  File "/lib64/python3.10/site-packages/zmq/_future.py", line 498, in _add_send_event
    f = future or self._Future()
DeprecationWarning: There is no current event loop

A library should never propagate a deprecation warning.

I don't mean that we should propagate it programmatically. I just mean that the code relying on deprecated behavior is not in pyzmq, it's in jupyter-client, but the warning is misleading about which code is responsible due to an implementation detail.

This is an indicator the the way the code is being called will break in a future release.

Yes, and the code that will break is in jupyter_client, not in pyzmq. Jupyter client is currently using async methods without an event loop, and that's deprecated by asyncio. pyzmq just happens to be an intermediate layer that instantiates the Future for this async method using a not deprecated method of asyncio.
pyzmq's not using any deprecated APIs here. What's deprecated is the context in which it's called, and that's not up to pyzmq.
I think it's an accident in jupyter-client to be passing async sockets to session.send at all, and that's being cleaned up in https://github.com/jupyter/jupyter_client/pull/835.

If the current behavior of creating a new loop if one does not exist is the intended behavior, it should be done explicitly by catching the RuntimeError and calling asyncio.new_event_loop()

The intended behavior is to follow asyncio's own behavior (deprecate implicit loop creation which will eventually be a RuntimeError in a later Python version), which pyzmq follows exactly.
If there were a change to make in pyzmq, it would be to show the same deprecation warning in the same circumstances with the same behavior, so that the code actually responsible gets the warning about asyncio's deprecated behavior. Raising a RuntimeError would be introducing a breaking change that Python already decided should be brought in slowly via a deprecation. Implicitly creating the loop is also established as a problematic pattern that should be removed, but cannot be removed immediately because it is relied upon, hence the deprecation. So I'm not sure of the benefit of recreating an existing deprecation message that's already there under the right circumstances, and not a deprecation in pyzmq at all, but a deprecation in Python itself.

Thanks for the detailed response.
If it were me, I'd use asyncio.get_running_loop().create_future() (with some additional logic for Python <3.7) instead implicitly getting the event loop with Future(). Then I'd catch the runtime error, raise a deprecation warning, and fall back to new_event_loop(). Then, on the next major version, drop the fallback.
The advantage here is you can create a clear warning message specific to zmq users and target the unsupported behavior rather than wait for it to work it's way out over the years through Python upgrades. I can see the advantage of leveraging the Python deprecation too, it's just not the way I would go.
As for me, this is only used in testing and only on the latest stable version, so I'd expect, by the time it would break, jupyter_client would have made sure their code works on the latest version.

Thanks for your perspective. I think there's value in getting the same warning for all instances of the same deprecated behavior, since that improves searchability. I think there's also value in that deprecation being tied to just one version of one package (Python itself), rather than the same deprecation occurring in two different versions of two different packages. This kind of situation is not so uncommon in asyncio where it's the context not the calling code that's responsible and needs to change, so the library triggering deprecated behavior gets misplaced fingers pointed at it.


Make a new release for our official release

Tag it as v1.0.0

https://github.com/amavumkal/ubpilots/releases/tag/v1.0.0


Do not merge: Version cardano-cli-<IP_ADDRESS>

Only creating a PR to build it in CI.

This has been tagged and uploaded to CHaP.


"Delete Oracle Java extension cache for this workspace" fails with an error

Attempting to execute the command says:

which seems logical. Red Hat's extension has a similar command and restarts VS Code, most likely to avoid issues like this.

Resolved in #245


Set up a GCP project for test purposes

This is to give non-Googler contributors an easy way to test their changes and also to create a continuous integration test environment to be able to do end-to-end tests.

I am closing this as for now it seems Travis can handle our e2e load.

I am closing this as for now it seems Travis can handle our e2e load.


Move from create-react-app to Vite or Webpack

We need to migrate our project from Create React App (CRA) to Vite/Webpack due to several reasons, including security concerns and performance improvements.
The idea is that:

The project should build and run successfully using Vite/Webpack
All existing functionality should remain intact.
No security vulnerabilities should be present in the dependencies.

From our build logs, we have many warnings related to react-scripts (a.k.a. create-react-app):
warning react-scripts ><EMAIL_ADDRESS>This version is no longer supported. Please see https://eslint.org/version-support for other options.
warning react-scripts ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > babel-preset-react-app ><EMAIL_ADDRESS>This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-class-properties instead.
warning react-scripts > babel-preset-react-app ><EMAIL_ADDRESS>This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-numeric-separator instead.
warning react-scripts > babel-preset-react-app ><EMAIL_ADDRESS>This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-nullish-coalescing-operator instead.
warning react-scripts > babel-preset-react-app ><EMAIL_ADDRESS>This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-optional-chaining instead.
warning react-scripts > babel-preset-react-app ><EMAIL_ADDRESS>This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-private-methods instead.
warning react-scripts > eslint ><EMAIL_ADDRESS>Use @eslint/config-array instead
warning react-scripts > source-map-loader ><EMAIL_ADDRESS>Use your platform's native atob() and btoa() methods instead
warning react-scripts > webpack-dev-server ><EMAIL_ADDRESS>Rimraf versions prior to v4 are no longer supported
warning react-scripts > jest > @jest/core ><EMAIL_ADDRESS>Rimraf versions prior to v4 are no longer supported
warning react-scripts > workbox-webpack-plugin ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > @svgr/webpack > @svgr/plugin-svgo ><EMAIL_ADDRESS>This SVGO version is no longer supported. Upgrade to v2.x.x.
warning react-scripts > eslint > file-entry-cache > flat-cache ><EMAIL_ADDRESS>Rimraf versions prior to v4 are no longer supported
warning react-scripts > eslint > @humanwhocodes/config-array ><EMAIL_ADDRESS>Use @eslint/object-schema instead
warning react-scripts > react-dev-utils > fork-ts-checker-webpack-plugin ><EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported
warning react-scripts > webpack-dev-server > rimraf ><EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported
warning react-scripts > babel-jest > babel-plugin-istanbul > test-exclude ><EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported
warning react-scripts > jest > @jest/core > jest-config ><EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported
warning react-scripts > jest > @jest/core > jest-runtime ><EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported
warning react-scripts > jest > @jest/core > @jest/reporters ><EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported
warning react-scripts > react-dev-utils > fork-ts-checker-webpack-plugin ><EMAIL_ADDRESS>this will be v4
warning react-scripts > webpack-dev-server > webpack-dev-middleware ><EMAIL_ADDRESS>this will be v4
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-window ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-routing ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-recipes ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-recipes ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-streams ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-streams ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-recipes ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-precaching ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-precaching ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>This package has been deprecated and is no longer maintained. Please use @rollup/plugin-terser
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-recipes ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-precaching ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-strategies ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-broadcast-update ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-recipes ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-expiration ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-range-requests ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS><EMAIL_ADDRESS>warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-recipes ><EMAIL_ADDRESS><EMAIL_ADDRESS>warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-cacheable-response ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>It is not compatible with newer versions of GA starting with v4, as long as you are using GAv3 it should be ok, but the package is not longer being maintained
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-google-analytics ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-google-analytics ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-google-analytics ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-google-analytics ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-background-sync ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > workbox-navigation-preload ><EMAIL_ADDRESS>this package has been deprecated
warning react-scripts > @svgr/webpack > @svgr/plugin-svgo > svgo ><EMAIL_ADDRESS>Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility
warning react-scripts > css-minimizer-webpack-plugin > cssnano > cssnano-preset-default > postcss-svgo > svgo ><EMAIL_ADDRESS>Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility
warning react-scripts > react-dev-utils > fork-ts-checker-webpack-plugin > glob ><EMAIL_ADDRESS>This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
warning react-scripts > @svgr/webpack > @svgr/plugin-svgo > svgo > coa ><EMAIL_ADDRESS>You or someone you depend on is using Q, the JavaScript Promise library that gave JavaScript developers strong feelings about promises. They can almost certainly migrate to the native JavaScript promise now. Thank you literally everyone for joining me in this bet against the odds. Be excellent to each other.

(For a CapTP with native promises, see @endo/eventual-send and @endo/captp)
warning react-scripts > jest > @jest/core > jest-config > jest-environment-jsdom > jsdom ><EMAIL_ADDRESS>Use your platform's native atob() and btoa() methods instead
warning react-scripts > workbox-webpack-plugin > workbox-build > @rollup/plugin-replace > magic-string ><EMAIL_ADDRESS>Please use @jridgewell/sourcemap-codec instead
warning react-scripts > jest > @jest/core > jest-config > jest-environment-jsdom > jsdom ><EMAIL_ADDRESS>Use your platform's native performance.now() and performance.timeOrigin.
warning react-scripts > jest > @jest/core > jest-config > jest-environment-jsdom > jsdom > data-urls ><EMAIL_ADDRESS>Use your platform's native atob() and btoa() methods instead
warning react-scripts > jest > @jest/core > jest-config > jest-environment-jsdom > jsdom ><EMAIL_ADDRESS>Use your platform's native DOMException instead
warning<EMAIL_ADDRESS>This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-class-properties instead.
warning<EMAIL_ADDRESS>This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-private-property-in-object instead.
warning @cypress/code-coverage > nyc ><EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported
warning @cypress/code-coverage > nyc ><EMAIL_ADDRESS>Rimraf versions prior to v4 are no longer supported
warning @cypress/code-coverage > nyc > spawn-wrap ><EMAIL_ADDRESS>Rimraf versions prior to v4 are no longer supported
warning @cypress/code-coverage > nyc > istanbul-lib-processinfo ><EMAIL_ADDRESS>Rimraf versions prior to v4 are no longer supported
warning @cypress/instrument-cra ><EMAIL_ADDRESS>Debug versions >=3.2.0 <3.2.7 || >=4 <4.3.1 have a low-severity ReDos regression when used in a Node.js environment. It is recommended you upgrade to 3.2.7 or 4.3.1. (https://github.com/visionmedia/debug/issues/797)
warning eslint@8.[57](https://github.com/BSC-ES/autosubmit-gui/actions/runs/11955798977/job/33329019375#step:5:58).1: This version is no longer supported. Please see https://eslint.org/version-support for other options.
warning source-map-explorer ><EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported
warning source-map-explorer > temp ><EMAIL_ADDRESS>Rimraf versions prior to v4 are no longer supported
warning source-map-explorer > temp > rimraf ><EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported


Add CREATE EXTENSION command to service example

I think this is a vital part of the configuration that's better be more visible. I spent an hour to look for bug elsewhere :)
Thanks a lot for pgvector!

Hi @iesahin, thanks for the PR, but this should typically be handled by applications when setting up the schema.


Remove < Methods from Middleware.

An answer to https://github.com/socketry/protocol-http/issues/26.
Types of Changes

Bug fix.
New feature.
Breaking change.

Contribution

[ ] I added tests for my changes.
[ ] I tested my changes locally.
[ ] I agree to the Developer's Certificate of Origin 1.1.

I think the answer is: the convenience outweighs the interface overhead. Therefore, we won't try to remove these methods.


virtcontainers: Remove unnecessary kernel parameters for ppc64le

Fixes: #360
Signed-off-by: Nitesh Konkar<EMAIL_ADDRESS>

@sboeuf @jodh-intel

PSS Measurement:
Qemu: 159746 KB
Proxy: 4653 KB
Shim: 8906 KB
Memory inside container:
Total Memory: 2045972 KB
Free Memory:  1997004 KB

Thanks @nitkon. Nice.
lgtm

@jodh-intel : I see one failure from jenkins-ci-ubuntu-16-04 which has a  Required tag.
Summarizing 1 Failure:

[Fail] Update number of CPUs Update CPU period and quota [It] should have 3 CPUs
/home/jenkins/jenkins_slave/workspace/kata-containers-runtime-ubuntu-16-04-PR/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:278

How do we treat this? I don't think its related to my patch.

Hi @devimc - any thoughts on that failure?

lgtm

@jodh-intel the error is
Stderr:
Running command '/usr/bin/docker [docker exec xtZlrXwGDH3mDcFRwE8sXY5bFBaDlD bash -c for c in $(seq 1 5); do [ -d /sys/devices/system/cpu/cpu3 ] && nproc && exit 0; sleep 5; done; exit 1]'
command failed error 'exit status 126'
[docker exec xtZlrXwGDH3mDcFRwE8sXY5bFBaDlD bash -c for c in $(seq 1 5); do [ -d /sys/devices/system/cpu/cpu3 ] && nproc && exit 0; sleep 5; done; exit 1]
Timeout: 60 seconds
Exit Code: 126
Stdout: OCI runtime exec failed: rpc error: code = Internal desc = Could not run process: container_linux.go:348: starting container process caused "process_linux.go:90: adding pid 173 to cgroups caused \"failed to write 173 to cgroup.procs: write /sys/fs/cgroup/cpu,cpuacct/docker/07c01f0fe8808f4083249dba2fe4ad5be451021998a692fdaf3214cdd4b3e16a/cgroup.procs: invalid argument\"": unknown

PSS Measurement:
Qemu: 161951 KB
Proxy: 6668 KB
Shim: 10918 KB
Memory inside container:
Total Memory: 2045972 KB
Free Memory:  1997128 KB

lgtm


Failed to change connection to newly created python kernel if Conda is installed

Azure Data Studio Version:

Steps to Reproduce:

Machine that has conda installed on it.

Configure Python runtime and choose new python installation

The installation doesn't report any error. these are the latest lines in the output
Notebook dependencies installation is in progress
Notebook dependencies installation is complete
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\ff413f18-84b7-45f0-9997-998da4b1da96
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\ff413f18-84b7-45f0-9997-998da4b1da96\config
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\ff413f18-84b7-45f0-9997-998da4b1da96\data
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\ff413f18-84b7-45f0-9997-998da4b1da96\config\custom
... Starting Notebook server
> "C:\Users\mosharaf\azuredatastudio-python\0.0.1\python.exe" "c:\Users\mosharaf\AppData\Local\Programs\Azure Data Studio\resources\app\extensions\notebook\resources\pythonScripts\startNotebook.py" --no-browser --no-mathjax --notebook-dir "c:\Users\mosharaf" --port=8925 --NotebookApp.token=83bf979420bfbfd07577038bab6a02ff85387da571441c0c
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\66ec6766-8a96-4326-bce2-011b5dfe802d
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\66ec6766-8a96-4326-bce2-011b5dfe802d\config
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\66ec6766-8a96-4326-bce2-011b5dfe802d\data
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\66ec6766-8a96-4326-bce2-011b5dfe802d\config\custom
... Starting Notebook server
> "C:\Users\mosharaf\azuredatastudio-python\0.0.1\python.exe" "c:\Users\mosharaf\AppData\Local\Programs\Azure Data Studio\resources\app\extensions\notebook\resources\pythonScripts\startNotebook.py" --no-browser --no-mathjax --notebook-dir "c:\Users\mosharaf" --port=9320 --NotebookApp.token=63f484ebf923cda4202746f937e99d3cc713aca4a90bc94f
Notebook dependencies installation is in progress
Notebook dependencies installation is complete
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\2b63194b-076f-4460-bd55-abba5c08952c
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\2b63194b-076f-4460-bd55-abba5c08952c\config
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\2b63194b-076f-4460-bd55-abba5c08952c\data
... Creating C:\Users\mosharaf\AppData\Roaming\jupyter\instances\2b63194b-076f-4460-bd55-abba5c08952c\config\custom
... Starting Notebook server
> "C:\Users\mosharaf\azuredatastudio-python\0.0.1\python.exe" "c:\Users\mosharaf\AppData\Local\Programs\Azure Data Studio\resources\app\extensions\notebook\resources\pythonScripts\startNotebook.py" --no-browser --no-mathjax --notebook-dir "c:\Users\mosharaf" --port=9071 --NotebookApp.token=978b452fefd99d8c49e18a936a55e68c122614c2e4a9d0e6

Open a new notebook and choose python as kernel

It fails with error
Failed to change kernel. Kernel SQL will be used. Error was: Notebook process exited prematurely with error code: 1. StdErr Output: Traceback (most recent call last):
File "c:\Users\mosharaf\AppData\Local\Programs\Azure Data Studio\resources\app\extensions\notebook\resources\pythonScripts\startNotebook.py", line 1, in
import notebook.notebookapp
File "C:\Users\mosharaf\AppData\Roaming\Python\Python36\site-packages\notebook_init_.py", line 27, in
from .nbextensions import install_nbextension
File "C:\Users\mosharaf\AppData\Roaming\Python\Python36\site-packages\notebook\nbextensions.py", line 18, in
from jupyter_core.paths import (
ModuleNotFoundError: No module named 'jupyter_core'
It seems it goes to the activated conda environment not the newly installed Python instance

ModuleNotFoundError: No module named 'jupyter_core'
This seems quite interesting. Can you verify that you have the jupyter and ipykernel packages in your conda environment?

Yes conda environments are all installed with jupyter.
However, it shouldn't have effect because this is a newly installed Python by data studio


OpenTelemetry prevents next.js to properly terminate its process on Windows if we choose to close the terminal directly using the mouse

What happened?
Steps to Reproduce

Open a Windows Terminal tab, use PowerShell 7, navigate to any next.js project.
Run npx next dev, or alternatively, create a npm script that runs next dev and run that using npm run <script name>.
Close the Terminal tab. Please note: you should close the tab directly using the mouse, instead of pressing ctrl-c.

Expected Result
The processes for next.js exit.
Actual Result
After the tab is closed, the processes of next.js do NOT exit. As a result, they still occupy port 3000.
Additional Details
It looks like PowerShell 7 is a necessary part to reproduce this: if cmd.exe is used the processes for next.js could exit properly. PS7 is widely used on modern Windows developers.
Per @sebastien-comeau's comment, it looks like OpenTelemetry is the root cause of this bug.
OpenTelemetry Setup Code
N/A. It is an indirect dependency from Next.js.

package.json
N/A. It is an indirect dependency from Next.js.

Relevant log output
No response

@be5invis thanks for reaching out.
Would you mind providing a simple reproducer repo? I'm not too familiar with next.js and it would take a bit for me to figure out how to properly set it up with their provided integration.

Hmm what's a "reproducer repo"? Any app project created by create-next-app could reproduce this.

Ah so steps to reproduce are:

npx create-next-app --example with-opentelemetry with-opentelemetry-app (continue with default for everything)
cd with-opentelemetry-app
npx next dev
close windows terminal tab
open new windows terminal tab, switch into project dir
npx next dev (states that port 3000 is still in use)

However, trying the same without otel:

npx create-next-app (continue with default for everything)
cd my-app
npx next dev
close windows terminal tab
open new windows terminal tab, switch into project dir
npx next dev (states that port 3000 is still in use)

So there's the same behavior. This does not seem like an OTel bug to me as I cannot see any OTel packages installed using the default template.

@be5invis can you reproduce the same behavior on a next.js app that does not use otel?

@pichlermarc Just tried both config and they behave the same. So it might be something else causing this bug.
Closing and returning to Next.js


jcharset is GPL license that is incompatible with the Apache 2.0 license

https://github.com/opentelecoms-org/jsmpp/blob/afbd9722b1d7fae534e52b141bf4f031063a3bca/jsmpp-examples/pom.xml#L20-L23
Do you have other substitutes or alternatives that are available?

Good catch. I will see if there is an Apache Licenced charset, or otherwise I will create one.

I found these charsets, which are MIT licensed: https://github.com/brake/telecom-charsets. I will rewrite to use these or incorporate these libraries into the project.

jCharset is not used anymore, and replaced by a library with a MIT license.

jCharset is not used anymore, and replaced by a library with a MIT license.

Thank you for your time and effort!


using justify for text aligment

this library can be support text-align:justify;? we have 2 direction LTR and RTL, RTL is for such as arabic language or china

Unfortunately, the Android TextView that's used internally does not support justified text.
http://stackoverflow.com/questions/1292575/android-textview-justify-text
One option might be using this library based on TextView internally:  but it seems to have several open issues:
https://github.com/ufo22940268/android-justifiedtextview

@stefanhaustein yes, thats right. you have right, the Android TextView that's used internally does not support justified text

One of the comments says it will be available in Android O. I hope it will get ported back to the support library then....