Support for a built-in "constructable" type or "class type"

TypeScript Version:  2.4.0
It would be interesting to allow type hinting for class type.
Something like
function generateMyClass(myClass: class) {
    return new myClass();
}

class Foo {}

generateMyClass(Foo); // Should work
generateMyClass('something else'); // should NOT work

Currently, the closest we have is
type Instantiable = {new(...args: any[]): any};

function doSomethingWithMyClass(myClass: Instantiable ) {
    // some code that doesn't matter
}

class Foo {}
abstract class Bar {}

doSomethingWithMyClass(Foo); // It works :)
doSomethingWithMyClass('something else' ); // It doesn't work and it's OK
doSomethingWithMyClass(Bar); // It doesn't work and it's NOT OK

It is of course logical that the abstract class causes an error with the code above, this is why it could be nice to have something to handle this case.
To go further, we can think about adding some genericity on it.
// With the actual implementation
type Instantiable<T = any> = {new(...args: any[]): T};
function foo<T>(myClass: Instantiable<T>): T { /* ... */ }

// With the new class type hint
function foo<T>(myClass: class<T>): T { /* ... */ }

We can actually get a little bit closer than this, but it's still lacking.
type Abstract<T> = Function & {prototype: T};
type Constructor<T> = new (...args: any[]) => T;
type Class<T> = Abstract<T> | Constructor<T>;

This can work okay for some APIs, but also accepts functions, as their prototype has type any. The type is also not considered constructable, so we can't extend from an object of type Class<T>.
I've actually just found another trick playing around with this now. I haven't seen this anywhere before, I don't know if this really works in the general case, would be nice to get some feedback.
abstract class EmptyAbstractClass {}
type Class<T = {}> = typeof EmptyAbstractClass & {prototype: T};

This seems to work nicely.
abstract class Foo {}
class Bar extends Foo {}
function foo<T>(C: Class<T>) {} // Accepts any class

foo(Foo); // Works as it should
foo(Bar); // Works as it should
foo(class{}); // Works as it should
foo(function(){}); // Fails as it should

And you can restrict the types of the class just fine.
abstract class Base { isBase = true; }
class Child extends Base {}
function bar<T extends Base>(C: Class<T>) {} // Accepts any class that extends Base

bar(Base); // Works as it should
bar(Child); // Works as it should
bar(class{}); // Fails as it should
bar(function(){}); // Fails as it should

Class<T> is considered a constructable type, so we can extend from it.
function makeDerived(C: Class<{}>) {
    return class extends C {};
}

However, this doesn't quite seem to work generically. This complains that type 'makeDerivedGeneric<any>.(Anonymous class)' is not assignable to type 'T'. I'm not completely sure what's going on here, or why TS can't tell that the anonymous class type extends T. Adding generic constraints doesn't seem to help.
function makeDerivedGeneric<T>(C: Class<T>) {
    return class extends C {};
}

All this is in 2.4.2.

There's an issue with @TheOtherSamP 's example: arrays.
Example
class Foo{
    public bar: string;
}
getData<T>(clazz: Class<T>):T{
    //Whatever implementation, the signature is the problem.
}

const instance: Foo = getData<Foo>(Foo);// Works as it should.
const array1: Foo[] = getData<Foo[]>(Foo);// Fails because Foo is not Foo[]'s class.
const array2: Foo[] = getData<Array<Foo>>(Array<Foo>);// Fails because type Foo[] provides no match for the signature 'new (...args: any[]): Foo[]'

@Supamiu
The issue in your example does not come from @TheOtherSamP proposal, it's just that you don't follow your function signature.

@noemi-salaun Yes and that's the issue because there's no valid signature for this type of call.
Actually, there's no type to say 'I want an array of this class', the only way to do this is:
function getArray<T>(clazz: Class<T>): T[]{
    return [].push(new clazz()); //This is a bad implementation bus just giving an example here.
}

// And then we make the call for an explicit 'getArray' function, there's no way to include this in a more generic function.
const array: Foo[] = getArray<Foo>(Foo);

Because Foo[] is a valid type, there should be a way to say 'this is the class of the array type'.
I don't know if this is clear because I'm struggling to explain it.

@Supamiu
I'll just start off by saying that I still support some form of this request. Even if that trick that I found could be made to work for all scenarios, it's a bit of an ugly hack, and hardly something you could expect anyone picking up TS to get intuitively. It's a pretty common scenario, and language support for it would be great.
To be honest, I'm not entirely sure what you're saying with this example. That getArray function looks like the right way to do that to me. I'm not sure that this proposal would allow you to do that in any other way, can you provide an example of how you'd like this to work under the proposal?

Just to clear up what the class type in this proposal would actually do, my understanding is that it basically means any 'constructor function type', that is, any type that it's valid to extend from. Is that your intention @noemi-salaun?

Yes that's it. class, abstract class but not interface or type.

@noemi-salaun That sounds good. I wonder if it would perhaps make sense to express this concept slightly differently. Would allowing the abstract keyword on constructor definitions be a good way to do things?
type AbstractConstructable<T> = abstract new(...args: any[]) => T;

A concrete type would still be valid here, it wouldn't force abstractness, but allow it.
I think this fits fairly nicely with the rest of the language, and allows this to be worked fairly nicely into interfaces. This would also allow you to specify the parameters of the abstract constructor.
More involved example:
export interface FooConstructor {
    abstract new(dependency: number): Foo;
    readonly defaultFoo: Foo;
}

export interface Foo {}

abstract class FooInternal implements Foo {
    static readonly defaultFoo: Foo;
    constructor(dependency: number) {}
}

The point of course being that you could extend from a variable of type FooConstructor.

@TheOtherSamP Sorry for the delay of my answer, I think that the best way to show you an example of what I'm trying to explain is to show you the issue in actual code implementation.
This test : https://github.com/kaiu-lab/serializer/blob/proper-type-matching/test/serializer.spec.ts#L223 is failing to compile because Foo's constructor doesn't return a Foo[].
Error:(233, 16) TS2345:Argument of type 'typeof Foo' is not assignable to parameter of type 'Class<Foo[]>'.
  Type 'typeof Foo' is not assignable to type 'Instantiable<Foo[]>'.
    Type 'Foo' is not assignable to type 'Foo[]'.
      Property 'length' is missing in type 'Foo'.

Here is the signature of the method involved (deserialize):
public deserialize<T>(obj: any, clazz?: Class<T>): T
Where Class<T> is the one you provided in your first comment.
What is missing here is the ability to provide a constructor for an array type, because Array<Foo> doesn't work neither, the error being:
Error:(233, 16) TS2345:Argument of type 'Foo[]' is not assignable to parameter of type 'Class<Foo[]>'.
  Type 'Foo[]' is not assignable to type 'Instantiable<Foo[]>'.
    Type 'Foo[]' provides no match for the signature 'new (...args: any[]): Foo[]'.

If we had such functionality, I'd think about something like Array<Foo> being understood as the Foo[] class, because is this case, we need to know what class to instantiate for each member of the array with the same method we're using for standard objects.
N.B: I'm starting to think that this is a complete different issue... I'll probably check if an issue about this exists and create one if it doesn't.

@SamPruden is there still no workaround for the generic case from your example above:
function makeDerivedGeneric<T>(C: Class<T>) {
    return class extends C {}; // Error here
}

@mshoho as @mhegazy said in https://github.com/Microsoft/TypeScript/issues/8853#issuecomment-224398399

this is behaving as i would expect. you can only extend object types, in other words something that of a known structure. type arguments are not. the extend relationship involves checking that the structure of the derived class matches that of the base. without knowing what is the shape of the base, the compiler can not report these errors.

So it seems that makeDerivedGeneric makes no sense.

TypeScript Version: 2.4.0
It would be interesting to allow type hinting for class type.
Something like
function generateMyClass(myClass: class) {
    return new myClass();
}

class Foo {}

generateMyClass(Foo); // Should work
generateMyClass('something else'); // should NOT work

Currently, the closest we have is
type Instantiable = {new(...args: any[]): any};

function doSomethingWithMyClass(myClass: Instantiable ) {
    // some code that doesn't matter
}

class Foo {}
abstract class Bar {}

doSomethingWithMyClass(Foo); // It works :)
doSomethingWithMyClass('something else' ); // It doesn't work and it's OK
doSomethingWithMyClass(Bar); // It doesn't work and it's NOT OK

It is of course logical that the abstract class causes an error with the code above, this is why it could be nice to have something to handle this case.
To go further, we can think about adding some genericity on it.
// With the actual implementation
type Instantiable<T = any> = {new(...args: any[]): T};
function foo<T>(myClass: Instantiable<T>): T { /* ... */ }

// With the new class type hint
function foo<T>(myClass: class<T>): T { /* ... */ }

Thank you for your post @noemi-salaun! Now I know I need to wait few years to come back to typescript


