2,580,375 events, 1,324,396 push events, 2,047,619 commit messages, 161,806,655 characters
Update Assignment 3.py
Current version. Everything is done but the god damn colorbar. What the fucking fuck.
Created Text For URL [www.timeslive.co.za/tshisa-live/tshisa-live/2020-12-18-black-motions-murdah-praises-his-girlfriend-dj-zinhle-with-cute-ig-post/]
sched/tune: Switch Dynamic Schedtune Boost to a slot-based tracking system
Switch from a counter-based system to a slot-based system for managing multiple dynamic Schedtune boost requests.
The primary limitations of the counter-based system was that it could only keep track of two boost values at a time: the current dynamic boost value and the default boost value. When more than one boost request is issued, the system would only remember the highest value of them all. Even if the task that requested the highest value had unboosted, this value is still maintained as long as there are other active boosts that are still running. A more ideal outcome would be for the system to unboost to the maximum boost value of the remaining active boosts.
The slot-based system provides a solution to the problem by keeping track of the boost values of all ongoing active boosts. It ensures that the current boost value will be equal to the maximum boost value of all ongoing active boosts. This is achieved with two linked lists (active_boost_slots and available_boost_slots), which assign and keep track of boost slot numbers for each successful boost request. The boost value of each request is stored in an array (slot_boost[]), at an index value equal to the assigned boost slot number.
For now we limit the number of active boost slots to 5 per Schedtune group.
Signed-off-by: joshuous [email protected] Signed-off-by: Henrique Pereira [email protected] Signed-off-by: PainKiller3 [email protected] Signed-off-by: madeofgreat [email protected] Signed-off-by: MadeOfGreat [email protected] Signed-off-by: CloudedQuartz [email protected]
Jingle all the way with opera tab completion
It's time to fulfil our quest that was desired to be done from times of yore (#56). And since Christmas is about giving back and caring about others we decided to bring merry to all our users and enable tab completion for opera CLI arguments.
One can almost get enchanted when looking at a CLI that has a nice-working shell completion. Shell completion can be hard to comprehend sometimes because there's many ways to support it. Since opera uses argparse we had to find a tab completion package that's compatible with it. The love on first sight would be argcomplete Python package which was designed for completing argparse commands and their arguments. However, when we tried it it didn't turn out so well. Most of the time we were unable to get it working with our subparsers and on the other hand we didn't want to activate completion globally. So we almost gave up with that. But then we remembered that failure only happens when you give up. Hoper and determination fuel the true champions. So we found shtab as a possible solution. The package is still very young and some features will probably be worked on in the future.
We were able to use shtab in our code to generate a shell completion
script. And we don't even need a separate command to do that since
shtab supports defining a global optional argument that will print
out the completion script for the main parser. We used that and
defined --shell-completion/-s flag which receives a shell type to
generate completion for. Shtab currently supports bash and zsh so those
are the options. So, after running opera -s bash|zsh the generated
tab completion script will be printed out. To activate it you must
source the contents which can be done with eval "$(opera -s bash)"
or you can save it to a file and then source it. The procedure will
be fully explained in the opera documentation.
First thoughts about tab completion also included a possibility to pre-install it for the user. For that we would need to do the sourcing within the installation. There was also a suggestion to have a separate opera shell-completion command that would have a --install switch to install tab completion on user's system. We didn't want to upset the users by installing something into their environment that they might not want. We also didn't want to modify their ~/.bashrc file and add our completion as that could bring a lot of problems. At the end, we decided to just print out the generated completion script and then the user can decide how to continue for himself.
The new completion feature will give aid to those opera users who seek it. Since opera CLI is evolving and growing, new and new commands and CLI options are being introduced. So it's easy to make a mistake while you're using the CLI. And that's when tab completion comes in handy.
Jingle all the way with opera tab completion
It's time to fulfil our quest that was desired to be done from times of yore (#56). And since Christmas is about giving back and caring about others, we decided to bring merry to all our users and enable tab completion for opera CLI arguments.
One can almost get enchanted when looking at a CLI that has a nice-working tab completion. Shell completion can be hard to comprehend sometimes because there's many ways to support it. Since opera uses argparse we had to find a tab completion package that's compatible with it. The love on first sight would be argcomplete Python package which was designed for completing argparse commands and their arguments. However, when we tried it, it didn't turn out so well. Most of the time we were unable to get it working with our subparsers and on the other hand we didn't want to activate completion globally. So we almost gave up with that. But then we remembered that failure only happens when you give up. Hoper and determination fuel the true champions. So we found shtab as a possible solution. The package is still very young and some features will probably be worked on in the future.
We were able to use shtab in our code to generate a shell completion
script. And we don't even need a separate command to do that since
shtab supports defining a global optional argument that will print
out the completion script for the main parser. We used that and
defined --shell-completion/-s flag which receives a shell type to
generate completion for. Shtab currently supports bash and zsh so those
are the options. So, after running opera -s bash|zsh the generated
tab completion script will be printed out. To activate it you must
source the contents which can be done with eval "$(opera -s bash)"
or you can save it to a file and then source it. The procedure will
be fully explained in the opera documentation.
First thoughts about tab completion also included a possibility to pre-install it for the user. For that we would need to do the sourcing within the installation. There was also a suggestion to have a separate opera shell-completion command that would have a --install switch to install tab completion on user's system. We didn't want to upset the users by installing something into their environment that they might not want. We also didn't want to modify their ~/.bashrc file and add our completion as that could bring a lot of problems. At the end, we decided to just print out the generated completion script and then the user can decide how to continue for himself.
The new completion feature will give aid to those opera users who seek it. Since opera CLI is evolving and growing, new and new commands and CLI options are being introduced. So it's easy to make a mistake while you're using the CLI. And that's when tab completion comes in handy.
Benjamin Kaduk's No Objection on draft-ietf-roll-unaware-leaves-26
From: Alvaro Retana [email protected] Sent: vendredi 18 décembre 2020 13:42 To: Michael Richardson [email protected]; Pascal Thubert (pthubert) [email protected] Cc: [email protected]; Routing Over Low power and Lossy networks [email protected]; [email protected]; Benjamin Kaduk [email protected]; The IESG [email protected] Subject: RE: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-unaware-leaves-26: (with COMMENT)
In the IANA Considerations section:
IANA is requested to add [this document] as a reference for MOP 7 in the RPL Mode of Operation registry.
All documents that define a MOP 7 behavior should have that sentence. Only UseofRPLInfo will have the extra text about reserving 7.
From: Pascal Thubert (pthubert) [email protected] Date: December 18, 2020 at 3:54:10 AM To: Alvaro Retana [email protected], Michael Richardson [email protected] CC: [email protected] [email protected], Routing Over Low power and Lossy networks [email protected], [email protected] [email protected], Benjamin Kaduk [email protected], The IESG [email protected] Subject: RE: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-unaware-leaves-26: (with COMMENT) Thanks!
Alvaro.
Dear all:
Sorry I failed to compute that the registry that Benjamin referred to was the IANA one. I see that it can be useful there and will be happy to do whatever change that helps in the future. Let us agree on a sentence/section to add in the drafts. Suggestions appreciated : )
You all keep safe, and let us enjoy the break, and for the lucky of us in these troubled times, with our families;
Pascal
From: Alvaro Retana [email protected] Sent: jeudi 17 décembre 2020 22:40 To: Michael Richardson [email protected] Cc: [email protected]; Routing Over Low power and Lossy networks [email protected]; [email protected]; Benjamin Kaduk [email protected]; The IESG [email protected] Subject: Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-unaware-leaves-26: (with COMMENT)
Let’s do it in each document where a behavior is specified for MOP 7. That way it remains consistent in case there’s something else in the future.
Thanks!
Alvaro.
On December 17, 2020 at 4:18:33 PM, Michael Richardson ([email protected]) wrote:
Alvaro Retana [email protected] wrote:
To do it can be as simple as requesting IANA to add additional references to MOP 7 in the registry.
So, it goes into the IANA Considerations for all three documents? Or, into useofrplinfo only, where we reserved it? Or, is it just an IESG request to IANA?
-- Michael Richardson [email protected] . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
Backing up again and...
god fucking damn it GitHub, gave me another near heart-attack
day 16 in perl^Wpython
While things have been a bit weird and so I often do the advent when I'm tired, so the perl version is much more messy than it needs to be, I got to the point where part2 didn't work for some reason and redid it (with hard-coded values) in python3.
It was so much faster&easier to get it right! Most of the bugs were brainfarts copypasting & replacing text from the input... Possible explanations:
- I'm more experienced with python than perl - no
- Perl becomes great when it becomes second nature but it sucks if you only use it for short silly scripts
- My brain is more python-shaped than perl-shaped
- Perl just sucks compared to python
Cursing aside, I believe it's John Michael Dorian.
Add Qt5 Configuration Tool’s config file
It does have some state, but what do I do? Fuck you, KDE. Great desktop and software but this is sad.
Makes changes to CONTRIBUTING.md's table as discussed in #830 (#841)
This includes de-listing @francesca64 from the table, as I suggested. I realize that this is a controversial decision, and it's not a decision I make lightly, but I believe I have justification for doing so:
I contacted @francesca64 last month asking her about her inactivity as a maintainer on this project. She replied on March 26th as follows. For the sake of her privacy, I've removed removed certain sections of her response, as it contains some personal details that I'm not comfortable sharing with the world at large without her explicit permission.
Hello! Thanks for reaching out!❤
In short, I've moved on. ...in November, I was hired by a company that recently started using Rust. I'm very happily building infrastructure there!
I'm simply not interested in spending more than 8 hours a day programming. You couldn't even pay me to do it! My time is best spent going on adventures with my beloved.
I'll still be active in the Rust ecosystem, but only insofar as the company I work for is. We use winit on iOS, Android, and (to a limited extent) macOS, so I'll work on those backends as needed.
Thank you for taking care of winit. I hope you're taking care of yourself too; .
I don't begrudge her for her decision, and others shouldn't either - I firmly believe that, as this is unpaid, volunteer work, everybody should have the right to move on when they decide they no longer have the time or will to contribute.
The exact impliciation of this in regards to her status as maintainer is open to interpretation. I would argue that this means, should she in her work stumble upon an issue in any of her listed backends, she would be willing to submit PRs addressing those issues. However, it also means that she is not able to put in the time to be active as a maintainer on those platforms, or review PRs and issues for those platforms.
On March 28th I responded to her email as follows:
Hey, thanks for responding.
<removed, personal details>
In the meanwhile, there are still a few loose ends from your time as maintainer that I'd like to get cleaned up. It's okay if you aren't going to be spending much time on Winit, but there's still a broad assumption that you're able to review PRs for them and that doesn't seem to be the case. Would you be able to do a couple things to ease the transition to whoever next takes over the macOS, X11, and Android backends?
- Submit a PR downgrading yourself from maintainer for macOS, X11, and Android, so somebody else can more actively take them over.
- Post your WIP macOS backend for EL2.0 as well as the issues it currently has, so whoever next maintains macOS can finish it.
Going forward, I'd like to reach out to the broader Rust community and find more active maintainers so Winit can get to 1.0 and I can mostly move on from it.
I recieved no response to that email. On April 4th, I followed up on that email:
If you aren't able to act as a maintainer for Winit, and aren't able to submit a PR updating your official status as maintainer to reflect reality, would you mind if I submitted a PR removing you as maintainer? That's not something I want to do since it's a bad image for me, a bad image for Winit, and sets an extremely uncomfortable precedent, but I'd like to start more aggressive outreach to ensure each backend is less dependent on one specific person and I don't want to see new contributors pinging you for help when you're unable to provide it.
If you don't reply by the 11th that's the path I'm going to take, but I consider it the nuclear option and I want to avoid invoking it if at all possible.
Up to this date (April 13th), I have recieved no response. Given the amount of time I've given her to respond, as well as her lack of response, I believe we have the justification to remove her from the table. Should she show back up again, any clarifications on her status would be welcome, and she is welcome to submit a PR re-listing herself on the table with a more accurate description of her current contributor status. However, once we begin the contributor marketing push discussed in #830, I don't want new contributors to attempt to ask her questions on the macOS, X11, or Android backends when she isn't able to give a response.
This PR also introduces HALL_OF_CHAMPIONS.md, which commends the efforts of former maintainers that have contributed greatly to the Winit project. This wasn't discussed previously, but I think it's important to recognize the people that brought us to where we are today. It currently lists @tomaka and @francesca64, as they are the two individuals I'm aware of that both deserve such recognition and no longer actively contribute to Winit, but if there's anybody I missed feel free to suggest them and a blurb describing their work.
introduce an annoying as hell override list of github usernames who dont update their company field! wtf! making my life hard yo! these folks get their companies hard coded because seriously, help me out here. further qualified ignoring certain uses of xamarin in the case of microsoft.
holy shit... you know, this ugly feeling when something just works fine on the first attempt? Like the end of a horror movie, where something just is off..
Update Bataille navale 0.1
CLion decided to stop working, my mouse also decided to stop working properly and the minGW sent me errors I'm unable to troubleshoot continue the code without a new variable error every build although the concerned variables worked fine 5mn before then.... I'm currently contemplating despair for having seen too deep into the abyss of this crippled mine after realizing I'm gonna have a shitty grade for not being able to have a proper stuff to work with.... good job me u can now wish to be able to work properly enough during these holidays and successfully pass this year.
Delete Frank Zappa & Steve Vai - Fuck Yourself.mp3
readability improvements and some structural improvements that allow (basic) automatic data validation for any data type that is constructed like the current parts of the map. I think apart from some out-of-bounds accesses right now, this SHOULD be extensible to allow for writing something like the 'strings' function, but for arbitrary blocks of game data - which, given the absolutely weird ROM layout of pokemon gen 1 MAY actually turn out to be the best way to find certain kinds of data in ROMs, regardless of region or version. Right now we have to hardcode base addresses for lists of important game state, and finding these base addresses often isn't all that easy. Given thorough enough data validation, I think it'll be possible to just linearly scan through the whole ROM to identify these data structures, with some degree of certainty, and if it were combined with a reverse pointer search, which is not that hard in a Gameboy ROM if we're being honest, assuming we can code in all the variants that pointers and lists are being stored in the ROM (I was genuinely surprised by the 'zipped' version used for the map data pointers, for instance, it wouldn't have occurred to me that there would be a static list of offsets in bank 0, AND a static list of banks in bank 0 at a completely unrelated location) - assuming we can code these, we can just throw some CPU and RAM at any gen 1 ROM, and we should at least never use any data structures that would crash our program, or Pokemon for that matter, if used in a certin way. That means we wouldn't need any magic lists, which I would like a lot better - apparently the common way of distributing these is through .ini files that SOMEONE has crafted SOMETIME in the past, with no real attribution or understanding going on... and that's not good. Let's do it right.
fuck I should have commited earlier, anyways tons of new features for yt added, doing shit for insta currently