Constraints should be inference sites for other type parameters

TypeScript Version:
1.8.0
Code
interface Class<T> {
	new(): T;
}
declare function create1<T>(ctor: Class<T>): T;
declare function create2<T, C extends Class<T>>(ctor: C): T;

class A {}
let a1 = create1(A); // a: A --> OK
let a2 = create2(A); // a: {} --> Should be A

Context
The example above is simplified to illustrate the difference between create1 and create2. I need both type parameters for the use case I have in mind (React) because it returns a type which is parameterized by both T and C:
declare function createElement<T, C extends Class<T>>(type: C): Element<T, C>;
var e = createElement(A); // e: Element<{}, typeof A> --> Should be Element<A, typeof A>

declare function render<T>(e: Element<T, any>): T;
var a = render(e); // a: {} --> Should be A

Again, this is simplified, but the motivation is to improve the return type inference of ReactDOM.render.

https://github.com/Microsoft/TypeScript/issues/6783 may be related, but I'm not sure.

@RyanCavanaugh any thoughts? Do you think this is a bug?

I should note that the very same issue is preventing me from removing React.Props<T> entirely. Currently, React developers explicitly declare the instance type T, and react.d.ts infers the props type P. It doesn't seem like I can infer both P and T simultaneously:
declare function createElement<P, T extends Component<P, {}>>(
    type: ComponentClass<P>,
    props?: P & { key?: Key, ref?: Ref<T> },
    ...children: ReactNode[]): ReactElement<P>;

interface FooProps {
    foo: string;
}
class Foo extends Component<FooProps, {}> {
    bar() { }
}

createElement(Foo, {
    ref: foo => foo.bar(), // OK
}); // P inferred as {} -> Should be ERROR (missing property foo)

cc @jbrantly

Not sure how much I can add atm except to say this is related.

I need someone more informed on generic type inference to weigh in here.
My speculation is that the root cause is because constraints aren't considered inference sites, but they'd be straightforward to add.

Thanks, that makes sense. I changed the name of this issue to better reflect the problem.

I was able to fool the type-system to behave properly, at least when working with constructor functions, by using a union type.  Modifying @vsiao's example:
interface Class<T> { new(): T; }
// Note the new type for 'ctor': C & (new(...args) => T)
declare function create2<T, C extends Class<T>>(ctor: C & (new() => T)): T;
class A {}
let a2 = create2(A); // a2: A, which is as it should be.

This work-around has a bad smell to it, but its the only thing I've found to work with the 1.8 compiler.
If you end up using it with constructors that require parameters, make sure you use a type that takes them into account, like new(...args) => T, instead.

Wow, great find @JHawkley. That works for my use case.

I guess it's not a complete workaround, though, since no inference is made for C as a constituent of an intersection type.

Accepting PRs on this, or we can take care of it a bit later.

I stumbled across this issue with a use case that I think is related... if someone can tell me this is a different case I'll happily raise another issue. Compiling the following with 1.9.0-dev.20160323:
interface HasKeyClass<T> {
	new(): HasKey<T>;
}

interface HasKey<T> {
	readonly Key: T;
}

interface F1<H> {
	(v: H): H;
}

function F1<H>(v: H): H {
	return v;
}

function F2<T extends HasKey<K>, K>(v: HasKeyClass<T>): void {
	let x1 = F3(v, F1);        // **** x1 has type {}; expected K
	let x2 = F3(v, <F1<K>>F1); // we can assert to 'fix' this: x2 has type K
}

function F3<T extends HasKey<K>, K, R>(v: HasKeyClass<T>, f: (k: K) => R): R {
	return undefined;
}

I'll reference here that @vsiao's original example (and mine for that matter) are also related to https://github.com/Microsoft/TypeScript/issues/7848.
Indeed do we need this issue to be fixed before we can attempt https://github.com/Microsoft/TypeScript/issues/7848?

Thanks to @RyanCavanaugh and @JsonFreeman, I've dug into my example above and a) fixed a bug but also b) separated my issue into two parts.
For the variable x, I believe this to be another instance of the problem originally described in this issue, #7234:
let x = F3(M1, F1);                       // ERROR: x has type {}; expected string

However, when it comes to the variable z, this is an instance of the #138:
let z = F3<M1, string, number>(M1, F1);   // ERROR: z has type number; expected string

Just adding these notes here for the record, in case anyone else encounters this when passing generic functions as arguments (or more generally with assignment of generic functions).

@myitcv I believe that fixing #138 would make the z line an error. Is that what you mean?
There is one place where we do contextual signature instantiation today, and it is in the context of inference. I believe that should make x a string in your example. My guess is that there is a bug related to F-bounded polymorphism.
The original example by @vsiao is interesting. In the call to create2, how is it possible to know (from the invocation) that T should be A? If T is {}, that leads to a consistent answer because K (in this case Class<A>) does indeed extend Class<{}>, so it satisfies the constraint.