Chocolatey package

Chocolatey is extremely useful software package manager for Windows. It provides packages for AWS CLI, Kubernetes kubectl, Minikube -- among many others.
It is proposed that AWS IAM Authenticator gets Chocolatey package.

/remove-lifecycle stale


Can we go back to previous activity  directly when the search view is focused?

Hi , when we use the floating search view ,  can we just listen to the left arrow when the view is focused , if we do not want to click the left arrow twice when we want to go back to the previous activity ,  can we do that ?

Hi @cuikangyuan ,
Using this you can listen to when the search View clears focus and then close your activity.

For anyone else left confused by this answer: The referenced method was "setOnFocusChangeListener", one can listen to onFocusCleared() with this method.
Because of recent commits, the referenced line changed and was referencing an unrelated private method at the time of my comment.

@knaeckeKami thanks for pointing that out! I fixed the link.
Regards,


check commands where we have --table

(this is blocked by https://github.com/ploomber/jupysql/issues/518)

there are a few commands that take --table as an argument, however, some of them don't expose a --schema, we need to add it
users might inadvertently pass something like --table schema.table, which should work as well (just like passing --schema schema --table table)

my guess is that the underlying functions already expose a schema argument so it's just exposing --schema and then passing it to the underlying function. but we'll have to check

Acceptance Criteria

Ensure %sqlcmd arguments that take --table also accepts --schema
For those arguments, ensure --table schema.table also works
Add test function
Modify documentation


NEFT noise alpha request

Good evening is possible to add NEFT noise alpha for better performance?

Open

Open

Open

Open

Open!


Implement contributors graph

Continuation of https://github.com/go-gitea/gitea/pull/25439.

Did some layout fixes in https://github.com/go-gitea/gitea/pull/27882/commits/0d08f06c14bac53c3a542631003d0fbd63ca1d00, now looks like this:

Open issues:

I'm incorrectly shown multiple times, it should only show one box per Gitea account.
Colors need adjustment for dark theme.
"Commits" should be a link and spacing needs tweaks.

I'm incorrectly shown multiple times, it should only show one box per Gitea account, not per-email.

I would like to look at this but I am not familiar with the code base that much. If someone can tell me how can I find the Gitea account of a user via email address, I might try to fix it.

I'm incorrectly shown multiple times, it should only show one box per Gitea account, not per-email.

I would like to look at this but I am not familiar with the code base that much. If someone can tell me how can I find the Gitea account of a user via email address, I might try to fix it.

Try https://github.com/go-gitea/gitea/blob/dcb648ee71853073d54e8a6e107b764212ede58e/models/user/user.go#L1115:

It should show one box per Gitea account now.

3. "n Commits" should be a link to user's commits

I actually wanted to implement this too. But I couldn't find an example in Gitea server. In Github, when I click on username on commits page, the url bar turns into something like /commits?author=username and all the commits of that user is shown. I couldn't find something similar to this in Gitea.

I also have another problem. I am editing web_src/js/components/RepoContributors.vue but I don't see my changes when I refresh the page. I'm sure it wasn't like this before. What should I do to see my changes?

@silverwind do you have any idea about this?

I actually wanted to implement this too. But I couldn't find an example in Gitea server. In Github, when I click on username on commits page, the url bar turns into something like /commits?author=username and all the commits of that user is shown. I couldn't find something similar to this in Gitea.

Ah yes it's likely we are missing this filter on backend. Not a requirement then. We can add the link later.

I also have another problem. I am editing web_src/js/components/RepoContributors.vue but I don't see my changes when I refresh the page. I'm sure it wasn't like this before. What should I do to see my changes?

Maybe some stale cache. Try deleting node_modules, some stuff keeps caches in there.

Ah yes it's likely we are missing this filter support on the backend. Not a requirement then. We can add the link later.

I actually figured how to filter it: <repo_url>/commits/branch/main/search?q=author%3A<username> is a link to all commits of a specific user.

Maybe some stale cache. Try deleting node_modules, some stuff keeps caches in there.

It's still same after deleting node_modules :/
Maybe you can add this link and also fix the spacing issue?

Yes, I can add this later I suppose. I plan on tweaking that display anyways.

It should show one box per Gitea account now.

Can confirm, it now only shows me once.

Various enhancements done. Colors are fixed in dark theme and other tweaks:

TODO (help appreciated):

Remove the scoll to zoom interaction, it's weird. It should zoom with click and drag if that's possible.
The plot could be smoothed out a bit to not be so spiky but more "wavy". Not sure what the right term is for this.

Remove the scoll to zoom interaction, it's weird. It should zoom with click and drag if that's possible.

Maybe this helps?

The plot could be smoothed out a bit to not be so "spiky" but more "wavy". Not sure what the right term is for this.

I think you are looking for the tension option. Currently it is set to 0.3 and I think it looks good on both small and big repositories but you can tweak it if you like.

ok @sahinakkaya cache is now in place - you just need to handle the 102 http status responce by make a sleep and retry later again

we might even use a dedicated cache at this point ?!? as we do with repo archives
-> I used the gitea repo to get this result

@6543 how can I reset the cache to test if I am handling http 102 correctly?

Just restart gitea to reset the cache

you are right 102 does invoke a second http call witch is 200. so we can not use that status :/
so I used 216 as it's unused as by the spec for now ... tell me if we should signal it in a different way :)

Wait, wait, wait, what?
I don't think it's a good idea to use status codes in this case.
It sounds like a bad idea to misuse an unintended status code to accomplish what we are trying to do here.
I can guarantee you that in a few months, people will be really surprised that we are expecting an unsupported status code here.
Perhaps always return 200, and handle the response using JS instead?
Either way, something sounds really fishy, if I understand the problem correctly.

This was @6543's idea to handle the problem mentioned at https://github.com/go-gitea/gitea/pull/27882#discussion_r1385869989 . What do you suggest for this @delvh?

Acting based on the response body instead of based on the response status.
Apparently, the code for it exists already as otherwise this problem wouldn't exist in the first place.
So, the only action I presume we need to take on the frontend is changing the if resp.status == 216 to if resp.body.IsLoading, and in the backend switching this return code with the corresponding body.

Maybe we should just make a background task that calculates the data for all repos and stores them in a cache, that way there is no issue with on-demand long-running operation.

Maybe we should just make a background task that calculates the data for all repos and stores them in a cache, that way there is no issue with on-demand long-running operation, and this intermediate status can also be removed.

This is also suggested before by @lunny: https://github.com/go-gitea/gitea/issues/847#issuecomment-452558208
I don't want to do this for 2 reasons:

The PR is already huge. I don't want to complicate it further.
I don't know how cron jobs work in the repo. So we need another volunteer to implement this if we really want it.

Maybe we can do that after merging this PR?

Acting based on the response body instead of based on the response status. Apparently, the code for it exists already as otherwise this problem wouldn't exist in the first place. So, the only action I presume we need to take on the frontend is changing the if resp.status == 216 to if resp.body.IsLoading, and in the backend switching this return code with the corresponding body.

OK, I tried to implement this but the resulting code is really ugly. I think instead of trying to avoid unsupported status code (216) by using response body, we should fix the thing that prevents us using the correct status code (102). I don't think anyone will be surprised when they see 102 because it fits perfectly to the problem we are having here.

102 had unexpected sideefects ...
... did chat about the status-code to signal things
i guess wrapping it up in a dedicated response struct in body is a way to do it

@sahinakkaya you might want to make the VUE code bit better ;)

Can also poll with HEAD requests from client, respond with 102 until done, which then responds with 200 and client does a GET.

Can also poll with GET requests from client, respond with 202 Accepted until done. When done respond with 200 and client does a GET.

Will try this one too.

@yp05327 you know that you can zoom in / out and pan the charts, right?

@yp05327 you know that you can zoom in / out and pan the charts, right?

I know. But it is not easy to get the graph in 1 week or 1 month or 3 months...
You need to move your mouse to the correct place and carefully scroll the mouse wheel to get it.
And if I zoom in too much, there's nothing in the x-axis, maybe we can display the date when the graph is big enough.

And the commit time in the graph above looks like in Oct 10? But the user's graph below looks like in Oct 2.

And if I zoom in too much, there's nothing in the x-axis, maybe we can display the date when the graph is big enough.

It wasn't like this before 36d8e81 but silverwind changed it to its current version. Can't make everyone happy I guess 🤷

It seems that the date range is not the same:

No, I am sure the date range is same. You can confirm by reverting 36d8e81 and checking yourself. Yeah, the charts seem inconsistent but I think such inconsistencies are normal in edge cases. Thank you for the analysis though.

And if I zoom in too much, there's nothing in the x-axis, maybe we can display the date when the graph is big enough.

It wasn't like this before 36d8e81 but silverwind changed it to its current version. Can't make everyone happy I guess 🤷

