DeepCollection()._obj not documented

Looking at the README, I wasn't able to find this for a refresh--it's a handy attribute that should probably  be clear from the get-go.

I can mention it. There should be some qualifications with it's usage, because I'd think most of the time it isn't needed because:

the DeepCollection object is a bona fide instance of the same type as _obj, so it should behave the same except where functionality is overridden
default usage of a dc object should still match what would have happened with _obj. E.g. you'll still get a KeyError or IndexError if you supply a single key to __getitem__, most of the time.

There is some flexibility in 2 though, so it may be simpler to use _obj if you really want those errors to pop up, and don't want to think about how to achieve that with a dc. That will of course mean you can't supply a path, but that's simpler than getting a [path] to return an error. I realize now that I haven't made strict be a kwarg on DeepCollection, so I'll add that.


Important Notice of the Project Future

Unfortunately, I have to tell you the truth that the initial RVC developer, whose name is RVC-Boss, basically refuses ANYONE to do ANY changes (including PR) on HIS project, which is, in his mind, "dirtying" his code. That is the main reason of why this project progresses so slowly. I had a chat with him and decided to REVERT the commit of the main repo to what he like it to be and put the newest code to my repo as below.
https://github.com/fumiama/Retrieval-based-Voice-Conversion-WebUI
My repo will continue to pull the algorithm update from the main repo (this repo), and, is open for everyone to contribute new features. I hope that with this effort, RVC will be better than before by the help from you alls.

@RVC-Boss this is really sad. RVC has been driven not only by you, but also by a great community, including some developers who did everything selflessly.
To let such a great project die this way, is a lack of maturity and commitment, and I don't think this is the end that anyone expects for something that has given us so many good things.
I think you should try to change that mentality, if some guys are helping you to maintain a code that you have abandoned, far from complaining you should thank them, and if you don't like the way they do it, do it yourself.
I am willing to help in everything you need, but take the actions with head and in a premeditated way, and if you are going to fire the project, do it in a dignified way.
I really appreciate you guys, regards.

@blaise-tk said that RVC has been driven not only by you

However, our boss do not think so. I have talked him with the importance of community but gave up finally. Therefore, this issue is the only thing that I can do to keep RVC alive, which is, separating from the main repo.

@blaise-tk said that RVC has been driven not only by you

However, our boss do not think so. I have talked him with the importance of community but gave up finally. Therefore, this issue is the only thing that I can do to keep RVC alive, which is, separating from the main repo.

😢, I sent you a request on Discord so we can talk @fumiama

@blaise-tk could you make a group?

@fumiama Will you also make a repo for the CLI/API version? Since many people are interested in that version too.

@fumiama Will you also make a repo for the CLI/API version? Since many people are interested in that version too.

Sure. This part will mainly be done by @Tps-F . Anyone who has interest can also contribute to his project.

@ic1149 here!｢
https://github.com/RVC-Project/Retrieval-based-Voice-Conversion
But it's still under the development, could be a disruptive change.

Really sad this has to come to this, to be honest. Despite everything, I still believed in this project. I'll follow the fumiama/Retrieval-based-Voice-Conversion-WebUI, lmk if there's something i can help with.

So (as a user) do I get this right - This repo here will only get updates if RVC-Boss allows them in his Reich and the repo fumiama will get frequent updates (maybe even new algorithms and such) from now on?
Plus - I've seen talk about discord - is there a community surrounding this? (Would be great!)

This repo here will only get updates if RVC-Boss allows them in his Reich

Yes, generally speaking, he want to control all details of this repo and it means that all modifications will only be done by him. Well, you can see the repo status of GPT-Sovits (and many opening PRs being ignored by him), which is the project I do not take part in.

and the repo fumiama will get frequent updates (maybe even new algorithms and such) from now on?

Yes. My repo is open to everyone to contribute, but not this repo.

is there a community surrounding this?

Currently it is the discord channel.

Edit: By Discord-Community I mean that if the RVC-Developers-Discord refers to the new repo then?

Yes because the main repo will no longer accept PRs basically.
Well, it doesn't means that this main repo is BAD. If you just want to use RVC, of course use this repo first. But the main repo will not actively accept new features (mainly in UI-level). As for the algorithm, I will keep my repo up to date with this main repo. We can try new algorithms, but now I just tidy the code first to let it easier to read the algorithm of RVC, and next, modify it.

Thanks for the clearance @fumiama :)

No code is perfect. And RVC is going to be considered outdated if no further improvement is done. He should already know that.

No code is perfect. And RVC is going to be considered outdated if no further improvement is done. He should already know that.

He knows. But as a researcher, the outdated only means the algorithm part, which he can completely control and update. Actually, he doesn't care about the codes' quality as long as it works. He just want to keep the code stable so that he can edit it anytime he want without understanding what others have done on HIS codes. From his view, the RVC algorithm is more like a charity and no one should complain about it. They'd better just USE and cheer for his wisdom, that's all.

Like I can see parts of the program are not written using the best practices. No code is perfect. That's why communities work together to improve the code.

@fumiama
I understand your frustration, but let's keep this professional for everyone's sake.
The RVC project is not great in faith of the open-source spirit, but as the RVC-Boss is the owner of this repository, You can't do anything specific about this particular repo.
However, we all can bind together and work on improving the project, even if it is separate from this specific repo.

However, we all can bind together and work on improving the project, even if it is separate from this specific repo.

Yes, that's why I finally decided to separate.

