2,627,320 events, 1,330,073 push events, 2,089,254 commit messages, 144,076,414 characters
HOLY FUCKING SHIT WE ALMOST DONE
just gotta be debuggin
width of curses menus
Menus with wide header or separator lines were rendered wide enough to avoid wrapping those lines, but ones with narrow header/separators and wide selectable entries were limited to half the display even though lots of lines that would fit with full width were being wrapped. Change the latter behavior.
Menus are right justified with the edge of the map when narrower than it, left justified otherwise, and if the display is wider than the map, they'll extend beyond its right edge. (That hasn't actually changed; it's just that left-justification is more likely now that menus will be wide enough to show wide inventory lines without wrapping.)
Get rid of my ridiculous hack to force wider menu for the 'symset' and 'roguesymset' sub-menus of 'O' since it's no longer useful.
There's still room for improvement. If any lines need to be wrapped despite using the full width, or perhaps are just a lot wider than most of the entries, menu width could be narrowed to just enough for 'normal' lines to fit so that one or two really long entries don't distort the menu. That's a bit more complicated than I want to deal with right now. [If implemented, it would be relevant for tty too.]
genirq: Allow the irqchip state of an IRQ to be save/restored
There is a number of cases where a kernel subsystem may want to introspect the state of an interrupt at the irqchip level:
- When a peripheral is shared between virtual machines, its interrupt state becomes part of the guest's state, and must be switched accordingly. KVM on arm/arm64 requires this for its guest-visible timer
- Some GPIO controllers seem to require peeking into the interrupt controller they are connected to to report their internal state
This seem to be a pattern that is common enough for the core code to try and support this without too many horrible hacks. Introduce a pair of accessors (irq_get_irqchip_state/irq_set_irqchip_state) to retrieve the bits that can be of interest to another subsystem: pending, active, and masked.
- irq_get_irqchip_state returns the state of the interrupt according to a parameter set to IRQCHIP_STATE_PENDING, IRQCHIP_STATE_ACTIVE, IRQCHIP_STATE_MASKED or IRQCHIP_STATE_LINE_LEVEL.
- irq_set_irqchip_state similarly sets the state of the interrupt.
Signed-off-by: Marc Zyngier [email protected] Reviewed-by: Bjorn Andersson [email protected] Tested-by: Bjorn Andersson [email protected] Cc: [email protected] Cc: Abhijeet Dharmapurikar [email protected] Cc: Stephen Boyd [email protected] Cc: Phong Vo [email protected] Cc: Linus Walleij [email protected] Cc: Tin Huynh [email protected] Cc: Y Vo [email protected] Cc: Toan Le [email protected] Cc: Bjorn Andersson [email protected] Cc: Jason Cooper [email protected] Cc: Arnd Bergmann [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner [email protected] Signed-off-by: fadlyas07 [email protected]
Fix Immediately Immobilized Caravans
I noticed that caravan capacity calculations were acting funny, so I explored this behavior with only Harmony, Core, HugsLib, GU-Core and GU-Caravans. I wrote and play-tested two alternate versions of the code responsible for the weird behavior. I've included both versions in this pull request - you will likely want to edit this after testing and deciding if you like it.
Problem: Some caravans become immediately immobilized upon embarking when animals are mounted, especially caravans near full mass capacity.
Observation: Let's form a caravan consisting of two naked colonists (2 x 35 kg capacity), a Muffalo (73.5 kg capacity), and three granite chunks (3 x 25 kg mass). We assign one rider, which reduces the Muffalo's capacity by 60 kg.
The caravan's capacity will appear correctly in the caravan screen: 35 + 35 + ( 73.5 - 60 ) = 35 + 35 + 13.5 = 83.5 kg
The caravan cargo will also appear correctly: 3 x 25 = 75 kg
Therefore, the caravan formation screen shows that we are in good shape: 75 kg / 83.5 kg (8.5 kg available capacity)
However:
Upon embarking, those three chunks are distributed to our two colonists and the Muffalo. This is done either manually by colonists loading a caravan leaving the home settlement, or automatically by Dialog_FormCaravan.AddItemsFromTransferablesToRandomInventories when leaving from an encounter map.
Either way, each of the colonists now carries 25 of their 35 kg capacity. 35 - 25 = 10 kg available capacity
Vanilla MassUtility.Capacity then calculates the Muffalo's capacity: 73.5 - 25 = 48.5 kg available capacity
And then GiddyUp's MassUtility_Capacity patch subtracts the rider and his inventory: __result -= pawnData.caravanRider.GetStatValue(StatDefOf.Mass); 48.5 - 85 = -36.5 kg
Then corrects the negative remaining capacity to 0: __result = Math.Max(__result, 0f); 0 kg
Now our caravan capacity has been reduced to 35 + 35 + 0 = 70 kg
And just like that, our caravan is immobilized, despite moments earlier boasting 8.5 kg excess capacity. 75 kg / 70 kg (5 kg overextended capacity)
Notes: The main problem right now is that due to the random cargo distribution, there is no way a player can predict how much mass a rider might be carrying (and therefore how much total mass capacity the caravan will have) until the caravan embarks, but by then it's too late to pack a reasonable load. Further, there is no guarantee that the mass distribution will be equal. In my tests, sometimes one colonist got two chunks and the other got none; other times, each colonist got one.
As in the example above, this often results in caravans that become immobilized immediately upon embarking - and the more colonists and animals in the group, the less reliable the caravan forming screen can be.
I believe the first step is to remove individual pawn inventories from the equation and simply focus on the overall mass carried and mass capacity. This makes sense, because inventory mass will still be counted as mass carried, so it doesn't need to also reduce mass capacity. Plus, we don't really care who is carrying which pieces of slag or chunks or blocks - we just care that the caravan can haul the prize home.
I'd like to propose two solutions that I've coded and tested in various situations.
Solution A - Easy Mode Each mounted animal's mass capacity is reduced ONLY by rider body mass. This solution would allow for some slightly inflated caravan capacities, because the rider's "backpack" would get a free ride on mounted animals. Would encourage more riding.
Solution B - Hard Mode Each mounted animal's mass capacity is reduced by (rider body mass + rider mass capacity). This solution is more realistic and would make riding more costly - the animal will feel the weight of the rider AND his backpack. If the rider has additional mass capacity, then the animal must account for that by reducing its own capacity. This solution would widen the gap further between the rider speed bonus versus higher mass capacity. Anecdotally, I played for a while with this option and strongly prefer it due to the greater importance placed on strategy. With Solution A, it was almost always better for everyone to ride all the time. With Solution B, there was great incentive to load up the animal with cargo and walk it home, and a higher cost when I had to abandon a significant amount of loot in order to mount up and hurry home because of the Flu.
Perhaps a mod option could offer a choice between Easy Mode and Hard Mode.
In either case, the mass capacity shown on the caravan formation screen becomes reliable and players can pack loot until their caravans are full to the brim, without risk of the caravan immediately becoming immobile upon embarking.
Thanks for the fantastic mods. Hopefully players will enjoy this fix without causing too much extra work for you and the other contributors.
Merge branch 'master' into docker
- master: (44 commits) Fix. Do not list broken tracks. Do not die if there is no polyline. Fix missing attributes. Deprecate these. Still broken. Yeah. Would be fucking useful to load track. Fix polyline generator command. Fix services and dependencies. Renew TrackEventSubscriber. WIP. Introduce some converters. Mock everything. All this will get mocked. WIP for mocking. Fix test. Broken WIP for test. Test empty position list. Add a test! Much refactoring and improvements. ...
Basic fetch on load, with tests
The pain! The pain!! Mocking
fetch() and useState() changes after fetch() returns is
PAAAAIIIINFUL. I went 'round and 'round the houses trying to mock fetch,
give it a fake return value, render the component and have react/jest
shut up about my code making updates outside of act(). The layers of
magic behind useX and react-testing-library are deep and rich. I
suppose they might be helpful once you've learned them, but they break
so many assumptions from my previous life, hide so much and introduce so
many new points of failure that I"m not currently convinced.
susan quiz april 20
-
Legal actions in which the alleged injured party sues for monetary damages are *a. Civil actions b. Criminal actions c. Malpractice d. Vicarious liability
-
Significant gaps in the quality of waived testing practices in that positions offices resulted in a recent development of a. Behavioral Competencies *b. good laboratory practices c. quality indicators d . test threshold values
-
The level of care that a person of ordinary intelligence and good sense would exercise under the given circumstances is the definition of *a. Due care b. Quality care c. critical care d. Standard of care
-
Which of the following is a phlebotomy QA procedure? *a. Checking needles for blunt tips and barbs b. keeping a record of employee sick leave c. recording any instrument maintenance d. tracking all lab OSHA violations
-
Which preanalytical factor that can affect validity of test results is not always under the phlebotomist’s control? a. Patient ID *b. Patient preparation c. specimen collection d. Specimen handling
-
After a failed venipuncture attempt and before deciding to switch to the patient’s other arm, the phlebotomist moves the needle around several times in search of the vein without knowing exactly where the needle is in relation to the desired vein. No blood was obtained. At the new site, blood easily flows and the venipuncture is completed. The patient later complains of pain in the antecubital area where the phlebotomist was unsuccessful. What claim can be made against the phlebotomists? a. Assault b. Fraud *c. Negligence d. Res ipsa loquitur
-
Which laboratory document describes in detail the steps to follow for specimen collection? a. OSHA safety manual b. policy guidelines *c. Procedure manual d. safety manual
-
Drawinga patient's blood without his or her permission can result in ca charge of *a assault and battery b. breach of confidentiality c. Malpractice d. Negligence
-
Which of the following would violate the patient’s right to confidentiality? *a. Discussing the nature of a patient’s test results with the family b. fibing the patient a physician name that you know and trust c. sharing information on a difficult draw with a coworker d. showing a patient his or her lab results when requested
-
A phlebotomist explains to an inpatient that he has come to collect a blood specimen. The patient extends his arm and pushes up his sleeve the is an example of a. Expressed consent *b. Implied consent c. malpractice d. negligence
-
How do QC and QA differ? a. QA aims to prevent future problems b. QA is a component of a QC program c. QC attempts to prevent future problems *d. All of the above.
FINALLY FIX THAT BUG WHERE SHIT TAKE A WHOLE FUCKING MINUTE FOR STUPID REASONS
Yeaaay its the first week of learning python!!!, today we learn about making module, how to call them, and also making virtual enviroment with requirements file.... thank god i feel blessed today, fuck you covid19
Merge #45865 #46857 #47582 #47583 #47629 #47756
45865: backupccl: remove unused username param in WriteTableDescs r=dt a=pbardea
Release note: None
46857: ui: Sortable loading state r=dhartunian a=elkmaster
Added global loading state to sort tables Added loading state to database tables
Resolves: #46568
Release justification: low risk, high benefit changes to existing functionality
Release note (ui): database loading state design updates
47582: backupccl: fix flake in TestProtectedTimestampDuringBackup r=pbardea a=pbardea
TestProtectedTimestampDuringBackup would sometimes flake as the GC queue would assign it a low priority that would be below the threshold to turn shouldQueue to true. However, the priority is non-zero indicating that the timestamp was indeed not protected. This change aims to remove the flake by checking for a non-zero priority rather than if shouldQueue is true.
This PR also makes the same change to the ImportInto variant of the test since they share the same test structure.
Fixes #47522.
Release note: None
47583: col*: use logical types throughout the vectorized engine r=yuzefovich a=yuzefovich
col...: create new package and move some code
This commit introduces colbase package which currently contains the
following (that are extracted from colexec package):
allocator.gorandom_testutils.goOperatorinterfaceCopyBatchmethod.
The reason for extracting these things is that they are used by multiple col* packages, so I think it's a good hygiene to separate them out.
This commit also renames execerror package to vecerror and then
moves it inside of colbase directory. It also changes the panic
matching so that now we catch all panics coming from a package that has
pkg/sql/col in its path (this will make sure that we don't forget to
register newly added packages that use panic-catching mechanism of the
vectorized engine with the panic-catcher). Additionally, this commit
renames the methods of execerror package.
Next, it moves colexec/typeconv package into colbase as well as
colexec/testutils.go file.
Finally, it removes vecerror.NonVectorizedPanic in favor of
vecerror.ExpectedError. The guidance on whether InternalError or
ExpectedError method should be used has been updated: the distinction
is whether the vectorized engine ends up in an unexpected - invalid -
state (for example, we expect that the vectorized engine might be
performing division by zero when evaluating a binary expression).
Release note: None
col...: use logical types throughout the vectorized engine
This commit transitions the vectorized engine to use SQL logical types
wherever possible, only converting to its physical type equivalent when
necessary (for example, when choosing which instance of projection
operator to use). This will allow us to have access to the actual type
whever we need and will allow us implement coltypes.Datum for all
unoptimized types.
This commit also moves some a few things around to clean up the
dependency graph (namely, BytesEncodeFormat is moved from
sql/sessiondata to sql/lex). Additionally, it replaces a single call
to util/log.Infof with a print statement in util/protoutil package
to remove the dependency on util/log (which depends on a bunch of
other things) so that pkg/workload would need to import less things.
Another thing worth calling out is the creation of copies of types in
execplan file to make sure that we don't override the input sync
specs.
Addresses: #43559.
Release note: None
col...: introduce new package and more code movement
Move coldata/random_testutils.go into newly created package
coldatatestutils.
Move contents of colbase/random_testutils.go into coldatatestutils
package.
Rename colbase to colexecbase. Also remove templated comments from
import sections of _tmpl files in favor of adding vars that remove
unused warnings (those templated comments work poorly when
moving/renaming the dependencies).
Rename vecerror to colexecerror.
Move CopyBatch from colexecbase into coldatatestutils. Also remove
memory accounting from CopyBatch.
Move typeconv from colexecbase into coltypes folder.
Move coldata/vec_test.go into coldata_test package to prevent an
import cycle. Also move one unit test from coldata/vec_test.go into
coldata/bytes_test.go.
Move colexecbase/allocator.go into newly created colmem package.
Release note: None
47629: sql: use Clock.PhysicalTime in beginTransactionTimestampsAndReadMode r=nvanbenschoten a=nvanbenschoten
Synchronizing with the HLC clock doesn't look to be necessary. I'm confused about this though. The comment on beginTransactionTimestampsAndReadMode says that "txnSQLTimestamp propagates to become the TxnTimestamp". Is this trying to say that the timestamp makes it way into the kv.Txn? Because that's not true.
Regardless, the one reason not to make this change is that PhysicalTime is not guaranteed to be monotonic on some systems and can generally diverge from the HLC's clock. If we're worried about that though, we should use the HLC here and feed that directly into the kv.Txn. We shouldn't need to grab two timestamps from the HLC per txn.
47756: cli,base: surface stored critical errors at the right moment r=tbg a=knz
Fixes #44041
If/when storage detects an important error, the text for this error is
stored in a file named _CRITICAL_ERROR.txt in the auxiliary
directory. The intention is to block subsequent server restarts until
the error is investigated and the file (manually) removed.
Prior to this patch, this check was done in the startup sequence 1)
before logging was fully initialized 2) using a log.Fatal to
announce the critical error.
The first aspect is problematic because it logs before logging flags are applied. The second is problematic because it makes the failure super-verbose and buries the lede.
This patch simplifies the code and makes the error reported at the right place.
Example, before:
kena@kenax ....com/cockroachdb/cockroach % ./cockroach start-single-node
F200421 14:24:02.303675 1 cli/start.go:478 From .../auxiliary/_CRITICAL_ALERT.txt:
boom
goroutine 1 [running]:
github.com/cockroachdb/cockroach/pkg/util/log.getStacks(0x6a7ca00, 0xed630f902, 0x0, 0x1000)
...//src/github.com/cockroachdb/cockroach/pkg/util/log/get_stacks.go:25 +0xb8
github.com/cockroachdb/cockroach/pkg/util/log.(*loggerT).outputLogEntry(0x6a79800, 0xc000000004, 0x33eb7b9, 0xc, 0x1de, 0xc000ba8180, 0x76)
...//src/github.com/cockroachdb/cockroach/pkg/util/log/clog.go:210 +0xa92
github.com/cockroachdb/cockroach/pkg/util/log.addStructured(0x15e3420, 0xc000078168, 0x4, 0x2, 0x0, 0x0, 0xc00063f7e8, 0x1, 0x1)
...//src/github.com/cockroachdb/cockroach/pkg/util/log/structured.go:66 +0x2c9
...
[147/245]
****************************************************************************
This node experienced a fatal error (printed above), and as a result the
process is terminating.
Fatal errors can occur due to faulty hardware (disks, memory, clocks) or a
...
[email protected]
The Cockroach Labs team appreciates your feedback.
Example, after:
kena@kenax ....com/cockroachdb/cockroach % ./cockroach start-single-node
*
* ERROR: startup forbidden by prior critical alert
* DETAIL: From /data/home/kena/src/go/src/github.com/cockroachdb/cockroach/cockroach-data/auxiliary/_CRITICAL_ALERT.txt:
* boom
*
Release note (cli change): The error message displayed upon cockroach start / cockroach start-single-node when manual intervention is
needed in the store directory is now clearer.
Co-authored-by: Paul Bardea [email protected] Co-authored-by: Vlad Los [email protected] Co-authored-by: Paul Bardea [email protected] Co-authored-by: Yahor Yuzefovich [email protected] Co-authored-by: Nathan VanBenschoten [email protected] Co-authored-by: Raphael 'kena' Poss [email protected]
Retire two unused background fsck sysctls.
These two sysctls were added to support UFS softupdates journalling with snapshots. However, the changes to fsck to use them were never committed and there have never been any in-tree uses of these sysctls.
More details from Kirk:
When journalling got added to soft updates, its journal rollback freed blocks that it thought were no longer in use. But it does not take snapshots into account (i.e., if a snapshot is still using it, then it cannot be freed). So I added the needed logic to fsck by having the free go through the kernel's blkfree code so it could grab blocks that were still needed by snapshots. That is done using the setbufoutput hack. I never got that code working reliably, so it is still sitting in my work directory. Which also explains why you still cannot take snapshots on filesystems running with journalling...
In looking over my use of this feature, and in particular the troubles I was having with it, I conclude that it may be better to extract the code from the kernel that handles freeing blocks claimed by snapshots and putting it into fsck directly. My original intent was that it is complex and at the time changing, so only having to maintain it in one place was appealing. But at this point it has not changed in years and the hacks like setinode and setbufoutput to be able to use the kernel code is sufficiently ugly, that I am leaning towards just extracting it.
Reviewed by: mckusick MFC after: 1 week Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D24484
git-svn-id: svn+ssh://svn.freebsd.org/base/head@360170 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
i bend the knee to dto even though it sucks, annoying to work with, and i hate it alot - thanks for listening (#71)
Add god damn shitty workaround just due to fakin' crlf