@JsonFreeman If you debug (TS repo) @vsiao 's example as a test case you'll see that TS knows about A, it also knows that C (Class) has a typeArgument T and that C is a new()=>T.
From all that we can infer T if its not preset, and the other way around infer C if we do:
declare function create2<T, C extends Class<T>>(ctor: new() => T): T;

The missing part here is connecting the 2 types together.

@JsonFreeman

@myitcv I believe that fixing #138 would make the z line an error. Is that what you mean?

Exactly, at least based on my understanding from our other thread.

This is also the problem for x in your more recent example.

Are you referring to this example?
I'll take the issue we think is attributable to #138 out of the equation and rewrite the example:
interface HasKeyClass<T extends HasKey<K>, K> {
    new(): T;
}

interface HasKey<T> {
    readonly Key: T;
}

function F4<T extends HasKey<K>, K>(v: HasKeyClass<T, K>): K {
    return undefined;
}

class M1 {
    get Key(): string { return "test"; }
}

let x1 = F4(M1);  // ERROR: x1 has type {}; should be string

Is it your understanding that x1 should have type {} or string?
Incidentally, I'm not a fan of generic inference ever returning the type {} for a type parameter - I believe, as has been mooted in other threads, if {} is ever inferred (and not explicitly supplied) then the compiler should error. We have just implemented a type checking rule in tsvet that does exactly this (error).

Yes, that was the example I meant. Like you and many other users, I agree that if it is not possible to do inference correctly, an error is more desirable than inferring {}. I think @DanielRosenwasser tried to introduce errors when there were no inference candidates, and ran into some issues with optional parameters.
I am a little bit confused about your example though. In particular, what is the purpose of T? I could imagine it being written in a different way, with only one type parameter:
interface HasKeyClass<K> {
    new(): HasKey<K>;
}

interface HasKey<T> {
    readonly Key: T;
}

function F4<K>(v: HasKeyClass<K>): K {
    return undefined;
}

class M1 {
    get Key(): string { return "test"; }
}

let x1 = F4(M1);

I think @DanielRosenwasser tried to introduce errors when there were no inference candidates, and ran into some issues with optional parameters.

Can you link me to that issue/PR? I will add to the thread there rather than go off on a tangent on this thread.

I am a little bit confused about your example though. In particular, what is the purpose of T? I could imagine it being written in a different way, with only one type parameter:

You're right, my attempt to reduce this to a minimal example has in fact obfuscated the original use case, which I now reproduce below (to distinguish from previous posts in this thread, I've called it example 3):
// *********
// example 3

interface Class<T> {
	new (...args: Array<any>): T;
}

interface HasKey<T> {
	Key: T;
}

interface Unit<T0> {
	__Type: "Unit";
	V0: T0;
}

interface Pair<T0, T1> {
	__Type: "Pair";
	V0: T0;
	V1: T1;
}

interface Triplet<T0, T1, T2> {
	V0: T0;
	V1: T1;
	V2: T2;
}

interface PairRowClass<T0 extends HasKey<K0>, K0, T1 extends HasKey<K1>, K1, KR> {
	New(v0: T0, v1: T1): PairRow<T0, K0, T1, K1, KR>;
}

interface PairRow<T0 extends HasKey<K0>, K0, T1 extends HasKey<K1>, K1, KR> {
	readonly Key: KR;
	readonly VO: T0;
	readonly V1: T1;
}

function PairRow<T0 extends HasKey<K0>, K0, T1 extends HasKey<K1>, K1, KR>(t0: Class<T0>, t1: Class<T1>, kb: (k0: K0, k1: K1) => KR): PairRowClass<T0, K0, T1, K1, KR> {
	let res: PairRowClass<T0, K0, T1, K1, KR>;
	// impl
	return res;
}

function joinUnitUnit<K0T0, K1T0>(k0: Unit<K0T0>, k1: Unit<K1T0>): Pair<K0T0, K1T0> {
	let res: Pair<K0T0, K1T0>;
	// impl
	return res;
}

function joinPairUnit<K0T0, K0T1, K1T0>(k0: Pair<K0T0, K0T1>, k1: Unit<K1T0>): Triplet<K0T0, K0T1, K1T0> {
	let res: Triplet<K0T0, K0T1, K1T0>;
	// impl
	return res;
}

class M1 {
	get Name(): string { return "Paul"; }
	get Valid(): boolean { return true; }
	get Key(): Pair<string, number> {
		let res: Pair<string, number>;
		return res;
	}
}

class M2 {
	get Key(): Unit<string> {
		let res: Unit<string>;
		return res;
	}
}

// ERROR: x1 has type PairRowClass<M1, {}, M2, {}, Triplet<{}, {}, {}>>
// should be: PairRowClass<M1, Pair<string, number>, M2, Unit<string>, Triplet<string, number, string>>
// believe this is because of #7234
let x1 = PairRow(M1, M2, joinPairUnit);
let eg1 = x1.New(new M1(), new M2());
eg1.Key;  // ERROR: type is Triplet<{}, {}, {}>, should be Triplet<string, number, string>
eg1.VO;   // OK: type is M1
eg1.V1;   // OK: type is M2