fumiama 传递了大量错误的信息，我会澄清一些你们很可能认知错误的事情。为使得我的表述不被误解，我将亲自将其翻译成英文。
Fumiama has conveyed a lot of incorrect information. I will clarify some things that you are very likely to misunderstand. To ensure that my statements are not misinterpreted, I will personally translate them into English.
1、basically refuses ANYONE to do ANY changes (including PR) on HIS project, which is, in his mind, "dirtying" his code. That is the main reason of why this project progresses so slowly.
(1) basically refuses ANYONE to do ANY changes：fake news
错误的。所有人都可以向仓库进行提交，我将优先合并稳定且有价值的提交进行验证，在验证成功后进行合并。
No. Everyone can commit to the repository. I will prioritize merging stable and valuable submissions for verification, and merge them after successful verification.
验证有成本，因此验证会有优先级，根据对用户使用体验的提升和代码稳定性来评定。
用户使用体验提升分为4点，一是运行速度的提升，二是合成效果的提升，3是用户反馈的已有bug，4是使用操作的更便捷。
Verification has costs, so it will be prioritized based on improvements to user experience and code stability. User experience improvement is divided into four points:
Improvement in running speed,
Improvement in synthesis quality,
Existing bugs reported by user feedback (or you meet),
More convenient user operations.
如果反馈速度慢，可以尝试联系我，我会加速审阅你的pr，决定是推进还是close。你也可以将代码提交到第三方仓库，例如https://github.com/fumiama/Retrieval-based-Voice-Conversion-WebUI，并基于第三方仓库进行开发，你有可能得到更快速的反馈。
If the feedback is slow, you can try contacting me, and I will expedite the review of your PR to decide whether to advance it or close it. You can also submit your code to a third-party repository, such as https://github.com/fumiama/Retrieval-based-Voice-Conversion-WebUI, and develop based on the third-party repository, where you may receive faster feedback.
(2)dirtying
我必须保证main分支是处于稳定的状态，因此我不会允许未经过完整验证可以跑通，例如pytorch推理、训练、实时变声、DML推理、UVR分离等功能的代码合并进main分支，或者你提交的时候自己能够确保。
I must ensure that the main branch remains in a stable state. Therefore, I will not allow code to be merged into the main branch unless it has been fully verified to run correctly. This includes functionalities such as PyTorch inference, training, real-time voice conversion, DML inference, and UVR separation. Alternatively, you need to ensure this yourself when you submit the code.
事实上这个帖子下面已经有不少人在未经验证跑通自己的环境的情况下就提交代码，早期我进行了合并，很快issue的数量大幅增加。所以为了不劣化用户体验，这些未经验证的提交我不会合并到main。之前有一个dev分支，你们一直可以进行提交，fumiama 在进行合并。dev分支或者第三方仓库的稳定性审核会轻很多。
In fact, many people have already submitted code without verifying it runs correctly in their environment. Initially, I merged these submissions, and the number of issues quickly increased. Therefore, to avoid degrading the user experience, I will not merge these unverified submissions into the main branch. There was a dev branch before, and you can submit to it. fumiama has been handling the merges there. The stability checks for the dev branch or third-party repositories will be much lighter.
"dirtying"是fumiama的个人总结，这显然不能准确描述以上情况。
"Dirtying" is Fumiama's personal summary, which clearly does not accurately describe the situation mentioned above.
(3)his code
错误的。目前的仓库不仅仅是我一个人的代码，它拥有很多贡献者，例如yxlllc提供了实时变声的拼接算法、共振因子参数等，CNChTu提供了FCPE高质量音高提取算法，EntropyRiser提供了早期的实时变声界面代码，nadare881提供了音质更高咬字更准确的faiss检索方法，还有很多人贡献了界面翻译文本，等等。因此我更要确保他们的代码能跑在一套正确运行的系统上，能切实让用户体验得到提升。
No. The current repository is not just my code; it has many contributors. For example, yxlllc provided the real-time voice conversion stitching algorithm and resonance factor parameters, CNChTu provided the FCPE high-quality pitch extraction algorithm, EntropyRiser provided the early real-time voice conversion interface code, nadare881 provided the faiss retrieval method for higher sound quality and more accurate articulation, and many others have contributed interface translation texts, among other things. Therefore, I need to especially ensure that their code runs on a correctly functioning system and genuinely improves the user experience.
(4)That is the main reason of why this project progresses so slowly.
错误的。该项目进展缓慢的根本原因是它本来已经到达了他的极限、巅峰状态，在这个状态下，有效提交在逐渐减少才是常态，你不可能在一个已经很成熟的项目上每天都还能有一次有效更新，反过来理解，如果他还在和初期一样常态化拥有大量提交，这些提交很可能是无效提交。
No. The fundamental reason for "the slow progress" of this project is that it has already reached its peak and limit. In this state, it is normal for effective submissions to gradually decrease. It is unrealistic to expect a mature project to have effective updates every day. Conversely, if it still has a large number of submissions as it did in the early stages, these submissions are likely to be ineffective.
2、REVERT the commit of the main repo to what he like it to be
更准确地说是main分支会处于合理的状态。最新的版本本身也是基于较老的main分支在dev分支的一些有效提交上进行的更新，不存在revert的说法。我会时不时观察pr和dev分支的merge，选取有价值的更新去验证他并合并到main分支。
More accurately, the main branch will be in a reasonable state. The latest version itself is an update based on some effective submissions from the dev branch on an older main branch. There is no concept of reverting. I will periodically review PRs and merges in the dev branch, selecting valuable updates to verify and merge into the main branch.
3、To let such a great project die this way
不, RVC不仅没有消亡，相反，使用RVC技术的视频一直在增加，RVC技术也逐渐潜移默化地在进入人们的日常生活中。不要将项目的更新速度降低等同于项目消亡。
No, The RVC project has not disappeared; on the contrary, the use of RVC technology in videos continues to increase. RVC technology is gradually permeating into people's daily lives. Do not equate the slowing update speed of the project with its disappearance.
4、some guys are helping you to maintain a code that you have abandoned
我没有放弃这个项目，这属于误解。
I have not abandoned this project; that's a misunderstanding.
5、this issue is the only thing that I can do to keep RVC alive, which is, separating from the main repo.
Fumiama一直在维护dev分支的合并，dev分支事实上承担了大量不稳定提交合并的职责。他认为将dev分支分离出主仓库更合适，我尊重他的决定。
Fumiama has been maintaining merges in the dev branch, which has actually borne the responsibility of merging a large number of unstable submissions. He believes that separating the dev branch from the main repository is more appropriate, and I respect his decision.
6、However, our boss do not think so. I have talked him with the importance of community but gave up finally.
我没有表述过类似想法。我需要再强调一下，社区的贡献是重要的，显然它也是RVC的一个重要组成部分。 事实上直到昨天，我都在进行社区开发人员提交的有价值代码。下文我不会再回复有关社区重要性的问题。
I have never expressed such an idea. I need to emphasize once again that community contributions are important and clearly an integral part of RVC. In fact, until yesterday, I was still reviewing valuable code submitted by community developers. I won't respond to further questions about the importance of the community.
7、generally speaking, he want to control all details of this repo and it means that all modifications will only be done by him.
错误的。我不仅没有控制仓库的完整细节，相反，有一些部分是未经过我自己审查验证也同意提交的，例如mac、ipex推理支持，以及实时变声的一部分代码(它由yxlllc自主提交)。我没有亲自验证，同时这部分提交也没有引起用户的负反馈，因为他们在提交前会自行验证程序的稳定性，至少懂得自己要能跑通了，再把代码提交上来。
No. I don't control all the details of the repository. On the contrary, there are some parts that have been submitted and accepted without my own review and verification, such as support for Mac and IPEX inference, as well as some code related to real-time voice conversion (which was autonomously submitted by yxlllc). I haven't personally verified these submissions, but they haven't received negative feedback from users either because they usually verify the stability of their programs before submitting. At least they ensure that the code can run before submitting it.
用户体验是第一位的，必须有人来负责main分支的稳定性，我能理解的部分我尽量自己负责，不能理解的部分也可以交付可靠的提交者自己负责。但是我不会将其交给连自己提交的代码自己都不先去验证的提交者。我必须对用户，和其他贡献者负责。
User experience comes first, and someone must be responsible for the stability of the main branch. I will take responsibility for the parts I understand as much as possible, and for the parts I don't understand, I can assign them to reliable contributors. However, I won't entrust them to contributors who don't even verify their own code before submitting. I must be accountable to users and other contributors.
8、No code is perfect. And RVC is going to be considered outdated if no further improvement is done.
人孰能无过，这是显然的事情。犯了过错当然可以被理解，但是人能通过自己的努力弥补过错。假如代码存在问题，你可以反复运行将其调试通过来纠正它。不自行验证而将错误代码提交上来的行为，反映的不是能力问题，而是态度问题。
People are bound to make mistakes, that's obvious. Making mistakes can be understood, but people can also make up for their mistakes through their efforts. If there are issues in the code, you can debug and correct them by running it repeatedly.
Submitting erroneous code without self-validation doesn't reflect an issue with capability but rather an attitude problem.
我们一直有在努力提升RVC的效果和产品用户体验，但是我们不想任何一点意义不大的提升都搞一个大新闻惊扰RVC的用户。RVC是否过时，用户的行为会说明一切，你我说了都不算。
We have been continuously striving to improve the quality and user experience of RVC, but we don't want to make a big fuss about any insignificant improvements that might disturb RVC users. Whether RVC is outdated or not, users' actions will speak louder than words.
社区是重要的，每个人都可以为RVC做出自己的贡献，这是自由的。但是为了切实提升用户体验，合并进主分支会有门槛。
The community is important, and everyone is free to contribute to RVC. However, to genuinely enhance the user experience, there will be a threshold for merging contributions into the main branch.
最后我想再警示大家，RVC的main分支改动的背后，会有大量的开发人员克隆、更新这个分支。提交代码不是儿戏，而是一件责任重大、神圣，且有时会枯燥到难以坚持下去的事情。因此，合并代码将进行严格的代码验证，在提交前请务必保证您的代码的稳定性和有效性。这是最基本的要求。
Finally, I would like to remind everyone once again that behind any changes to the main branch of RVC, there will be numerous developers cloning and updating this branch. Submitting code is not child's play; it is a significant and sacred responsibility, and sometimes it can be tedious to the point of being difficult to persevere. Therefore, merging code will undergo strict code validation, and before submitting, please ensure the stability and effectiveness of your code. This is the most basic requirement.

Happy to hear the formal reply from RVC-Boss. In my previous chats with him, his attitude to the GitHub codes changes violently so maybe I have some misunderstanding.
I will reply to RVC-Boss's comment point by point from my view according to my collaboration experiences with him.

(1) basically refuses ANYONE to do ANY changes：fake news
No. Everyone can commit to the repository. I will prioritize merging stable and valuable submissions for verification, and merge them after successful verification.

That's true, but something is hidden. RVC-Boss will merge the PRs that he thinks useful, and for the PRs he thinks not important or he cannot understand, he just ignore them (or let me to decide, which will be explained later) in most cases, which is his successful verification really means.

If the feedback is slow, you can try contacting me ...

Sure. RVC-Boss is very busy, so he cannot spend so much time on this repo at GitHub, which means, a PR will wait for a month or longer to let him have a look (and possibly just ignore it).
And, he let me to decide the PRs that are not related to the algorithm. I did as he said, but actually, he cannot TRUST every codes I merge/write, whose detail will be explained later.

(2)dirtying
I must ensure that the main branch remains in a stable state.

I also agree.

Alternatively, you need to ensure this yourself when you submit the code.

The meaning of this sentence in English is different (and unclear) from the Chinese version. In Chinese version, it means

If you can ensure this yourself when you submit the code, the code can be merged into the main branch.

Which is what I have done in the recently. I migrated some new translations and error fixes that will not affect the main functions into the main branch without asking him because he his busy.

There was a dev branch before, and you can submit to it. fumiama has been handling the merges there.

Yes. RVC-Boss will check and validate dev branch when he want to release a new version. As the dev branch usually contains many changes when he is absent, he may not have the patient to check it completely. At the beginning (in the past year, 2023), he did some merges from dev to main. However, when he is busier in this year, he just give up seeing the dev branch and let it alone, which is a separation in fact. What I have done is just normalize it.

"Dirtying" is Fumiama's personal summary, which clearly does not accurately describe the situation mentioned above.

