2,660,813 events, 1,369,552 push events, 2,207,302 commit messages, 158,440,706 characters
0.8.8.1 Wanamingo death animation implementation without the bug fix because god officialy hates me when I'm sleeping, so he tries to persude my innocent body with the temptation of working. I'll be honest, I want a cute girl to headpat me. That's it. It's not asking too much, now is it? No lewd things, no weird shenanigans, just a complicated narrative between a man working for his dreams and a cute girl who can appretiate his efforts and therefore headpats him. What he doesn't know, however, is that she is being commanded by god to cause the bug, therefore invalidating both the efforts of the man she has developed a crush on, as well as the true meaning of the headpat. However, such a false sign of affection is enough for the man to arm up against the omnipotent being that controls his life, starting a war: his conditions total rebelion, god's being absolute victory. After countless crunch, the man lays defeated on the ground, having lost all of his team, sponsors, fanbase, and even Borja's cats, who he used to headpat. As god turns his back to return to his palace, a small figure approaches the weakened body. That same girl, with tears on her eyes, moves her hand onto the mans head. However, the feeling is totally different. Despite the sadness on her face, her hand feels like a giant mantle that could keep the warmth of his thoughts, and the flame of his heart. As their eyes cross, she reveals the truth, but also, the big news: "Borja's cat used to headpat me. And in his dying breath, he revealed he knew what I had been doing all along. Yet as his body consumed, he extended his fluffy paw and headpated my one last time. At that moment I understood that we all deserve to be headpated wholeheartedly." The prohibit act was brought upon this cursed land: the headpat cycle was completed between the three primal genders: man, woman and cat, now as one, defied the iron fist of God on the deadliest showdown of rock-paper-scissors. As god was defeated, it trembled at the thoght of his own death. The new ruler, however, simply extended his bright and piadous arm, and headpated god instead. The unknown feeling of comfy recognition, acceptance, tenderness, the sweet embrace of being a good boi and recieving your earned god dang headpats, was a new sensations to the previously all-knowing all-powerful being. Oceans rise, empires fall, nuclear storms appear at the call, babies stop shitting themselves, gatchas give you a 100% 5 stars ratios, and I become good at fighting games. The chaos and bloodshed, which are not the solution, mix with the order and goodness of the world. The final headpat had ocurred and after that, nothing else was worth existing on the universe, which colectively decided to colapse, as every single atom could feel the affective touch of the godly all-powerful headpat, the universe concentreted into a giant big hand, which collapsed, creating a new big bang. As life started sprouting again, headpats reappeared, only an inevitable reminder of the cycle of creation and destruction that this universe is subjected to
Well, that was way the fuck more trouble than it was worth. Wasted nearly a damn hour to a missing %>, then another half-hour getting the delete page to render. Eh, at least it works now.
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
Merge: Performance improvements.
This patchset brings some performance improvements and the addition of the LZO-RLE algorithm to the kernel, also usable in zram (yup, tested, works but LZ4 is still ok for us).
The main performance improvement is for SWAP space: the locking has changed and the swap cache is now split in 64MB trunks. This gives us a reduction of the median page fault latency of 375%, from 15uS to 4uS, and an improvement of 192% on the swap throughput (this includes "virtual" swap devices, like zRAM!). The real world user experience improvement of this on a mobile device is seen after a day or two of usage, where it usually starts losing just a little performance due to the large amount of apps kept open in background: now I cannot notice any more performance loss and the user experience is now basically the same as if the phone was in its first 2 hours of boot life.
Other performance improvements include, in short:
UDP v4/v6: 10% more performance on single RX queue
Userspace applications will be faster when checking running time of threads
2-5% improvements on heavy multipliers (yeah, not a lot, but was totally free...)
Improvements on rare conditions during sparsetruncate of about 0.3% to a
way more rare around 20% improvement (that's never gonna happen, but there
is no performance drop anywhere).
Tested on SoMC Tama Akatsuki RoW
This was taken from Repo: https://github.com/sonyxperiadev/kernel PR: 2039 ([2.3.2.r1.4] Performance improvements)
Bug 889911 - Switch xpcshell to SystemErrorReporter with a little bit of special magic. r=mrbkap
XPCShell currently overrides all the JSContexts whose creation it observes with its own custom error reporter. This reporter does all sorts of funny things which we try to clean up for the most part. But there are a few very intricate considerations at play.
First, the old xpcshell error reporter does some mumbo jumbo with the XPCCallContext stack to try to guess whether some other code might catch the exception. This is total garbage on a number of fronts, particularly because the XPCCallContext stack has no concept of saved frame chains, nested event loops, sandbox boundaries, origin boundaries, or any of the myriad of complicating factors that determine whether or not an exception will propagate.
So we get rid of it. But this causes some crazy debugger tests to fail, because they rely on an exception from uriloader/exthandler/nsHandlerService.js getting squelched, and can't handle anybody reporting errors to the console service at the particular moment of contortionism when the exception is raised. So we need to introduce an explicit mechanism to disable the error reporter here to keep things running.
Second, we have to be very careful about tracking the return status of the xpcshell binary. The old code would simply flag an error code if the error handler was invoked, and we can mostly continue to do that. But there are some complications. See the comments.
Finally, we don't anything analogous in XPCShellEnvironment, because I have patches in bug 889714 to remove its state-dependence on the error reporter. I'll switch it to SystemErrorReporter in that bug.
Add integration test that runs the app.
Pretty basic test, really: just runs the app using the default configuration (not that anything is actually configirable yet) and verifies that the output is kinda sorta okay.
Had to touch a stupid number of lines to accomplish this, though, as:
- The IT needs to deserialize the JSON output to verify it.
- In order to reuse those structs, I needed to add a
lib.rstarget. - I had to mark those structs as
Deserializeable, which required lifetime/ownership changes, as&'static strmembers can't be deserialized.
Anyways, it's done. I think. I'll have to let GH Actions actually run it, as my Linux box is off getting repaired at the moment.
"4:05pm. I am up. I should be working on Spiral. Let me try to ease myself into the current sample.
4:10pm. Not yet. I still feel like just dwelling on things. So let me do just that. I am tired of bed, so let me just sit here.
6:45pm. So I ended up thinking all this time in bed.
6:50pm. I enter this kind of mind state every once in a while. I stop to think at the meta level. What are my principles and what am I trying to accomplish. This plugin adventure taking so long without even starting has definitely been enough to unsettle me. So I'll take some time to resettle.
I have various thought going through my head.
One with respect to ML - I really do not want to pray for a mathematical miracle in the understanding of intelligence.
Over the past decade there have been no real breakthroughs and yet AI advanced just fine through steady and incremental optimization. Maybe the pieces really are out there and just haven't been put together. Maybe the OpenAI guys are right, but just haven't applied themselves correctly.
With regards to Spiral and programming in general - I keep wondering whether there is a point in optimizing my skills like this. In a way, these meaningless sample refactorings are an image of the past 5 years. Is there a point to this? I think that there is. In fact doing it the opposite way is meaningless.
6:55pm. If I keep improving eventually my skills will grow into having real world use.
Spiral - it started as a crude codegen, but eventually everything became about it. Because I do not know how to hit human level AI off the bat, I took a conservative approach and focused on my own skills instead. Doing it this way will eventually prove to be right.
Every programmer wants to be good, but you cannot really improve your skills without improving your tools. I need to get back to it. I need to focus on these samples and finish them. Typescript will rot my brain.
The way I programmed in 2018 where I worked on ML and Spiral side by side was right. I should get back to it. Once I get top down typing back online, I should have a much smoother workflow. That should be fun.
If learning is program search then optimizing the way I program is surely the way to go.
7:20pm. Just because I do not know how to win is no reason to stop fighting.
7:25pm. In terms of how long humans have existed, modern programming is at most 30 years old. I think Scheme only invented lexical scope in the 80s.
But that is really stretching it. In the 80s and even the 90s people were still using assembly because high level languages (such as C) were too slow. Modern programming is in the now.
It is not like math which is seemingly stuck in the 17th century.
The art of programming is still under development and won't happen separately from AI development. If something like AI was possible to figure out separately from computation, mathematicians would have long done it.
I need to become to programming what those old guys in wigs were to mathematics. I weave all the threads together into a coherent whole. The current state of math is like Javascript - the turd on the face of its respective domain. So science and programming respectively.
7:35pm. The new of hardware will nearly hit and I am still twiddling my thumbs here. Tomorrow, I will focus and deal with the sample I should have today.
I'll only have to bear Typescript for a little while longer. Doing the client side really won't take much code or effort at all."
pinctrl: Don't just pretend to protect pinctrl_maps, do it for real
Way back, when the world was a simpler place and there was no war, no evil, and no kernel bugs, there was just a single pinctrl lock. That was how the world was when (57291ce pinctrl: core device tree mapping table parsing support) was written. In that case, there were instances where the pinctrl mutex was already held when pinctrl_register_map() was called, hence a "locked" parameter was passed to the function to indicate that the mutex was already locked (so we shouldn't lock it again).
A few years ago in (42fed7b pinctrl: move subsystem mutex to pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex. ...but (oops) we forgot to re-think about the whole "locked" parameter for pinctrl_register_map(). Basically the "locked" parameter appears to still refer to whether the bigger pinctrl_dev mutex is locked, but we're using it to skip locks of our (now separate) pinctrl_maps_mutex.
That's kind of a bad thing(TM). Probably nobody noticed because most of the calls to pinctrl_register_map happen at boot time and we've got synchronous device probing. ...and even cases where we're asynchronous don't end up actually hitting the race too often. ...but after banging my head against the wall for a bug that reproduced 1 out of 1000 reboots and lots of looking through kgdb, I finally noticed this.
Anyway, we can now safely remove the "locked" parameter and go back to a war-free, evil-free, and kernel-bug-free world.
Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by: Doug Anderson [email protected] Signed-off-by: Linus Walleij [email protected]
Slowly going FUCKING INSANEEEEE
i hate you weapons system. oh i really do i think the amount of loathing i have for you isnt even able to verbally described in human tongue.
weapons rehaulatron 3000 game plays for time being, but you need to know what weapons are available.... yeah dont ask
Fix for the extremely slow model generation with some MySQL databases.
If one tries to generate the models on a MySQL database with a lot of databases and tables the generation is getting very slow (#329).
This seems to result from MySQL not optimizing queries on views very well.
The solution I have chosen and validated is to replace the table and schema in the subquery with the actual names instead of references to the parent queries.
The result for my system is insane and went down from over 9 hours to 4 seconds.
This fix is kinda ugly but straight forward and I think the speed advantage is worth it. Especially as the code is never being seen by anyone.
Update 00128.txt
aaron's updates: "i reshuffled the music again so here
changes (that i remember):
my kingdom pfhor a horse: now uses leela acoustic, because otherwise leela showed up twice in one chapter let sleeping gods die: uses aliens again, because guardians was too cheery eat s’pht and die: uses guardians, because i’d removed it from every other level in the game that used it pfhor får lamm: uses rapture, because i changed dread not to leela, and rapture fits this level perfectly dread not: uses leela, because you are reunited with leela on this level after hathor was impersonating her for two levels i’ve got a bad feeling about this: uses landing, because we wanted something grand and dark, and this brings it back full circle with the first mission where you’re serving hathor
i think that’s all of them? oh, also, i made a few of my latin translations a bit more reliable, i hope"
Create a first implementation using Rc<RefCell>. It sucks... fml.
The following is my current issue and the proposed solution which will be implemented in the following commit.
Creating a graph is especially hard is rust because of the borrow checker and the desire of immutability. The two possible ways I could devise was to use a shit ton of Rc<RefCell> so many states could point to a single state and a state can be mutated (so we can connect NFAs). The other problem with this solution is that RefCell cannot really go into a HashSet/HashMap since Hash in rust seems to want to hash based on data rather than memory location (or ptr value). The other solution was to use unsafe rust, I didn't try implementing this since I have a better solution now.
My current solution which is unimplemented is to simplify things. Instead of passing around State structs and connecting them to each other, which would lead to a single piece of data having many owners and gets tedious with rusts borrow checker, I will just represent states by integers. By doing this, instead of passing around ptrs which is quite annoying in rust, we pass integers which point to a location in a vector.
Lesson learned. Having just completed CS350 (intro to operating systems) at UWaterloo, I have gotten into a rhythm of passing around pointers and handling them on a very low level, even distinguishing between virtual and physical pointers. Coding like this in rust is a path to despair I think, handling ptrs like that is tough with the borrow checker. I think at a fundamental level, I have to learn more idiomatic rust.
I don't usually write commit messages like diary entries, but Rc<RefCell<>> everywhere had me very frustrated for this commit and I wanted to write down my thoughts so I don't repeat this in the future. I do like rust so far, but it can be frustrating.