// OK: x2 has type PairRowClass<M1, Pair<string, number>, M2, Unit<string>, Triplet<string, number, string>>
let x2 = PairRow<M1, Pair<string, number>, M2, Unit<string>, Triplet<string, number, string>>(M1, M2, joinPairUnit);
let eg2 = x2.New(new M1(), new M2());
eg2.Key;  // OK: type is Triplet<string, number, string>
eg2.VO;   // OK: type is M1
eg2.V1;   // OK: type is M2

let prop1 = eg2.VO.Name; // OK type is string
let prop2 = eg2.VO.Valid; // OK type is string

// ERROR: x3 has type PairRowClass<M1, Pair<string, number>, M2, Unit<string>, Triplet<boolean, boolean, boolean>>
// this should be impossible because of the definition for joinPairUnit; we think this is "allowed" because of #138
let x3 = PairRow<M1, Pair<string, number>, M2, Unit<string>, Triplet<boolean, boolean, boolean>>(M1, M2, joinPairUnit);

// ERROR: x4 has type PairRowClass<M1, {}, M2, {}, Pair<{}, {}>>
// this should be impossible because the resulting Key cannot be of type Pair<K0, K1> given the definitions of M1 and M2
// this is a compound result of #7234 and #138
let x4 = PairRow(M1, M2, joinUnitUnit);

I'll make the following observations about example 3:

x1 has the incorrect type because of the issue in this thread, #7234
x2 is ok, but we've had to manually specify the types of in the call to PairRow - if #138 is fixed, then x1 will be fixed and this manual specification of type parameters will not be required
x3, the RHS should be impossible, but is permitted because of #138
x4, the RHS should also be impossible, but is allowed as a result of both #7234 and #138 combining

Hopefully the requirement for the T* parameters for interfaces PairRow etc is made clear by the RHS for variables prop{1,2}? In these situations it's important the type of the getter on PairRow, e.g. readonly V0 is the concrete type T0 and not the interface HasKey<K0>.