No. I'm completely repeating what RVC-Boss said in our QQ-dev-group, and, I even beautified it. Let's see the original text. I will translate it on the picture.
The red line that he said is the direct reason that let me make the final decision to separate. It's a matter of principle.

(3)his code
there are some parts that have been submitted and accepted without my own review and verification

And RVC-Boss got mad when these codes contain bugs, which are unavoidable in develop process. Actually, many changes of the repo is pushed by me and got many complains and abuses from him. From my view, it's he that is protecting his code.

No. The fundamental reason for "the slow progress" of this project is that it has already reached its peak and limit.

Hear the voices of the community.

Conversely, if it still has a large number of submissions as it did in the early stages, these submissions are likely to be ineffective.

ineffective, exactly. That's the true thought of RVC-Boss.

The latest version itself is an update based on some effective submissions from the dev branch on an older main branch.

Exactly.  Thanks to his effort.
And again, this is a separation in fact.
To avoid these troubles, the LICENSE of MY REPO has been changed to AGPL-3.0 in the dev branch. So, now RVC-Boss CANNOT pick any effective submissions from my repo only if he also change the LICENSE of this main repo to AGPL-3.0.

Do not equate the slowing update speed of the project with its disappearance.

Not a suitable thought for building a community. See the reason of the slowing update speed.

I have not abandoned this project; that's a misunderstanding.

Yes, he just want it be stable.

He believes that separating the dev branch from the main repository is more appropriate, and I respect his decision.

I want to mention that this decision is not from my personal view. I just realized a fact. In fact, I would rather not separate if a little bit hope exists, which has been broken down rudely by the chat log above.

In fact, until yesterday, I was still reviewing and merging valuable code submitted by community developers.

Yes, I have seen it. So I will give back all the merge duties in the main repo to RVC-Boss and work on my separated repo to avoid further misunderstanding of the word valuable code.

At least they ensure that the code can run before submitting it. ... However, I won't entrust them to contributors who don't even verify their own code before submitting.

I agree, but do not be completely negative about all codes from others.

If there are issues in the code, you can debug and correct them by running it repeatedly.

I want to mention that RVC is not a product online in a large company. Do not rule the free-devs with the industrial rules. In open-source project, bugs is acceptable (even in main branch) as long as someone notice it and fix it quickly, which is easy for a large project.

Didn't know this issue went so deep... Honestly, quite shocked about this

If this problem transcends to these levels, no matter how much you want, this technology is DEAD. No matter what repositories you make or updates you release, you must clear up all these problems and establish the direction and future of RVC.
No developer is going to want to collaborate in such a toxic environment

why do you embed UVR and such into a product which main purpose is to convert the voices

Because the base of this project is never the GitHub repo, but the General Pack. You can see the launch script of the General Pack easily ex. go-xxx.bat.

Exactly, @blaise-tk !
The RVC started taking... ODD turns lately
Main repo contains literally EVERYTHING, which makes it EXTREMELY heavy to clone, push to and even update!
Main weights are contained inside the repo itself, which is simply overkill. Weights should have been uploaded to huggingface and cloned from there, at the very least
It feels like the project lost its main direction and just does random things at this point, with very little amount of things being actually relevant to the idea

No developer is going to want to collaborate in such a toxic environment

RVC-Boss is a good researcher. He can make brand new algorithms and this is his capital. No one can replace him at this time.

Because the base of this project is never the GitHub repo, but the General Pack. You can see the launch script of the General Pack easily ex. go-xxx.bat.

That's the problem in my opinion, the project should do one thing, but do it good; not do<PHONE_NUMBER>381 things and do them semi-good
Maintaining single thing is much easier and better than maintaining: realtime, web, notebooks and all of that in a single project; why none of these were ever split into multiple repos is beyond me

why none of these were ever split into multiple repos is beyond me

RVC-Boss mainly faced to the new-bee Chinese users (小白 in Chinese), this is his basic disk. As for the GitHub, just the icing on the cake to absorb valuable commits from the community.

It feels like the project lost its main direction and just does random things at this point

This is what RVC-Boss means of

The fundamental reason for "the slow progress" of this project is that it has already reached its peak and limit.

Because he is quite satisfied about the status now and do not want to change a lot.

Honestly, I'm beginning to see all this unnecessary public drama. I understand the need to expose this bad situation, but I think you should clarify things between your team and take the project in the best direction.
Maybe you should open up and take the opinion of more people related to the RVC community.
There are great communities that support this technology and I think it will not cost you much to expand your team.

https://discord.gg/iahispano & https://discord.gg/aihub

If you want, we can create a Discord group with all the RVC team and I will invite the most influential people from all the communities so we can chat and try to help you to achieve something more than a dead-end discussion.

@blaise-tk i'd strongly advise against aihub, the community there is extremely toxic
i think creating a group chat for rvc team would be the best solution

If you want, we can create a Discord group with all the RVC team and I will invite the most influential people from all the communities so we can chat and try to help you to achieve something more than a dead-end discussion.

Maybe a good solution. But perhaps you have some misunderstanding about the RVC-dev-team. There's no tight team. All the directions is given from RVC-Boss and I, yxlllc or others do not know. The has the final decision.  So it is me who quit the project. If you want to create a new team based on this main repo, just talk to the RVC-Boss. Maybe he is happy to welcome you all. As for me, just want to work alone without listening the instructions from RVC-Boss.

If you want, we can create a Discord group with all the RVC team and I will invite the most influential people from all the communities so we can chat and try to help you to achieve something more than a dead-end discussion.

Maybe a good solution. But perhaps you have some misunderstanding about the RVC-dev-team. There's no tight team. All the directions is given from RVC-Boss and I, yxlllc or others do not know. He has the final decision right. I just devoted to manage the repo (more like a worker with no money) but now I'm tired about the trouble that I work for this project selflessly without salary and being abused by him meanwhile. So it is me who quit the project. If you want to create a new team based on this main repo, just talk to the RVC-Boss. Maybe he is happy to welcome you all. As for me, just want to work alone without listening the instructions from RVC-Boss.

I think this is the problem, we have to create a less hierarchical team where developers can be more free based on some rules.

@fumiama
whenever open-source project's decisions are ultimately up to a single individual, that's when you know the project is screwed
working on something together is the best approach for FOSS, where people give suggestions and add requested features. the main rvc repo is NOT about teamwork though and i can't imagine why anyone would want to contribute to RVC-Boss' repo...
you branching from the repo to have a more community-maintained solution is much better in spirit than whatever the heck RVC-Boss is doing.
I will attempt to contribute to your repo as much as possible

I think this is the problem, we have to create a less hierarchical team where developers can be more free based on some rules.

If I can, I would like to.