Never mind. Maybe silverwind will change his mind later  (or not ) That's not important.
I just want to tell the idea. Maybe my idea is wrong, maybe my idea is not good enough.
If it is wrong or not good, that means I can learn more knowledges from others.
So do it or not depends on you and other maintainers who have the permission.I won't be unhappy about this. 😄

Edit: I actually found the reason why they seem inconsistent. The contributor charts are re-rendered with the "selected time range" data on every resize (this is required because we sort them based on selected contribution type on each resize). But the main graph is rendered with "all data" at all times. So the child graphs doesn't know surrounding data and they become sharp.

Actually, there is a way to fix this. We can sort them based on selected time range data as usual but while drawing charts, we can use whole data and programmatically zoom to the selected time range. I don't know if this would affect performance but it should fix inconsistencies between charts. @yp05327 you can try this if you want :)

total commits are 2, but the max is 1.0

max_contribution_type is correct, it seems that the graph has some problems.

Edit: I actually found the reason why they seem inconsistent. The contributor charts are re-rendered with the "selected time range" data on every resize (this is required because we sort them based on selected contribution type on each resize). But the main graph is rendered with "all data" at all times. So the child graphs doesn't know surrounding data and they become sharp.

Actually, there is a way to fix this. We can sort them based on selected time range data as usual but while drawing charts, we can use whole data and programmatically zoom to the selected time range. I don't know if this would affect performance but it should fix inconsistencies between charts. @yp05327 you can try this if you want :)

I have done my changes.
But I have no permission to push commits directly to PR, so I will add some suggestions later. 😕
After:

I have done my changes.
But I have no permission to push commits directly to PR, so I will add some suggestions later. 😕

You can open a PR in my repo. @hiifong did something similar in the past. Take a look at their PR.

Thanks to @yp05327's contributions, we now have:

more consistent charts (see https://github.com/go-gitea/gitea/pull/27882#issuecomment-1809761277 and quoted comment for the problem)
better looking avatars (rounded corners just like in other places in Gitea)
double click to reset zoom instead of single click (as some of you people requested)

as per https://github.com/go-gitea/gitea/pull/28112
would you update the pull description and add a nice up-to-date screenshot :)

would you update the pull description and add a nice up-to-date screenshot :)

I've added a screenshot and description. Description is mostly taken from #25439 and modified to reflect current version. Let me know if you need anything else.

BTW, chartjs has built-in support for drag-selection zooming it seems:
https://www.chartjs.org/chartjs-plugin-zoom/latest/samples/drag/time.html

BTW, chartjs has built-in support for drag-selection zooming it seems:
https://www.chartjs.org/chartjs-plugin-zoom/latest/samples/drag/time.html

Wow, I didn't know drag to zoom was this easy. I will change it and add instructions on how to use it.

Thanks, please get rid of chartjs-plugin-zoom in turn. I think the drag area may need some color fixes, I can do that afterwards.

get rid of chartjs-plugin-zoom in turn.

Uhhm... The link you posted is includes chartjs-plugin-zoom feature?

We have now something like this:

I don't like area that title occupies but couldn't find a way to get rid of it. If it can be overlayed on top of chart that would be perfect.

Changed it to this:

Internal Server Error

Merge PR into the main branch and compile it

Internal Server Error

I can't reproduce this on my side. Clone my repo and merge contributors-graph into main if you want to make sure everything is same.

Merged main into this once more, so if it reproduces only on merge, it will reproduce on this branch now.

Can someone run make generate-swagger and commit the result? compliance / checks-backend is failing because of this but I don't see any change when I run that command on my computer.

The gitea binary file is compiled from the current pr, and the contributors page also displays internal server error.

@hiifong  Did you restart the Gitea server as I said?

@hiifong Did you restart the Gitea server as I said?

I've tried restarting gitea many times, but it still doesn't work.

I've tried restarting gitea many times, but it still doesn't work.

Does it happen on other repositories? If not, can I see which repository it doesn't work specifically?

I've tried restarting gitea many times, but it still doesn't work.

Does it happen on other repositories? If not, can I see which repository it doesn't work specifically?

All repos are like this

I am sorry, I can't help because it works on my machine ¯\_(ツ)_/¯

Let me check

Maybe it is better to print out the unexcepted type in the log.

It's already printed in https://github.com/go-gitea/gitea/pull/27882#issuecomment-1818997552

It's already printed in #27882 (comment)

I mean what is this unexcepted type, as this information may help us detect the problem.

Let me check

Did you find any issue? I don't think the error hiifong facing is reproducible.

Let me check

Did you find any issue?   We probably need to handle that case as well. I will give that a try but I'm not sure if I can pull it off.

ctx.Cache can be nil when setting.CacheService.Enabled is false. So we should check it in GetContributorStats.

ctx.Cache can be nil when setting.CacheService.Enabled is false. So we should check it in GetContributorStats and generateContributorStats.

Instead of checking the "cache disabled" again and again, it needs a framework-level support:

https://github.com/go-gitea/gitea/pull/19708#issuecomment-1126904397

ctx.Cache can be nil when setting.CacheService.Enabled is false. So we should check it in GetContributorStats and generateContributorStats.

