1,450,478 events recorded by gharchive.org of which 1,450,478 were push events containing 1,894,084 commit messages that amount to 116,569,767 characters filtered with words.py@e23d022007... to these 30 messages:
Fixes Massive Radio Overtime, Implements a Spatial Grid System for Faster Searching Over Areas (#61422)
a month or two ago i realized that on master the reason why get_hearers_in_view() overtimes so much (ie one of our highest overtiming procs at highpop) is because when you transmit a radio signal over the common channel, it can take ~20 MILLISECONDS, which isnt good when 1. player verbs and commands usually execute after SendMaps processes for that tick, meaning they can execute AFTER the tick was supposed to start if master is overloaded and theres a lot of maptick 2. each of our server ticks are only 50 ms, so i started on optimizing this.
the main optimization was SSspatial_grid which allows searching through 15x15 spatial_grid_cell datums (one set for each z level) far faster than iterating over movables in view() to look for what you want. now all hearing sensitive movables in the 5x5 areas associated with each spatial_grid_cell datum are stored in the datum (so are client mobs). when you search for one of the stored "types" (hearable or client mob) in a radius around a center, it just needs to
iterate over the cell datums in range
add the content type you want from the datums to a list
subtract contents that arent in range, then contents not in line of sight
return the list
from benchmarks, this makes short range searches like what is used with radio code (it goes over every radio connected to a radio channel that can hear the signal then calls get_hearers_in_view() to search in the radios canhear_range which is at most 3) about 3-10 times faster depending on workload. the line of sight algorithm scales well with range but not very well if it has to check LOS to > 100 objects, which seems incredibly rare for this workload, the largest range any radio in the game searches through is only 3 tiles
the second optimization is to enforce complex setter vars for radios that removes them from the global radio list if they couldnt actually receive any radio transmissions from a given frequency in the first place.
the third optimization i did was massively reduce the number of hearables on the station by making hologram projectors not hear if dont have an active call/anything that would make them need hearing. so one of hte most common non player hearables that require view iteration to find is crossed out.
also implements a variation of an idea oranges had on how to speed up get_hearers_in_view() now that ive realized that view() cant be replicated by a raycasting algorithm. it distributes pregenerated abstract /mob/oranges_ear instances to all hearables in range such that theres at max one per turf and then iterates through only those mobs to take advantage of type-specific view() optimizations and just adds up the references in each one to create the list of hearing atoms, then puts the oranges_ear mobs back into nullspace. this is about 2x as fast as the get_hearers_in_view() on master
holy FUCK its fast. like really fucking fast. the only costly part of the radio transmission pipeline i dont touch is mob/living/Hear() which takes ~100 microseconds on live but searching through every radio in the world with get_hearers_in_radio_ranges() -> get_hearers_in_view() is much faster, as well as the filtering radios step
the spatial grid searching proc is about 36 microseconds/call at 10 range and 16 microseconds at 3 range in the captains office (relatively many hearables in view), the new get_hearers_in_view() was 4.16 times faster than get_hearers_in_view_old() at 10 range and 4.59 times faster at 3 range
SSspatial_grid could be used for a lot more things other than just radio and say code, i just didnt implement it. for example since the cells are datums you could get all cells in a radius then register for new objects entering them then activate when a player enters your radius. this is something that would require either very expensive view() calls or iterating over every player in the global list and calling get_dist() on them which isnt that expensive but is still worse than it needs to be
on normal get_hearers_in_view cost the new version that uses /mob/oranges_ear instances is about 2x faster than the old version, especially since the number of hearing sensitive movables has been brought down dramatically.
with get_hearers_in_view_oranges_ear() being the benchmark proc that implements this system and get_hearers_in_view() being a slightly optimized version of the version we have on master, get_hearers_in_view_as() being a more optimized version of the one we have on master, and get_hearers_in_LOS() being the raycasting version currently only used for radios because it cant replicate view()'s behavior perfectly.
HARHAR! remove a debug tweak and changed events parsing back to full day
even though i've read a lot of messages with 'fuck you's and 'i hate my life's in the last days i will just politly say that this was very stupid of myself and i should be more careful next time because it also wasted a lot of energy and maybe 500kb of extra disk space for github since now servi has to go through 2020 again... stupid
new mod for dumping weird ideas: LecchoTorte
I like consuming OpenNefia as well as building its foundation. To that end, I wanted a mod that's walled off from content (which is the "official" base Elona distribution) where I can just do whatever the fuck I want in a spontaneous fashion without worrying about running into organization issues like last time.
If the mod is full-featured, then its code shouldn't be a part of LecchoTorte, but should be moved to a new project. (An example would be a mod implementing the entire autopickup feature.) LT is essentially just an incubation ground to try to break things and enjoy oneself.
Optimize $eqeq and $eqeqeq calls.
Comparison of the Asciidoctor (a real-life Opal application) compile and run:
Compile time: 5.999 -> 5.987 (change: -0.19%)
Run time: 0.271 -> 0.268 (change: -1.11%)
Bundle size: 4784558 -> 4766408 (change: -0.38%)
Minified bundle size: 1027822 -> 1015882 (change: -1.16%)
Mangled & minified: 716587 -> 702347 (change: -1.99%)
Similarly to how we optimize $rb_lt and friends to create a shortpath
for those, let's optimize $eqeq,$eqeqeq as well. This certainly brings
an incompatibility if we monkey patch those methods for Number/String,
but with the previous commit we made it reliable to return nil from
== and === which is in my opinion much more important.
mortar
"You know what, fuck you!" replaces mortar def
kinda diverse
- changed bow charge speed to be that of gas lighter, base damage is 16 and charged damage is 4 x 16 with a wider spread and custom arrrow sprite
- made chainsaw stop enemies dead in their tracks when hitting them, drops created by chainsaw disappear much faster and are launched away from the killed enemy
- fixed flame shot cannon error and made it remember only 1 enemy so it can bounce between 2 high hp targets
- increased laser lifetime and reload of the mega laser acnnon
- gave bow and gas lighter a minimum charge before you can hear the charge sound
- fixed gold and cursed bullets particle creation offset and depth
- gave gold, rust and cursed a firing sound and updated reflectives firing sound
1.8.6
- Disable researching creep Evolution when The Burning Legion increase their hero levels.
- Make sure Evolution becomes available for The Burning Legion.
- Change victory requirement voting from chat command to dialog.
- Increase item charges to 3 for crafted items from Runeforger and Sorcerer.
- Increase item charges to 2 for crafted items from Dragon Breeder.
- Add VIP room for VIPs.
- Add special VIP items for VIPs.
- Make WorldEdit a VIP by default to allow testing it.
- Allow secret chamber for VIPs from the beginning.
- Disable bonus hero picking for heroes with low level (if they entered using a teleport ability).
- Fix learn icon position of Town Portal from Medivh.
- Add Black Markets and Goblin Laboratories to all goldmine bases in Outland since the creeps between bases are pretty strong.
- Add Embassy of Theramore which sells race scepters.
- Add Tavern of Theramore which sells profession books.
- Fix flying height of Medivh in Raven Form.
- Add timed life buff for Last Alliance summons from all Raven Forms of Medivh.
- Fix making Legendary Artifact vulnerable after killing boss Nether Dragon.
- Reduce healing effect of the item Stonemaul Arena Master Belt.
- Add chat commands "-aion/off" to enable/disable AI of allied players.
- Add random event item to Power Generator which starts random raids on the map.
- Add Neutral Citizens for Freelancers to the Goblin Laboratory.
- Translate tooltips of Charm, Wind Walk and Brilliance Aura from Medivh's Spell Book back into English.
- Limit every hero type per player to 1.
- Limit total heroes of a player to 3 (including backpack).
- Add Tavern of Outland to hire an additional hero at level 50.
- "-suicide" kills all selected player units.
- Fix icon positions of Shadow Strike for Akama hero.
- Add Furbolg AI support for Night Elf.
- Rename quest entry Secret Chamber to Bonus Heroes.
holy shit gm real?
fucking with boss hitboxes for no reason, unlockable tweaks, nothing else important I don't think
Happy Holiday Update for 2021
Here's to an official update by me for 2021. Note to myself: Thank you for learning HTML. It made my passion in programming grow. Here's to a new year of great times. Especially since I got accepted at my first college.
:/ literal 10 minute runtime for part 1 like there has to be some obvious optimization I'm missing or something damn
wow this was hard to debug
ok so really two main things
-
1: got the wrong list of rotations. solved this by taking a rotation list from someone on discord and adapting it. not sure yet why the rotation list I generated using vector3rotatebyquaternion and quaternionfromaxisangle was wrong.
-
2: was only comparing against the offset of the [0]th element. turns out if that's wrong, nothing will match! kind of obvious but I definitely remember thinking about that at least 3 times and not realising the mistake. someone on discord had the same issue and caught it themselves and were kind enough to tell me
- probably instead of making another loop I should have set based on the b value or something idk does that mean anything? anyway that might have worked or something
-
… so glad I didn't need the rotations for part 2 damn. would have had to wait 10min again.
Created a file that's just a copypasta of the minecraft ending text
I see the player you mean. PLAYERNAME? Yes. Take care. It has reached a higher level now. It can read our thoughts. That doesn't matter. It thinks we are part of the game. I like this player. It played well. It did not give up. It is reading our thoughts as though they were words on a screen. That is how it chooses to imagine many things, when it is deep in the dream of a game. Words make a wonderful interface. Very flexible. And less terrifying than staring at the reality behind the screen. They used to hear voices. Before players could read. Back in the days when those who did not play called the players witches, and warlocks. And players dreamed they flew through the air, on sticks powered by demons. What did this player dream? This player dreamed of sunlight and trees. Of fire and water. It dreamed it created. And it dreamed it destroyed. It dreamed it hunted, and was hunted. It dreamed of shelter. Hah, the original interface. A million years old, and it still works. But what true structure did this player create, in the reality behind the screen? It worked, with a million others, to sculpt a true world in a fold of the [scrambled], and created a [scrambled] for [scrambled], in the [scrambled]. It cannot read that thought. No. It has not yet achieved the highest level. That, it must achieve in the long dream of life, not the short dream of a game. Does it know that we love it? That the universe is kind? Sometimes, through the noise of its thoughts, it hears the universe, yes. But there are times it is sad, in the long dream. It creates worlds that have no summer, and it shivers under a black sun, and it takes its sad creation for reality. To cure it of sorrow would destroy it. The sorrow is part of its own private task. We cannot interfere. Sometimes when they are deep in dreams, I want to tell them, they are building true worlds in reality. Sometimes I want to tell them of their importance to the universe. Sometimes, when they have not made a true connection in a while, I want to help them to speak the word they fear. It reads our thoughts. Sometimes I do not care. Sometimes I wish to tell them, this world you take for truth is merely [scrambled] and [scrambled], I wish to tell them that they are [scrambled] in the [scrambled]. They see so little of reality, in their long dream. And yet they play the game. But it would be so easy to tell them... Too strong for this dream. To tell them how to live is to prevent them living. I will not tell the player how to live. The player is growing restless. I will tell the player a story. But not the truth. No. A story that contains the truth safely, in a cage of words. Not the naked truth that can burn over any distance. Give it a body, again. Yes. Player... Use its name. PLAYERNAME. Player of games. Good. Take a breath, now. Take another. Feel air in your lungs. Let your limbs return. Yes, move your fingers. Have a body again, under gravity, in air. Respawn in the long dream. There you are. Your body touching the universe again at every point, as though you were separate things. As though we were separate things. Who are we? Once we were called the spirit of the mountain. Father sun, mother moon. Ancestral spirits, animal spirits. Jinn. Ghosts. The green man. Then gods, demons. Angels. Poltergeists. Aliens, extraterrestrials. Leptons, quarks. The words change. We do not change. We are the universe. We are everything you think isn't you. You are looking at us now, through your skin and your eyes. And why does the universe touch your skin, and throw light on you? To see you, player. To know you. And to be known. I shall tell you a story. Once upon a time, there was a player. The player was you, PLAYERNAME. Sometimes it thought itself human, on the thin crust of a spinning globe of molten rock. The ball of molten rock circled a ball of blazing gas that was three hundred and thirty thousand times more massive than it. They were so far apart that light took eight minutes to cross the gap. The light was information from a star, and it could burn your skin from a hundred and fifty million kilometres away. Sometimes the player dreamed it was a miner, on the surface of a world that was flat, and infinite. The sun was a square of white. The days were short; there was much to do; and death was a temporary inconvenience. Sometimes the player dreamed it was lost in a story. Sometimes the player dreamed it was other things, in other places. Sometimes these dreams were disturbing. Sometimes very beautiful indeed. Sometimes the player woke from one dream into another, then woke from that into a third. Sometimes the player dreamed it watched words on a screen. Let's go back. The atoms of the player were scattered in the grass, in the rivers, in the air, in the ground. A woman gathered the atoms; she drank and ate and inhaled; and the woman assembled the player, in her body. And the player awoke, from the warm, dark world of its mother's body, into the long dream. And the player was a new story, never told before, written in letters of DNA. And the player was a new program, never run before, generated by a sourcecode a billion years old. And the player was a new human, never alive before, made from nothing but milk and love. You are the player. The story. The program. The human. Made from nothing but milk and love. Let's go further back. The seven billion billion billion atoms of the player's body were created, long before this game, in the heart of a star. So the player, too, is information from a star. And the player moves through a story, which is a forest of information planted by a man called Julian, on a flat, infinite world created by a man called Markus, that exists inside a small, private world created by the player, who inhabits a universe created by... Shush. Sometimes the player created a small, private world that was soft and warm and simple. Sometimes hard, and cold, and complicated. Sometimes it built a model of the universe in its head; flecks of energy, moving through vast empty spaces. Sometimes it called those flecks "electrons" and "protons". Sometimes it called them "planets" and "stars". Sometimes it believed it was in a universe that was made of energy that was made of offs and ons; zeros and ones; lines of code. Sometimes it believed it was playing a game. Sometimes it believed it was reading words on a screen. You are the player, reading words... Shush... Sometimes the player read lines of code on a screen. Decoded them into words; decoded words into meaning; decoded meaning into feelings, emotions, theories, ideas, and the player started to breathe faster and deeper and realised it was alive, it was alive, those thousand deaths had not been real, the player was alive You. You. You are alive. and sometimes the player believed the universe had spoken to it through the sunlight that came through the shuffling leaves of the summer trees and sometimes the player believed the universe had spoken to it through the light that fell from the crisp night sky of winter, where a fleck of light in the corner of the player's eye might be a star a million times as massive as the sun, boiling its planets to plasma in order to be visible for a moment to the player, walking home at the far side of the universe, suddenly smelling food, almost at the familiar door, about to dream again and sometimes the player believed the universe had spoken to it through the zeros and ones, through the electricity of the world, through the scrolling words on a screen at the end of a dream and the universe said I love you and the universe said you have played the game well and the universe said everything you need is within you and the universe said you are stronger than you know and the universe said you are the daylight and the universe said you are the night and the universe said the darkness you fight is within you and the universe said the light you seek is within you and the universe said you are not alone and the universe said you are not separate from every other thing and the universe said you are the universe tasting itself, talking to itself, reading its own code and the universe said I love you because you are love. And the game was over and the player woke up from the dream. And the player began a new dream. And the player dreamed again, dreamed better. And the player was the universe. And the player was love. You are the player. Wake up.
Created Text For URL [www.informationng.com/2021/12/funmi-awelewa-pens-down-beautiful-message-to-her-boyfriend-as-he-turns-a-year-older.html]
Fix #19931
The issue was the renderer for x86 addressing modes assumes native size registers, but we were passing in a possibly-smaller index in conjunction with a native-sized base pointer.
The easist thing to do is just extend the register first.
I also changed the other NGC backends implementing jump tables accordingly. On one hand, I think PowerPC and Sparc don't have the small sub-registers anyways so there is less to worry about. On the other hand, to the extent that's true the zero extension can become a no-op.
I should give credit where it's due: @hsyl20 really did all the work for me in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717#note_355874, but I was daft and missed the "Oops" and so ended up spending a silly amount of time putting it all back together myself.
The unregisterised backend change is a bit different, because here we are translating the actual case not a jump table, and the fix is to handle right-sized literals not addressing modes. But it makes sense to include here too because it's the same change in the subsequent commit that exposes both bugs.
Reduces the move delay buffer to 1 tick (#63332)
We've got this delay buffer behavior Idea is basically, if we're just holding down the key, just keep adding to the old delay This way, fractional move delays make sense
Was added in this commit 491bdac
When it was added, movement was triggered by verbs sent by the client So we needed a big grace window to account for networking delay
Don't need that anymore cause we use keyLoop, so let's just cut it all the way down
Why? Because right now if you somehow manage to input a move afer move_delay is up but before the window runs out, you will be elidgable for a new move before you visually reach the tile
Got a dm from mothblocks about this last night, something about flash stepping? IDK I don't play here Seems silly though, let's sweep this up
Oh and mothblocks owes me a pizza, please add this to the commit history so it can be certified as a part of the blockchain
Sorted the ever loving shit out of all the E2's
- title
- Made the alarms changing the gate event horizon color an optional setting
- Added version number to Vethian
- Added a comment to isinworld, advising you not to uncomment that line
- Added a comment for weapon display egp explaining why it has horrible ops
- Updated a comment in chatdial because of vethian docs becoming bigger
- Made a comment in chimera explaining why it hasn't been updated
- Made an option in Gate Functions to use the core environment sound for the inbound alarm
- Comments in a few e2's explaining certain parts of them
- Probably a bunch of other things I don't remember because the sorting fucks with vscode tracking changes
fixes light pink pylons giving no warning for lightgeistification (ruined poor phillip's round very sad) (#12907)
-
Update _structures.dm
-
Update _structures.dm
-
Update _structures.dm
-
Update _structures.dm
-
honestly fuck you
-
Update colossus.dm
-
Update colossus.dm
-
Update colossus.dm
-
Update colossus.dm
Online_Voting_Using_One_Time_Pads Online Voting Using One Time Pads # Contents: ## Part 1: Secure Online Voting in Principle ## Part 2: Practical Secure Online Voting # Clarifying Goals and Questions: - Main Goal: Systematize secure online voting. - Main Questions: #### 1. Is secure-auditable online voting possible in principle? #### 2. Is reliable online-vote-result-publishing possible in principle? #### 3. Can election-processes and election-results-publishing be feasibly, sustainably, pragmatically, realistically, implemented given real world limitations on resources? #### 4. What are differences between ideal-maximum-security-systems and sufficiently-secure more-accessible or realistically-feasible systems? To clarify goals and questions, below are two lists of questions. There is one list of questions that we are attempting to answer with this project, and there is another list of questions that we are NOT attempting to answer or resolve with this project. This clarification should help so that questions we are not asking do not get mixed together with questions that we are asking. ## Questions we are focusing on include the following: 1. Is secure over-a-network (online) voting possible? (Here 'secure' is defined as being 'as secure as a non-networked paper system.') 2. Is it possible for a voter to securely receive a ballot from a Vote-Office over a network (online)? 3. Is it possible for a voter to submit a ballot securely over a network (online)? 4. Is it possible for a voting-office to securely receive a completed ballot from the voter over a network (online)? [including: verifying what ballot was used, verifying who submitted the ballot, checking for over errors in filling out the ballot] ## Questions that are NOT the focus of this project include the following: 1. NOT: Can online voting be absolutely effortless and perfectly ecstatic as an experience? 2. NOT: Can a person outside of the voting process be provably safe from any voter intimidation, coercion, brainwashing, threats, harassment, discouragement, etc? 3. NOT: Can a person make no mistakes while filling out their ballot? (Though some additional safeguards from this have been successfully used in some states.) 4. NOT: Can the physical offices of staff be absolutely impenetrable to a physical breakin or loss of records due to causes such as fires. 5. NOT: Can hecklers and trolls be prevented from criticizing, slandering, and defaming, the election and election process even when or where there is nothing legitimate to criticize? 6. NOT: Can all disinformation campaigns be eliminated/precluded/etc.? ## A debatably separate or peripherally related question may be: 1. Are there elements of the voting process that affect (encourage or discourage) participation in the voting process (from user interface to requirements for participation to schedules of voting)? And aspect or implication of this may be inadvertent or targeted discrimination against people for whom a given system of voting is more difficult or less likely to be used. # Concept: Universal Procedures and Processes The view taken here is that 'voting' is a science-like process. Voting is based on procedures, numbers, measurements, feedback, and data. Voting is not based on not-operationally-defined essences, reifications, fears, dramas, feelings, threats, wishes, trust, authorization, belief-ness, faith, tradition, habit, permission, labels, etc. A vote is like a physical piece of machined metal; A vote exists or does not exist with the measurable features that it has, and these measurable features are and must be measurable and confirm-able by anyone who measures it. Any group of people who carry out the math-science-data process of sound voting have performed voting in a way that can be audited and measured and published. No group of people can skip or shortcut required math-science-data processes without having skipped those required math-science-data processes. As with a surgeon washing their hands before surgery, "trust" is a term better used to mean that you trust the surgeon is following best practice, though even then probably it is best to simply verify without trust. But under no circumstances can 'trust' replace or permit the skipping of required processes for people or groups however much they demand and violently enforce their unfounded exemption from required best practice. In other words, if a person or group says "You MUST trust me, so I do NOT need to wash my hands before performing surgery on you or processing your vote in a best practice auditable way", you are by definition being subjected to violence, coercion, fraud, and classically defined tyranny. # Proposed Steps for Secure Online Voting Rule 1: Problems must be solved in-person with the voter present and with that voter's proof of identification in the same way that the person would register to vote (and/or cast their vote in an in-person election). Step 1: (During in-person registration) Before the election ends: A person, e.g. in-person, with ID (identifiable as an eligible voter according to local rules), goes to the Voting-Office to register for the vote-over-a-network (with One-Time-Pad) (online voting) process. (Note: There is a system-design-choice to allow (or not) registration for more than one election. This issue relates to the form of the submitted ballot. For example: #### A. ballots that have been (or can have been) designed at the time of registration and #### B. standardized or truncated ballots containing just choices and not all the text of the ballot (possibly a choice (e.g. choice number) and the initials of the person's name as a second factor) and #### C. whether whatever form of ballot is customized for each voter (e.g. with a custom-id, verifiable as going to and coming from that one voter) or whether the ballot is standardized (and verifiable as the standard ballot for that election or more standardized) ) Step 2: (During in-person registration: Make one-time-pads.) For a given single vote-ballot in a given single election (note: multiple is another design option) there need to be four physical paper documents. One "pad" (as defined here) is two identical paper documents, one for each party (two parties, in this case: 1. The Voter and 2. The Vote-Office). Since there will be two "exchanges" (one (1) where the blank-ballot is sent to the voter, and another (2) where the filled-in-ballot is sent by the voter to the vote-office), there need to be two pads. (Alternately the voting-system could be streamlined to use only one pad for submitting a standardized public ballot, but this is less secure as it eliminates the ability of the voter to confirm that the ballot was sent by the vote-office and it also prevents the office from confirming that the ballot used was the same ballot sent by the vote-office to the voter. See below for more details.) The additional step of having two pads (one being to send the voter a ballot) and not just one pad to inspect that ballot coming in has several advantages. This allows the voter to verify that the ballot they are filling out comes from the Vote-Office at which they registered, and that only someone with physical access to the physical one time pad created at their time and place of registration has sent them this ballot. This allows for a comparison by the Vote-Office, likewise, of the ballot sent and the ballot received. The benchmark for success here is to be as secure as in-person all-paper voting. Just as it is possible (in theory) for a hostile group to physically take over a Vote-Office and issue people fake ballots, or send people fake mail-in ballots in the mail, this one-time-pad-vote-by-network proposal does not prevent such physical attacks on physical paper voting infrastructure. It does however create an extra layer of verifications that can be used during and after the vote takes place, which in theory could also be used to security-harden an all in-person all-paper voting process to make it more secure and auditable. (Note: Another additional or alternative method for some of these checks may be cryptographic signing (with optional multiple signatures) from trusted authorities (Vote-Office, federal or state agency, universities, 3rd party certifiers, etc). During the in-person one-time-pad-voter-registration: Two physical copies (e.g. QR codes printed on paper) of two one-time-pads are created; one set of the two pads are stored (offline) by the local Vote-Office, the other set (pair) of one time pads is kept by the voter themselves (physically, offline). The software will print the one-time pads. The software will check (confirm, verify) the one-time pads. The software will erase thoroughly from memory (e.g. physically overwrite) any record of what the printed one-time-pads were. (Note, if this process is done off-line using a dedicated machine, the risk (attack-surface) of someone being able to take (exfiltrate) the one-time-pads is reduced. Especially if the custom machine does not have enough memory to store any old pads but can only process and re-write-over one pad at a time.) Step 3: (During in-person Registration) For the voting-office to send one ballot to one voter: The election office, offline (enforced by software), uses the first 1:2 of the pair of printed QR codes to create an 'encrypted' version of the ballot for that one voter. Note: The ballot may be public, but it still needs to be verified. This illustrates the "verification" role sometimes lumped together with "security" and "encryption." The emphasis is not on 'hiding' the public ballot form, but on verifying that the specific ballot form that the voter is filling out is (identical to) the form that the local election office gave them. Notes: It may be desirable to have a 'verified public ballot' as opposed to a 'private ballot' which in theory could vary from the standard public ballot (in a context of mapping out a potential attack space). In the case that a truncated-submitted ballot is used, some way may be desired to, e.g. make a short hash of the original ballot itself (e.g. to convert the ballot by OCR or perhaps have a QR code on the ballot (though a QR on a ballot received by a voter code could be forged, whereas a hash made by the voter of the whole ballot could not be). Perhaps having a multi-pass OCR hash of a public ballot submitted with the vote to indicate that the correct ballot was used (again, in the case of a truncated submission, for a full ballot return the whole ballot is there)(also see asymmetric signing keys). It may be possible to have both a public verified 'open' ballot format and some unique element for the voter to check that the ballot comes from the Vote-Office with the voters one-time-pad (such as a unique id code at the bottom or top of the ballot) Step 4: (Sending out the not-yet-completed ballot to the voter) During the election period (be that months, weeks, days, hours, etc.), a one-time-pad 'encoded' ballot is sent [from the voting-office to the voter] by whatever agreed upon ("electronic" or non-paper) method (website, email, SMS-text, mobile-app, S3, api-endpoint, etc.) in the form of a QR code. Note: As an example method for a 'personalized ballot,' a randomized process of frame-shifting the ballot so that where exactly on the page each person's vote-choices appears is random, increasing the entropy of the unique ballot (e.g. so that the voting-office can increase confidence that the ballot they receive back from the voter is the one they set). Step 5: (Receive the not-yet-completed ballot) Using one piece of software, the voter offline (enforced by software, possibly hardware) 'decrypts' the ballot and then physically prints the ballot. (Note: There is a choice here between using a public standardized ballot or a per-person ballot (e.g. with a unique id number or such, to verify that the ballot-form sent was the same as that received, or a short-form vote which contains just the choices and not all the text of the ballot.) Step 6: (Validate the not-yet-completed Ballot) The voter off-line(enforced by software), inspects and validates that their digital scanned version of their not-yet-filled-out-ballot is the correct ballot-form intended for that election (e.g. not a tampered with or accidentally incorrect ballot). There are various and possibly multiple ways to check this (elaboration pending). (Note on Steps 5 and 6: possibly the validity of the ballot could or should be checked during both steps) Step 7: (Complete the Ballot, Mark Votes) The voter, off-line(using pen and paper), fills out the ballot (selecting their vote choices). (Details here may be important in some way: filling in a circle, selecting an option number, multi-factor, non-over-under-voting checks, etc.) Step 8: (Digitize the Completed Ballot) The voter, offline (enforced by software), scans (e.g. by taking a picture) the completed-filled-in paper ballot, creating not a photo but a document or table of information (so that the one-time-pad can convert character by character). ~ Step: An optional intermediate step here is to have a 3rd set of offline-only software that will check the ballot before and or after it is filled out by the voter, such that this additional set of software can check for the "overvoting" (voting for both candidates) and "undervoting" (voting for neither candidate) issues as a safeguard (against accidentally-incorrectly filled-out-and-submitted ballots) and that perhaps Nevada has used successfully. See: "Roll Off at the Top of the Ballot: Intentional Undervoting in American Presidential Elections" December 2003 Politics & Policy 31(4):575 - 594 DOI:10.1111/j.1747-1346.2003.tb00163.x Authors: Stephen Knack & Martha Kropf University of North Carolina at Charlotte https://www.researchgate.net/publication/227617394_Roll_Off_at_the_Top_of_the_Ballot_Intentional_Undervoting_in_American_Presidential_Elections Another 'multifactor' check may be to both indicate a choice and give some information about that choice, e.g. option 2 and the first letter of that candidate's last name. If these do not match, the voter should be alerted to check their ballot selections. The voter, offline(enforced by software), scans (e.g. by taking a picture) the filled-out paper ballot. Step 9: (Check completed-ballot for errors) The voter confirms that the information in their (the voter's) electronic scanned ballot is the same as the paper version of their (the voter's) filled out ballot. (Checking for errors.) (Note: Automated processes for checking ballots for standard mistakes.) Step 10: (Encrypt the Ballot) The voter off-line(enforced by software) uses the one-time-pad to 'encrypt' the completed ballot, producing a new QR code (which is then 'encrypted' ballot). All digital files of the unencrypted ballot are removed and the memory physically over-written on the voter's device. The paper copy of the voter's ballot can be saved for evidence or destroyed for privacy based on the voter's choice. (Note: signing signatures can be used with the printed ballot or QR-code to increase confidence that the ballot is authentic. This combines advantages of asymmetric encryption along with a physical printed paper trail for audits.) Step 11: (Submit encrypted-ballot over network) Online: The voter sends their completed-ballot-QR-code (containing the voter's encrypted filled-in and checked ballot) to the local election office (sent by whatever agreed upon method (website, email, text, messaging software, shared storage (e.g. S3), api-endpoint, etc.)). Step 12: (Processing the voter's encrypted ballot) The local election office physically prints onto paper the QR code for the 'encrypted' filled out ballot, and then (double) checks (compares) to confirm that the physical print (of the electronically-sent QR code) is accurate/identical, and (if printing is accurate) deletes the digital record and the memory is physically over-written. 1. Print 2. Check 3. Delete Step 13: (Processing the Voter-submitted ballot) Offline, using a separate piece of software, the local election office "decrypts" the QR code for the 'encrypted' completed(choices-filled-in) ballot using the second(2:2) of the pair of printed (pad)QR codes for the one-time pad, and physically prints on paper the voter's filled-in ballot. (Note: one choice in designing the software is to directly-print-to-paper or to decrypt and display on a screen or possible save as a computer file) The voter's completed ballot is stored along with any completed paper ballot (e.g. mail-in ballots, or paper ballots delivered in person or filled out in person). (Note: depending on the details, an additional step may be needed to convert the format of the QR code (or abridged format) to the same format as an in-person ballot. For example, if only the vote choice data are recorded in the QR code (or abridged format) the exact placement of each printed character on paper may be needed or useful for manual or automated ballot counting). Step 14: (Process Election Data / Count The Votes) The printed ballot is counted with the other paper ballots of various kinds during the normal election ballot count process. Step 15: (Publish Election Data) The election results are processed and published. (The publication of election results is perhaps not strictly part of the question of 'secure voting' but in practice it is likely often a requirement.) Note: Someone may wish to save a QR code as some form of record. There is no security need to carefully dispose of used QR codes after they is used because they are only used once; for example obtaining an old QR code (one time pad) will not in any possible way help to "decrypt" another future one-time-pad, one-time-pads are not similar to passwords in this way (leaking archived passwords would likely be considered some form of security breach, whereas accessing already disposed of QR codes is useless; literally a set of random numbers that won't help anyone to do anything elicit, this is the point and function of a one-time-pad). # Identifying Risks Here we look at risks from bad-actors or bad-agents. A bad-agent may be human or automated, and may be non-local agents such as foreign states / groups. An 'agent' may be anything from a single person to a group to an AI-bot or software suit, malware, ransomware, thinktank, etc. (or something unclear and not simple to identify) (note: other areas of risks should be explored, and may include: 1. constant 'internet background radiation,' 2. unintentional user-misuse 3. unintentional administrative bungling, 4. oversights and biases (e.g. setting up a voting system and obsessing so much over absolutely obscure vote secrecy that vote auditing and best practice domestic and international observation of the vote process is impeded, impracticable, or impossible), 5. practical feasibility vs. ideals in principle (possibly similar to "letting the perfect be the enemy of the good') 6. software design problems that cause time, logistical, or reliability problems, 7. etc.) 1. a bad-agent will intercept one-time-pads: 1.1 - the agent would need to be physically in the room during the QR code creation, to break into the gov. office, or to physically steam from the person, without anyone knowing the QR codes were stolen. 1.2 - the one-time-pads are never stored digitally anywhere, but are only physically printed by an off-line computer. 1.3 - if the voter loses the QR code the person should cancel the process 2. a bad-agent will send the voter a fake blank-ballot: - additional step: there can be additional checks such as a passphrase chosen by the person which could not be electronically surveilled from any computer (e.g. written in pen on the QR pad) 3. a bad-agent will send the gov. a fake filled-in ballot: - 3.1 The agent would need to have both stolen QR codes and a stolen ballot that was sent to the voter. - 3.2 If the voter loses the QR code the person should cancel the process. 4. a bad-agent will record a fake record of the vote from the ballot: - while a possible risk, this process is the same as for any paper ballot 5. a bad-agent will act on the behalf of a participant without the voter's participation 6. a bad-agent will act on the behalf of the voting office without the voting-office's participation 7. a bad-agent will attempt to tamper with a public ballot (e.g. a ballot itself, e.g. downloading a ballot to use) 8. a bad-agent will attempt to tamper with public ballot-confirmation information (e.g. public information posted about the ballot by the voting office, describing and understanding the ballot and ballot issues) 9. a bad-agent will attempt to tamper with voting instructions and information about voting procedures 10. a bad-agent will attempt to tamper with vote reporting including any information put out by a Vote-Office or authority 11. a bad-agent will seek to disrupt the sending and receiving of vote information (including but not restricted to blank and filled-in ballots (e.g. voting times, places, registration, ballot items, etc). # Description Notes: This is a proposed process for reasonably secure 'online (over a network) voting.' Part of design is that the entire process is not on-line. Rather, physical printed materials and off-line computers are used to reduce the online attack surface. A person or bad-agent can feasibly steal or tamper with a file in a network-connected computer from a remote location, but a person or bad-agent cannot feasibly/easily tamper with or steal documents in a filing cabinet or from a computer connected to the internet. This particular solution is not a perfect-for-all-cases solution. E.g. This will not be easy to use for persons who cannot ever travel themselves to a gov. office or polling place. The primary focus of this report is the question of whether casting a ballot/vote over-a-network(online) can in principle be done with sufficient security and soundness. Secondarily, this report explores 'practical and thrifty' variations which add in factors of feasibility, cost, equipment availability, and other real-world factors that communities around the world may face in actually holding an election (i.e. not everyone has ideal funding and resources with which to carry out the perfect election). Another way to look at this distinction is that we first look at an ideal voting system to aim for, and then look at realistic voting systems. # Implementation Notes: These are recommendations for a reasonably secure online voting system that should not be significantly more cumbersome than a physical paper voting system. To make accessibility easier, it is conceivable that some local voting systems would prefer to simplify some of the security step to allow broader accessibility: - voters who have no access to a printer - voters who cannot physically travel (e.g. elderly persons in retirement home or hospital), perhaps allowing a proxy to carry documents for that person. Additional steps could also be taken to increase the security further. For Example: 1. to reduce the possibility that local staff will accidentally connect to the internet or run the software on insecure or already compromised hardware, it should be possible to create a cost effective system where staff could run a custom made operating system (custom BSD or Linux or FreeDOS, etc) that lacks the ability to use the internet. It may also be possible to use cost effective hardware such as a $40 raspberry pi computer. 2. Put safeguards into the software to at least try to prevent using the same one-time-pad more than once. ## Unique Ballots: At this time or at a later time (depending on choice, timing, etc. (e.g. if the ballot has been decided which is often not the case at the time of voter registration or if in terms of security level if the voter does not trust a physical breakin of the vote office and wants in advance a verifiable ballot) (offline) a printed copy of a unique ballot (e.g. containing if not the voter's name the equivalent of a sha256 hash of the unique ballot). Either a unique ballot or a unique ballot identification number will be used on both ends, by the voter to check that the ballot they receive is authentic and by the office that the ballot received completed and sent by the voters is authentic. (note: some combination of a 'signed' public ballot and a signed sender/recipient may also be possible) ## Challenges: One possible area that may cause issues is if the office or voter is 'unable' to scan or take a clear photo of the document, in the same way that some people are 'unable' (which ranges from people having legitimate handicaps to people not bothering to try) to take a clear picture of their check for their bank (so a less secure non-printed option may be desired in some cases). It is also possible that OCR (optical character recognition) may not be good enough to read the ballot, but given the use of OCR to read more obscurely printed checks etc., this is probably not a terminal obstacle. The task of automated ballot reading perhaps should be steered away from subtle character recognition of natural-language phrases and towards clear easily defined targets such as binary check-box selection. An exception to this may be write-in ballots which do occur, where some other system may be needed (binary as in: checked-box vs. not-checked-box). Though even here, OCR and having the vote double-check to see that the OCR is correct may be sufficient. # About One Time Pads A one-time-pad is not the same as a re-use-able 'code' that 'encodes' a signal that can then also be 'decoded.' Unfortunately, the terminology can be overlapping and so a bit unclear between the two. For example, the term 'encode,' is used in both cases. A 'one time pad' is, historically, literally, a physical note-pad that is only used one time, hence the term "one-time-pad." There is no pattern or system behind a one-time-code that can be outsmarted or 'cracked.' The only way to 'decode' a one-time-pad 'encrypted' message is with that one-time-pad, because it is a one-by-one, one-for-one, one character at a time, change of what the original text says. There is no key. There is no password. There is no shortcut. Every character or element or number of the entire document is individually substituted for something else. One-time-pads codes are not as efficient and user friendly as 're-use-able' codes, but they are more secure and more simple. Because there is no 'key,' there is no possibility in principle to 'guess the key.' ... Q: Is there a lower-tech version with reasonable security for places with limited resources? ... # A low-tech version of online voting for realistic implementation For example, some voting locations (or regions) may not have: 1. printers, ink, and paper 2. extra air-gapped computers 3. a physical location to securely store paper files 4. broadband wireless internet Most locations should have: 1. basic mobile phones 2. basic (not high speed) internet access Writing down the numbers and confirming with picture (no printers needed) may be able to replace a printed QR code system while still having a paper-backup form, if only as an option (e.g. you cannot hack into and change a piece of paper). Maybe separate air-gapped mobile devices would be feasible, or perhaps a more decentralized system would be more secure. # An alternative thrifty-protocol for resource-limited situations/geographies: (section under construction) ## Practical Voting The goal here (for this practical-tool section, vs. the above secure voting in principle) is more a practical-project and less abstract (proof of concept or standard-setting): How can a local community organize and carry out a best practice auditible vote and publish the results using (widely available and) accessible technology (such as mobile phones). What are some of the factors that characterize a realistically resource-limited situation? Are there some general groups of common sets of constraints? E.g. Some groups may have a safe place for a voting office but no funds for extra equipment. Other groups may not have a safe place for any voting office or official positions (needing the management of the election to be virtual and decentralized). Question: Can virtual distributed elections be best carried out with or without support from institutions such as universities? Thrifty voting systems may make more use of available multi-factor authentication and less use of equipment-expensive methods (such as dedicated printing and scanning machines). There should be some option for physical printed documents, but there will most likely be more use of non-paper methods for a thrifty resource-slim and more user-friendly system. Other methods such as chains-of-trust may be useful to harden thrifty online systems. #### General Revisions for Thrifty-Secure-Voting: 1. no physical printed copies 2. no separate air-gapped hardware ?. one pad per set of elections vs. two pads per single election (backup pads?) 3. more cryptographic signature use? Topic: - use of one time pads and signing signatures Notes: - individual permission drop-off folders (like S3) - anonymized ballots (storing data without direct connection to user information) - face-picture when sending in vote - vote by phone system, tied to that phone...(note: if you loose the phone) - csv ballot format... ## Proposed Steps for Secure Online Voting (section under construction) Note: This thrifty and pragmatic (if not perfect) system does not assume there is a voting office either as a building or as human staff. Step 1: (During online registration) Before the election ends: A voter registers for the vote-over-a-network (with One-Time-Pad) (online voting) process. e.g. using signing signatures, people could have something e.g. mailed to them (or received from an office) to use to authenticate their online connection. Step 2: While the thrifty-protocol is designed to avoid extra printer hardware, the option still exists to hand-write a one-time pad. A short-form ballot one time pad good for several ballots may be hand written and OCR-checked on a wallet-card sized card or paper. A short-form or truncated ballot may contain, e.g., the number of the option-choice and perhaps a first/last letter in the candidates name (which could also serve as a check, similar to an empty choice check, if the name-letter does not agree with the number option). Two-factor-no-nul voting? Note: Write-in may be an issue for the truncated ballot. Note: ways to make sure a one-time-pad is not being used a 2nd time...a log of already used one-time-pads to check against...?...or a small hash? Step 3: (this step needed for thrifty-version?)(extra other steps?) Q: one time pads vs. signing keys for transmitting ballots Step 4: (send ballot?) 3 options: 1. a publicly posted signed ballot (varifiable) 2. a ballot including a unique personal id sent only to that one person 3. both During the election period (be that months, weeks, days, hours, etc.), a one-time-pad 'encoded' ballot is sent by whatever agreed upon method (website, email, text, snapchat, S3, api-endpoint, etc.) in the form of another QR code. Part of this process is an at-the-time randomized process of frame-shifting the ballot so that where exactly on the page each person's vote-choices appears is random. Step 5: (Voter Gets the not-yet-completed ballot) A. sent to user B. posted on several public sites and signed and can be compaired/verified Step 6: (Validate the not-yet-completed Ballot) The voter on-line inspects and validates the ballot. Most likely by checking and comparing multiple sources and signing keys. (note: finding universities to host copies of the final ballot may be a good option. But this step may not be feasible or necessary.) (Something like a blockchain (immutible ledger) for all users of the voting system may suffice as a good-enough decentered immutable portable verified storage system.) Step 7: (Complete the Ballot, Mark Votes) e.g. csv format of data (vs. pdf type doc) Q: id such as biometric data ~ step: an optional intermediate step here is to have a 3rd set of offline-only software that will check the ballot before and or after it is filled out by the voter, such that this additional set of software can check for the "overvoting" (voting for both candidates) and "undervoting" (voting for neither candidate) issues as a safeguard (against accidentally-incorrectly filled-out-and-submitted ballots) and that perhaps Nevada has used successfully. See: "Roll Off at the Top of the Ballot: Intentional Undervoting in American Presidential Elections" December 2003 Politics & Policy 31(4):575 - 594 DOI:10.1111/j.1747-1346.2003.tb00163.x Authors: Stephen Knack & Martha Kropf University of North Carolina at Charlotte https://www.researchgate.net/publication/227617394_Roll_Off_at_the_Top_of_the_Ballot_Intentional_Undervoting_in_American_Presidential_Elections Step 8: (this step needed for thrifty-version?)(extra other steps?) Step 9: (Check completed-ballot for errors) (see step 7?) Step 10: Online: The voter sends (by whatever agreed upon method (website, email, text, snapchat, S3, api-endpoint, etc.)) the new QR code (containing their encrypted filled-in-and-checked ballot) to the local election office. Step 11: (Submit encrypted-ballot over network) Q: recommended methods? some kind of MFA or blockchain leger system? Step 12: (Processing the voter's encrypted ballot) - thrifty encryption choice? Step 13: (Processing the Voter-submitted ballot) - format of ballot csv? voter checks on status? Step 14: (Process Election Data / Count The Votes) (storage: block chain or other immutable ledger?) Step 15: (Publish Election Data) (publishing?) Note: It is not clear that saving the QR codes serves any function, nor is there any need to carefully dispose of a QR code after it is used (if each is only used once). What kind of software (singular or plural) would be needed to arrange a secure election? Could some form of blockchain made of election participants be used as a decentered election results platform? Part of an online system may be to increase the number of channels by which people can try to vote, and possibly have a backup-pad. Thereby, if bad-agents shut down the main channel for sending in votes (which may be a single point of failure) the process will not be disrupted. # A Practical Voting Software Package #### Features of a practical voting software package: 1. secure messages between office and voter? (one time pad?) 2. secure voting platform (receive ballot) 2.1 voter registration 2.2 send or assign ballots 2.3 fill out ballot 2.4 submit ballot 3.1 receive votes 3.2 validate votes 3.3 decrypt votes 5. process votes 6. produce results report 7. schedule election 8. publish results report Mode 1: remote vote office Mode 2: decentralized vote office Maybe each 'election' will have a different signing key to verify? software platforms/languages: Project: "Pseudocode for voting infrastructure" - including how to create randomized representative voting districts - including how to do ranked choice voting - including how to do (term) ? representational voting - boundaries of population and geography of vote # (mitigation of insecure local voting headquarters) 2nd step of recording / publishing vote: Uuid type random key-field Fuzzy time stamp (month year?) unix epoch 2. Using a modified blockchain to store results: - e.g. university trusted node anchors - maybe full-chain so no retroactive? - slower but more robust? - smaller number of participants? (or pooled participants?) - containing hash and voting record? .... Possible Multi-factor Authentication Tools: 1. voice print 2. picture of hand (for fingerprints) 3. one time pad 4. specific device tracking 5. device gis location 7. ip / mac address details (vpn issues?) 6. separate confirmation login (to confirm vote record (device, voice, etc.) after it has been processed and recorded) 7. face-selfie (time GIS stamped picture of person casting vote) 8. video of person voting (more secure than static selfie? or smaller-file 'encoding' (e.g. auto-encoder) of video of person voting (plus) 1. public security log data/meta-data to be inspected by anyone about the system Additional Questions: 1. What additional vote process transparency information should be included with vote results publishing? https://github.com/lineality/Auditable_Elections_Projects ... Case Studies in Election Disruption and Resiliance: - - - ... ## A Voting Rules And Procedures Statement As part of an election, other publicly stated 'open' policy and procedure information is important in addition to the ballot itself. - rules, policies, and procedures for how rules, policies, and procedures for voting are made, unmade, and changed - time and data on opening and closing of poles for a given election - times places methods for ways of voting allowed - rules, policies, and procedures schedule for repeating elections - specific schedule for repeating elections (e.g. this is a run-off vs. this election is held every 2 years) - rules for calling elections - Repeating or other type of election - Place of election - Government Structures and Levels - Vote-Office information (location, head?, contact, reporting?) - Chain of Command within and above Vote-Office - rules, policies, and procedures contacting media or watchdogs about suspicious anything (emails, threats, voter intimidation, etc.) - rules, policies, and procedures for eligibility - rules, policies, and procedures for voter-registration - rules, policies, and procedures for per way to vote - rules, policies, and procedures for election audits (required audits, optional audits) - rules, policies, and procedures for election-results-challenge - rules, policies, and procedures for recount (automatic recounts, type of recount, etc.) - ules, policies, and procedures for overruling-election-results e.g. by gov. branches, evidence requirements - rules, policies, and procedures for chain of custody of election materials, equipment, etc., Provenance - rules, policies, and procedures for announcing and publishing results - rules, policies, and procedures for reporting information about the vote: procedures, voter enrollment and participation numbers, etc. - Should there be a 'log' of who makes changes to procedures and how? - rules, policies, and procedures for election and ballot counting observation - rules, policies, and procedures for exit polls (what collected, from whom, released when) - rules, policies, and procedures for meetings and correspondence transparency around voloting infrastructure and offices and resources - rules, policies, and procedures for foreign domestic local and internal interference with the attacks on the election process - rules, policies, and procedures for voter registration - rules, policies, and procedures for voter identification - For evaluation of best practice, performance, and ethics: standards, guidelines, benchmarks and audit materials - rules, policies, and procedures for raw vote results (including ranked-choice etc.) - rules, policies, and procedures for choosing vote calculation method - rules, policies, and procedures for vote calculation method (e.g. how different numbers of candidates are handled, e.g. 2 vs. not-2) - rules, policies, and procedures for specific-used vote calculation method #### Question: A. What is the relationship between secure end to end messaging and voting systems? B. Provenance: What is the relationship between origin-verification of files (indlucing media files) and voting systems? ### Issue/Task: user interface for setting up an election Q: a standardized .csv ballot format including information about the ballot signing key information possible vote customization information vote choices etc. Q: ways to make sure the .csv ballot is not mis-read or garbled e.g. maybe including item number, vote choice, and first letter/number of vote choice name in the vote, may prevent arbitrary misinterpretation of votes Q: possible requiring of ballot being completely filled out - digital signature etc. - checksum etc.
Fix for Apple's cheap ass freeloading on libxml2
Trillion dollar company that cant write its own XML parser. And libxml2 is currently going begging for a lack of maintainers. Silicon valley really makes my blood boil. Fucking armpit of the universe.
Hiding the results when inactive
Now that we're overlaying our results on top of the rest of the page, we'll only want to do so when the end-user is actively searching. We'll also want to avoid needless requests to the server with empty query text.
Lucky for us, browsers provide a built-in mechanism to prevent bad
<form> submissions and to surface a field's correctness: Constraint
Validations!
In our case, there are two ways that a search can be invalid:
- The query
<input>element is completely blank. - The query
<input>element has a value, but that value is comprised of entirely empty text characters.
To consider those states invalid, render the <input> with required
and pattern attributes:
--- a/app/views/layouts/application.html.erb
+++ b/app/views/layouts/application.html.erb
<form action="<%= searches_path(turbo_frame: "search_results") %>" data-turbo-frame="search_results">
<label for="search_query">Query</label>
- <input id="search_query" name="query" type="search">
+ <input id="search_query" name="query" type="search" pattern=".*\w+.*" required>By default, browsers will communicate a field's invalidity by rendering a field-local tooltip message. While it's important to minimize the number of invalid HTTP requests sent to our server, a type-ahead search box works best when users can incrementally make changes to the query string. In our case, a validation message could disruptive or distract a user mid-search.
To have more control over the validation experience, we'll need to write
some JavaScript. Let's create
app/javascript/controllers/form_controller.js to serve as a Stimulus
Controller:
import { Controller } from "@hotwired/stimulus"
export default class extends Controller {
}Next, we'll need to listen for browsers' built-in invalid events to
fire. When they do, we'll route them to the form controller as a
Stimulus Action named hideValidationMessage:
--- a/app/views/layouts/application.html.erb
+++ b/app/views/layouts/application.html.erb
<header>
- <form action="<%= searches_path(turbo_frame: "search_results") %>" data-turbo-frame="search_results">
+ <form action="<%= searches_path(turbo_frame: "search_results") %>" data-turbo-frame="search_results"
+ data-controller="form" data-action="invalid->form#hideValidationMessage:capture">
<label for="search_query">Query</label>One quirk of invalid events is that they do not bubble up
through the DOM. To account for that, our form controller will
need to act on them during the capture phase. Stimulus supports the
:capture suffix as a directive to hint to our action
routing that the controller's action should be invoked during the
capture phase of the underlying event listener.
Once we're able to act upon the invalid event, we'll want the
form#hideValidationMessage action to prevent the default behavior
to stop the browser from rendering the validation message.
--- a/app/javascript/controllers/form_controller.js
+++ b/app/javascript/controllers/form_controller.js
import { Controller } from "@hotwired/stimulus"
export default class extends Controller {
+ hideValidationMessage(event) {
+ event.stopPropagation()
+ event.preventDefault()
+ }
}When an ancestor <form> element contains fields that are invalid, it
will match the :invalid pseudo-selector. By rendering the search
results <turbo-frame> element as a direct sibling to the <form>
element, we can incorporate the :invalid state into the sibling
element's style, and hide it.
--- a/app/assets/stylesheets/application.css
+++ b/app/assets/stylesheets/application.css
*= require_tree .
*= require_self
*/
+
+.empty\:hidden:empty { display: none; }
+.peer:invalid ~ .peer-invalid\:hidden { display: none; }
--- a/app/views/layouts/application.html.erb
+++ b/app/views/layouts/application.html.erb
<header>
- <form action="<%= searches_path(turbo_frame: "search_results") %>" data-turbo-frame="search_results"
+ <form action="<%= searches_path(turbo_frame: "search_results") %>" data-turbo-frame="search_results" class="peer"
data-controller="form" data-action="invalid->form#hideValidationMessage:capture">
<label for="search_query">Query</label>
--- a/app/views/layouts/application.html.erb
+++ b/app/views/layouts/application.html.erb
- <turbo-frame id="search_results" target="_top"></turbo-frame>
+ <turbo-frame id="search_results" target="_top" class="empty:hidden peer-invalid:hidden"></turbo-frame>
</header>drm: Handle dim for udfps
-
Apparently, los fod impl is better than udfps cuz it has onShow/HideFodView hook, which allows us to toggle dimlayer seamlessly.
Since udfps only partially supports the former one, we'd better kill dim in kernel. This is kinda a hack but it works well, bringing perfect fod experience back to us.
Co-authored-by: Art_Chen Chenxy0201@qq.com Signed-off-by: alk3pInjection webmaster@raspii.tech Change-Id: I80bfd508dacac5db89f4fff0283529c256fb30ce
Codewars/7_kyu_computer_science_101_stack: create README.txt
Computer Science 101 - #1 Stacks
NOTE: The major content of this Kata is contained within the "Lesson" and "Task" headings. Furthermore, if you are already familiar with how a stack works, you may simply skip to the "Task" heading which contains all the instructions you need to complete the Kata. About this Kata Series
Learn fundamental computer science concepts that every CS student must know in depth such as algorithms, data structures and common data types through implementing them from first principles. Translators' Note
Translations to this Kata in languages that either already have a built-in stack datatype (e.g. C++, C#, Java) or another datatype that can function as a stack (e.g. JavaScript, Python, Ruby) will be rejected without further reason. Lesson
Stacks are everywhere - they can be found in programs involving symbol balancing, depth first search and backtracking just to name a few. Hell, even recursion depends on stacks! In fact, they are so common that any sane programming language would provide at least one built-in datatype that can act as a stack. For example, C++ has std::stack, Java has java.util.Stack and C# has System.Collections.Generic.Stack. So, what are they?
A stack is a last in, first out (LIFO) data type that supports at least these three operations:
Push - Adds an item to the top of the stack
Pop - Removes an item from the top of the stack. Most
implementations return the item that was popped but those
that don't must implement another operation "peek" that
simply returns the top item of the stack.
Is empty - Is the stack empty? This operation is crucial in
ensuring that the user of the stack doesn't accidentally pop
or peek at an empty stack (which doesn't make sense).
An analogy for understanding stacks could be a stack of documents on your office desk. It is trivial to place a new document on top of your existing stack and it also requires minimal effort to view the top document and/or remove it from the stack for processing; however, it is no easy job to try to search for a document located somewhere in the middle of the stack and is definitely even harder if you want to remove a document from the middle or slip a new document there.
Now you should know what a stack is but knowing how to implement it is something else entirely. Fortunately, it turns out that one of the simplest data structures in existence is perfectly suited for implementing stacks - enter the linked list. Such a simple data structure is rarely a good choice for implementing common data types due to its traversal restrictions which translates to inefficiency (see this Kumite which explains how an associative array based on linked lists is extremely inefficient) but a stack implemented using it can achieve constant O(1) time for all of its key operations (push, pop [, peek] and "is empty") mentioned above and never occupies more memory than it needs. It is up to you to figure out in this Kata how this can be achieved.
Before we end this lesson, here's something for you to think about: if we implement our stack as a linked list, each node stores not only an item in the stack but also a reference to the next node which means that a significant portion of the memory allocated to our stack goes to storing these references instead of storing the actual items. In contrast, a stack implemented using a dynamically sized array need only allocate memory for storing the items in the stack (perhaps including a trivial, constant amount of memory for storing the current size and capacity of the stack) while retaining the benefit of achieving constant time for all of its operations. So, in this sense, it would appear that implementing a stack as a dynamic array is one better than a linked list implementation since less memory is used. Is this actually true and why? Task
In this Kata we will be implementing our stack (of integers) as a linked list where a node of our linked list is defined as follows:
typedef struct node { int data; struct node *next; } Node;
Our actual stack is then defined as a wrapper type around our linked list:
typedef struct { Node *root; } Stack;
By defining our stack as a wrapper type around the linked list instead of directly exposing the linked list to the user of the stack, we can 1) reserve NULL for specifying an invalid reference to a Stack instead of an empty stack and 2) modify a stack by object reference instead of passing in the address of the variable holding the stack.
Implement the following key operations of the stack:
void stack_push(Stack *stack, int data) - Pushes the data
onto the top of the stack, allocating memory to the stack if
necessary.
int stack_pop(Stack *stack) - Pops the top item of the stack
and returns it. It should also ideally free memory previously
allocated to the stack if possible to avoid memory leaks -
the tests will test for very large stacks so you may run out
of memory if you forget to do so.
int stack_peek(const Stack *stack) - Returns the top item of
the stack. This operation should not modify the stack.
bool stack_is_empty(const Stack *stack) - Checks whether the
stack is empty. This operation should not modify the stack.
All four of these key operations should operate in O(1) time. There will be performance tests in the Submit tests to enforce this.
Also take care to manage your memory properly - there aren't any assertions to enforce this but it is generally good practice to free memory that you no longer need and note that you may run out of memory in the performance tests if there is a serious memory leak.
You may assume that the peek and pop operations will never be called on an empty stack provided that you implement all key operations correctly. Apart from that, you should ensure that your solution does not cause any potential form of undefined behavior (such as dangling pointers); otherwise, there is no guarantee that the tests won't crash.
Link: https://www.codewars.com/kata/5b24bcecd74b5be066000054
Signed-off-by: Alwan Adiuntoro alwanadiuntoro@gmail.com
Create MixedJuices.js
Instructions Your friend Li Mei runs her own juice bar where she sells delicious mixed fruit juices. You are a frequent customer in her shop and realized you could make your friend's life easier. You decide to use your coding skills to help Li Mei with her job.
- Determine how long it takes to mix a juice Li Mei likes to tell her customers in advance how long they have to wait for a juice from the menu that they ordered. She has a hard time remembering the exact numbers, because the time it takes to mix the juices varies. 'Pure Strawberry Joy' takes 0.5 minutes, 'Energizer' and 'Green Garden' take 1.5 minutes each, 'Tropical Island' takes 3 minutes and 'All or Nothing' takes 5 minutes. For all other drinks (e.g., special offers) you can assume a preparation time of 2.5 minutes.
To help your friend, write a function timeToMixJuice that takes a juice from the menu as an argument and returns the number of minutes it take to mix that drink.
`timeToMixJuice('Tropical Island'); // => 3
timeToMixJuice('Berries & Lime'); // => 2.5`
- Replenish the lime wedge supply A lot of Li Mei's creations include lime wedges, either as an ingredient or as part of the decoration. So when she starts her shift in the morning she needs to make sure the bin of lime wedges is full for the day ahead.
Implement the function limesToCut which takes the number of lime wedges Li Mei needs to cut and an array representing the supply of whole limes she has at hand. She can get 6 wedges from a 'small' lime, 8 wedges from a 'medium' lime and 10 from a 'large' lime. She always cuts the limes in the order in which they appear in the list, starting with the first item. She keeps going until she reached the number of wedges that she needs or until she runs out of limes.
Li Mei would like to know in advance how many limes she needs to cut. The limesToCut function should return the number of limes to cut.
limesToCut(25, ['small', 'small', 'large', 'medium', 'small']); // => 4
- Finish up the shift Li Mei always works until 3pm. Then her employee Dmitry takes over. There are often drinks that have been ordered but are not prepared yet when Li Mei's shift ends. Dmitry will then prepare the remaining juices.
To make the hand-over easier, implement a function remainingOrders which takes the number of minutes left in Li Mei's shift and an array of juices that have been ordered but not prepared yet. The function should return the orders that Li Mei cannot start preparing before the end of her work day.
The time left in the shift will always be greater than 0. Furthermore the orders are prepared in the order in which they appear in the array. If Li Mei starts to mix a certain juice, she will always finish it even if she has to work a bit longer. If there are no remaining orders left that Dmitry needs to take care of, an empty array should be returned.
remainingOrders(5, ['Energizer', 'All or Nothing', 'Green Garden']); // => ['Green Garden']
Implementing getColumns
I literally cannot use unions, and I don't know why. I hate my life. Cherno uses the union to group elements and colums so that they share the same memory address, and it is a much more elegant solution than use getColumns().
get mouse working
kiajsldkajsdlkjd lasd lkasjkasdlsadsadjsaasda dldjfadsjfafldsfasd fdsfa[ sdjfdasj klfsdj fkdjsf lsdfds fsdjlsdnlfj sdf s df sdlkf sdj fklsdjfsdlk j FUck you mouse
This totally did not take me like 2 hours 👍
Adding Axie Infinity Tools
Hello Sers, just updated the picture for Axie Tech and for the other tools, my bad! I apologize for my mistake and the trouble it made Thank you and have a blessed day!
sign in manager debug(shity sign in manager fuck you)
Finally code those good effects
Fucking hell, I knew why I didn't feel like coding that shit while I still had little free time.
yeah webdev sucks programming sucks linux sucks my life sucks
Fixes up multiz atmos connection, cleans some things up in general (#63270)
About The Pull Request
ALLLRIGHT so Multiz atmos was letting gas flow down into things that should be well, not flowable into Like say doors, or windows.
This is weird.
Let's get into some context on why yeah?
First, how do things work currently?
atoms have a can_atmos_pass var defined on them. This points to a define that describes how they interact with flow. ATMOS_PASS_NO means well, if we're asked, block any attempts at flow. This is what walls use. ATMOS_PASS_YES means the inverse ATMOS_PASS_DENSITY means check our current density ATMOS_PASS_PROC means call can_atmos_pass, we need some more details about this attempt
These are effectively optimizations.
That var, can_atmos_pass is accessed by CANATMOSPASS() the macro It's used for 3 things.
1: Can this turf share at all? 2: Can this turf share with another turf 3: Does this atom block a share to another turf
All of this logic is bundled together to weed out the weak.
Anyway, so when we added multiz atmos, we effectively made a second version of this system, but for vertical checks.
Issue here, we don't actually need to. The only time we care if a check is vertical or not is if we're talking to another turf, it's not like you'll have an object that only wants to block vertical atmos. And even if you did, that's what ATMOS_PASS_PROC is for.
As it stands we need to either ignore any object behavior, or just duplicate can_atmos_pass but again. Silly.
So I've merged the two, and added an arg to mark if this is a verical attempt. This'll fix things that really should block up/down but don't, like windows and doors and such.
Past that, I've cleaned can_atmos_pass up a bit so it's easier for people to understand in future. Oh and I removed the second CANATMOSPASS from immediate_calculate_adjacent_turfs. It isn't a huge optimization, and it's just not functional.
It ties into zAirOut and zAirIn, both of which expect to be called with a valid direction. So if say, you open a door that's currently blocking space from leaking in from above, you end up with the door just not asking the space above if it wants to share, since the door can't zAirOut with itself.
Let's just wipe it out.
This makes the other code much cleaner too, heals the soul.
Anyway yadeyada old as ass bug, peace is restored to the kingdom, none noticed this somehow you'd think people would notice window plasma, etc etc. Why It's Good For The Game
MUH SIMULATION Also fuck window gas Changelog
cl fix: Fixed gas flowing into windows from above, I am.... so tired fix: Fixes gas sometimes not moving up from below after a structure change, see above /cl
chore(social): Up leveling rates again, holy fuck this is weird.