@myitcv search `is:pr is:closed author:DanielRosenwasser candidates' :)

@shlomiassaf Are you referring to #220? I don't think that is the right issue. I tried searching around but could not find the issue I was thinking of.

@myitcv Looking at your example, there's some unreferenced type parameters. What if you instead wrote it like this:
interface PairRow<K0, K1, KR> {
    readonly Key: KR;
    readonly VO: HasKey<K0>;
    readonly V1: HasKey<K1>;
}
interface PairRowClass<K0, K1, KR> {
    New(v0: HasKey<K0>, v1: HasKey<K1>): PairRow<K0, K1, KR>;
}
function PairRow<K0, K1, KR>(t0: Class<HasKey<K0>>, t1: Class<HasKey<K1>>, kb: (k0: K0, k1: K1) => KR): PairRowClass<K0, K1, KR> { }

Writing it this way would make it so that in the PairRow function, all the type parameters are somehow observed in the arguments list.

@JsonFreeman

Looking at your example, there's some unreferenced type parameters

Really? I thought I'd checked a few times.. can you point out where?
Or are you talking K0 and K1 in  interface PairRow? I didn't think these were unreferenced... because there are effectively referenced in the constraint of T0 and T1.

Writing it in this way...

interface PairRow<K0, K1, KR> {
    readonly Key: KR;
    readonly VO: HasKey<K0>;
    readonly V1: HasKey<K1>;
}

I don't think this works, because we then know nothing about the type of V0:
//
let eg2: PairRow<Pair<string, number>, Unit<string>, Triplet<string, number, string>>;
eg2.VO.Name; // ERROR

Unless I'm missing something in your response?

Yes I was referring to K0 and K1 in PairRow. But I see the problem now. You want to capture T0 itself, but you also want access to a particular property in T0, namely K0.

Just curious, what happens if you use an intersection type instead of a constraint, like this:
function PairRow<T0, K0, T1, K1, KR>(t0: Class<T0 & HasKey<K0>>, t1: Class<T1 & HasKey<K1>>, kb: (k0: K0, k1: K1) => KR): PairRowClass<T0, K0, T1, K1, KR> { }

@JsonFreeman - that fixes K0 and K1 but now T0 and T1 are inferred only as HasKey<K0> and HasKey<K1> respectively:
// example 4: example 3 rewritten to change definition of function PairRow
// all other definitions remain the same
function PairRow<T0 extends HasKey<K0>, K0, T1 extends HasKey<K1>, K1, KR>(t0: Class<T0 & HasKey<K0>>, t1: Class<T1 & HasKey<K1>>, kb: (k0: K0, k1: K1) => KR): PairRowClass<T0, K0, T1, K1, KR> {
    let res: PairRowClass<T0, K0, T1, K1, KR>;
    // impl
    return res;
}

// x1 has type PairRowClass<HasKey<Pair<string, number>>, Pair<string, number>, HasKey<Unit<string>>, Unit<string>, Triplet<string, number, string>>
let x1 = PairRow(M1, M2, joinPairUnit);

// eg1 has type PairRow<HasKey<Pair<string, number>>, Pair<string, number>, HasKey<Unit<string>>, Unit<string>, Triplet<string, number, string>>
let eg1 = x1.New(new M1(), new M2());

// hence the following fails to compile
eg1.VO.Name;  // ERROR: 'Name' does not exist on type 'HasKey<Pair<string, number>>'
eg1.VO.Valid; // ERROR: 'Valid' does not exist on type 'HasKey<Pair<string, number>>'

Yeah in general, intersection does not work well with bare type parameters. I think something about inference would need to be tweaked for your scenario to work. I actually do prefer the intersection idiom because the type parameters are inferred directly from arguments that are passed in. It is more consistent with the TS philosophy on type argument inference.

Note that with the changes in #8821 the pattern of using intersection types to infer multiple type parameters from a single argument now works really well. For example:
interface Class<T> {
    new(): T;
}

interface Item<T, C> { t: T, c: C }

declare function create<T, C>(ctor: C & Class<T>): Item<T, C>;

class A {}

let item = create(A);  // Item<A, typeof A>
item.t;  // A
item.c;  // typeof A

And another example:
interface KeyAndValue<K, V> { key: K, value: V }

interface ObjectWithKey<K> {
    key: K
}

function getKeyAndValue<T, K>(obj: T & ObjectWithKey<K>): KeyAndValue<K, T> {
    return { key: obj.key, value: obj };
}

class Foo {
    key: string;
    data1: number;
    data2: number;
}

class Bar {
    key: number;
    description: string;
}

const kv1 = getKeyAndValue(new Foo());  // KeyAndValue<string, Foo>
const kv2 = getKeyAndValue(new Bar());  // KeyAndValue<number, Bar>

After discussing with Anders, I think we'll go with the intersection-type based workaround. I'll add an example to Advanced Types in the handbook so that others can find the workaround.


api_key_cmd with pipes (|) ?

https://github.com/jackMort/ChatGPT.nvim/blob/8191b4a1faea28483aa3a495d01ade3eb86409fe/lua/chatgpt/api.lua#L174
Is there a way this can be changed so I can use a pipe in my command?
I'd like to use:

api_cmd_key = "rbw get -f OPENAI_API_KEY chat.openai.com | awk '{print $2}'"

Using only rbw get -f OPENAI_API_KEY chat.openai.com gets a custom field from the entry but its output format is:

OPENAI_API_KEY: sk-fda94jf88gfdssblah

so I need to pipe to awk, sed, cut, jq or something.  I wrote a wrapper script which works, but this is not ideal for having my config files be portable.
Thanks

same here +1


feat: Improve for windows

Description
See https://forum.codeigniter.com/showthread.php?tid=92138
An attempt to adapt to the Windows system. This PR is not for merging, it is for viewing. I ask you to speak about the method. File ./errors.txt the errors that remained in my system. For those who do not have windows.
Maybe I want too much, but we don't have enough discussion to resolve such issues.
Checklist:

[ ] Securely signed commits
[ ] Component(s) with PHPDoc blocks, only if necessary or adds value
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[ ] Conforms to style guide

@datamweb We are waiting for an opinion

It is important to consider the fix globally. Is it good to use the new functions?


Switches on Popovers not clickable

Switches on popovers are not clickable via mouse
          <Popover.State placement="bottom-end">
            <Popover.Disclosure use={Button}>

            </Popover.Disclosure>
            <Popover title={user ? `Welcome ${user.displayName}` : 'Login to Continue!'} usePortal>
              <Heading use="h6">User Settings</Heading>
              <Switch
                label={`${isLightMode ? 'Light' : 'Dark'} Mode`}
                checked={isLightMode}
                onClick={() => {
                  if (isLightMode) {
                    setColorMode('dark');
                  } else {
                    setColorMode('light');
                  }
                }}
              />
              <hr />
            </Popover>
          </Popover.State>

You can still toggle it via the spacebar when selected

Hmm, can you reproduce this in Playroom? It seems to work for me.
https://bumbag.style/playroom/#?code=N4Igxg9gJgpiBcIA8AFCAHCA3GAnAdAMoAuAhsTAHwA6AdgAT2obZ74AiAlgM5gA2EbgFdcMekO4wAvMABCQ4sQi0AvpQDy6GAzSYcuJAHpdrAl14DhomgyYn9NxowDqAC3L0A7qW71irsQAjGG5iP1dOWgBzcI93dC1aGCg-CHoATwghVKhSdIB%2BOicmQk9OYjBXej5SYL4pahAAFQgoqL4xAFsxXFa8AEJG%2BkNHJmMWBzojezYScioQFSA

Unfortunately I can't reproduce in playroom, i will debug further.
Line in question is here: https://github.com/ericjiang97/nextjs-personal/blob/feat/firebase/components/nav.tsx#L57

Whoops my fault... just realised its onChange not onClick lol


[BUG] When upgrading 1 node Harvester with PCI passthrough the VM won't come up and kube-vip crashes

Describe the bug

When you upgrade a single node Harvester cluster from v1.2.1 -> v1.2.2-rc3
To Reproduce
Steps to reproduce the behavior:

Create a Harvester cluster
Add PCI passthrough
Create a VM with a PCI passthrough device (I used an Nvidia GPU)
Turn off VM
Upgrade to v1.2.2-rc3
Wait for upgrade to finish
Turn VM back on

Expected behavior

VM should turn on successfully.
Support bundle

supportbundle_09ea7a32-1b8f-4996-80fa-845eb2a84415_2024-05-13T20-29-36Z.zip
Environment

Harvester ISO version: v1.2.1 -> v1.2.2-rc3
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): DL360

Additional context
Add any other context about the problem here.
Possibly related to #5373 and #5374 .
It's worth noting I can still admin the cluster from the node IP and from the upstream Rancher cluster where it is imported. Just the VIP seems to be down.
The kubevip worked immediately after the upgrade, and stopped working after a while. kube-vip is getting this error then it's looping on the waiting error.
time="2024-05-13T20:27:11Z" level=info msg="Using existing macvlan interface for DHCP [vip-e8d7c773]"
time="2024-05-13T20:27:21Z" level=error msg="timeout to request the IP from DHCP server for service kube-system/ingress-expose"
time="2024-05-13T20:27:46Z" level=error msg="request failed, error: got an error while processing the request: no matching response packet received (waiting 10s)"
time="2024-05-13T20:28:28Z" level=error msg="request failed, error: got an error while processing the request: no matching response packet received (waiting 1m0s)"

The PCI passthrough VM is getting a memory setting error. I recall a similar issue in the past where when you edited a VM and added PCI passthrough it would not work because we were overcommiting memory by default and it seemed like kubevirt didn't like that with VMs that had PCI devices.

@noahgildersleeve
kube-vip failed to get dhcp response, is your dhcp server still alive?  you may tcpdump on your server side then kill kube-vip pod to re-trigger the dhcp process; and aslo tcpdump harvester mgmt-bo to check if dhcp frames are sending and receiving.
time="2024-05-13T20:27:11Z" level=info msg="Using existing macvlan interface for DHCP [vip-e8d7c773]"
time="2024-05-13T20:27:21Z" level=error msg="timeout to request the IP from DHCP server for service kube-system/ingress-expose"
time="2024-05-13T20:27:46Z" level=error msg="request failed, error: got an error while processing the request: no matching response packet received (waiting 10s)"
time="2024-05-13T20:28:28Z" level=error msg="request failed, error: got an error while processing the request: no matching response packet received (waiting 1m0s)"

We tried to clear out the tube-vip and it's having the same issue. It might be environmental. I'm going to test it again without DHCP on the VIP in a different more simple environment.

Validation steps

Create a v1.2.1 cluster
enable pci passthrough
Enable PCI passthrough device
Create VMs and assign PCI device
Upgrade to v1.2-head
unassign pci device
Create new VM and assign PCI device
Turn on new VM
Check for warning on Harvester cluster with kubectl get events | grep Warn

Also I validated that the issue with the kubevip was that it lost the DHCP lease. When I ran the upgrade with a static IP for the VIP it worked fine.

Closing as completed.


[Doc] For running and testing capsule proxy on kind cluster

Is there doc showing, how to run capsule proxy on a kind cluster ?

Hello @viveksyngh, and thank you for your question.
You can follow guidelines describe inside the repository README ;
anyway,  take a look to a real example inside Makefile at e2e/%: docker-build step.
Please, let me know if you have any other questions 👍


Add semantic-models: config to dbt_project.yml page

Contributions

[X] I have read the contribution docs, and understand what's expected of me.

Link to the page on docs.getdbt.com requiring updates
https://docs.getdbt.com/reference/dbt_project.yml
What part(s) of the page would you like to see updated?
Add the semantic-models: config
Additional information
No response

Thread with context for this issue https://dbt-labs.slack.com/archives/C05LRDBSCNL/p1699645088331809


feat(config): allow onComplete to return a promise

Closes #1944

I'm thinking that our runners (jasmine and mocha) are complex enough that we should have a 'frameworks' folder under our specs, which exercises them with some simple files.
But that can be work for a separate PR - this looks good to me.


Improve build disk usage

@agherzan @floion

Can one of the admins verify this patch?

LGTM

test this please

LGTM

LGTM but maybe you could reword the comment:
"Remove the old image before the new one generated to save disk space"
feels a bit weird. Maybe "is generated" is more appropriate

LGTM


Merge snackbar styles when closed as well as open

Inline styles aren't being overridden when the snackbar is closing because they were only merged when it was open. This fixes that. It still doesn't give a good way to add your own, different styles for opening and closing though.

Good call, using the ternary now

Thanks @lourd


[RIS-Import] Error during processing of title fields T1 or TI during RIS import

Discussed in https://github.com/asreview/asreview/discussions/1153

Originally posted by felixhorch June  8, 2022
Hello!
When processing a .RIS file exported from Citavi, I noticed an error when processing the T1 or TI title fields: Apparently, the title of the publications is only recognized correctly by ASReview if the title field is labeled TI. But if the title is exported as T1, as it is apparently implemented in Citavi, ASReview does not show any titles, neither in the search nor in the review. However, as far as I understand the RIS specification, both are allowed and correct.
Couldn't this be added relatively easily in the RIS processing?
Best regards
Felix
@felixhorch thanks for reporting, what version of ASReview are you using? Thanks for the attempted debug. Will look into it.

I'm using 0.19.3

rispy supports the following titles: https://github.com/MrTango/rispy/blob/d795f51264823ce666b36dd1538d3c8955f6d26f/rispy/config.py#L66-L72.
    "ST": "short_title",
    "T1": "primary_title",
    "T2": "secondary_title",
    "T3": "tertiary_title",
    "TA": "translated_author",
    "TI": "title",
    "TT": "translated_title",

ASReview should be able to parse the following titles: https://github.com/asreview/asreview/blob/0865f691ef47c963505c482f60105685bab35bc5/asreview/config.py#L59
This makes me think that TI also occurs in your dataset, but is used rarely. TI column is displayed in ASReview.
A solution might not be that straightforward as we only display the content of 1 column for the title and abstract. We don't mix the contents in ASReview atm.
Can you share your dataset via<EMAIL_ADDRESS>I will have a closer look.

Quick Fix for this is obviously (as in #1005)

Open the .RIS file in a text editor
Replace T1  -  with TI  -
Open the .RIS file in ASReview


pokerth: 1.1.1 -> 1.1.2, refactor, Qt 5

Motivation for this change
Disclaimer: I'm not a user of pokerth, so ping @obadz. I've just picked up a random item from #33248, and updated from Qt4 to Qt5 version.
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Fits CONTRIBUTING.md.

@GrahamcOfBorg build pokerth pokerth-server

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: pokerth, pokerth-server
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: pokerth, pokerth-server
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/1abva9afdl4p1xrkhcsyr7pjsjzp38b7-pokerth-client-1.1.2
shrinking /nix/store/1abva9afdl4p1xrkhcsyr7pjsjzp38b7-pokerth-client-1.1.2/bin/pokerth
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/1abva9afdl4p1xrkhcsyr7pjsjzp38b7-pokerth-client-1.1.2/bin
patching script interpreter paths in /nix/store/1abva9afdl4p1xrkhcsyr7pjsjzp38b7-pokerth-client-1.1.2
checking for references to /build in /nix/store/1abva9afdl4p1xrkhcsyr7pjsjzp38b7-pokerth-client-1.1.2...
postPatchMkspecs
postPatchMkspecs
/nix/store/1abva9afdl4p1xrkhcsyr7pjsjzp38b7-pokerth-client-1.1.2
/nix/store/5vqcvjqyypr4935vq4xh0l47b24z2lhp-pokerth-server-1.1.2

Success on x86_64-linux (full log)
Attempted: pokerth, pokerth-server
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/ghm5cdrpwagyv2fpvqdhfr1f1pp6pcbw-pokerth-client-1.1.2
shrinking /nix/store/ghm5cdrpwagyv2fpvqdhfr1f1pp6pcbw-pokerth-client-1.1.2/bin/pokerth
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/ghm5cdrpwagyv2fpvqdhfr1f1pp6pcbw-pokerth-client-1.1.2/bin
patching script interpreter paths in /nix/store/ghm5cdrpwagyv2fpvqdhfr1f1pp6pcbw-pokerth-client-1.1.2
checking for references to /build in /nix/store/ghm5cdrpwagyv2fpvqdhfr1f1pp6pcbw-pokerth-client-1.1.2...
postPatchMkspecs
postPatchMkspecs
/nix/store/ghm5cdrpwagyv2fpvqdhfr1f1pp6pcbw-pokerth-client-1.1.2
/nix/store/klsjjg9dm3zfh5sp8ksi37x1nvggjnfn-pokerth-server-1.1.2


Autocomplete Updates

Precautious update ref instead of ~innerRef~ in MenuCard to avoid warning of deprecated ~innerRef~, when styled-components upgrades to v4:

Uptick downshiftdep of Autocomplete to latest version

Update upper case of 1st letter (per console warning from the pcln-design-system v2 requirement) of the name prop for the pin icon in Autocomplete.

Codecov Report

Merging #459 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #459   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          43     43
  Lines         398    398
=====================================
  Hits          398    398

Impacted Files
Coverage Δ

packages/autocomplete/src/index.js
100% <100%> (ø)
:arrow_up:

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 51448b0...0b9b1fe. Read the comment docs.


rancher集群用负载ip添加主机报错：[TaskScheduler-2] [i.c.p.a.s.ping.impl.PingMonitorImpl ] Failed to get ping from agent [46543] count [9]

What kind of request is this (question/bug/enhancement/feature request):
Steps to reproduce (least amount of steps as possible):
Result:
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
Installation option (single install/HA):

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported):
Machine type (cloud/VM/metal) and specifications (CPU/memory):
Kubernetes version (use kubectl version):

(paste the output here)

Docker version (use docker version):

(paste the output here)

Can you supply more info on your setup (basically copy paste from this and fill in: https://raw.githubusercontent.com/rancher/rancher/master/.github/ISSUE_TEMPLATE.md)
Or find us by searching rancher2 via wechat


Initialise the calendar component with Monday as the first day

After thinking about this for a while, I think we should put a foot in the ground and display calendars as the rest of the world: Monday first in all calendar views.
I am assuming this is a configuration option in fullCalendar, and so switching is trivial.

It's an option in fullcalendar but that doesn't fix the issue. All views where built with the knowledge that the first day of the week would be a Thursday so we'll have to go through them and make changes.

"go through them": We should estimate the effort and make an emotional decision :8ball:

AFAIK nothing has come up in user testing to indicate that the current start of day is confusing. I'll close this issue.


Dependency update PR title has blank list of new versions

Minor thing, but it's a bit weird how dependency update PRs that don't actually change any versions (they just reformat the buildpack.toml) have a title that includes an empty list of dependency versions. Like https://github.com/paketo-buildpacks/dotnet-core-sdk/pull/263 .
Seems like this is because the PR title in the update workflow is always the same regardless of whether the updated versions output is empty or not:
https://github.com/paketo-buildpacks/github-config/blob/f28fd2b7cebd88309f0d13303824fd2b3900c82d/implementation/.github/workflows/update-dependencies.yml#L46

Once we fully move all of our dependencies onto the dep-server this won't occur anymore.


Initial Security Model

What type of PR is this?
/kind documentation
What this PR does / why we need it:
Initial security model markdown to inform users on permissions, and overall security related information.
In the future, this will contain also include compliance status (i.e. NIST, SLSA, etc.)
Which issue(s) this PR fixes:
Relates to #653
Does this PR have test?
N/A
Special notes for your reviewer:
N/A
Does this PR introduce a user-facing change?
NONE

@jhrozek @JAORMX @saschagrunert keen on hearing thoughts on how we can improve this. Also, need some other pairs of eyes to double check on the selinux front.

Codecov Report

Merging #693 (79317eb) into master (447c89a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #693   +/-   ##
=======================================
  Coverage   51.57%   51.57%
=======================================
  Files          31       31
  Lines        2065     2065
=======================================
  Hits         1065     1065
  Misses        947      947
  Partials       53       53

/hold
For other reviews.

Btw does it make sense to mention that by default almost all the containers run with the spc_t SELinux type which pretty much means "unconfined"? (If you prefer, I can propose another PR atop this)

@jhrozek great point - yes. I think we should get out at a container level:

SELinux type
AppArmor profile
Seccomp profile
Capabilities

Happy for you to propose a follow-up PR on that. :+1:
On the mid/long term, it would be great if we could think on ways to automatically extract such information (like we do for RBAC).

@jhrozek went through your poinds - thank you so much for the extensive feedback. PTAL

@saschagrunert thank you. In my opinion we can keep as is right now. Once we are a bit more settled in terms of features - specially around AppArmor and the great bits around eBPF profiling you are working on - we review it. What do you think?

Sounds great!

/test pull-security-profiles-operator-test-e2e

/test pull-security-profiles-operator-test-e2e

/test pull-security-profiles-operator-verify

I'm happy with the current state!
/lgtm

/retest

/test pull-security-profiles-operator-verify

/test pull-security-profiles-operator-verify

/test pull-security-profiles-operator-verify

/unhold

/retest

/retest

/test pull-security-profiles-operator-verify

/retest

/retest

/override pull-security-profiles-operator-verify

/override pull-security-profiles-operator-verify


Fix crash in init #trivial

This should fix #441

          1 Warning

  :warning:
  Tests were not updated

  Generated by :no_entry_sign: danger

This fixes the issue for me 👍

Doh! - nice find

@marcelofabri FWIW, I don't think a crash fix is trivial, it really should go in the CHANGELOG 👯 it's a good fix!


fix sig-node kubernetes contributor award 2024

This PR fixed the question of https://github.com/kubernetes/contributor-site/pull/552.
See https://github.com/kubernetes/contributor-site/pull/552/files#r1875198047.

/cc @tokt
/assign @jberkus @mfahlandt
cc @ffromani
I opened the PR to fix the description of sig-node award.

/approve

/lgtm


[JAVA-3782] Use the platform-specific line separator in Authorization header

Hello, please do not merge. I think my solution is wrong. I need to investigate further this issue.

The second commit is the correct solution.
Aws use unix-style line endings (\n)

@fhassak thanks for the fix.  We are much obliged!


update mwaa to 2.9.2 & update requirements/constraints

Describe your changes

update MWAA to 2.9.2
update to latest MWAA constrains from https://docs.aws.amazon.com/mwaa/latest/userguide/airflow-versions.html
update individual MWAA constraints to remediate security scan results
verified by E2E deoloyment and DAG run

NOTE: MWAA 2.9.2 has strict dependency on Werkzeug==2.2.3 and cryptography<42.0.0.
Checklist before requesting a review

[x] I updated CHANGELOG.MD with a description of my changes
[x] If the change was to a module, I ran the code validation script (scripts/validate.sh)
[x] If the change was to a module, I have added thorough tests
[x] If the change was to a module, I have added/updated the module's README.md
[x] If a module was added, I added a reference to the module to the repository's README.md
[x] I verified that my code deploys successfully using seedfarmer apply

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: 9ebe9226135770452417d6907789257d01aaa226
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: d8410991c42cb59fe0b025a1c495343c2d2002fe
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: fb84be8d14d3e6b718392fad480c3006ab279305
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

Note: there is broken s3 metadata plugin in IDF that does not impact ML DAG run and should be fixed in upstream IDF MWAA module:
Broken plugin: [/usr/local/airflow/plugins/plugins/s3_metadata_plugin.py] No module named 'sensors'


Add option to add stats to Job Summary page

Adds a job-summary option that adds the stats to the Job Summary section of a workflow run. Requires CCache 4.10+
Also added some unit tests and a workflow job for same.
Just added cache hits for now but is easily extendable. - looks like this:

Nice!
Do you see a reason why somebody would decide against this? I understand the need for the version check. Given that the version supports it, I would enable it. Or do I miss anything? Is there a usecase for disabling the output?

Nice!
Do you see a reason why somebody would decide against this?

No problem. Just being conservative - I'll update the PR enabling the feature by default.

I've done something similar for a private repo, Something that I found looks really good is to use a mermaid diagram to show the direct/preprocessed/missed stats in a pie chart diagram.
https://mermaid.js.org/syntax/pie.html
Since the summaries support github flavoured markdown they render right in the summary view!
e.g.
pie showData title CCache Summary
    "Direct Hits" : 149818
    "Preprocessed Hits" : 1840
    "Misses" : 3743

@planetmarshall Thanks again for the contribution. I think this ready to be merged, however I meanwhile merged some dependabot PRs and caused a merge conflict.
Shall I fix it myself or can you?
I also wonder, do you want to lock into the suggestion from @TrentHouliston? Or is that something for a follow up? - I definitely like the idea and support it, however it could be done in a separate change.

@planetmarshall Thanks again for the contribution. I think this ready to be merged, however I meanwhile merged some dependabot PRs and caused a merge conflict.
Shall I fix it myself or can you?

I've updated the branch.

I also wonder, do you want to lock into the suggestion from @TrentHouliston? Or is that something for a follow up? - I definitely like the idea and support it, however it could be done in a separate change.

I like the the idea but I think it's better added as a future enhancement.


[BUG] - Adding a Pool with meta info borks querying ledger state

Exernal
Summary
(PS: Understand that master can break existing release, but raising it since someone trying this can potentially break the network)
Tested registering a pool with a test metadata (using URL and hash) on a seperate (guild) network. The pool was registered successfully, but querying the ledger using cli (via cardano-cli shelley query ledger-state) run from any node causes CLI to hang , using up 100% CPU.
Since this change was committed to master branch, if someone attempts to, this can potentially break the existing public testnet network
(CC: @kevinhammond @intricate )

This needs some investigation.  We should make sure that the chain data is clean, also that the node does not fail if bad data is present on the chain


Move "New Files" filtering to earlier

It would be clearer for the user imho, if the NewFilesOnly filtering were done earlier in the run, like maybe here where you get the timestamp anyways https://github.com/keboola/ex-ftp/blob/18425661fe0c42ffa1d1c92431f93f06c5ce791d/src/FtpExtractor.php#L139 .
We could compare with the saved state timestamp there.
This way the list of files to process would A) be shorter, and B) be more accurately reflected in the logs.

https://keboola.zendesk.com/agent/tickets/11706

@marc any update here?


Annotation support

Would be nice to have the ability to drop lines, arrows, more than one set of cursors, text, callouts, etc in the UI, and have this attach to historical waveforms.

Factors to consider when implementing this:

Each WaveformArea is a separate surface for rendering. Do we want to support annotations spanning more than one WaveformArea? If so, where do we store this state?
What happens when WaveformAreas are resized or moved to another WaveformGroup?

In ngscopeclient, each WaveformGroup is a single window so it's perfectly reasonable to have annotations spanning multiple WaveformArea's.