Instead of checking the "cache disabled" again and again, it needs a framework-level support:
* [Use noCache when cache disabled #19708 (comment)](https://github.com/go-gitea/gitea/pull/19708#issuecomment-1126904397)

Do you think we can also remove the enabled for lastcommit cache as well?

I didn't even know you could disable caching. We probably need to handle that case as well. I will give that a try but I'm not sure if I can pull it off.

Well, I still didn't have a chance to look at this. I don't have much time these days and I probably won't have any time for at least a month. If someone wants to continue feel free to do so.

Happy new years everyone! :partying_face: I realized it has been nearly 6 months since I opened this PR. And I decided I don't want to celebrate 1st year anniversary of it :smile: I want you to kindly work with me here and review and report the issues you want to be resolved. I will try to look into cache related problem mentioned above. Any ideas on how to proceed on that will also greatly appreciated.
I will also mention the maintainers who reviewed other PR before it was accidentally closed: @lunny @yardenshoham

Count me in as well, this PR is also on my TODO list before 1.22

However, I don't know if I'll be able to review within the next month

Happy new years everyone! 🥳 I realized it has been nearly 6 months since I opened this PR. And I decided I don't want to celebrate 1st year anniversary of it 😄 I want you to kindly work with me here and review and report the issues you want to be resolved. I will try to look into cache related problem mentioned above. Any ideas on how to proceed on that will also greatly appreciated.
I will also mention the maintainers who reviewed other PR before it was accidentally closed: @lunny @yardenshoham

Happy new year too! Please fix the lint error. I will review it again.

Please fix the lint error. I will review it again.

That error is related with swagger. Whenever I run make generate-swagger on my computer, it adds (or removes, don't remember atm) one extra line to swagger file which causes that error. Maybe the version of linter is different or some misconfiguration on my end, I don't know.
Anyway, I run make generate-swagger 10 minutes ago and it is still running :/ There is definitely a problem on my side so I think it would be better if someone else fixes that error.

❯ make generate-swagger
make: Nothing to be done for 'generate-swagger'.

:man_shrugging:

ctx.Cache can be nil when setting.CacheService.Enabled is false. So we should check it in GetContributorStats and generateContributorStats.

How can I disable caching so that I can look into this issue? I looked at /custom/conf/app.ini file but there were no cache related setting. How do I disable it?

I just realized another problem. Previously avatars were shown like this:

But now, I can't see them on my computer:

Relevant comment is here: https://github.com/go-gitea/gitea/pull/27882#discussion_r1387615793
Any idea on why it might be broken? Is there a recent change in upstream that changes how avatars are generated? Or is it only broken on my computer?

Is there a recent change in upstream that changes how avatars are generated?

It looks like it is because #28548 but I am not quite sure. I've changed OFFLINE_MODE = false in /custom/conf/app.ini but I still can't see avatars. Maybe I need to reinstall, idk.

ctx.Cache can be nil when setting.CacheService.Enabled is false. So we should check it in GetContributorStats and generateContributorStats.

How can I disable caching so that I can look into this issue? I looked at /custom/conf/app.ini file but there were no cache related setting. How do I disable it?
And I wonder is this cache issue still relevant or it will be solved with #27882 (comment) in future?

Cache cannot be disabled from 1.22.

Is there a recent change in upstream that changes how avatars are generated?

It looks like it is because #28548 but I am not quite sure. I've changed OFFLINE_MODE = false in /custom/conf/app.ini but I still can't see avatars. Maybe I need to reinstall, idk.

I can see the right avatar but the avatar link is not right.

I can see the right avatar but the avatar link is not right.

Uhm, can you share a screenshot?

Cache cannot be disabled from 1.22.

Ok, so that means I don't have anything to fix other than the change requests coming from reviews.

some avatars is incorrect

It seems that the codes above is a copy from here:

Does this also have issues?

It seems that the codes above is a copy from here:

Yes, you are right. In my local, the situation is like this: https://github.com/go-gitea/gitea/pull/27882#issuecomment-1909969193

Does this also have issues?

That piece of code is responsible for Activity page. In my PR it is converted to Pulse page. Can you check and see if it does have the same problem? I guess the avatars won't look correct on that page either.
Also, what does your suggested changes fix?

except #27882 (comment)

@lunny Just to be sure, are you referring to the avatar issue or cache issue?

except #27882 (comment)

@lunny Just to be sure, are you referring to the avatar issue or cache issue?

My concern is the avatar link is wrong.

I've applied suggested changes. Can you check if it works correctly now?

Confirmed that the activity page also has this issue. Should we fix this in another PR?

I think we should be able to assume that the root url is set correctly, after all that's the reason why it exists.

It seems that AvatarLink is used for API, as it will return the full avatar link with http host, and AvatarLinkWithSize is used for web UI, as it will not contain http host.

Confirmed that the activity page also has this issue

I am not surprised. I actually can't reproduce this issue on my computer. You said

avatars is incorrect when ROOT_URL is not matching the site visiting.

How is that even possible? And if ROOT_URL is wrong, isn't that signify a bigger problem?
Also, does it work after the latest commit @yp05327 ?

I don't think avatar issue is related with this PR. Here is proof:
If you are observing avatars are broken, I suggest you to check out to main branch of upstream and observe that the avatars are still broken on Activity page.
If this problem concerns you, it should be fixed with another PR as yp05327 suggested.

My concern is the avatar link is wrong.

@lunny
http://host/suburl/avatar/xxxx
/avatar/xxxxx
Which one is the correct avatar link we should use here?

I mean, the link of the name is blank.

I mean, the link of the name is blank.

It is expected behaviour when that user is not present on the server. Try it with another user whom have a registered account.

I mean, the link of the name is blank.

@lunny It is expected behaviour when that user is not present on the server. Try it with another user whom have a registered account.

If it's not in the server. Don't put a tag there?

As far as I remember, if I don't put an a tag, it would format it differently and would be ugly.
I am not on computer right now so I can't test it. Will try it again when I am available.

Maybe show a tooltip that the user does not have an account on this instance?

I rendered p or a tag but as I said, it looks ugly to me. p tag is not correctly aligned vertically and its font is probably different size than a tag and obviously has a different color.

Maybe show a tooltip that the user does not have an account on this instance?

I am not positive about this. If it needs to be changed, it should be consistent with the /commits page. There is no tooltip shown for unregistered users.

I don't think a different colour is a problem, and alignment can surely be fixed with 1-2 lines of css

Fixed with e52db02

I'm looking to merge this soon. Some lint errors need to be fixed and hopefully we can resolve the remaining discussions.

Omg it looks seriously broken after merging upstream. I will look into this soon

Can I kindly ask why is this still not merged? I can't wait to finally use it in my server.

I thought after having 2 LGTM's it is OK to merge. @6543 said he could "perhaps" look into adding test cases and it was more than a week ago. I doubt if he is still interested.

give me some time ... firt i attend FOSDEM now i was in the hospital - doing coding is kinda hard - i focused on reviews and comments ...

@6543 what do you suggest instead?

while writing the test, i had a look how the data is serialized.
basicly there is a start and endtime calculated, and then for each week in between there is the unix timestamp calculated ans saved in a slice.
now for each unique contributor there is a map generated with contains the amount of structs the mentioned slice contains with mostly just empty changes e.g. the contributor did nothing in this week ...
we should at leaset skip that empty information and if we dont have a datapoint the webUI should asume there was just nothing

also we calculate a "total" user witch contains this information kind a reduntant - is this real needed or does the WebUI can calc that more efficiently?

I created an initial test, the backendlogic can be tested and corrected against.
I also added some codecoments to be solved.
as of the frontend, it shuld not relay on empty weeks to draw graphs, in the worst case generate them on the frontend??!?

@sahinakkaya sorry that this will take bit longer ... I still think your contribution is of great value.
But I personaly dont want to merge it in this state, as it would have great resource usage with mostly doing things that can be avoided

Why Sundays for the week start or am I reading something wrong?

Why Sundays for the week start or am I reading something wrong?

well thats right - I personaly dont mind as you need to cut the dates into buckets ... and using this date dont hurt. but any other should be as much suficient as a sunday

But why not use something more standard as Monday, pretty much only 3 countries in the world uses Sundays as week start so to me that seems weird choice

But why not use something more standard as Monday, pretty much only 3 countries in the world uses Sundays as week start so to me that seems weird choice

17 countries start the week on Sunday (USA,Canada, India, Pakistan...) But ISO 8601 states that Monday is the start

Why Sundays for the week start or am I reading something wrong?

Yes, you are interpreting it incorrectly. I explained it here: https://github.com/go-gitea/gitea/pull/27882#discussion_r1466513564
Basically, it could be any other day other than sunday and it would make absolutely ZERO difference.It is just a matter of choice and I choosed Sunday, even though my country uses Monday as start of the week.

@6543 I understand your objections. Actually, I was aware of them but since no one mentioned about them, I thought I better left them to be fixed in another PR. So thank you for bringing that up (in half serious half sarcastic way :D). I think it should be easy to fix for someone who knows go and some frontend. I will try when I've some time.
I was rushing because I wanted to get this merged before 1.22 enters feature freeze. I don't know if we have enough time now.

Well depending on how long it will take we can maybe delay feature freeze a bit for such a big PR

That's great. I will start and let you know how much time is required asap.

I created an initial test, the backend logic can be tested and corrected against

make test-backend takes a lot of time. Can I just run the specific test cases? If so, how?
Also, make test-backend command fails on some test cases even though I didn't change anything. How should I run these tests?

Unit tests are failing after your changes @6543. I guess this is not expected.

also we calculate a "total" user witch contains this information kind a reduntant - is this real needed or does the WebUI can calc that more efficiently?

Yeah, it can also be calculated on the frontend. But I think it is better if we do it in backend because it might be useful in future. (I am planning to open another PR for "Code frequency" page. It will contain duplicate code if we calculate 'total' in frontend)

I will start working on it and let you know how much time is required asap.

Good news: 75% of the work is finished. I am planning to push my changes late today or tomorrow. It is much more efficient now! 🥳

It is much more efficient now!

I am not kidding. It is real! It is unbelievable that these two are doing the same thing lol :D
Before:

After:

Thanks @6543 for insisting to fix this.

it also uses less cache that way - thanks ;)

Why Sundays for the week start or am I reading something wrong?

Yes, you are interpreting it incorrectly. I explained it here: #27882 (comment)
Basically, it could be any other day other than sunday and it would make absolutely ZERO difference. It is just a matter of choice and I choosed Sunday, even though my country uses Monday as start of the week.
Edit: sorry if this sound a bit rude. It is just that I am tired to answer the same question third time. There is nothing personal ^^ @lafriks

User's preferred start day of week can be determined in JS with this API in most browsers, but I see the logic is in backend so not so simple and definitely not a blocker.

There is a odd non-critical eslint error, I'm trying to fix that and am taking another look at the JS.
https://github.com/go-gitea/gitea/actions/runs/7889881019/job/21530794112?pr=27882#step:5:7

I don't say that it should be per user but just that Monday would be way more logical choice

I don't say that it should be per user but just that Monday would be way more logical choice

Living in a Monday-first region, I tend to agree, if it's not too hard. But I wont block on it.

09d5d27 is probably breaking my code. It should not generate sundays (or start dates) based on user's local time zone because sometimes some countries change their clock and this will cause all the generated timestamps to be shifted. Then, it won't match the timestamps generated from backend, and will result in empty spaces in graphs:

I will mark as 'ready for review' again once I fix this.

sometimes

Hmm I did carefully check that the function's output is the same before and after the change, are you sure?

Hmm I did carefully check that the function's output is the same before and after the change, are you sure?

yeah, I am sure. It might have worked because maybe in your country, you don't advance clocks to save day time. Here is what I am talking about: https://en.wikipedia.org/wiki/Daylight_saving_time

Okay, sorry for that. I will add a unit test to the function in a bit.

Okay, sorry for that. I will add a unit test to the function in a bit. The comment you added seems a bit hostile, and I think instead of such comments, we should just have proper unit tests that confirm the functionality.

No, I didn't want to be mean. I am sorry if it sounds like that. As most of the people here, english is not my main language so I guess that's the problem. I didn't want to offend anyone in any comment of mine.
Yes, a unit test might be good :+1:

Yes I will add it. It's likely a good use case for a snapshot test.

I moved the code and added a simple test. As I understand it, that test should suceed when ran in every time zone because start and end day are Thursdays.

I moved the three functions and added a simple test. As I understand it, that test should succeed when ran in every time zone because start and end day are Thursdays.

Nope, testing against thursdays is not different from testing against sundays. Backend code generates timestamps with UTC+0 and it will never advance clock for 1 hour. (i.e. There will be always 168 hours between two consecutive sundays, or tuesdays or thursdays etc.) But some countries advance their clock for 1 hour at certain times of the year. That means sometimes there will be 167 or 169 hours between two consecutive sundays, tuesdays or thursdays etc. Frontend code knows about this change because it uses local time zone to process date related things. So it won't match timestamps generated from backend on some countries if you just say list all sundays with time 00.00
That's why adding 7*24 hours instead of 1 week works.
This is the best way I could explain. I hope it is clear.

I think you misunderstood. I mean time when tests run can vary 24h between time zones and such issues are very common with unit tests that involve time often to the point that one has to "freeze" time for tests to get stable results. By using thursday, a timestamp can only shift by at most 24h into, so it won't shift into the next or previous week :)

Let's merge this in the next 24h. I think it's good enough and the change to Monday can follow separately.

@sahinakkaya thanks for you work and also for your persistance 👍.

Thank you everyone who contributed by their comments, reviews, and suggestions. I learned a lot in this process. And hey, we have a lovely contributors page now! :partying_face: :tada:


Failed to load the merge-conflicts package

[Enter steps to reproduce below:]

start atom

Atom Version: 1.7.2
System: Mac OS X 10.11.4
Thrown From: merge-conflicts package, v1.4.2
Stack Trace
Failed to load the merge-conflicts package
At Cannot find module 'property-accessors'

Error: Cannot find module 'property-accessors'
    at Module._resolveFilename (module.js:338:15)
    at Function.Module._resolveFilename (/Applications/Atom.app/Contents/Resources/app.asar/src/module-cache.js:383:52)
    at Function.Module._load (module.js:289:25)
    at Module.require (module.js:366:17)
    at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:50:27)
    at Object.<anonymous> (/Users/mriesterer/.atom/packages/merge-conflicts/node_modules/space-pen/node_modules/grim/node_modules/emissary/lib/behavior.js:9:23)
    at Object.<anonymous> (/Users/mriesterer/.atom/packages/merge-conflicts/node_modules/space-pen/node_modules/grim/node_modules/emissary/lib/behavior.js:120:4)
    at Module._compile (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:103:30)
    at Object.defineProperty.value [as .js] (/Applications/Atom.app/Contents/Resources/app.asar/src/compile-cache.js:208:21)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:313:12)
    at Module.require (module.js:366:17)
    at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:50:27)
    at Object.<anonymous> (/Users/mriesterer/.atom/packages/merge-conflicts/node_modules/space-pen/node_modules/grim/node_modules/emissary/lib/helpers.js:5:14)
    at Object.<anonymous> (/Users/mriesterer/.atom/packages/merge-conflicts/node_modules/space-pen/node_modules/grim/node_modules/emissary/lib/helpers.js:55:4)
    at Module._compile (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:103:30)
    at Object.defineProperty.value [as .js] (/Applications/Atom.app/Contents/Resources/app.asar/src/compile-cache.js:208:21)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:313:12)
    at Module.require (module.js:366:17)
    at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:50:27)
    at Object.<anonymous> (/Users/mriesterer/.atom/packages/merge-conflicts/node_modules/space-pen/node_modules/grim/node_modules/emissary/lib/emissary.js:4:13)
    at Object.<anonymous> (/Users/mriesterer/.atom/packages/merge-conflicts/node_modules/space-pen/node_modules/grim/node_modules/emissary/lib/emissary.js:14:4)
    at Module._compile (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:103:30)
    at Object.defineProperty.value [as .js] (/Applications/Atom.app/Contents/Resources/app.asar/src/compile-cache.js:208:21)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:313:12)
    at Module.require (module.js:366:17)
    at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:50:27)
    at Object.<anonymous> (/Users/mriesterer/.atom/packages/merge-conflicts/node_modules/space-pen/node_modules/grim/lib/grim.js:4:13)

