2,909,411 events, 1,475,034 push events, 2,358,842 commit messages, 168,811,182 characters
Graphics Demo's War Against Eyes is Officially Over!
Dark mode is here, and oh boy did I have to do some questionable css to do it (blood to the css variables god).
Half the bulma css might be semi-broken, and this might not work in older browsers now, but hey, isn't that the price of progress? At least the color.js is more streamlined.
Code
print("Title of program: CCA Matching Personality test") print() print("Welcome to DHS! Please answer the following questions truthfully and we'll suggest a CCA for you!") print("Please respond with a number 1 - 5, where 1 is strongly disagree and 5 is strongly agree.") print()
tech1 = input("I enjoy building and fixing things.")
outdoor1 = input("I'll go crazy if I d my mind when i hear music.")
tech2 = input("I know how to build apps and websites.")
outdoor2 = input("I'm good with tying knots and ropes.")
music2 = input("I play a musical instrument well.")
tech3 = input("I love computers.")
outdoor3 = input("I don't mind the sun.")
music3 = input("I love playing my assigned instrument.")
tech_final = int(tech1) + int(tech2) outdoor_final = int(outdoor1) + int(outdoor2) music_final = int(music1)+ int(music2)
print()
if tech_final > outdoor_final and tech_final > music_final: print("You might be suitable for Infocomm club!") elif outdoor_final > music_final: print("You might be stuiable for ODAC!") else: print("You might be suitable for CO!")
"9am. Though it was 9:30pm, it was too early to go to bed at that time. Well, it is fine, but my rest was not great. Right now I feel groggy. Let me do my morning reading.
9:30am. Ok, one more chapter and then I will start. I will dedicate myself to dealing with packages. I am still thinking about how to do it. I thought of maybe making a supervisor that deals with multiple package servers, but nevermind that. I do not need concurrency for dealing with packages. I'll make that thing single threaded and have a single server manage all of them. That will make dealing with recursive checks easier.
9:35am. No, I like my concurrency. There is no need to lower it here.
9:50am. I am thinking about it. Let me turn off the router as I can't stop lurking Elaina threads.
9:55am. I have the whole day ahead of me. I have plenty of time to think before I start and that is what I am going to do.
10:05am. Ahhh, this desire.
A switch has been flipped in me. I keep thinking about the stock market and the knowledge that I finally have the ingredients I need to beat it are giving me focus.
Just what were those days of hardship for? In the end it all feels so simple.
There is no need for regrets. There is only desire in the end. It either drives you or it does not. Everything else is just foam on the waves.
10:15am. Right now, I feel like Livermore finally understanding what it means to sit tight. Even if I read his book, holding a position for over 3 months against market downturns would have been unthinkable to the past me.
I keep thinking about TAN. Sure I am bullish on it, but it is not like I expect it to go up 50% right away in the next 3 months. Even if it is going to double a few times, it is going to be a wild ride over the next 2 years. And I'd always need to be on guard in case the momentum is waning and this initial impulse turns out to be a dud. Given how stretched the market is, there will inevitably be shakeouts. Maybe TAN or ARKK will turn out surprisingly weak on market corrections and will force me take losses.
Either way, right now I want that hardship. Previously I only wanted to fit the market into a tight, understandable box. I wanted stocks to have the junk bond fund kind of persistent momentum. But now I want to stand against the waves, because I have the confidence I would be able to handle them.
10:25am. I want a fight.
Right now I can't trade, but what is a few years here and there to somebody taking the long term view?
10:30am. I am almost desire this as much as the Singularity right now. In the end, the markets won't matter, but this will of taking the long road will.
Really, the hardest thing in the world is what I've done so far - work every day for the past 5.5 years. And before that I spend so much time writing Simulacrum.
I see this as qualitatively different from my trading days when I only looked at charts and read the news. During the trading days, I fought to maintain a balance between hardness and laziness.
In contrast to this, holding a position and sitting on my ass would be nothing.
10:35am. It is not just stocks, holding a position that I will be able to make my agents and that I will be able to reach the Singularity is easy. The hard part is maintain that belief in the face of work.
Who wants to sit in this room constantly being faced with failure? Who wants to work for untold months on a language? Who wants to keep working on those agents that keep going nowhere?
Who wants to be looked down on for having ambition?
10:40am. But now most of my reasons for wanting something like money have died. The only thing I want it is because to some extent I need it, and because I want to prove that it is a triviality it really is. Peasants live their whole lives scrounging for such pitiful amounts. I want to go beyond that at least.
10:45am. It might be a triviality, but you need to look beyond the short term in order to be able to trully claim that.
And once you have that perspective, maybe having that perspective for its own sake is what really matters.
10:50am. That view really is power itself.
As I rant, I am thinking about the package server in the background.
I am pitting individual servers + a supervisor against having a single server that handles all of the files. The tug is going back and forth.
I think I know what scheme I want to use. Let me review the benefits and disadvantages of various approaches so I can explain my decision.
- Individual servers + a supervisor.
This was the first thing I started thinking about. It is a straightforward extension of the current scheme. Right now I already have the individual server. So I thought of making a special supervisor that checks for circularity.
The benefits of this is that it maximizes concurrency in the system.
Of course having high concurrency means having low control. That is the disadvantage. I am afraid that having circularity checking outside the individual packages might make compilation more difficult - it is possible to have concurrency bugs when the user triggers the build, but the individual servers are still working on their own thing.
So I do not really like this.
- Single server.
This would get rid of all the synchronization issues. This would even be easy to implement.
The issue is that every package would need to be loaded in sequential order. Right now my CPU is 4 cores so this is not a big deal, but I want to optimize the start up times. The place where doing things sequentially will hurt the most is right there.
So I have a proposal how to make this work.
I'll load the packages in a breadth first fashion.
Suppose I have packages A - Q W E B - R T Y C - Z X V
If I were loading the packages sequentially, that would be in the depth first fashion. A, then is packages Q W E, then B, then R T Y, then C, then Z X and lastly V.
There is a lot of potential for concurrency here. A B C are independent of one another, and so are their submodules. It would be good not to waste this opportunity.
Rather than strictly aiming to maximize concurrency, what I can do is first deal with A B C. Then I can deal with Q W E R T Y Z X V.
I can just start A B C as separate jobs. It would be a list of jobs. Then I'd just use ... Array.mapJob in order to map this to a single result. Or use Array.iterJobIgnore and just send a message to the server.
This would be really good.
12:20pm. I am brainstorming like crazy here. I figured out how to do loading fully concurrently within a single server.
12:30pm. Let me stop here.
12:35pm. I need to go through this brainstorming session and after that I'll be done."
Update AUTHORS
This repo uses the terms "The Hush developers" and "The Supernet developers" without them being defined, so we define them explicitly.
This repository was forked from jl777/komodo.git at a time when it had no LICENSE, AUTHORS or DEVELOPER_AGREEMENT files. I advised jl777, as an expert with 23 years of experience with open source and free software license, for him to fix it.
He did not listen to my advice correctly and hastily added some files to the LEGAL/ subdirectory and added himself as sole author, without consulting all people who had commit rights in the past and present. Additionally the new developer agreement including wording about closed source binaries that I would never have agreed to:
https://github.com/jl777/komodo/tree/master/LEGAL
Every source code file in the repo refers to files in the root directory of the repo, so jl777's "LEGAL hack" is not even legally binding in his own code repository, and doesn't even exist in this repository, because Hush v3 forked from KMD before I advised jl777 to fix the issue in his repo.
For the purposes of this code repository, "The Supernet developers" refers to people who were in AUTHORS previous to this commit. This commit clarifies the situation by defining "The Hush developers" explicitly and the fact that jl777 should not be considered a Hush Developer, unless he agrees to our new devloper agreement.
Additionally, The Supernet developers only released software under MIT/GPLv2 and the new policy of The Hush developers is to release all code under GPLv3 and to pursue violation enforcement to the fullest extent possible by law.
Mother fucking holly shit fucking mother fucker bullshit CMake
Address PR71 refactor (small changes, additions) (#77)
-
Maintenance: Adjust Screenshots to "new" look and feel
-
Maintenance: Fix 2020 emoji & add search function hint
Earlier version of this file was using a very current 2020 emoji which isn't available on a broad number of systems yet (magic wand). To improve compatibility we changed it to sparkle.
Also the hints on how an agent can adjust users was incomplete (search function was missing). In my opinion this is one of the most used ways and thus should be declared. This also helps admins to tell their users the options the agents have.
- Maintenance: Be a bit more specific
In order to solve the question "why don't I get notifications" ?
Earlier this was mentioned in within "the standard issue" on the example part:
"This provides the complete notification and ticket experience for the group in question."
Above should be enough though.
- Maintenance: Replace links to functionalities
Linking to administration documentation for permissions that are about agents is confusing in my opinion. Thus we're rather linking to the user documentation and provide hints on "hey, you gotta configure stuff first here".
The only exception is the reporting currently, because this needs work and love first.
- Maintenance: Readd "users are global" information
This is a common question on "how to restrict" users being available globally.
As this is not a function within Zammad, we should state it explicitly. This also fixes #46
- Maintenance: Re-add preference info & adjust ldap wording
A common confusion is that a customer gets the "notification" permission, but doesn't receive any system notification. To make this clearer from the beginning, I've added that one liner. (Flew below my radar earlier)
Regarding password permissions: Changing the user password when using LDAP does only "visually" drift passwords. In fact it actually sets a second password (a local one) which allows you to use two passwords, one local and one from your ldap source.
As Zammad does not change the ldap password for you, this will be confusing. This is why I adjusted the end of the sentence.
- Address Ryans suggestions
As per comments on PR#77
-
Move user being global hint to groups as suggested by Ryan
-
Update manage/roles/user-preferences-permissions.rst
Use Ryans suggestion to raise not too many questiosn but make clear that when using LDAP you should not allow affected users to set or change their password.
Co-authored-by: Ryan Lue [email protected]
Co-authored-by: Ryan Lue [email protected]
Time schedule (Morning walk, Breakfast, Lunch, Dinner and Sleep) program in C
"2:40pm. Let me shut down for a while. I am going to take a nap and think about it.
5:15pm. Done with lunch. I've been thinking about it all this while.
...It is hard. Nothing about the compilation pipeline is easy. It needs to be concurrent, but I am struggling to retain control once I introduce this concurrency.
5:25pm. I had a system for doing things, but introducing file ownership really threw a wrench into the whole thing.
I am going to have to go with the batch management scheme rather than relying on individual typechecker servers. Damn it.
I am really feeling a lot of pressure here.
There is no way around it. When the system is simple you can afford to keep it all together, but as it gets more complex, in order to retain efficiency you simply have to split it into concurrent pieces.
5:30pm. I'll call it a day here. No way can I start now. I am definitely going to bed early today and when it is time to start tomorrow I will be ready for hell.
This is just extremely difficult and I can't meet all my goals properly. I am going to have to go with what I have in mind - deal with packages and work from there.
I am going to have to make drastic changes to the current scheme to the point that I am better off dumping what I have and doing it from the top. I need to make up my mind and just do it.
Two monthly PL reviews ago, I said that my ETA is two months for Spiral's release, but I am going to have to necessarily miss that. Regardless, all the pieces are here, so if I sit down and start churning out code I will get something.
5:45pm. Days like today are the worst. They are the complete opposite of making consistent good progress. They are relentless inner struggle beyond the scope of a steady routine.
5:50pm. Usually when the day is over I'd read novels and waste time in a similar fashion, but right now I feel like getting away from everything. My mind feels scattered in a hundred directions. What I want to is re-establish my will.
Today, I figured out how to do proper concurrent module loading and combined with my improved knowledge of graph theory, I have everything I need to implement a proper project file manager. All I need to do is make that my starting point and move from there. i'll bring in my stream ideas and implement all the proper machinery.
I think a little and then I work a little. I go back and forth between the two phases. It is hard, but I will make progress that way.
6pm. Let me close for the day here. I am honestly considering just going to bed now. Going to bed this early would exhaust me mentally and leave me like that tomorrow, but the last thing I want right now is indulge in distractions. Even if it would be tiresome, this kind of hardship would hone my will. Right now I am not in the mood, but suppose I for example start reading novels and read those till 11pm. I'll got to bed and have a comfortable night, but that does not really leave me time to mediate on the task at hand.
6:10pm. Fun indulgences are only something I'll allow when things are going well.
Tomorrow I will let my hands do the talking. I will get back into the routine and I will keep going until I deal with compilation pipeline."
Improve incremental builds by 710% by dropping webpack
I spent this morning messing with drawing a voting screen, which for someone who isn't good at geometry involves a lot of trial and error, and the incremental build perf started to really get to me.
So, currently we're using webpack to bundle our JS for production, and for a devserver. That came in from the wasm-pack starter kit so I figured it was a reasonable enough choice. However, we've got just a couple KB of JS, basically the entire project is written in Rust, and it seemed like webpack was taking a decent amount of time to build, so I wanted to see if we could do better.
I started out doing a few timing runs of incremental builds and wasm-pack -> webpack commands were together taking ~12s. The first thing I tried was to upgrade to webpack 5, which is supposed to have better caching and maybe be faster. Looks like it makes our build about 1s slower, so that's no help.
Looking at the output that wasm-pack was producing, it included a synchronous import of the generated .wasm file which isn't yet standard (though import assertions are probably going to unblock making that work, the syntax is likely to be import game from "./client.wasm" assert { type: "wasm" };).
It turns out that wasm-pack by default runs with --target bundler which emits code designed for webpack to consume. Kinda gross to emit pseudostandard output by default, but it means that your imports can all by synchronous which is kinda nice. But there's a --target web version, what's that do?
Well, while the import syntax is worked out, there are some interim methods for loading and instantiating a WebAssembly module. Because they involve loading data from the network they're asynchronous, but that's no big deal, our initialization function is already async, so we can just add an async initWasm() no problem. With that, we can drop webpack entirely, bringing us down from 12s to 4s.
3x faster!? Our 90% Rust project that has one JS file and zero JS dependencies was spending 3s in webpack for every second in the Rust compiler? The infamously slow Rust compiler that everyone warns you about when you say you're gonna try out this new Rust thing?
But then, poking around a bit, it turns out that's just the start! Because I switched us run wasm-pack with the --release flag even during development because it was net faster, as the larger unoptimized wasm file made webpack take tens of seconds to process. With webpack out of the picture we can afford to run in dev mode, which gets the build time down to 1.69s! That's 7x faster!
The difference is night and day, finally I can quickly iterate again!
Now potentially we'd still want to do some bundling, maybe if we add more JS to our repo. Seems like esbuild is a good option there if we go that route. For a devserver I'm using @web/dev-server just for livereload, but it can also downlevel if we end up needing that.
Hungry Shark
Project Description: This game design document shows the information about the multi-platform based 2D game in which the player eats fish to get full. This game is an underwater concept and plays with a character gaining points and avoid touching the bombs.
Character: The main character of the story is the shark who seek a food for his hungry tummy. This character is big, strong and wild character who can eat fishes as many as he can.
Story: There was a Shark who is very hungry and find something to eat. He keeps on swimming and finally found huge number of fishes at the center of the ocean where it is a chance that he can provide his starvation. Suddenly, he did not expect there were bombs in the ocean which is also a disadvantage of losing his life. A thing which he can survive is to avoid of touching the bombs.
Theme/Gameplay: Hungry Shark is an underwater theme as what a real shark lives in the sea. You can see the beauty of sea creatures. There are also different speeds if the sharks get into higher points. • GOALS: Shark needs to eat fishes and avoid touching the bombs to survive. • USER SKILLS: Just tap the screen or mouse to swim • PROGRESSION AND CHALLENGING: Increasing of speed • Losing: The losing part of the game is when the shark touches the one of the bombs.
Art Style: This is a 2D adventure game composes gradient color white and blue for water, plants, rocks, soil in results of a colorful background. The shark character is mixed with dark blue and light blue while fishes looks like ‘nemo’.
Music and sounds: background: baby shark minus-one by pinkfong eat fish: eating cookie sound lose game: disc stops sound effect Technical Description: The game will be used on: IOS, Android and PC. · Controls: Tap to start, play and restart · Fonts: Minecraftia · Graphics: 1.Character: Shark 2. Ambient(background): Background: showing the different places in the world (location is changing if the player moves to the next level) Dart board: uses colors black, green,white Scoreboard: places at the upper left corner(Arial font) Border: Metal gray Demographics: Age: 5 years old and above Sex: Everyone Platforms & Monetization: Free to download on android app, iOS, windows(PC) with in-game ads.
Merge pull request #8 from notseanyay/master
this made me mad fuck you