Oh good lord...
There seems to be some value to what @fumiama said about @RVC-Boss.  there come "statements".
I think @fumiama's decision to create a separate repo is actually a good one, since there are two approaches to the project right now (sort of compareable to OpenOffice and LibreOffice) whereas both will have their strengths and weaknesses. I will try to keep up with the development on both at my docker-hub-repo (see https://hub.docker.com/r/cherrymint/rvc_webui ) and hopefully we will see some progress in the end somewhere.
Now @RVC-Boss - maybe think about your mindset on FOSS and life in general - @fumiama get back to work on your repo!
@Both: In the end you're fuckin' over the community with this - maybe some competition will help and in the end we will see who has the better software (@fumiama - maybe that's some motivation for you).

i can't imagine why anyone would want to contribute to RVC-Boss' repo...

Because this repo has many many stars. You can see the PR status of another famous repo GPT-SoVITS, which is also a project of HIM. And also, he ignored most of the PRs.

I will attempt to contribute to your repo as much as possible

Thanks so much. That's the community I want to work with.

To Both: In the end you're fuckin' over the community with this

Apologize to all the troubles I made but I have to. Now I will return to my repo.

To Both: In the end you're fuckin' over the community with this

Apologize to all the troubles I made but I have to. Now I will return to my repo.

I'm comming from a "user"-standpoint here. To me it's not about you @fumiama or @RVC-Boss. I couldn't care less about two people from the other side of the planet (no offense).
But to me it feels like that the user-side of the story needs to be heard. Speaking of which:
@RVC-Boss has a point in wanting the repo to be as stable and userfriendly as possible, but a word to the wise here: The latter (usability) can be acchieved by a good documentation and some thorough tutorials on how to do things.

If this problem transcends to these levels, no matter how much you want, this technology is DEAD. No matter what repositories you make or updates you release, you must clear up all these problems and establish the direction and future of RVC.
No developer is going to want to collaborate in such a toxic environment.
Things that I think would be important to save this situation:

Re-organize the RVC team
Establish new project guidelines
Establish roadmap for the future
More direct contact between RVC team <-> community
Announce the status of upcoming releases (roadmap)

To add on to this, a lot of the bugs could be caught if you added unit testing for some baseline features. This will ensure that any new code merged to main will not affect existing core functionality.

RVC-Boss is a good researcher. He can make brand new algorithms and this is his capital. No one can replace him at this time.

@fumiama is this the reason there's no whitepaper for RVC? Other researchers could be helping with algorithmic changes if he released an architectural map of the model.

is this the reason there's no whitepaper for RVC? Other researchers could be helping with algorithmic changes if he released an architectural map of the model.

I have ask someone else with the problem. The answer is he has no time and no interest on writing the paper/docs. And of course, he welcome the algorithm improvement, but maybe he thought that they will read his code.

To add on to this, a lot of the bugs could be caught if you added unit testing for some baseline features. This will ensure that any new code merged to main will not affect existing core functionality.

I will add those unit tests on my repo, but not this main repo because in this repo, all the stuffs just mix together and it is hard to test part of them.


Add evaluation results to the website

Display evaluation results(e.g., comparison with Apache Spark) to help users get a sense of the system performance.

Please be more specific, as mentioned in #689

Closing for now, as per the discussion on Slack.


Could you please add Template for blob soft delete in this page?

[Enter feedback here]
In the soft delete for container page, there is a tab that explaining how to set container level soft delete by template. There is no such template for blob soft delete. some customers may be confused and thought that they are not able to set blob soft delete via ARM Template.
Could you please add Template for blob soft delete in this page?

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

ID: ce25ff08-4d2a-70db-df3f-650ea80f9c4b
Version Independent ID: 6e61f44d-c752-6818-ad21-2377efcee633
Content: Enable soft delete for blobs - Azure Storage
Content Source: articles/storage/blobs/soft-delete-blob-enable.md
Service: storage
GitHub Login: @normesta
Microsoft Alias: normesta

@jejass
Thanks for your feedback! We will investigate and update as appropriate.

@normesta
Can you please check and add your comments on this doc update request as applicable.

@jejass
I'm going to assign this to the document author so they can take a look at it accordingly

I added a template tab to the Blob Soft Delete doc. The change should appear live by tomorrow AM. Thank you for the suggestion!
#please-close


Support for linux/arm64

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
I'm trying to build docker images of NREL tools (WEIS, WISDEM etc) for both amd64 and arm64 platforms. openfast is one of our dependencies and would appreciate support for linux/arm64 via conda-forge.
Installed packages
N/A

Environment info
N/A

see https://conda-forge.org/docs/maintainer/knowledge_base.html#using-arch-rebuild-txt

I gave this a shot a couple of weeks ago and it failed with a bunch of compiler errors. It didn't make sense because it builds fine in a Linux docker container on an M1 Macbook, so the architecture and GCC can definitely do it. I will revisit this soon now that the Windows build issues have been resolved.


Upgrade SDL (2.0.16) for Windows

Include the latest version of SDL in Windows releases.

Merged into dev: 3a39bacb76003fec3dcfd14200f12d52114c3289


[SPARK-26755][SCHEDULER] : Optimize Spark Scheduler to dequeue speculative tasks…

… more efficiently
Currently, Spark Scheduler takes quite some time to dequeue speculative tasks for larger tasksets within a stage(like 100000 or more) when speculation is turned on. On further analysis, it was found that the "task-result-getter" threads remain blocked on one of the dispatcher-event-loop threads holding the lock on TaskSchedulerImpl object
def resourceOffers(offers: IndexedSeq[WorkerOffer]): Seq[Seq[TaskDescription]] = synchronized {
which takes quite some time to execute the method  "dequeueSpeculativeTask" in TaskSetManager.scala, thus, slowing down the overall running time of the spark job. We were monitoring the time utilization of that lock for the whole duration of the job and it was close to 50% i.e. the code within the synchronized block would run for almost half the duration of the entire spark job. The screenshots of the thread dump have been attached below for reference.

What changes were proposed in this pull request?
Have split the main queue "speculatableTasks" into 5 separate queues based on locality preference similar to how normal tasks are enqueued. Thus, the "dequeueSpeculativeTask" method will avoid performing locality checks for each task at runtime and simply return the preferable task to be executed.
How was this patch tested?
We ran a spark job that performed a join on a 10 TB dataset to test the code change.
Original Code:

Optimized Code:

As you can see, the run time of the ShuffleMapStage came down from 40 min to 6 min approximately, thus, reducing the overall running time of the spark job by a significant amount.
Another example for the same job:
Original Code:

Optimized Code:

Test build #102999 has started for PR 23677 at commit 65d0926.

Test build #102999 has finished for PR 23677 at commit 65d0926.

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

Merged build finished. Test PASSed.

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

Hi @squito , any chance we could take a look at this one. We have experimented quite a lot with this code change and we have seen quite positive results especially in terms of running time improvements. Thank you.

@tgravescs @vanzin @squito We have been running Spark on our clusters with this code patch and have observed runtime improvements for large jobs by a factor of 20-25 mins. Would appreciate your reviews. Thank you.

Test build #106899 has started for PR 23677 at commit e525b1c.

Test build #106899 has finished for PR 23677 at commit e525b1c.

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

Merged build finished. Test FAILed.

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

test this please

Test build #106902 has started for PR 23677 at commit e525b1c.

Test build #106902 has finished for PR 23677 at commit e525b1c.

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

Merged build finished. Test PASSed.

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

Test build #107083 has started for PR 23677 at commit 41ddf23.

Test build #107083 has finished for PR 23677 at commit 41ddf23.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class PendingTasksByLocality(

Merged build finished. Test PASSed.

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

Test build #107361 has started for PR 23677 at commit 1fa17ec.

Test build #107361 has finished for PR 23677 at commit 1fa17ec.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #107362 has started for PR 23677 at commit 025e548.

Test build #107362 has finished for PR 23677 at commit 025e548.

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

Merged build finished. Test PASSed.

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

Test build #107414 has started for PR 23677 at commit b58c34f.

Test build #107414 has finished for PR 23677 at commit b58c34f.

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

Merged build finished. Test PASSed.

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

I need to do another careful pass, which will probably not happen till next week, but I think this probably ready.  Would like to ping a couple more reviewers if they'd like to take a look in the meantime @tgravescs @Ngone51 @jiangxb1987

Test build #107616 has started for PR 23677 at commit 62a15d7.

Test build #107616 has finished for PR 23677 at commit 62a15d7.

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

Merged build finished. Test PASSed.

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

Can you also update the PR description, to something which just focuses more on the actual improvement and less on the discovery of the issue?   I think you should just mention something like
"This improves the performance of scheduling speculative tasks to be O(1) instead of O(numSpeculativeTasks), using the same approach used for scheduling regular tasks.  The performance of this method is particularly important because a lock is held on the TaskSchedulerImpl which is a bottleneck for all scheduling operations.
In particular, this works by storing a separate stack of tasks by executor, node, and rack locality preferences.  Then when trying to schedule a speculative task, rather than scanning all speculative tasks to find ones which match the given executor (or node, or rack) preference, we can jump to a quick check of tasks matching the resource offer.  This technique was already used for regular tasks -- this change refactors the code to allow sharing with regular and speculative task execution."

Test build #107762 has started for PR 23677 at commit 466849e.

@squito @Ngone51 Have updated the PR with the changes. Thank you once again for your valuable reviews.

Test build #107762 has finished for PR 23677 at commit 466849e.

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

Merged build finished. Test PASSed.

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

Test build #107790 has started for PR 23677 at commit 7b23ef3.

Test build #107790 has finished for PR 23677 at commit 7b23ef3.

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

Merged build finished. Test PASSed.

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

Test build #107797 has started for PR 23677 at commit 7b23b37.

Test build #107797 has finished for PR 23677 at commit 7b23b37.

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

Merged build finished. Test PASSed.

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

lgtm
I am going to be unreachable next week, so I am going to wait till I'm back to merge it (though another committer is free to merge in the meantime of course).  Sorry I know this has been delayed a lot already, but this is too brittle a part of spark for me to merge without being around to follow up on.  thanks again for all the work on it @pgandhi999 , feel free to bug me after that.

Makes complete sense @squito , thank you once again for all your time.

@pgandhi999 I'll do another look tomorrow :)

Test build #107922 has started for PR 23677 at commit 32fa4d2.

Test build #107922 has finished for PR 23677 at commit 32fa4d2.

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

Merged build finished. Test PASSed.

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

Test build #108019 has started for PR 23677 at commit 685bbae.

Test build #108019 has finished for PR 23677 at commit 685bbae.

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

Merged build finished. Test PASSed.

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

LGTM

Test build #108346 has started for PR 23677 at commit 7a8c992.

Test build #108346 has finished for PR 23677 at commit 7a8c992.

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

Merged build finished. Test PASSed.

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

merged to master, thanks @pgandhi999 !

Thank you @squito and @Ngone51 for all your valuable reviews.


Doubt in Mahalanobis distance formula

Hi All,
I stepped through how Mahalanobis distance is calculated in scipy.spatial.distance
I could see the below implementation.
def mahalanobis(u, v, VI):
    u = _validate_vector(u)
    v = _validate_vector(v)
    VI = np.atleast_2d(VI)
    delta = u - v
    m = np.dot(np.dot(delta, VI), delta)
    return np.sqrt(m)

What is confusing me is that in the original formula [1] , there is  a transpose applied on the second delta. That seems to be missing in the line
 m = np.dot(np.dot(delta, VI), delta)
Can some one please clarify on this ?
[1] http://docs.scipy.org/doc/scipy/reference/generated/scipy.spatial.distance.cdist.html

Perhaps this will help:
>>> x, y = np.ones(10), np.ones(10)
>>> x.shape, y.shape
((10,), (10,))
>>> np.dot(x, y)
10.0
>>> x, y = x.reshape(1, 10), y.reshape(1, 10)
>>> x
array([[ 1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.]])
>>> y
array([[ 1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.]])
>>> np.dot(x, y)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: shapes (1,10) and (1,10) not aligned: 10 (dim 1) != 1 (dim 0)
>>> np.dot(x, y.T)
array([[ 10.]])

IOW the documentation is thinking of the inputs as row vectors, which correspond to numpy arrays of shape (1, n), but by default numpy creates arrays of shape (n,), and on such arrays dot computes their dot product.

Closing as there's no bug here; it's a difference in notation.


HDFS-17272. NNThroughputBenchmark should support specifying the base directory for multi-client test

Currently, NNThroughputBenchmark does not support specifying the base directory, therefore does not support multiple clients performing stress testing at the same time. However, for high-performance namenode machine, only one client submitting stress test can not make the namenode rpc access reach the bottleneck. Therefore, multiple clients are required for parallel testing to make the namenode pressure reach the level of the large-scale production cluster.
So I specify the base directory through the -baseDirName parameter to support multiple clients submitting stress tests at the same time.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
17m 59s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
42m 41s

trunk passed

+1 :green_heart:
compile
1m 20s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
1m 15s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
1m  8s

trunk passed

+1 :green_heart:
mvnsite
1m 21s

trunk passed

+1 :green_heart:
javadoc
1m  5s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 39s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 16s

trunk passed

+1 :green_heart:
shadedclient
34m 38s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m  9s

the patch passed

+1 :green_heart:
compile
1m 14s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
1m 14s

the patch passed

+1 :green_heart:
compile
1m  6s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
javac
1m  6s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 57s
/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs-project/hadoop-hdfs: The patch generated 8 new + 124 unchanged - 2 fixed = 132 total (was 126)

+1 :green_heart:
mvnsite
1m 12s

the patch passed

+1 :green_heart:
javadoc
0m 51s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 31s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 16s

the patch passed

+1 :green_heart:
shadedclient
34m 37s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
266m 41s

hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 41s

The patch does not generate ASF License warnings.

419m 44s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6319

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 971c5c6d5da2 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / a41f6a94a6f9932f6fde6ebf845a4cacd777614e

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/1/testReport/

Max. process+thread count
3203 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

@ayushtkn Thank you for your review. I have updated based on your suggestions.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 56s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
42m 42s

trunk passed

+1 :green_heart:
compile
1m 21s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
1m 15s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
1m  7s

trunk passed

+1 :green_heart:
mvnsite
1m 20s

trunk passed

+1 :green_heart:
javadoc
1m  7s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 35s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 16s

trunk passed

+1 :green_heart:
shadedclient
34m 24s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m  8s

the patch passed

+1 :green_heart:
compile
1m 13s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
1m 13s

the patch passed

+1 :green_heart:
compile
1m  4s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
javac
1m  4s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 55s
/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs-project/hadoop-hdfs: The patch generated 10 new + 124 unchanged - 2 fixed = 134 total (was 126)

+1 :green_heart:
mvnsite
1m 11s

the patch passed

+1 :green_heart:
javadoc
0m 51s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 28s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 17s

the patch passed

+1 :green_heart:
shadedclient
34m 41s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
262m 10s

hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 42s

The patch does not generate ASF License warnings.

397m 42s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6319

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux c9df5736afdf 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / fa1ce214549d6da7fab1efb2656dce3cbb76b3c8

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/2/testReport/

Max. process+thread count
3054 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 54s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
markdownlint
0m  0s

markdownlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  1s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 49s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
30m 51s

trunk passed

+1 :green_heart:
compile
16m  6s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
14m 52s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
4m 14s

trunk passed

+1 :green_heart:
mvnsite
3m 10s

trunk passed

+1 :green_heart:
javadoc
2m 25s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 39s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
5m 54s

trunk passed

+1 :green_heart:
shadedclient
34m 56s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 31s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m  3s

the patch passed

+1 :green_heart:
compile
15m 33s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
15m 33s

the patch passed

+1 :green_heart:
compile
14m 45s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
javac
14m 45s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
4m 10s

root: The patch generated 0 new + 117 unchanged - 9 fixed = 117 total (was 126)

+1 :green_heart:
mvnsite
3m 10s

the patch passed

+1 :green_heart:
javadoc
2m 20s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 43s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
6m 14s

the patch passed

+1 :green_heart:
shadedclient
35m 17s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
19m 19s

hadoop-common in the patch passed.

+1 :green_heart:
unit
261m 23s

hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
1m  5s

The patch does not generate ASF License warnings.

500m 57s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6319

Optional Tests
dupname asflicense mvnsite codespell detsecrets markdownlint compile javac javadoc mvninstall unit shadedclient spotbugs checkstyle

uname
Linux 0d5bd7603bf9 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 84cd5ee8781680077a281e9c61a7c63d9f43ae26

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/3/testReport/

Max. process+thread count
3506 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 22s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
markdownlint
0m  0s

markdownlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m  3s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
20m  6s

trunk passed

+1 :green_heart:
compile
8m 18s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
7m 26s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
2m  6s

trunk passed

-1 :x:
mvnsite
0m 45s
/branch-mvnsite-hadoop-common-project_hadoop-common.txt
hadoop-common in trunk failed.

-1 :x:
mvnsite
1m 57s
/branch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in trunk failed.

-1 :x:
javadoc
1m 33s
/branch-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-common in trunk failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
1m 32s
/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in trunk failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
1m 32s
/branch-javadoc-hadoop-common-project_hadoop-common-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-common in trunk failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
javadoc
1m 33s
/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in trunk failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
spotbugs
1m  2s
/branch-spotbugs-hadoop-common-project_hadoop-common.txt
hadoop-common in trunk failed.

-1 :x:
spotbugs
1m 11s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in trunk failed.

-1 :x:
shadedclient
32m 47s

branch has errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 11s

the patch passed

-1 :x:
compile
5m 28s
/patch-compile-root-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
root in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javac
5m 28s
/patch-compile-root-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
root in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
compile
5m 12s
/patch-compile-root-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
root in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
javac
5m 12s
/patch-compile-root-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
root in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m 51s

root: The patch generated 0 new + 117 unchanged - 9 fixed = 117 total (was 126)

-1 :x:
mvnsite
0m 35s
/patch-mvnsite-hadoop-common-project_hadoop-common.txt
hadoop-common in the patch failed.

-1 :x:
mvnsite
1m 54s
/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
javadoc
1m 33s
/patch-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-common in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
1m 29s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
1m 44s
/patch-javadoc-hadoop-common-project_hadoop-common-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-common in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
javadoc
1m 56s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
spotbugs
1m  3s
/patch-spotbugs-hadoop-common-project_hadoop-common.txt
hadoop-common in the patch failed.

-1 :x:
spotbugs
1m  4s
/patch-spotbugs-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

+1 :green_heart:
shadedclient
35m  9s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
19m 16s

hadoop-common in the patch passed.

-1 :x:
unit
188m 47s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 28s

The patch does not generate ASF License warnings.

339m 31s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.datanode.TestDirectoryScanner

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6319

Optional Tests
dupname asflicense mvnsite codespell detsecrets markdownlint compile javac javadoc mvninstall unit shadedclient spotbugs checkstyle

uname
Linux fd6153b4816a 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / d6b7c8857506737408df755f6e6c1de6b6fc4370

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/4/testReport/

Max. process+thread count
4093 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/4/console

versions
git=2.25.1 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 53s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
markdownlint
0m  0s

markdownlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 30s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
31m  4s

trunk passed

+1 :green_heart:
compile
16m 19s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
14m 47s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
4m 11s

trunk passed

+1 :green_heart:
mvnsite
3m 12s

trunk passed

+1 :green_heart:
javadoc
2m 24s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 48s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
5m 54s

trunk passed

+1 :green_heart:
shadedclient
34m 53s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 31s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m  4s

the patch passed

+1 :green_heart:
compile
15m 39s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
15m 39s

the patch passed

+1 :green_heart:
compile
14m 50s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
javac
14m 50s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
4m  7s

root: The patch generated 0 new + 117 unchanged - 9 fixed = 117 total (was 126)

+1 :green_heart:
mvnsite
3m  5s

the patch passed

+1 :green_heart:
javadoc
2m 19s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 38s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
6m 15s

the patch passed

+1 :green_heart:
shadedclient
35m 22s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
19m 14s

hadoop-common in the patch passed.

+1 :green_heart:
unit
264m  5s

hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
1m  2s

The patch does not generate ASF License warnings.

503m 43s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6319

Optional Tests
dupname asflicense mvnsite codespell detsecrets markdownlint compile javac javadoc mvninstall unit shadedclient spotbugs checkstyle

uname
Linux 5f859dc6a525 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 14566b74d274a286f28f1efa751c3f2941e74d61

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/5/testReport/

Max. process+thread count
3476 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6319/5/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.


Black screen after some time

My setup:
Mac Pro (late 2013)
macOS 10.15.5
4K LG monitor
Issue:
After playing videos totally fine for like 10-20 minutes the screen becomes blank and no videos are displayed. This happens constantly. I turned on HEVC and 4K. Here's my log around that time:
2020-07-15 17:50:59.511 : <AerialView: 0x7fea16d30ad0> notification: name = AVPlayerItemDidPlayToEndTimeNotification, object = Optional(<Aerial.AerialPlayerItem: 0x60000077d200, asset = <AVURLAsset: 0x60000077e000, URL = streaming://sylvan.apple.com/Aerials/2x/Videos/comp_A105_C003_0212CT_FLARE_v10_SDR_PS_FINAL_20180711_SDR_4K_HEVC.mov>>), userInfo = nil
2020-07-15 17:50:59.511 : <AerialView: 0x7fea16d30ad0> observeValue Optional("readyForDisplay") false (0.0, 0.0, 1920.0, 1080.0)
2020-07-15 17:50:59.511 : <AerialView: 0x7fea16d30ad0> Setting player for all player layers in []
2020-07-15 17:50:59.511 : initvideocache
2020-07-15 17:50:59.513 : <AerialView: 0x7fea16d30ad0> streaming video (not fully available offline) : http://a1.phobos.apple.com/us/r1000/000/Features/atv/AutumnResources/videos/b4-3.mov
2020-07-15 17:50:59.513 : <AerialView: 0x7fea16d30ad0> observing current item <Aerial.AerialPlayerItem: 0x60000077a080, asset = <AVURLAsset: 0x60000077bd60, URL = streaming://a1.phobos.apple.com/us/r1000/000/Features/atv/AutumnResources/videos/b4-3.mov>>
2020-07-15 17:50:59.513 : <AerialView: 0x7fea16d30ad0> playing next video for player Optional(<AVPlayer: 0x600000535f10>)
2020-07-15 17:50:59.514 : AssetLoaderDelegate deinit

Hi @jnpatrick99
Couple of things to check, first one is, I'm sure you are aware of this but the screensaver only runs a limited time depending on your macOS power saving settings. Can you check what that setting is set to ?

Second one is, your log says you are streaming videos. Streaming is unreliable and will go away in next version. Please try caching your videos. If you are concerned about disk space, have a look at the upcoming 2.0 builds with the cache limit from this thread : https://github.com/JohnCoates/Aerial/issues/1006
In general, streaming failures are more being stuck on a frozen image than full black screen but who knows.

Here are the settings that have, is this right?
In any case I turned on "Never stream videos" and "Never stream previews". Will see how it goes.

Sounds good, if you have disk space, press the "Download Now" to cache all videos. If you don't, I suggest only downloading a few from there (using the + button next to the ones you want.

Cool, thanks! It seemed to have fixed the issue! No black screen anymore.


Make reductin on 32 rows at a time instead of 16.

Ticket
Link
Problem description
Currently, Partial reductions are done on 16 rows at a time in max pool which is inefficient in case of large kernel size.
What's changed
Make it work for 32 rows at a time.
Checklist

[ ] Post commit CI passes
[ ] Blackhole Post commit (if applicable)
[ ] Model regression CI testing passes (if applicable)
[ ] Device performance regression CI testing passes (if applicable)
[ ] New/Existing tests provide coverage for changes

Would be nice to have some test to showcase this perf improvement, or some model that got faster, and document in commit/pr what is the perf impact of this change.

As of now this can impact only on yolov4 as large size kernels are used there only. Let me talk with someone to get numbers and mention here.


Roadmap for the project

Hello,
If you wish you contribute to this project or use the library, I am creating a road map below that would give a fair idea how i would like proceed with this project
Currently the project has base setup with slide animation working  and it is in very early stage so APIs may change in future.
As i will release the new version with new features, APIs may change on version upgrade, there won't be any seperate docs for previous versions, all the changes would be done in readme update.
Things that i would like to do for next release -

[ ] Work on CSS animations for next release, my next 3 target is stack, reveal and elastic

After i am done with all the CSS animations, i would like to work on these

[ ] Writing tests

[ ] Supporting Custom Icons

[ ] Improving the Code quality

[ ] Integration with Vuex and Vue Router

I am also creating github release for every version that is published on npm
npm link - https://www.npmjs.com/package/vue-burger-menu
All Ideas and suggestions are warmly welcome, you can create a new issue or reply to this comment thread.

Can you can render 60 Frames per second to the roadmap

@AleksejDix Can you elaborate a bit more ? what is your use case ?

Have you started implementing "Stack" amination implementation ? Otherwise I wish to start.


ModiferKeys?

Is that intentional?

Lol, nope. A prime example of my spelling skills.
Will fix that. :P

Fixed with 079a4dd


Added a cancel feature and a couple of minor UI fixes

Fixes for #45
What was changed?
I have implemented a cancel feature to the application, which enables users to successfully cancel a shift if necessary. I have also added some (very) minor UI fixes to the "Your Dashboard" and "Sign Up For Shifts" page:

I added some bottom padding to the "Impact Created" cards ["Your Dashboard"]
I added some bottom margin to the paragraph elements for the shelters in the "Shelters looking for Volunteers" column ["Your Dashboard"]
Changed "Sign up For Shifts" to "Sign Up For Shifts" in the nav bar
I added a small top margin to the "Radius (miles): [dropdown button]" to make it look less compact ["Sign Up For Shifts"]
I fixed the spelling of "opportunities" ["Sign Up For Shifts"]

Why was it changed?
Using the existing (DELETE /shifts/) API endpoint, the cancel feature was added to give users the option to cancel their upcoming shifts. The user should not be able to cancel past shifts and the user is required to confirm their cancellation to reduce chances of accidental cancels. The minor UI fixes were made to improve the readability, but please feel free to reject these changes, or let me know if you would like me to undo these UI changes.
How was it changed?
To add the cancel feature, I added an event handler that makes a DELETE request to the server to remove a shift identified by shiftCode. If the shift time is still upcoming and the server responds indicating the deletion was successful (response.ok is true), then the data state is updated to remove the canceled shift. This is done by setting the data to a new array that filters out the shift with the shiftCode. This change in state will cause the component to re-render and reflect the change in the UI. This change can be seen in lines 22-49 in Shifts.js and line 75 in ShiftList.js.
The rest of the UI fixes can be seen in lines 165 + 167 in Shelters.js, line 37 in NavBar.js, and lines 183-210 + 259-262 + 289 in index.css.

@jenniferlee20 Thank you for the pull request. Your changes generally look good. One thing that needs to be changed is: the user shouldn't be able to cancel past shifts. Right. now, when I go to previous shifts screen, I have an option to cancel.

If you adjust the code in your fork, the pull request should get adjusted automatically.

Sorry for not catching that—I will work on it immediately and adjust the code in my fork as soon as possible.

In the most recent commit, I have made the following changes:

I added lines 32-33 + 77-83 into ShiftList.js, which now uses a boolean check to make sure the cancel feature only appears for upcoming shifts. I deleted lines 23-27 from Shifts.js, which I originally thought would ensure that past shifts could not get canceled.
I updated some more UI aspects of dashboard page because the overall page looked a bit squished to the right. Lines 287-289 of index.css cover this change.
I added more spacing underneath the shift timeframe  and lines 216-219 of index.css cover this change.

Please let me know if you see any additional issues with the changes I have made!


#192 - Project documentation

Added documentation of the project - technical and end user.

Technical documentation contains information about the application, configuration and setup instructions.
User documentation contains instructions for using specific functionalities of the application.

The documentation is located in the docs folder and is independent of the rest of the project.
Command to run the documentation:
docker-compose exec node-docs npm run dev
It should appear at: http://localhost:8080/
A new action has been added that builds documentation and publishes at:
https://blumilksoftware.github.io/internships/ (should be available after pushing on main)
For the correct behavior of the action, there is a need to switch the repository Build and deployment Source setting under the Pages tab to GitHub Actions (Beta):

Along with the documentation, a assets.json file has been added to the frontend folder of the project, which allows to configure basic data about the university.
It looks like this:

{
    "college": {
        "name": "Collegium Witelona Uczelnia Państwowa",
        "website": "http://www.pwsz.legnica.edu.pl/",
        "latitude": 51.2048546,
        "longitude": 16.1472681
    }
}

Closes #192
Closes #81

I can't generate a documentation:

(I killed all docker containers and run sh setup.sh, but it doesn't help)
2. Please look more one time at this documentation and mark all commands and file nameslike this. Somewhere I marked it for you, but not in all places.
3. Why in Polish documentation (I mean in docs/pl/user/images/) we have pictures in English? For example account-reset.png, account-verify.png. EDIT: Oh, we don't translate e-mails - what a pity :(

You need to install required dependencies: docker-compose exec node-docs npm install
I denoted other names, commands as code.
Yes, we still need to figure it out

I also removed empty files and accepted the other suggestions.


GRXBufferedPipe suffers from race condition in writeValue

Using GRXBufferedPipe triggers a crash: "Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'A precondition for calling grpc_call_start_batch wasn't met. Error 8'". This can be reproduced by calling writeValue: on GRXBufferedPipe in a loop.
The underlying issue is that while all changes to the state property synchronized, they are synchronized on the GRXWriter instance the caller was passed in, rather than a common shared object. For example, GRPCCall synchronizes on it's requestWriter which is a GRXForwardingWriter, while the actual update of the state property is forwarded to the underlying GRXBufferedPipe. This makes it impossible to synchronize calls to writeValue: from the user of GRXBufferedPipe.
The state property is then accessed in writeValue: (https://github.com/grpc/grpc/blob/master/src/objective-c/RxLibrary/GRXBufferedPipe.m#L81) through shouldFastForward. However, that access is unsynchronized and races with updates from writeBufferUntilPausedOrStopped which is called on the GRPCCompletionQueue and is outside of the user of GRXBufferedPipe.
What happens in sequence is after being in the paused state, the state is changed to started and writeBufferUntilPausedOrStopped is called. That code takes the write and passed it to the layer below but before the state is updated to paused, it can happen that writeValue: is called on a different thread and shouldFastForward still returns true because the state is still started. writeValue: then also proceeds to pass the write on to the layer below. Because both writes were passed to the layer below, it causes a state violation in the C layer triggering the crash.

That must have been a heck of a thing to figure out. Thanks for the details, and sorry for the trouble! I think we have a super nice solution that @muxi is gonna try.

Resolved by #11070.


Prepare data for quantitative analysis

[x] Need to create a rosbag recording the entire pipeline running. This will capture both the intermediate BEVFusion output AND the BEV map with the predicted workzone masks. DONE: Here: https://drive.google.com/file/d/1J2QiT3MSH1UXkZMs6GTJpIXaqSVx7RnP/view?usp=drive_link (shouldn't need to use this, though).
[x] Will find some kind of utility to export / extract the images from the ros bags for @brendaju to use.
[x] Upload the images to Google Drive. DONE: Here: https://drive.google.com/file/d/1w5oQI9uWOR0VSK9zqobMvtuqYPXzDHIq/view?usp=drive_link

Yay!

@nlitz88 I just pushed a change on boundary segmentation package so that it overlays the ego frame on top of the segmented workzone (boundary_image). Also let me know if you need help in generating the binary prediction results (or maybe you have already acquired it).

@CMUBOB97

Okay, I see the ego-vehicle overlaid. Very cool!


Adding boolean operations

Based on the defined spec, we created the following implementation.

Pull Request Test Coverage Report for Build 745580052

101 of 116 (87.07%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.2%) to 93.514%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

booleanoperations/decoder.go
19
34
55.88%

Totals

Change from base Build 733784886:
-0.2%

Covered Lines:
3835

Relevant Lines:
4101

💛  - Coveralls


feat(RHTAPWATCH-578): write Dockerfile for exporter service

Dockerfile is added to the o11y repo to build the docker image for the prometheus exporters.
Jira-Url: https://issues.redhat.com/browse/RHTAPWATCH-578

Waiting for RHTAPWATCH-562 PR to be merged, so put it as Draft.


Python 2.6: bug in repeating elements.

In Python 2.6, when the input is a unicode object, for some reason the repeating elements become a string instead of a list. In every later version, this works correctly.
docopt.docopt('Usage:\n  app  <params>...', [u'v', u't'])
{u'<params>': u'vt'}

docopt.docopt('Usage:\n  app  <params>...', [b'v', b't'])
{u'<params>': ['v', 't']}

Duplicate of #219


Training freezes on CUDA10.1 with 98 haploid individuals

The process uses 100% CPU and 100% GPU and becomes uninterruptible (kill -9 needed).
64, 96, or 128 individuals work fine. CPU training with 98 individuals works fine. GPU training with 98 bins for the haplotype matrix works fine.

Can't reproduce with CUDA 11.


The API changelog from almost a year ago describes how @mentions are changing and we need to use the new model before September 12, 2018, but it's impossible to get at the necessary profile data with the present implementation.  This implementation isn't perfect (just shoving all the profile data into a dict in the User model), but it's backwards compatible and will allow us the ability to construct @mentions that will still function a month  (and some change) from now).
Considering the timeliness of the API change SOME measure is needed, even if not ideal, IMHO.
Requirements (place an x in each [ ])

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Jeremy Logan seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Travis is only failing on an SSL cert error that's unrelated, this should not count.

Thank you very much for taking the time to make this PR. This project no longer supports version 1.x as we've described here. Allow me to close this now. If you see the necessity to fix something similar in v2, please let us know by raising a new issue.


Two co-dependendent updates not being reported (deadlock)

Hi, I have the repo skaut/wordpress-verison-checker and I noticed some updates not being reported by dependabot on d94ee5f. I have an idea about why this might happen:
I have both @typescript-eslint/parser on version 1.13 and eslint on version 5.16.0 - both lagging behind by a major version (to 2.4.0 and 6.5.1 respectively at the moment). However, @typescript-eslint/parser 1.X depends on eslint 5.X and @typescript-eslint/parser 2.X depends on eslint 6.X.
So, effectively, updating only @typescript-eslint/parser to version 2 is broken because the requirement on eslint would no longer be satisfied. But updating eslint to version 6 is also broken because the requirement on eslint by @typescript-eslint/parser would also not be satisfied. The only valid path is to update both at the same time.
AFAIK, Dependabot doesn't support this at the moment and I think detecting all the ways to update multiple dependencies at once would be rather hard. So I'm not asking for that. What I would like to see is for Dependabot to let me know in some way that the updates couldn't be done - open an issue or whatever. Because now I'm in a situation where I just noticed several packages are outdated while depending on dependabot (no pun intended) to sort this kind of thing automagically...
Disclaimer: The reason why the packages aren't being updated is just a hypothesis, I haven't tested it out...

Closing this due to age and low demand. If this scenario is critical to your workflow please feel free to comment.

I wouldn't think of the issue as being critical to any particular workflow, but it diminishes the trust in dependabot a lot - you can no longer think of it as giving you the peace of mind of having all dependencies up-to-date. For smaller and hobby projects, that's the big value proposition of dependabot - a lot of the projects I use dependabot for are largely done and dependabot gives me the ability not to have to check up on them periodically to check what's stale or broken. This issue breaks that assurance...

Oh and as for demand, this issue manifested for me in the twin packages @typescript-eslint/parser and @typescript-eslint/eslint-plugin They seem to always bump major versions together and thus dependabot can't upgrade them. That's pretty sure to be a lot of users, but probably they just haven't noticed...


Thorchain affiliates

Results of dbt test

Results of dbt run --full-refresh -s models/thorchain


Development.

@portlek the puzzle #91 is still not solved.

@portlek 3 puzzles #100, #101, #91 are still not solved.

@portlek the puzzle #91 is still not solved; solved: #100, #101.

@portlek 3 puzzles #107, #108, #91 are still not solved; solved: #100, #101.

@portlek 4 puzzles #107, #108, #153, #91 are still not solved; solved: #100, #101.

@portlek 4 puzzles #107, #108, #153, #91 are still not solved; solved: #100, #101.

@portlek 5 puzzles #107, #108, #153, #188, #91 are still not solved; solved: #100, #101.

@portlek 5 puzzles #107, #108, #153, #188, #91 are still not solved; solved: #100, #101.

@portlek 5 puzzles #107, #108, #153, #188, #191 are still not solved; solved: #100, #101, #91.

@portlek 3 puzzles #108, #188, #191 are still not solved; solved: #100, #101, #107, #153, #91.

@portlek 4 puzzles #108, #188, #191, #255 are still not solved; solved: #100, #101, #107, #153, #91.

@portlek 3 puzzles #188, #191, #255 are still not solved; solved: #100, #101, #107, #108, #153, #91.

@portlek all 9 puzzles are solved here: #100, #101, #107, #108, #153, #188, #191, #255, #91.

@portlek the puzzle #445 is still not solved; solved: #100, #101, #107, #108, #153, #188, #191, #255, #91.

@portlek 2 puzzles #445, #447 are still not solved; solved: #100, #101, #107, #108, #153, #188, #191, #255, #91.

@portlek the puzzle #447 is still not solved; solved: #100, #101, #107, #108, #153, #188, #191, #255, #445, #91.


[iTerm] Fix: keep the same desktop focused when creating a new window

Description
Closes #8112.
Change the behavior of the "new iTerm window" command. Without this fix, when you create a new tab if on exists on another desktop/screen it first focuses the existing window and then creates the new one. It's for me, an unwanted behavior.
launch in macOS scripts typically refers to starting an application, whereas activate refers to bringing an already running application to the foreground or making it the active window.
By changing activate to launch the focus behavior is fixed.
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Thanks for the correction @papey 🔥
@ron-myers do you mind checking this?

Looks great!@


Support for Opus through HLS

Describe the feature
HI! It would be nice to add support for Opus codec through HLS

Hello, thanks this feature request, i didn't knew that HLS could play Opus, but it turned out that recent versions of hls.js, Firefox and Chrome allow to read Opus tracks inside MP4 segments.
Reading Opus tracks with HLS is now fully supported.
The implementation is based on this specification.

This is now supported since v0.21.1


ios11 doesn't show normally

when swiper area scroll and leave from screen and go back, need to slide to normal display

I have the same problems with 1st

Perhaps,we have the same problem , sometime,the swiper  inites again , when swiper area scroll and leave from screen and go back . And the area become white block , then the swiper init again .

Same problems, any clue?

same problem on ios only


Module field label appears underneath the delete button in bulk edit modal

Reproduction steps

Solution
To be discussed

https://github.com/cortezaproject/corteza/pull/1339/commits/6f6df66d6f8dd28b29d581cbbf5443c4864294d4


Move api client initialization into api package

This PR move the initialization of the api client into a function NewClientFromParams in api package. This removes duplicate code, as the api client was initialized in various commands (heartbeat, today and todaygoal). It is a preparation for implementation of sync offline command (https://github.com/wakatime/wakatime-cli/issues/404).

Api client initialization is moved into api.NewClientFromParams. Main initialization logic is only moved and not modified.
legacyparams.API and legacyparams.Network are unified into api.Params.
Tests for api related parameter loading from viper is unified in legacyparams package and removed everywhere else.
sync-offline-activity command will be able to use the initialization logic via api.NewClientFromParams and does not need to implement it itself.

Branch is outdated, needs a rebase.

Branch is outdated, needs a rebase.

Thanks for the heads-up :+1:


refactor: optimize small things: colors, margins, orders, comments, renaming, legibility

All the little things are reported here. Please refer to this issue when submitting a PR with small fixes that you found while developing

Thank you all for participating in this one-week GO HORSE protocol. It's over now.


Fox32 architecture documentation

Hi everyone,
I've spend some time documenting the Fox32 CPU based on how it's handed in the emulator. It's still a bit incomplete (I haven't written descriptions for the individual instructions), but I think it's a start.
The already existing encodings.md file is now a bit stranded, as I didn't know best to integrate it into the new document.
Feel free to merge just part of this PR, but I wanted to get it out for review now.

Woah this is incredibly detailed even though it's currently unfinished, thank you so much for doing this!! I'll merge the entire PR, I think every little bit of documentation helps. Really the only thing I would change in the future is the fact that "fox32" should be all lowercase, it's just a style consistency thing :P


Cherry pick #3900 #3901 #3905 #3908 #3910 #3911 to release v0.37.x

What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?:

NONE

We don't need #3904?

If all recently added commits are ok, how about merging the master branch to release-v0.37.x branch to release?

If all recently added commits are ok, how about merging the master branch to release-v0.37.x branch to release?

lgtm 👍 it reduces the risk of missing commit

@nghialv @khanhtc1202
Okay, let's do that after editing RELEASE file and close this PR.


Running with  python 3.12 will raise " No module named 'imp'"

some py files calls import imp in many places, Due to the abandonment of the imp module in Python 3.12, it is recommended to change it to import importlib as imp

Hi, this is issue of TRex API itself as it's not really ready for Python 3.12.
We use Python3.11 and had to make changes to original code to get it to work. We currently don't plan on moving to Python3.12.

Got it, Thanks for your response.


Adding option to shuffle shards before splitting to workers, based on current epoch

What
This PR adds an option to shuffle the shards before splitting them between nodes and workers. We coordinate this shuffling via a shared random seed, to ensure shards are properly distributed between workers. With epoch-based training loops, the idea is to set this random seed to a different number every epoch, ensuring shards are distributed differently at each iteration. This is completely optional, and should not affect existing workflows in any way. If users chose to use it, the only change they need to make is to simply call dataloader.set_epoch(epoch) at each epoch before iterating.
Why
Without this, each worker always sees the same subset of shards at every epoch, when using the standard nodesplitter and split_by_worker. We found this to have a drastic negative impact in performance when training contrastive models, since it limits the possibilities of which datapoints are being contrasted. With this fix, this issue was substantially mitigated.
How
The fix is two small modifications. One is to introduce a set_epoch method, which informs the dataloader (and everything that composes it up to the ShardList) of the current epoch. The second one is to use that as a random seed for shuffling shards before they are being split between workers and nodes.
We have found this to significantly improve performance in our contrastive learning experiments, and would greatly appreciate if you could take a look at this!
cc @mitchnw

Thanks; let me have a look at it. I'm not sure that this really needs a new method on WebDataset. Why don't you simply make the nodesplitter function dependent on the epoch itself and add a set_epoch function to that?
I'll see whether I can document this better and add examples.
(Also note that these issues are specific to actually performing splitting by nodes; if you use sampling with replacement, i.e. all shards on all nodes, none of this arises. That's how we usually train.)

Thank you for the response!
A new nodesplitter would also do the trick here. This way we don't need to change the logic inside ShardList or Composable. The downside of this solution is that users would need to interact with another object in their training loops (since they would need to keep track of the splitter in addition to the dataloader itself). The upside is minimal interference with existing classes. If this is preferred, we could add something like the following to workerenv.py:
class RandomNodeSplitter:
   """Randomly split shards between nodes.

   Used as a shard selection function in Dataset.
   In epoch-based training loops, this splitter can be used to ensure shards are distributed
   differently among nodes at each epoch. A typical use is to call `set_seed(epoch)` before
   iterating over the dataset in each epoch.
   """
   def __init__(self, start_seed=0):
      self.set_seed(start_seed)

   def set_seed(self, seed):
      self.seed = seed

   def __call__(self, urls, env=None):
      random.Random(self.seed).shuffle(list(urls))
      return split_by_node(urls, env)

While this problem indeed only arises in specific use cases, splitting by nodes in epoch-based training loops is not an uncommon scenario. A good example is contrastive learning, which has gained a lot of popularity recently. In this paradigm, it is still common to have epoch-based training loops since sampling with replacement can be problematic, leading to pairing the same instance as a negative sample of itself. I agree that this fix could be done outside the library, but this seems like a common enough use case that it could benefit the library to have native support for it, especially if its done with minimal interference to existing workflows.
Let me know your thoughts!

I'll just add the RandomNodeSplitter class for now, which should point people in the right direction. I'll also add an example to the documentation.
A couple of comments:

I think the PR doesn't work, because a WebDataset is a pipeline of IterableDataset instances, not an single object
there are shorthands for common multinode configurations (multimode=) now, and I may eventually add such a shorthand for this case as well.

Roughly, the way PyTorch handles spawn is that the workers are spawned in subprocesses where torch.distributed is not initialized; in addition, the Dataset instances are restored from pickled data on every epoch. That also means that set_epoch in your patch wouldn't work as expected.  The usual arguments to DataLoader (shuffle, sampler, batch_sampler) are explicitly disabled in DataLoader for IterableDataset, so they don't help us.
I have refactored the code now in a way in which this should work more like you expect and that does also allow you to use per-epoch shuffling.
If you don't need per-epoch shuffling, just don't do anything.
If you do want epoch_shuffle, you can create the dataset instance as follows:
    shardlist = functools.partial(wds.PytorchShardList, epoch_shuffle=True)
    dataset = wds.WebDataset("imagenet-{000000..000015}.tgz", shardlist=shardlist). ...
    loader = wds.WebLoader(dataset, num_workers=4, batch_size=20)

And then you must put the epoch in the environment:
    loader = make_loader()
    for epoch in range(2):
        os.environ["WDS_EPOCH"] = str(epoch)
        for inputs, labels in loader:
            ...

You can find a preliminary example notebook here
https://github.com/webdataset/webdataset/blob/master/notebooks/multinode-test.ipynb

Thank you so much for the response and updating the code!!
Your refactoring seems to also do what we need, i'll go ahead and test it out. Is there any reason why the default of shuffle of PytorchShardList is set to False? I also noticed the code crashes if we set it to True because self.epoch is not defined (see https://github.com/webdataset/webdataset/blob/master/webdataset/dataset.py#L244)

Thanks for spotting that. I'm not sure how the self.epoch got past the test case. I think I have fixed it. I'll try to add some test cases for it.

Thanks for the responsiveness here! I tested the new code and it matches the performance of the previous solutions we suggested. I'll go ahead and close this PR.
Thanks again for your help!


Add WordPress TOC entry

This PR add the WordPress example to the TOC.

@mglaman Could you give this a try if when you get a chance?

Deleted post above in incorrect PR.