Commands

Config
{
  "core": {
    "audioBeep": false,
    "disabledPackages": [
      "language-gfm"
    ],
    "followSymlinks": false,
    "projectHome": "/Users/mriesterer/workspace",
    "themes": [
      "one-light-ui",
      "one-light-syntax"
    ]
  }
}

Installed Packages
# User
angularjs, v0.3.4
autocomplete-angular-material, v0.4.0
autocomplete-python, v1.7.2
editorconfig, v1.4.1
hyperclick, vundefined
language-ansible, v0.1.3
language-docker, v1.1.6
language-markdown, v0.12.0
language-puppet, v0.19.1
merge-conflicts, v1.4.2

# Dev
No dev packages

I'm getting this related issue:

Startup Atom.

Atom Version: 1.0.11
System: Ubuntu 12.04.4
Thrown From: merge-conflicts package, v1.4.2
Stack Trace
Failed to load the merge-conflicts package
At /home/jeahm/.atom/packages/merge-conflicts/lib/git/shellout.js:15
    .then((results) => {
                    ^^
Unexpected token =>

/home/jeahm/.atom/packages/merge-conflicts/lib/git/shellout.js:15
    .then((results) => {
                    ^^
SyntaxError: Unexpected token =>
  at exports.runInThisContext (vm.js:53:16)
  at Module._compile (module.js:435:25)
  at Object.defineProperty.value [as .js] (/opt/atom/resources/app.asar/src/compile-cache.js:169:21)
  at Module.load (module.js:347:32)
  at Function.Module._load (module.js:302:12)
  at Module.require (module.js:357:17)
  at require (module.js:376:17)
  at Object.<anonymous> (/home/jeahm/.atom/packages/merge-conflicts/lib/git/index.js:10:20)
  at Module._compile (module.js:452:26)
  at Object.defineProperty.value [as .js] (/opt/atom/resources/app.asar/src/compile-cache.js:169:21)
  at Module.load (module.js:347:32)
  at Function.Module._load (module.js:302:12)
  at Module.require (module.js:357:17)
  at require (module.js:376:17)
  at Object.<anonymous> (/home/jeahm/.atom/packages/merge-conflicts/lib/main.coffee:4:12)
  at Object.<anonymous> (/home/jeahm/.atom/packages/merge-conflicts/lib/main.coffee:1:1)
  at Module._compile (module.js:452:26)
  at Object.defineProperty.value [as .coffee] (/opt/atom/resources/app.asar/src/compile-cache.js:169:21)
  at Module.load (module.js:347:32)
  at Function.Module._load (module.js:302:12)
  at Module.require (module.js:357:17)
  at require (module.js:376:17)
  at Package.module.exports.Package.requireMainModule (/opt/atom/resources/app.asar/src/package.js:759:34)
  at /opt/atom/resources/app.asar/src/package.js:190:28
  at Package.module.exports.Package.measure (/opt/atom/resources/app.asar/src/package.js:167:15)
  at Package.module.exports.Package.load (/opt/atom/resources/app.asar/src/package.js:181:12)
  at PackageManager.module.exports.PackageManager.loadPackage (/opt/atom/resources/app.asar/src/package-manager.js:405:14)
  at PackageManager.module.exports.PackageManager.loadPackages (/opt/atom/resources/app.asar/src/package-manager.js:369:14)
  at Atom.module.exports.Atom.startEditorWindow (/opt/atom/resources/app.asar/src/atom.js:667:21)
  at Object.<anonymous> (/opt/atom/resources/app.asar/src/window-bootstrap.js:12:8)
  at Object.<anonymous> (/opt/atom/resources/app.asar/src/window-bootstrap.js:23:4)
  at Module._compile (module.js:452:26)
  at Object.defineProperty.value [as .js] (/opt/atom/resources/app.asar/src/compile-cache.js:169:21)
  at Module.load (module.js:347:32)
  at Function.Module._load (module.js:302:12)
  at Module.require (module.js:357:17)
  at require (module.js:376:17)
  at setupWindow (file:///opt/atom/resources/app.asar/static/index.js:82:25)
  at window.onload (file:///opt/atom/resources/app.asar/static/index.js:35:9)

Commands

Config
{
  "core": {
    "disabledPackages": [
      "php-getters-setters",
      "line-ending-selector",
      "linter-scss-lint",
      "linter-eslint",
      "php-debug",
      "phpunit",
      "autoclose-html"
    ],
    "packagesWithKeymapsDisabled": []
  }
}

Installed Packages
# User
atom-text-transformer, v0.7.0
auto-detect-indentation, v1.0.0
auto-indent, v0.5.0
autocomplete-php, v0.3.7
docblockr, v0.7.3
docs-snippets, v0.8.0
exception-reporting, v0.38.1
html-entities, v0.4.0
indentation-indicator, v0.6.0
line-ending-converter, v1.3.2
linter, v1.11.4
linter-bootlint, v1.0.2
linter-coffeelint, v1.1.2
linter-csslint, v1.3.2
linter-htmlhint, v1.1.4
linter-pep8, v1.2.1
linter-php, v1.2.0
linter-phpcs, v1.3.2
linter-shellcheck, v1.2.0
linter-xmllint, v1.3.4
merge-conflicts, v1.4.2
metrics, v0.53.1
minimap, v4.23.1
pigments, v0.26.0
sync-settings, v0.7.2

# Dev
No dev packages

@MattRiesterer: That looks like a partial or corrupted install. Try apm uninstall merge-conflicts && apm install merge-conflicts at a terminal to reinstall from scratch.
@nelson6e65: That's a different problem: your Atom is too far out of date! The Chromium build with native arrow function support was included a while ago, but more recently than 1.0.11. Try installing the latest Atom build.

@smashwilson Yes, I know. But I'm using Ubuntu x86, so there is not .deb available in order to update Atom (Or there is it?).
I installed Atom time ago from some kind of PPA repo, but it's outdated (like everything in Ubuntu).
I don't like Ubuntu, because all it's a problem to compile everything and I'm not able to build Atom myself in this machine.
There is not a version of this package compatible with this Atom that I could install?

You could try backporting to v1.3.7 - that was the last release before I started working in natively-supported ES2015. I think that's just:
apm uninstall merge-conflicts
apm install<EMAIL_ADDRESS>

Thank you! It's working.
This is a nice package! :smile:

This is a nice package! :smile:

Thanks!

But I'm using Ubuntu x86, so there is not .deb available in order to update Atom (Or there is it?).

Hmm, yeah, I only see an amd64 .deb on the releases page. Unfortunately, I suspect that's because Chromium itself dropped 32-bit support a while ago...

Neither .rpm for Fedora x86. But in my own PC I can build Atom for 32-bit easily in fedora. Actually, I made a build helper for Fedora.

@smashwilson you were right with the corrupted install. After reinstalling everything works fine. This fixes the issue for me.
Thank you

Fantastic! Glad to hear it. :tada:


Error handling and response schemas

I'm trying to get started building Apigee-127 proxies, but I'm having trouble figuring out how to map to response types defined by swagger, especially for error cases.
For example, take the "hello world" template code that is created when you do a127 project create <name>, and make a single change: make the ?name= query string parameter required.
If you do provide a valid name, the example project doesn't return a JSON structure I'd expect based on the HelloWorldResponse in the swagger.yaml. We just get a string saying "Hello, John" instead of {"message": "Hello, John"}. That can be easily fixed by updating the controller code, though it seems I have to personally ensure that my response body matches the swagger definition.
But if you don't provide a name, the swagger middleware throws a validation error (we made it a required value) and the controller isn't called. The end result does not match the ErrorResponse type defined in the swagger.yaml.
How is this meant to be handled? Is there something built into Apigee-127 for helping developers map to the swagger-defined responses?
I read this StackOverflow post and issue #37 but they only talked about the HTTP status code, not the response body.
I know I can create a middleware error handler in the app.js file (something like app.use(function(err, req, res, next) {...}); and I see that I can get info from the req.swagger object... But it seems like there's still a lot of work I'd have to do to determine how to map the error to the appropriate JSON body. And it could get much more complicated as I add additional routes since there is only one error handler.
It would be nice if the tooling helped out here somehow. Maybe transform errors into the default response types? Or allow controllers to define an error handler (or validationErrorHandler) which the swagger middleware could call? Or am I just missing something?

Have you given this any more thought, assuming you're still using swagger-tools?  The only thing I can think of would be very brittle and it would require you to set res.statusCode prior to flagging the error.  Either that or I expose an API to get the response for a given status code and then use that to help you out.


Add intermediate cert to P12 chain if ca.crt is empty

If ACME (or any other that has no CA.crt) issues an intermediate certificate it is dropped from our pkcs12 keystore.
This was due to the logic being inside an if statement that checked the CA.crt secret.
Fixes #3039
Supplants: https://github.com/jetstack/cert-manager/pull/3146
Release note:
Fix issue where intermediate certificates are not in the pkcs12 keystore

/approve
/lgtm

/kind bug


feat(data-table): add select component to data-table

Select works within Data Table, added examples, zebra theme

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots:
Before (If applicable):

After:

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation update
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

Checklist:

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

agree with Ben, love all the examples, I am wondering if the test cases need a bit more though

Will be adding the site examples to this PR.


feat!: Add support for setOnInfoWindowLongClickListener() for Markers

As mentioned in #750, we currently support clicking on info windows for markers in the library, but not long clicking. This PR implements long clicking as well.
BREAKING CHANGE: Note that this could be considered a breaking change because ClusterRenderer is a public interface and may be used outside of the library if apps implemented their own renderer. Also, if apps were doing map.setOnInfoWindowLongClickListener() on their own this implementation will break that behavior and force them to use the collection info window long click listener, similar to how info window click listeners are currently handled (see the Migration Guide).
I've tested this in the demo app with:
        mClusterManager.getMarkerCollection().setOnInfoWindowLongClickListener(marker ->
                Toast.makeText(ClusteringDemoActivity.this,
                        "Info window long pressed.",
                        Toast.LENGTH_SHORT).show());

...and it works, although I can't add the above code in a PR until this is released and we bump the demo app version.

Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

[x] Make sure to open a GitHub issue as a bug/feature request before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
[x] Ensure the tests and linter pass
[ ] Code coverage does not decrease (if any source code was changed)
[x] Appropriate docs were updated (if necessary)
[x] Will this cause breaking changes to existing Java or Kotlin integrations? If so, ensure the commit has a BREAKING CHANGE footer so when this change is integrated a major version update is triggered. See: https://www.conventionalcommits.org/en/v1.0.0/

Fixes #750 🦕

All Connected........(NameTown or city That )


reporter html is generated each 1mn.

I want to display the report only one time for all my tests.

Here is the same problem.I have the same pathBuilder as in example and my test are working more than 1 minute, reporter generates more folders with reports.
I want to make one folder with minute I have start the tests.


[PowerShell] Update to 7.0.1

PowerShell Update to 7.0.1
nuget Update to v5.6.0
7-Zip Update to 19.0.0

gmp:x64-windows=fail to C:\agent\_work\1\s\scripts\ci.baseline.txt.

REGRESSION: boost-atomic:arm-uwp. If expected, add boost-atomic:arm-uwp=fail to C:\agent\_work\1\s\scripts\ci.baseline.txt.
REGRESSION: boost-signals:arm-uwp. If expected, add boost-signals:arm-uwp=fail to C:\agent\_work\1\s\scripts\ci.baseline.txt.

REGRESSION: boost-exception:arm-uwp. If expected, add boost-exception:arm-uwp=fail to C:\agent\_work\1\s\scripts\ci.baseline.txt.

REGRESSION: boost-regex:arm-uwp. If expected, add boost-regex:arm-uwp=fail to C:\agent\_work\1\s\scripts\ci.baseline.txt.

REGRESSION: boost-nowide:arm-uwp. If expected, add boost-nowide:arm-uwp=fail to C:\agent\_work\1\s\scripts\ci.baseline.txt.

REGRESSION: boost-system:arm-uwp. If expected, add boost-system:arm-uwp=fail to C:\agent\_work\1\s\scripts\ci.baseline.txt.

REGRESSION: boost-container:arm-uwp. If expected, add boost-container:arm-uwp=fail to C:\agent\_work\1\s\scripts\ci.baseline.txt

more

pdal:x86-windows=fail
libmikmod:x86-windows=fail
gmp:x86-windows=fail
gsoap:x86-windows=fail
gmp:x64-windows=fail
seal:arm64-windows=fail
boost-stacktrace:arm64-windows=fail
boost-exception:arm64-windows=fail
boost-regex:arm64-windows=fail
boost-signals:arm64-windows=fail
boost-system:arm64-windows=fail
boost-container:arm64-windows=fail
quickfix:arm64-windows=fail
boost-atomic:arm64-windows=fail
libfabric:x64-windows-static=fail
zxing-cpp:x64-windows-static=fail
mpg123:x64-windows-static=fail

Regressions related to #11502.


concourse: update postgresql exporter colocated database

Please remove all the lines starting with '>'
Hi there! Thanks for submitting a pull request to the Concourse Helm chart!
If you haven't already, please take a look at our Code of Conduct.

To help us review your PR, please fill in the following information.
Feel free to delete any sections not applicable to your pull request.

Existing Issue

Is there an existing issue related to this PR? Fill in the issue number as follows: Fixes #1234.

Fixes # .
Why do we need this PR?

No issue number? Please give us a few lines of context describing the need for this PR.

Changes proposed in this pull request

What are the changes included in this PR? Feel free to add as many lines as needed below.

Contributor Checklist

Are the following items included as part of this PR? Please delete checkbox items that don't apply.

[ ] Variables are documented in the README.md

Reviewer Checklist

This section is intended for the core maintainers only, to track review progress. Please do not
fill out this section.

[ ] Code reviewed
[ ] Topgun tests run
[ ] Back-port if needed

lgtm


local video has poster volume bar be hidden

in mac chrome  v70.0.3538.67

What version of the library?

@sampotts Yes,is latest.

Same here. Mac/Chrome 70.0.3538.77

Same here. Chrome.

Feel free to take a look and open a pull request 👍

Same here

Same here

Some here Mac/Chrome 75.0.3770.100

I'm experiencing the same thing. A hidden tag is being added to them. Not sure where it comes from.

It is removed when I scrub on the progress bar though.

Same here

Happy to review PRs for this - they're a lot useful than "same here"s 👍 😉.
The problem is that the inverse was originally an issue; a video with no audio showed the volume control. Some logic was added to hide the volume control if no audio track was present. The problem is the browser seems to give flaky results when querying for an audio track. You'll see that there's several events that we check for audio but perhaps we need to add more in there for make up for the crappy browser APIs 🤦♂

Hey guys, if you put the preload attribute on your video tag, volume bar appears.
<video preload="none">
It's not a fix but maybe help someone.

Same issue here as well.

Same issue here as well.
<video preload="none">
not works for me

player.once('canplay', () => player.currentTime = 0);

Was this ever fixed? This is really broken for me, not being able to change the sound on a video with sound is terrible UX, is this fixed in a newer version or what's the latest version before the change was implemented that caused this? 🤔

Yes, the logic to hide the volume control has been reverted due to the browser APIs not working as expected. Yes, it's not great UX but it was temperamental behavior and hard to reproduce. If you want to hide the volume control now, you have to do so via the controls option.

See the changelog for v3.5.7:
https://github.com/sampotts/plyr/blob/master/changelog.md#v357

Hey np at all, I know browsers can be finicky, overall plyr is great thank you for your work!


it will be displayed "en" content When I build your example with {defaultLanguage: "de"} in SSR mode.(Incognito)

Describe the bug
it will be displayed "en" content When I build your example with {defaultLanguage: "de"}. (Incognito) https://github.com/isaachinman/next-i18next/tree/master/examples/simple
Occurs in next-i18next version
my dependencies are lastest version at today

Steps to reproduce
my config is

I add defaultLanguage: "de" to NextI18Next config but when I run yarn run dev and then I see "i18next: languageChanged en" in my console.log

and i setup my server.js with

Expected behaviour
my expectation is content will be show "de" content
Screenshots

OS (please complete the following information)
chrome lastest version
Additional context
help me please. thank you verymuch

So I found step to fix my issue
add
    lookupCookie: 'next-i18next',
    order: ['cookie', 'querystring', 'localStorage', 'path', 'subdomain'],
    caches: ['cookie'],
  },```
to my configuration

it is correct way?

I suggest you read up on how language detection works. Good luck!


Fix typo: importnakamura.py

fix typo, match.txt --> corresp.txt

this is not a typo, the file is named match.

Could you check again?

I noticed that the nakamura alignment algorithm v240109 (C++) outputs both match.txt and corresp.txt.
In Partitura, pt.load_nakamuramatch uses the match.txt file as input. (current document is correct)
However, for pt.load_nakamuracorresp, using the match.txt file causes an error. You must use the corresp.txt file instead—the documentation is incorrect.

Hello @mimbres, I'm sorry for the early dismissal. You are right; there is probably a typo on the document. However, since this is a very small documentation edit, I will go ahead and correct it in one of the already open PRs.


Salesforce is trying to run an inactive rollup

The error message is as follows:
Apex script unhandled exception by user/organization: ***
Failed to process batch for class 'dlrs.RollupJob' for job id ***
caused by: System.QueryException:
dlrs__LookupRollupSummaryScheduleItems__c
^
ERROR at Row:1:Column:146
Invalid field: ***
The invalid field exists, and the specific rollup is inactive.
So, why is Salesforce trying to run an inactive rollup?
Please advise.

You likely still have the DLRS Scheduled Apex class in your scheduled jobs. Please check and let us know.

@JimBTek , I have the same issue. How can I differentiate which one is for a specific field roll up? They are all called
RollupCalculateJob in Apex jobs

You should be able to use the job id and look in the url when you review the scheduled job to match them.


.env variables stopped working, unable to save plugin settings

I'm not sure why but Scout stopped pulling in the .env variables.  I thought it might be a caching issue so I went to the plugin settings page and went to save and it tells me "unable to save plugin settings"
It was working before, and i've not changed anything regarding Scout.
Not sure how I can diagnose the issue?
Craft: 3.7.44
Scout: 2.7.2

I was trying to flush/update the index via the command line.
The .env variable for the Admin API key isn't working with this method, I had to hard code it. However, the Application ID works as a .env variable. So I'm not sure why variable works and the other doesn't.
I ended up flushing and rebuilding the indexes through the Utilities section.

Hey @Joobs
That's strange, as the Utility will just use the same config and thus the same variables as the command line interface.
Are your logs showing anything when you try to save the settings?

The settings for the key fields are all environment variable aware, I use environment variables for all three in my Scout config.
'application_id' => '$ALGOLIA_APPLICATION_ID',
'admin_api_key' => '$ALGOLIA_ADMIN_API_KEY',
'search_api_key' => '$ALGOLIA_SEARCH_API_KEY'

Which works OK, there is no reason why the admin key shouldn't work as an env var, as it's being put through parseEnv. You're not missing the $ sign before the environment name or happen to have typo with the environment name at all?

Closing this for now, feel free to re-open if the issue is still happening and is scout related.


python3.pkgs.rl-coach: mark as broken

cc @timokau

Motivation for this change
Things done

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

[ ] 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 nixpkgs-review --run "nixpkgs-review wip"
[ ] 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)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Oh, that's a shame. I haven't lived up to the "maintainer" status for this package, so marking it as broken is the right thing to do here. Maybe someone else will step up. Thank you for noticing.


Couldn't access platform secure storage

i got this error on debian. is there any app to install before this keyring-cli can be use?
Couldn't set password for '[daily]debian@keyring-cli': Couldn't access platform secure storage: SS error: prompt dismissed

The error message is indicating that the secret service was not able to prompt you to unlock your secure store.  This sometimes happens when you are using a headless box (or if you are using ssh to access a machine and cannot see its desktop interface).
There is nothing else you need to install in order to use the CLI.  But you have to unlock your secure store before using it, because when the CLI has no way to prompt you from the command line - it relies on the Secret Service to prompt you using your machine's desktop GUI.


Pass the index to the method to allow multiple

Had to redeploy as a different verification key

We enforce the index via the precondition in the transaction.
The index is incremented in the zkApp so there is no way to generate this incorrectly? Need a test for this.

Run like npm run build && node build/src/main.js 0 39 29 where arguments are index, epoch, feePayerNonce.
Can run multiple times incrementing to, e.g., npm run build && node build/src/main.js 8 39 30 or store the resulting GraphQL and broadcast later.


@concurrent annotation doesn't work in the OOP script method

I.E:
class SomeClass:
    @concurrent [doesn't work, 2 args]
    def request(self, flow):
        pass

Good catch - thanks!


using libedgetpu 2.7.0 to support python 3.10

This PR upgrades pycoral to version 2.7.0 based on libedgetpu 2.7.0.
It supports and build on python 3.10

Mvp


OpenRC support

I tested and it doesn't seem to break anything

i am still trying to get this branch working on gentoo.
start() in res/ly-openrc does not execute.
i have been playing around with other commands to try to
fix this, and i will let you know when i have solved the issue.

Weird.. if it's running openrc it should run fine since it's the exact same init and afaik it's the same structure.
You could try changing the shebang to /usr/bin/openrc-run or something, or using getty instead of agetty. (if you haven't tried these already)
That, or it's just spawning in another tty that you're not looking xd. That's all i can think of...

@wncry Did you manage to get it working?

Also I don't know if this a case specific issue (I am testing on artix linux) but I will start on tty2, no matter what the script does. So it might just be best to use tty2 (It might also be useful to note that the systemd service file uses tty2).

The script only starts ly in the provided tty, it's ly that's teleporting you to tty2, try to edit the tty in config.ini to be the same as the init. (sorry, i guess i forgot to say that)
I'll try to come with something so that the two values sync automatically.
I'm using tty7 because i thought it's easier, for the 1-6 ones you have to disable the agetty.tty* service so that the normal agetty doesn't override the ly agetty (assuming you have them enabled by default)

Instead it's recommended to use supervisor.

Yeah, that's fine i guess.

I made a fork with my version of the script feel free to just steal it for this PR. I did use this script from pspiagicw to start out because it worked somewhat.

pspiagicw's script clogs up openrc-run which introduces a lot of issues, read my issue here where i tried to explain: #343
Basically you shouldn't be using exec ly directly because it doesn't fork the process, thus clogging up openrc-run.

I see now! I'm thinking this should be mentioned in the documentation. Although this could be intuited, some users may not intuit this.
I changed the script to fit these needs, would you say it works for the use case?

I see now! I'm thinking this should be mentioned in the documentation. Although this could be intuited, some users may not.
I changed the script to fit these needs, would you say it works for the use case? It is essentially the same as your script, but it follows the guidelines in the OpenRC Script Guide a bit more closely.

Yeah. Nice script, i'll try it out but i'm pretty sure it works.
One thing though, i think the TTYCONF can be boiled down to just
cat /etc/ly/config.ini | sed -n 's/^tty.*=[^1-9]*// p'

~For automatically syncing with config.ini do you think that using sed would be appropriate?~ I got the script to pull from the config for tty. I have tested it and it appears to work.

lmao that's exactly what i was doing

Sounds great! It might be useful to mention that the method mentioned in #207 by Figuera; for changing the background and foreground color is still possible. By adding this line (Best to place it after either CONFTTY or TTY and depending on which var; the var in place of the tty will need to be changed, of course):
/usr/bin/printf "%b" "\e]P0{background-color}\e]P7{foreground-color}\ec" > /dev/"${TTY}"

I'm recommending that along with this PR there should be a version bump so that the non-git packages also come with the fix to the issue talked about in #216 which prevents logging in, at least with systems not running systemd.

The background color changer could be added but i don't think the init script is the best place to put that. It should be a built-in option in ly .
Also @MadcowOG i think you forgot to accept my PR so i can merge the changes

My apologies I didn't see that. I have merged it.

The background color changer could be added but i don't think the init script is the best place to put that. It should be a built-in option in ly .

I would like the same thing but nullgemm has said that he doesn't plan on supporting that feature, #207. So it's more of a workaround.

One thing that is a bit annoying that could be a good change is to move the installation of each service file to their own makefile functions (like with openrc atm). Because install just always installs the systemd service file even if you are on openrc. It might require a bit of work downstream but still might be worth it for compatibility.

I made a new branch which contains a modified makefile and readme. I think this could provide better transparency over different systems.

@wncry Would you mind testing the latest script in this PR to confirm that it works on Gentoo?

@MadcowOG @Cavernosa Can this be merged?

I think so. I don't have any new ideas and the script is working fine.

Alright then!


Dynamic Range Operator

Dynamic Range is used in model from relevance team. Add in custom support.

Ooops, sorry merge changes too early.


Microsoft Edge removal tool causes problems with other Microsoft software setup

I found a bug on Edge Uninstaller tool: it sets a Windows registry key to: 0, something related to WebView2 update, and some software won't install because this value. For now I encountred problems during installing Visual Studio 2022 Community.
This is involved registry path:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
These are the involved 32 bit Dword
Install
InstallDefault
Riccardo

possible duplicate of:
https://github.com/ChrisTitusTech/winutil/issues/1075
Sorry I read better then I discovered you already know about this. Closing thread, waiting for your new edge removal tool.
R


[Feature Request] Implement ttnn.where as a fused operation

Is your feature request related to a problem? Please describe.
ttnn.where uses large amount of operations.
Describe the solution you'd like
Fused operation
Describe alternatives you've considered

Composite operation - reduced performance

@davorchap ttnn::where is one of the main reason why we have elementwise (unary + binary) top1 perf issue.

@davorchap @yan-zaretskiy  this issue is similar to the gelu_bw.
we have just a few calls in forward function and it takes 15-20ms from total time.


Dev

Codecov Report

Merging #19 (9d6a9bf) into main (2395645) will decrease coverage by 0.21%.
The diff coverage is 60.46%.

:exclamation: Current head 9d6a9bf differs from pull request most recent head d0a2c8f. Consider uploading reports for the commit d0a2c8f to get more accurate results

@@            Coverage Diff             @@
##             main      #19      +/-   ##
==========================================
- Coverage   43.93%   43.72%   -0.22%
==========================================
  Files          10       10
  Lines         808      741      -67
==========================================
- Hits          355      324      -31
+ Misses        453      417      -36

Impacted Files
Coverage Δ

src/functional/builder.jl
0.00% <0.00%> (ø)

src/dlr.jl
52.52% <63.41%> (-2.42%)
:arrow_down:

src/spectral.jl
79.02% <0.00%> (-2.31%)
:arrow_down:

src/sample/sample.jl
87.87% <0.00%> (-1.60%)
:arrow_down:

src/operation.jl
98.05% <0.00%> (-0.02%)
:arrow_down:

src/discrete/kernel.jl
0.00% <0.00%> (ø)

src/discrete/builder.jl
0.00% <0.00%> (ø)

src/utility/chebyshev.jl
0.00% <0.00%> (ø)

... and 1 more

Continue to review full report at Codecov.

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


App Refactoring & Component Standardization: Number Keypad Component

The code for this is currently very verbose and is being duplicated on several screens. We should abstract it to a single, reusable component.
Design example

This is not required anymore. Closing.


BLD: raise an error with clear message for too-new Python version

This works for both python install xxx, which gives:
RuntimeError: Your Python version is too new. SciPy 1.9 supports Python 3.8-3.11; if you are trying to build from source for the most recent SciPy version you may hit this error as well. Please build from the `main` branch on GitHub instead.

as the last line.
For installing through meson or meson-python, we get:
meson.build:55:2: ERROR: Problem encountered: Your Python version is too new. SciPy 1.9 supports Python 3.8-3.11; if you are trying to build from source for the most recent SciPy version you may hit this error as well. Please build from the `main` branch on GitHub instead.

A full log can be found at /home/path/to/log
Meson build setup failed! ({0} elapsed)

Through pip or build we get some more boilerplate at the end that is not avoidable, but the error message is still clear:
      Program python3 found: YES (/home/rgommers/anaconda3/envs/scipy-dev/bin/python3.10)

      ../../meson.build:55:2: ERROR: Problem encountered: Your Python version is too new. SciPy 1.9 supports Python 3.8-3.11; if you are trying to build from source for the most recent SciPy version you may hit this error as well. Please build from the `main` branch on GitHub instead.

      ...
      AttributeError: module 'mesonpy' has no attribute 'prepare_metadata_for_build_wheel'

      During handling of the above exception, another exception occurred:

          ....
          raise CalledProcessError(retcode, cmd)
      subprocess.CalledProcessError: Command '['meson', 'setup', '--native-file=/home/rgommers/code/scipy/.mesonpy-native-file.ini', '-Ddebug=true', '-Doptimization=2', '--prefix=/home/rgommers/anaconda3/envs/scipy-dev', '/home/rgommers/code/scipy', '/home/rgommers/code/scipy/.mesonpy-_3w2qa5b/build']' returned non-zero exit status 1.

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.

Closes gh-14986
Note that this patch should be reverted after SciPy 1.9.0 is released. We just need a single sdist on PyPI with this message. After that we can simply rely on the correct metadata in pyproject.toml.
Note: this patch will go into maintenance/1.9.x after 1.9.0rc2 and before 1.9.0rc3

Small gotcha: don't compare strings directly in meson.build files, use version_compare: https://mesonbuild.com/Reference-manual_elementary_str.html#strversion_compare

Are we going to try to do this for each release series (patch version 0) to prevent the resolver from dropping too far down in the "sdist chain" to older releases?

It sounds like the idea is that you just need the resolver to look for various available versions, notice that 1.6.x is "compatible but also 1.9.0 is "compatible", and prefer the newest "compatible" version. Then 1.9.0 takes precedence over 1.6.x and properly errors out, preventing the really old versions with bad metadata from being encountered.
So it doesn't matter how much work the resolver does, as long as it ends up preferring a version that errors so that users get a good error message?

Exactly, @eli-schwartz's explanation is right. We only need to do this once; the problem was that before the 1.6.1 sdist was found as the last release without an upper bound for supported Python version, and it did not error out with a clear message but failed with known but obscure build errors. Now, 1.9.0 should remain the last version without an upper bound, and it will have a clear message.


Docs: Reference is a dead link

Description
This PR makes attenation of a document issue, regards chapter of In-source testing where the reference points to a URL which drops a 404 error.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[x] Ideally, include a test that fails without this PR but passes with it.
[x] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[x] Run the tests with pnpm test:ci.

Documentation

[x] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[x] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

This was fixed, it now links to https://github.com/vitest-dev/vitest/tree/main/examples/in-source-test