2,210,112 events, 1,119,588 push events, 1,817,975 commit messages, 136,279,795 characters
Added input
Tested and doesn't work. This is the most god awful fucking trash I've ever had to try and piece together.
Add the pronouns of my beautiful amazing wonderful lovely Sophie
Created Text For URL [www.news24.com/SouthAfrica/News/student-sentenced-to-life-for-killing-his-girlfriend-20200305]
Merge #45566 #45783
45566: sql,kv: add SQL savepoints support r=andreimatei a=andreimatei
This patch adds support for SAVEPOINT , RELEASE SAVEPOINT , ROLLBACK TO SAVEPOINT . Before this patch, we only had support for the special savepoint cockroach_restart, which had to be placed at the beginning of the transaction and was specifically intended for dealing with transaction retries. This patch implements general support for savepoints, which provide an error recovery mechanism.
The connExecutor now maintains a stack of savepoints. Rolling back to a savepoint uses the recent KV api for ignoring a range of write sequence numbers.
At the SQL level, savepoints differ in two characteristics:
- savepoints placed at the beginning of a transaction (i.e. before any KV operations) are marked as "initial". Rolling back to an initial savepoint is always possible. Rolling back to a non-initial savepoint is not possible after the transaction restarts (see below).
- the savepoint named "cockroach_restart" retains special RELEASE semantics: releasing it (attempts to) commit the underlying KV txn. This continues to allow for descovering of deferred serilizability errors (i.e. write timestamp pushes by the ts cache). As before, this RELEASE can fail with a retriable error, at which point the client can do ROLLBACK TO SAVEPOINT cockroach_restart (which is guaranteed to work because cockroach_restart needs to be an "initial" savepoint). The transaction continues to maintain all its locks after such an error. This is all in contrast to releasing any other savepoints, which cannot commit the txn and also never fails. See below for more discussion. The cockroach_restart savepoint is only special in its release behavior, not in its rollback behavior.
With the implementation of savepoints, the state machine driving a SQL connection's transactions becomes a lot simpler. There's no longer a distinction between an "Aborted" transaction and one that's in "RestartWait". Rolling back to a savepoint now works the same way across the two states, so RestartWait is gone.
This patch also improves the KV savepoints. They now capture and restore the state of the read spans and the in-flight writes.
Some things don't work (yet): a) Rolling back to a savepoint created after a schema change will error out. This is because we don't yet snapshot the transaction's schema change state. b) After a retriable error, you can only rollback to an initial savepoint. Attempting to rollback to a non-initial savepoint generates a retriable error again. If the trasaction has been aborted, I think this is the right behavior; no recovery is possible since the transaction has lost its write intents. In the usual case where the transaction has not been aborted, I think we want something better but it will take more work to get it. I think the behavior we want is the following:
- after a serializability failure, retrying just part of the transaction should be doable by attempting a ROLLBACK TO SAVEPOINT. This rollback should succeed if all the non-rolled-back reads can be refreshed to the desired timestamp. If they can be refreshed, then the client can simply retry the rolled back part of the transaction. If they can't, then the ROLLBACK should return a retriable error again, allowing the client to attempt a deeper rollback - and so on until the client rolls back to an initial savepoint (which succeeds by definition). Implementing this would allow for the following nifty pattern:
func fn_n() {
for {
SAVEPOINT savepoint_n
try {
fn_n+1()
} catch retriable error {
err := ROLLBACK TO SAVEPOINT outer
if err != nil {
throw err
}
continue
}
RELEASE SAVEPOINT savepoint_n
break
}
}
The idea here is that the client is trying to re-do as little work as possible by successively rolling back to earlier and earlier savepoints. This pattern will technically work with the current patch already, except it will not actually help the client in any way since all the rollbacks will fail until we get to the very first savepoint. There's an argument to be made for making RELEASE SAVEPOINT check for deferred serializability violations (and perhaps other deferred checks - like deferred constraint validation), although Postgres doesn't do any of these. Anyway, I've left implementing this for a future patch because I want to do some KV work for supporting it nicely. Currently, the automatic restart behavior that KV transactions have is a pain in the ass since it works against what we're trying to do.
For the time-being, non-initial savepoints remember their txn ID and epoch and attempting to rollback to them after these changes produces a retriable error automatically.
Release note (sql change): SQL savepoints are now supported. SAVEPOINT
, RELEASE SAVEPOINT , ROLLBACK TO SAVEPOINT now works.
SHOW SAVEPOINT STATUS can be used to inspect the current stack of active
savepoints.
Co-authored-by: Raphael 'kena' Poss [email protected] Co-authored-by: Andrei Matei [email protected]
45783: roachtest/django: set test status while running tests r=andreimatei a=andreimatei
... to override the setup status
Release note: None
Co-authored-by: Andrei Matei [email protected] Co-authored-by: Raphael 'kena' Poss [email protected]
new fb_serialize mode, which supports keysets
Summary: I've been looking at HHVM serialization code this week anyway, and recalled a recurring feature request for keysets in fb_serialize. Since I've already have the relevant context paged-in, building support for keysets serialization was a matter of few hours.
This diff adds new fb_serialize mode, which supports serializing keysets. For now, users would need to opt into this behavior at serialization time by passing in FB_SERIALIZE_HACK_ARRAYS_AND_KEYSETS option.
To implement this, I added new FB_SERIALIZE_SET (20) tag with serialization format very similar to FB_SERIALIZE_LIST (which is used for serializing vecs).
FB_SERIALIZE_SET will only be produced by HHVM fb_serialized implementation and only if FB_SERIALIZE_HACK_ARRAYS_AND_KEYSETS is passed in. This means, there will be no behavior changes to any existing code (including memcache serialization). The only way to get new behavior is for a call site to explicitly opt-in via fb_serialize($val, FB_SERIALIZE_HACK_ARRAYS_AND_KEYSET).
On deserialization side I'm adding support for deserializing FB_SERIALIZE_SETS into all major FBSerialize implementations without extra gating. It also means, fb_unserialize() will be able to unserialize keyset even if FB_SERIALIZE_HACK_ARRAYS_AND_KEYSETS is not passed in. I have considered an alternative approach - only support deserializing FB_SERIALIZE_SET on opt-in basis (e.g. require FB_SERIALIZE_HACK_ARRAYS_AND_KEYSETS in hack), but I don't think it is good idea:
- allowing FB_SERIALIZE_SET means a slight behavior change on deserialization side - what was previously malformed serialized data may no deserialize into keyset correctly. However, this is extremely low risk. Previously FB_SERIALIZE_SET tag would be rejected by every existing FBSerialize implementation, and to my best knowledge the tag value "20" have been never used before. There are no plausible scenarios, which would lead to confusing output being constructed
- allowing FB_SERIALIZE_SET deserialization by default, especially in non-Hack serializers, makes it possible to eventually allow keysets in fb_serialize by default, if we want to do so (with appropriate migration to preserve behavior of WWW code). If C++/Python deserializers treat FB_SERIALIZE_SET as invalid value, we'll never be able to allow it in WWW by default for fear of cross-language compatibility issues. It's also much harder to change semantics, once FB_SERIALIZE_SET is actually being used anywhere.
Future possibilities:
- replace FB_SERIALIZE_HACK_ARRAYS with FB_SERIALIZE_HACK_ARRAYS_AND_KEYSETS - i.e. allow keysets by default. We should wait for 3-6 months before we consider this to ensure, that support for deserializing FB_SERIALIZE_SET is pushed out fleet-wide in fbcode. It's totally up to us whether we want to do it, but technically this will be couple of days of active work.
- enable python's fb_serialize implementation to serialize python sets int FB_SERIALIZE_SET. Python has
settype, which is slightly more flexible than keyset (it can store any hashable objects, not just ints or strings), but is close enough fit. I do not plan on adding support for serializing python sets (currently not supported by fb_serialize in python), but it's possible to do in future if anyone wants it.
Reviewed By: billf
Differential Revision: D19636679
fbshipit-source-id: c32aece64a00e4abc5a04249074a083153be9cc8
The reason I love theorem provers is: you can not do stupid mistakes
FIXED BALLS SHIT ASS COLLISION
Collision no longer makes me want to die and now it just fucking CUMS
Bonus piety for sacrificing Love, if you have a demonic guardian (afterall you're sacrificing a full 3 level demonspawn facet on top of the base that everyone else sacrifices).
fixed sandwich's fucky wucky
-
Frostmaw and Skydrake drop loot properly now and DON'T cause a stackmap error
-
FIXED bugs of: wither crash and console spam from invalid undead_horse attributes
-
ADDED a shitton more animal + monster interactions (turf wars between frostmaw and stymphalian birds! spoiler - they get bodied. skydrakes hate harpies almost as much as the collective REBN playerbase does. bears gotta eat. illagers really do be hatin the villagers)
-
nerfed stock, uncooked parasite, ice chunks (we can use ice chunks for something later but they're just there for flavor atm. hardcore version would be neat if you could chew the ice chunks to cool down)
-
it is actually "all manner of X", not plural mannerS, but ty for fixing all the other typos/making descrips clearer :)
Merge pull request #15 from TiviPlus/nodefix
Resin nodes and structure changes. Love the idea, good fucking work my dude!
oh no something got leaked ... lmao man just give me a break
did you really think i will i will still use that old shit ?? i have fully rewrited cheat based on escaperoom idea about making and components for each thing worth it. Its actually a good idea and kinda speedup code if its not much to calculate.
6082 - bugfix in spilling register vars
In the process I'm starting to realize that my approach to avoiding spills isn't ideal. It works for local variables but not to avoid spilling outputs.
To correctly decide whether to spill to an output register or not, we really need to analyze when a variable is live. If we don't do that, we'll end up in one of two bad situations:
a) Don't spill the outermost use of an output register (or just the outermost scope in a function). This is weird because it's hard to explain to the programmer why they can overwrite a local with an output above a '{' but not below.
b) Disallow overwriting entirely. This is easier to communicate but quite inconvenient. It's nice to be able to use eax for some temporary purpose before overwriting it with the final result of a function.
If we instead track liveness, things are convenient and also easier to explain. If a temporary is used after the output has been written that's an obvious problem: "you clobbered the output". (It seems more reasonable to disallow multiple live ranges for the output. Once an output is written it can only be shadowed in a nested block.)
That's the bad news. Now for some good news:
One lovely property Mu the language has at the moment is that live ranges are guaranteed to be linear segments of code. We don't need to analyze loop-carried dependences. This means that we can decide whether a variable is live purely by scanning later statements for its use. (Defining 'register use' is slightly non-trivial; primitives must somehow specify when they read their output register.)
So we don't actually need to worry about a loop reading a register with one type and writing to another type at the end of an iteration. The only way that can happen is if the write at the end was to a local variable, and we're guaranteeing that local variables will be reclaimed at the end of the iteration.
So, the sequence of tasks: a) compute register liveness b1) verify that all register variables used at any point in a program are always the topmost use of that register. b2) decide whether to spill/shadow, clobber or flag an error.
There's still the open question of where to attach liveness state. It can't be on a var, because liveness varies by use of the var. It can't be on a statement because we may want to know the liveness of variables not referenced in a given statement. Conceptually we want a matrix of locals x stmts (flattened). But I think it's simpler than that. We just want to know liveness at the time of variable declarations. A new register variable can be in one of three states w.r.t. its previous definition: either it's shadowing it, or it can clobber it, or there's a conflict and we need to raise an error.
I think we can compute this information for each variable definition by an analysis similar to existing ones, maintaining a stack of variable definitions. The major difference is that we don't pop variables when a block ends. Details to be worked out. But when we do I hope to get these pending tests passing.
Crime scene report #84262
When I glance over my notes and records of the Sherlock Holmes cases between the years '82 and '90, I am faced by so many which present strange and interesting features that it is no easy matter to know which to choose and which to leave. Some, however, have already gained publicity through the papers, and others have not offered a field for those peculiar qualities which my friend possessed in so high a degree, and which it is the object of these papers to illustrate. Some, too, have baffled his analytical skill, and would be, as narratives, beginnings without an ending, while others have been but partially cleared up, and have their explanations founded rather upon conjecture and surmise than on that absolute logical proof which was so dear to him. There is, however, one of these last which was so remarkable in its details and so startling in its results that I am tempted to give some account of it in spite of the fact that there are points in connection with it which never have been, and probably never will be, entirely cleared up.
The year '87 furnished us with a long series of cases of greater or less interest, of which I retain the records. Among my headings under this one twelve months I find an account of the adventure of the Paradol Chamber, of the Amateur Mendicant Society, who held a luxurious club in the lower vault of a furniture warehouse, of the facts connected with the loss of the British barque "Sophy Anderson", of the singular adventures of the Grice Patersons in the island of Uffa, and finally of the Camberwell poisoning case. In the latter, as may be remembered, Sherlock Holmes was able, by winding up the dead man's watch, to prove that it had been wound up two hours before, and that therefore the deceased had gone to bed within that time--a deduction which was of the greatest importance in clearing up the case. All these I may sketch out at some future date, but none of them present such singular features as the strange train of circumstances which I have now taken up my pen to describe.
It was in the latter days of September, and the equinoctial gales had set in with exceptional violence. All day the wind had screamed and the rain had beaten against the windows, so that even here in the heart of great, hand-made London we were forced to raise our minds for the instant from the routine of life and to recognise the presence of those great elemental forces which shriek at mankind through the bars of his civilisation, like untamed beasts in a cage. As evening drew in, the storm grew higher and louder, and the wind cried and sobbed like a child in the chimney. Sherlock Holmes sat moodily at one side of the fireplace cross-indexing his records of crime, while I at the other was deep in one of Clark Russell's fine sea-stories until the howl of the gale from without seemed to blend with the text, and the splash of the rain to lengthen out into the long swash of the sea waves. My wife was on a visit to her mother's, and for a few days I was a dweller once more in my old quarters at Baker Street.
"Why," said I, glancing up at my companion, "that was surely the bell. Who could come to-night? Some friend of yours, perhaps?"
"Except yourself I have none," he answered. "I do not encourage visitors."
"A client, then?"
Crime scene report #754315
"My uncle Elias emigrated to America when he was a young man and became a planter in Florida, where he was reported to have done very well. At the time of the war he fought in Jackson's army, and afterwards under Hood, where he rose to be a colonel. When Lee laid down his arms my uncle returned to his plantation, where he remained for three or four years. About 1869 or 1870 he came back to Europe and took a small estate in Sussex, near Horsham. He had made a very considerable fortune in the States, and his reason for leaving them was his aversion to the negroes, and his dislike of the Republican policy in extending the franchise to them. He was a singular man, fierce and quick- tempered, very foul-mouthed when he was angry, and of a most retiring disposition. During all the years that he lived at Horsham, I doubt if ever he set foot in the town. He had a garden and two or three fields round his house, and there he would take his exercise, though very often for weeks on end he would never leave his room. He drank a great deal of brandy and smoked very heavily, but he would see no society and did not want any friends, not even his own brother.
"He didn't mind me; in fact, he took a fancy to me, for at the time when he saw me first I was a youngster of twelve or so. This would be in the year 1878, after he had been eight or nine years in England. He begged my father to let me live with him and he was very kind to me in his way. When he was sober he used to be fond of playing backgammon and draughts with me, and he would make me his representative both with the servants and with the tradespeople, so that by the time that I was sixteen I was quite master of the house. I kept all the keys and could go where I liked and do what I liked, so long as I did not disturb him in his privacy. There was one singular exception, however, for he had a single room, a lumber-room up among the attics, which was invariably locked, and which he would never permit either me or anyone else to enter. With a boy's curiosity I have peeped through the keyhole, but I was never able to see more than such a collection of old trunks and bundles as would be expected in such a room.
Crime scene report #648069
"Indeed! You say that there was a gentleman in the pew. Some of the general public were present, then?"
"Oh, yes. It is impossible to exclude them when the church is open."
"This gentleman was not one of your wife's friends?"
"No, no; I call him a gentleman by courtesy, but he was quite a common-looking person. I hardly noticed his appearance. But really I think that we are wandering rather far from the point."
"Lady St. Simon, then, returned from the wedding in a less cheerful frame of mind than she had gone to it. What did she do on re-entering her father's house?"
"I saw her in conversation with her maid."
Crime scene report #573045
"It is fear, Mr. Holmes. It is terror." She raised her veil as she spoke, and we could see that she was indeed in a pitiable state of agitation, her face all drawn and grey, with restless frightened eyes, like those of some hunted animal. Her features and figure were those of a woman of thirty, but her hair was shot with premature grey, and her expression was weary and haggard. Sherlock Holmes ran her over with one of his quick, all-comprehensive glances.
"You must not fear," said he soothingly, bending forward and patting her forearm. "We shall soon set matters right, I have no doubt. You have come in by train this morning, I see."
"You know me, then?"
"No, but I observe the second half of a return ticket in the palm of your left glove. You must have started early, and yet you had a good drive in a dog-cart, along heavy roads, before you reached the station."
The lady gave a violent start and stared in bewilderment at my companion.
Crime scene report #59324
"It was in January, '85, that my poor father met his end, and two years and eight months have elapsed since then. During that time I have lived happily at Horsham, and I had begun to hope that this curse had passed away from the family, and that it had ended with the last generation. I had begun to take comfort too soon, however; yesterday morning the blow fell in the very shape in which it had come upon my father."
The young man took from his waistcoat a crumpled envelope, and turning to the table he shook out upon it five little dried orange pips.
Crime scene report #837916
"'Ah!' said he, 'you must not think me rude if I passed you without a word, my dear young lady. I was preoccupied with business matters.'
"I assured him that I was not offended. 'By the way,' said I, 'you seem to have quite a suite of spare rooms up there, and one of them has the shutters up.'
"He looked surprised and, as it seemed to me, a little startled at my remark.
"'Photography is one of my hobbies,' said he. 'I have made my dark room up there. But, dear me! what an observant young lady we have come upon. Who would have believed it? Who would have ever believed it?' He spoke in a jesting tone, but there was no jest in his eyes as he looked at me. I read suspicion there and annoyance, but no jest.
"Well, Mr. Holmes, from the moment that I understood that there was something about that suite of rooms which I was not to know, I was all on fire to go over them. It was not mere curiosity, though I have my share of that. It was more a feeling of duty--a feeling that some good might come from my penetrating to this place. They talk of woman's instinct; perhaps it was woman's instinct which gave me that feeling. At any rate, it was there, and I was keenly on the lookout for any chance to pass the forbidden door.
Crime scene report #94356
"We must sit without light. He would see it through the ventilator."
I nodded again.
"Do not go asleep; your very life may depend upon it. Have your pistol ready in case we should need it. I will sit on the side of the bed, and you in that chair."
I took out my revolver and laid it on the corner of the table.
Holmes had brought up a long thin cane, and this he placed upon the bed beside him. By it he laid the box of matches and the stump of a candle. Then he turned down the lamp, and we were left in darkness.
How shall I ever forget that dreadful vigil? I could not hear a sound, not even the drawing of a breath, and yet I knew that my companion sat open-eyed, within a few feet of me, in the same state of nervous tension in which I was myself. The shutters cut off the least ray of light, and we waited in absolute darkness.
Crime scene report #291175
"That is possible."
"If so, much may have happened between."
"Oh, you must not discourage me, Mr. Holmes. I know that all is well with him. There is so keen a sympathy between us that I should know if evil came upon him. On the very day that I saw him last he cut himself in the bedroom, and yet I in the dining-room rushed upstairs instantly with the utmost certainty that something had happened. Do you think that I would respond to such a trifle and yet be ignorant of his death?"
"I have seen too much not to know that the impression of a woman may be more valuable than the conclusion of an analytical reasoner. And in this letter you certainly have a very strong piece of evidence to corroborate your view. But if your husband is alive and able to write letters, why should he remain away from you?"
"I cannot imagine. It is unthinkable."
Created Text For URL [www.dailysun.co.za/News/my-brother-killed-his-girlfriend-20200306]
"9:55am. Got up 20m ago. I'll start this thing soon.
10:10am. Enough slacking. Time for the rest of the video from yesterday. After that I will have to take some time to think what comes next.
10:20am. I am doing it. I just remembered what I had been thinking about last night.
I've been trying to resolve some of the design issues Spiral.
Previously when I talked about this, I said that I decided on objects as modules, but my heart is not set on this after all. I decided to invert the idea completely.
Rather than adding yet more stuff to the language, I will instead remove keyword args. With type inference I won't need them as much. I'll only leave the unary .method style thing in as I need it to index into records.
Here is what I have in mind.
That is to translate From: 0 NearTo: 3 to From_NearTo_ (0,3) during the parsing stage. The reason for converting :s to _ is so I can grab the function itself. This will also allow me to index it in modules by writing .From_NearTo_.
Doing it this way is perfect. And I can do union constructions such as.
type Q =
| A
| B: int
| From: int NearTo: int
This is pretty powerful. I would be making the language more ergonomic while at the same time removing stuff from it and thereby reducing its complexity. It is wonderful.
Part of the reason why I intro'd the keyword args is because pattern matching on records can be a anti-pattern when some of the record fields are missing. For example passing colour rather than color as one of the fields, and having it be ignored without error in some function.
But once I add top down typing, I won't be able to test for missing fields anyway, so this won't be an anti-pattern anymore. It will be impossible to make the kind of error I am fearing so I can go back to using records for everything I would have used keyword args.
10:35am. Also this would add additional structure to the language - most languages treat camelCase and snake_case as a matter of convention, but now I will have a very real reason to differentiate them and think more carefully of how functions should be named.
Perfect. This is truly perfect. Also this will encourage opening of modules, which will improve compile time performance.
10:40am. I am in a good mood, as this was the last thing that really bugged me about Spiral.
Now let me get back to the video.
11:15am. Ok, with this I am done.
11:20am. Now what is next? Let me take a look the ASP.NET docs. I won't really study them right now, I just want to figure out what I should be doing next.
I am reading this. I can definitely understand more of this now, but even if that is the case, one thing has no changed - I still find this code exceptionally ugly and convoluted.
In comparison to C#, the TS code that I wrote while following along with the video was much more elegant and more functional in nature. I do not like putting annotations on things nor do I like reflection.
Oh, towards the end, there is a Youtube version of that tutorial. Let me take a look.
11:35am. Forget it, the documentation is just so convoluted. I don't want this at all.
11:40am. Let me take a different track. Yesterday when I looked into F# webdev, ASP.NET was not mentioned at all.
Let me try searching for F# ASP.NET and seeing what happens. I think there is a F# library that integrates with Blazor. I saw it mention somewhere.
https://github.com/giraffe-fsharp/Giraffe
11:45am. Let me try installing the template here.
E:\Webdev\giraffe>dotnet --version
3.1.101
E:\Webdev\giraffe>build
E:\Webdev\giraffe>dotnet restore src/giraffe
E:\Webdev\giraffe\src\giraffe\giraffe.fsproj : error NU1108: Cycle detected.
E:\Webdev\giraffe\src\giraffe\giraffe.fsproj : error NU1108: giraffe -> Giraffe (>= 3.4.0).
Restore failed in 27.77 sec for E:\Webdev\giraffe\src\giraffe\giraffe.fsproj.
E:\Webdev\giraffe>dotnet build src/giraffe
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
E:\Webdev\giraffe\src\giraffe\giraffe.fsproj : error NU1108: Cycle detected.
E:\Webdev\giraffe\src\giraffe\giraffe.fsproj : error NU1108: giraffe -> Giraffe (>= 3.4.0).
Restore failed in 565.99 ms for E:\Webdev\giraffe\src\giraffe\giraffe.fsproj.
Build FAILED.
E:\Webdev\giraffe\src\giraffe\giraffe.fsproj : error NU1108: Cycle detected.
E:\Webdev\giraffe\src\giraffe\giraffe.fsproj : error NU1108: giraffe -> Giraffe (>= 3.4.0).
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.99
So the template itself fails with an error. Great. F# OS tooling and ecosystem is really a mess.
I guess I'll open an issue.
12:05pm. https://github.com/giraffe-fsharp/Giraffe/blob/master/samples/GoogleAuthApp/GoogleAuthApp/Program.fs
This kind of code is much more to my taste. Definitely, but is still feels like F# is second class.
Nevermind this.
Let me check out the other F# stuff.
12:10pm. https://suave.io/
This seems like F#'s equivalent of Express.
Bolero, that is the name of the library I heard about. Now I remember.
12:20pm. Agh, all of this is besides the point. Let me stop here for a while. I am going to start planning how to do a language server when I get back."
Merge pull request #528 from Skyrat-SS13/upstream-merge-11303
[MIRROR] what the fuck you mean music line too long??
nerfs syndie outpost (#106)
-
yeah fuck ops
-
makes holdout pistol less shitty in general and replaces ops pistol with it
i mean they jammed every 2-3 shots, unreal nigga
-
minor stuff
-
Update pistol.dm
Co-authored-by: SireTurret [email protected]
powerpc: Book3S 64-bit "heavyweight" KASAN support
Implement a limited form of KASAN for Book3S 64-bit machines running under the Radix MMU:
-
Set aside the last 1/8th of the first contiguous block of physical memory to provide writable shadow for the linear map. For annoying reasons documented below, the memory size must be specified at compile time.
-
Enable the compiler instrumentation to check addresses and maintain the shadow region. (This is the guts of KASAN which we can easily reuse.)
-
Require kasan-vmalloc support to handle modules and anything else in vmalloc space.
-
KASAN needs to be able to validate all pointer accesses, but we can't instrument all kernel addresses - only linear map and vmalloc. On boot, set up a single page of read-only shadow that marks all these accesses as valid.
-
Make our stack-walking code KASAN-safe by using READ_ONCE_NOCHECK - generic code, arm64, s390 and x86 all do this for similar sorts of reasons: when unwinding a stack, we might touch memory that KASAN has marked as being out-of-bounds. In our case we often get this when checking for an exception frame because we're checking an arbitrary offset into the stack frame.
See commit 20955746320e ("s390/kasan: avoid false positives during stack unwind"), commit bcaf669b4bdb ("arm64: disable kasan when accessing frame->fp in unwind_frame"), commit 91e08ab0c851 ("x86/dumpstack: Prevent KASAN false positive warnings") and commit 6e22c8366416 ("tracing, kasan: Silence Kasan warning in check_stack of stack_tracer")
-
Document KASAN in both generic and powerpc docs.
KASAN support on Book3S is a bit tricky to get right:
-
It would be good to support inline instrumentation so as to be able to catch stack issues that cannot be caught with outline mode.
-
Inline instrumentation requires a fixed offset.
-
Book3S runs code in real mode after booting. Most notably a lot of KVM runs in real mode, and it would be good to be able to instrument it.
-
Because code runs in real mode after boot, the offset has to point to valid memory both in and out of real mode.
[ppc64 mm note: The kernel installs a linear mapping at effective address c000... onward. This is a one-to-one mapping with physical memory from 0000... onward. Because of how memory accesses work on powerpc 64-bit Book3S, a kernel pointer in the linear map accesses the same memory both with translations on (accessing as an 'effective address'), and with translations off (accessing as a 'real address'). This works in both guests and the hypervisor. For more details, see s5.7 of Book III of version 3 of the ISA, in particular the Storage Control Overview, s5.7.3, and s5.7.5 - noting that this KASAN implementation currently only supports Radix.]
One approach is just to give up on inline instrumentation. This way all checks can be delayed until after everything set is up correctly, and the address-to-shadow calculations can be overridden. However, the features and speed boost provided by inline instrumentation are worth trying to do better.
If at compile time it is known how much contiguous physical memory a system has, the top 1/8th of the first block of physical memory can be set aside for the shadow. This is a big hammer and comes with 3 big consequences:
-
there's no nice way to handle physically discontiguous memory, so only the first physical memory block can be used.
-
kernels will simply fail to boot on machines with less memory than specified when compiling.
-
kernels running on machines with more memory than specified when compiling will simply ignore the extra memory.
Despite the limitations, it can still find bugs, e.g. http://patchwork.ozlabs.org/patch/1103775/
At the moment, this physical memory limit must be set even for outline mode. This may be changed in a later series - a different implementation could be added for outline mode that dynamically allocates shadow at a fixed offset. For example, see https://patchwork.ozlabs.org/patch/795211/
Suggested-by: Michael Ellerman [email protected] Cc: Balbir Singh [email protected] # ppc64 out-of-line radix version Cc: Christophe Leroy [email protected] # ppc32 version Reviewed-by: [email protected] # focussed mainly on Documentation and things impacting PPC32 Signed-off-by: Daniel Axtens [email protected]
Changes since v7:
-
Don't instrument arch/powerpc/kernel/paca.c, it can lead to hangs. Also don't instrument setup_64.c; it's too early to be safe.
-
Reword this commit message, thanks Mikey.
-
Reinsert some tidier stack walking code, with hopefully some better justification. Certainly it is a common, cross-platform sort of issue.
-
Fix a stupid bug in early printing where I multiplied by SZ_1M rather than divided.
-
Make the memory reservation code FLATMEM friendly.
-
Kconfig tweaks, thanks Christophe.
Changes since v6:
- rework kasan_late_init support, which also fixes book3e problem that snowpatch picked up (I think)
- fix a checkpatch error that snowpatch picked up
- don't needlessly move the include in kasan.h
Changes since v5:
- rebase on powerpc/merge, with Christophe's latest changes integrating kasan-vmalloc
- documentation tweaks based on latest 32-bit changes
Changes since v4:
- fix some ppc32 build issues
- support ptdump
- clean up the header file. It turns out we don't need or use KASAN_SHADOW_SIZE, so just dump it, and make KASAN_SHADOW_END the thing that varies between 32 and 64 bit. As part of this, make sure KASAN_SHADOW_OFFSET is only configured for 32 bit - it is calculated in the Makefile for ppc64.
- various cleanups
Changes since v3:
- Address further feedback from Christophe.
- Drop changes to stack walking, it looks like the issue I observed is related to that particular stack, not stack-walking generally.
Changes since v2:
- Address feedback from Christophe around cleanups and docs.
- Address feedback from Balbir: at this point I don't have a good solution for the issues you identify around the limitations of the inline implementation but I think that it's worth trying to get the stack instrumentation support. I'm happy to have an alternative and more flexible outline mode - I had envisoned this would be called 'lightweight' mode as it imposes fewer restrictions. I've linked to your implementation. I think it's best to add it in a follow-up series.
- Made the default PHYS_MEM_SIZE_FOR_KASAN value 1024MB. I think most people have guests with at least that much memory in the Radix 64s case so it's a much saner default - it means that if you just turn on KASAN without reading the docs you're much more likely to have a bootable kernel, which you will never have if the value is set to zero! I'm happy to bikeshed the value if we want.
Changes since v1:
- Landed kasan vmalloc support upstream
- Lots of feedback from Christophe.
Changes since the rfc:
-
Boots real and virtual hardware, kvm works.
-
disabled reporting when we're checking the stack for exception frames. The behaviour isn't wrong, just incompatible with KASAN.
-
Documentation!
-
Dropped old module stuff in favour of KASAN_VMALLOC.
The bugs with ftrace and kuap were due to kernel bloat pushing prom_init calls to be done via the plt. Because we did not have a relocatable kernel, and they are done very early, this caused everything to explode. Compile with CONFIG_RELOCATABLE!
Awful awful awful hacks to get keyboard to work between scene switches god midijack has some deep and disturbing problems
Welp, we are perpetually Instruction PAge Faulting, but we think we've mapped everything correctly, but honestly, who really knows because Zig sucks and pointers in Zig are hell so we have no idea where to begin. Shoutout to @3PIV to helping with this hell.
fuck you owner
expo build breaks when the wrong owner is used
Crime scene report #791049
"By the select prices. Eight shillings for a bed and eightpence for a glass of sherry pointed to one of the most expensive hotels. There are not many in London which charge at that rate. In the second one which I visited in Northumberland Avenue, I learned by an inspection of the book that Francis H. Moulton, an American gentleman, had left only the day before, and on looking over the entries against him, I came upon the very items which I had seen in the duplicate bill. His letters were to be forwarded to 226 Gordon Square; so thither I travelled, and being fortunate enough to find the loving couple at home, I ventured to give them some paternal advice and to point out to them that it would be better in every way that they should make their position a little clearer both to the general public and to Lord St. Simon in particular. I invited them to meet him here, and, as you see, I made him keep the appointment."
"But with no very good result," I remarked. "His conduct was certainly not very gracious."
"Ah, Watson," said Holmes, smiling, "perhaps you would not be very gracious either, if, after all the trouble of wooing and wedding, you found yourself deprived in an instant of wife and of fortune. I think that we may judge Lord St. Simon very mercifully and thank our stars that we are never likely to find ourselves in the same position. Draw your chair up and hand me my violin, for the only problem we have still to solve is how to while away these bleak autumnal evenings."
"Holmes," said I as I stood one morning in our bow-window looking down the street, "here is a madman coming along. It seems rather sad that his relatives should allow him to come out alone."
My friend rose lazily from his armchair and stood with his hands in the pockets of his dressing- gown, looking over my shoulder. It was a bright, crisp February morning, and the snow of the day before still lay deep upon the ground, shimmering brightly in the wintry sun. Down the centre of Baker Street it had been ploughed into a brown crumbly band by the traffic, but at either side and on the heaped-up edges of the foot-paths it still lay as white as when it fell. The grey pavement had been cleaned and scraped, but was still dangerously slippery, so that there were fewer passengers than usual. Indeed, from the direction of the Metropolitan Station no one was coming save the single gentleman whose eccentric conduct had drawn my attention.
Crime scene report #743278
"My dear fellow, I know you well. I know the military neatness which characterises you. You shave every morning, and in this season you shave by the sunlight; but since your shaving is less and less complete as we get farther back on the left side, until it becomes positively slovenly as we get round the angle of the jaw, it is surely very clear that that side is less illuminated than the other. I could not imagine a man of your habits looking at himself in an equal light and being satisfied with such a result. I only quote this as a trivial example of observation and inference. Therein lies my métier, and it is just possible that it may be of some service in the investigation which lies before us. There are one or two minor points which were brought out in the inquest, and which are worth considering."
"What are they?"
"It appears that his arrest did not take place at once, but after the return to Hatherley Farm. On the inspector of constabulary informing him that he was a prisoner, he remarked that he was not surprised to hear it, and that it was no more than his deserts. This observation of his had the natural effect of removing any traces of doubt which might have remained in the minds of the coroner's jury."
"It was a confession," I ejaculated.
"No, for it was followed by a protestation of innocence."
"Coming on the top of such a damning series of events, it was at least a most suspicious remark."
Crime scene report #82019
"I do not wish to make a mystery," said he, laughing. "The matter was perfectly simple. You, of course, saw that everyone in the street was an accomplice. They were all engaged for the evening."
"I guessed as much."
"Then, when the row broke out, I had a little moist red paint in the palm of my hand. I rushed forward, fell down, clapped my hand to my face, and became a piteous spectacle. It is an old trick."
"That also I could fathom."
Crime scene report #962940
"They must be cunning devils," he exclaimed at last. "How could they have decoyed him down there? The Embankment is not on the direct line to the station. The bridge, no doubt, was too crowded, even on such a night, for their purpose. Well, Watson, we shall see who will win in the long run. I am going out now!"
"To the police?"
"No; I shall be my own police. When I have spun the web they may take the flies, but not before."
All day I was engaged in my professional work, and it was late in the evening before I returned to Baker Street. Sherlock Holmes had not come back yet. It was nearly ten o'clock before he entered, looking pale and worn. He walked up to the sideboard, and tearing a piece from the loaf he devoured it voraciously, washing it down with a long draught of water.
"You are hungry," I remarked.
Crime scene report #72182
"Do you not think, then, that he might have been trying to straighten it?"
"God bless you! You are doing what you can for him and for me. But it is too heavy a task. What was he doing there at all? If his purpose were innocent, why did he not say so?"
"Precisely. And if it were guilty, why did he not invent a lie? His silence appears to me to cut both ways. There are several singular points about the case. What did the police think of the noise which awoke you from your sleep?"
"They considered that it might be caused by Arthur's closing his bedroom door."
"A likely story! As if a man bent on felony would slam his door so as to wake a household. What did they say, then, of the disappearance of these gems?"
"They are still sounding the planking and probing the furniture in the hope of finding them."
woof: Import version 1.0.1
Woof! is a continuation of Lee Killough's Doom source port MBF targeted at modern systems.
MBF stands for "Marine's Best Friend" and is regarded by many as the successor of the Boom source port by TeamTNT. It serves as the code base for many of today's successful Doom source ports such as PrBoom+ or The Eternity Engine. As the original engine was limited to run only under MS-DOS, it has been ported to Windows by Team Eternity under the name WinMBF in 2004. Woof! is developed based on the WinMBF code with the aim to make MBF more widely available and convenient to use on modern systems.
To achieve this goal, this source port is less strict regarding its faithfulness to the original MBF. It is focused on quality-of-life enhancements, bug fixes and compatibility improvements. However, all changes have been introduced in good faith that they are in line with the original author's intentions and even for the trained eye, this source port should be hard to distinguish from the original MBF.
Finally the shit for liveness compiles wtf this is so annoying I hate compilers
"1:50pm. It is chores time. Let me get to it.
1:55pm. No, I'll leave them for later today as the weather is bad.
...Let me chill for a while longer.
2:25pm. Ok, enough. Let me finally resume. I'll do the chores in 2h or so.
Now I need to think of a strategy.
The first that comes to mind is that .NET has not bee particularly good to me lately. But even if it fails me, when it some to making language servers, I think I can manage now with just JS. I learned a lot of useful stuff, so in addition to the ideas I have now, I should be able to understand more if I look at the VS Code samples again.
Now...to start things off, let me do a search for remote procedure call. Something should come out if I look at how to do that in .NET.
2:40pm. Focus me, stop reading the Dendro thread.
My mission here is to learn how to make that RPC language server. So I need to stop messing around.
2:45pm. https://www.c-sharpcorner.com/article/getting-started-with-remote-procedure-call/
This is just like a regular sever it seems. It even uses IPv4 addresses for network communication.
https://stackoverflow.com/questions/4195587/what-methods-exist-for-local-remote-procedure-call
Hrrrmmm...I really do feel like I should make an effort to learn gRPC.
https://www.itprotoday.com/security/rpc-dynamic-port-allocation
RPC is a protocol?
2:55pm. http://www.fssnip.net/td/title/REST-For-Free
Somebody tagged this as RPC.
3pm. https://github.com/Zaid-Ajaj/Fable.Remoting
I am into this.
https://github.com/Zaid-Ajaj/Fable.Remoting#call-the-functions-from-the-client
Interesting.
3:10pm. https://www.quora.com/What-are-the-pros-and-cons-of-REST-versus-RPC
Read this.
3:15pm. https://docs.microsoft.com/hr-hr/aspnet/core/grpc/?view=aspnetcore-3.1
Ok, focus me. What I will do is make it a goal to implement what I want using gRPC. After I've gone through the documentation, I'll take a look at what the guy who offered help to me on the PL sub has to say.
3:20pm. https://tools.ietf.org/html/rfc5246
Now I find myself reading the TLS document.
What are these problems? I really want my language server to be usable everywhere if possible.
3:30pm. https://docs.microsoft.com/hr-hr/aspnet/core/grpc/aspnetcore?view=aspnetcore-3.1&tabs=visual-studio
Let me study the gRPC template. Basically, at this point I am 90% sure that a simple HTTP server will serve as a language server.
3:40pm. https://serverless-stack.com/
Somebody mentioned this in the /wdg/ thread.
3:45pm. https://www.youtube.com/watch?v=RzsaM6kL1FU Serverless Architecture Explained
Ah, let me watch this.
...No first let me check out the the RPC app works using Postman.
4:25pm. Had some take time off to do the chores. Let me finally do what I said I would.
Ah, the clients need to be special for this to work. Postman requests are getting no reply.
Still, the fact that even they use using var channel = GrpcChannel.ForAddress("https://localhost:5001");, that is local ports and addresses like this is actually enough to tell me everything I need to know about what language servers should be. Just regular servers. I can use Suave to do this.
I am 100% sure of it now.
4:35pm. Seriously, I wish somebody had told me this a month ago rather than me having to try to find my way through a jungle. Am I stupid for not realizing this on my own?
It is like being in front of a lake. I was afraid to go further as I had no idea how deep the thing was only to realize that it is knee length in depth after building a raft.
4:40pm. A month of my life spent on this...but I did get quite a bit of familiarity with basic web concepts.
What is my status now? Where do I go from here?
I think it is time for me to start tying up loose ends.
Since the day is starting to near its end, let me watch that serverless intro video.
4:55pm. So it is cloud stuff. Ok...this is beyond my interest at the moment.
Now what is next?
Let me check out the plugin by that guy who offered me advice.
It is this guy. It seems he did it in TS, but as far as I am concerned that is perfectly fine now.
I'll be able to manage it.
Ok, so let me clone the repo.
https://github.com/microsoft/vscode-languageserver-node
So it uses this.
5:15pm. No as well intentioned as his example was, it is too complex to really study. There is too much stuff there.
Let me take a look at the repo I just linked instead.
5:25pm. Wow, this is so amazingly complex. It reminds me of the plugin studying days.
5:30pm. What a waste of time. Whenever I look, I find a bloated mess. I made the right choice to focus on fundamentals.
Brevity is the soul of wit. Whether it is math or programming, when they are let out in the wilds they have a tendency to fill up and consume the resources in the computational environment in the process, much like actual genetic programs.
As a programmer I have enough confidence to toss away trash, whether that be overcomplicated frameworks (Reach/Angular/Vue) or other plugins. The same goes for math.
Both programming or math should either be simple, or not be at all.
Small languages like Svelte, and embedded DSLs made of functions are where true beauty lies.
5:35pm. Now...
5:45pm.
// Create a connection for the server. The connection uses Node's IPC as a transport.
// Also include all preview / proposed LSP features.
let connection = createConnection(ProposedFeatures.all);
https://www.npmjs.com/package/node-ipc
Yeah, I can definitely see more now. IPC here stands for interprocess communication. It uses that overly complex client I linked to, but I have a thread while to follow now.
5:50pm. https://github.com/microsoft/vscode-extension-samples/blob/master/lsp-sample/server/src/server.ts
// Create a connection for the server. The connection uses Node's IPC as a transport.
// Also include all preview / proposed LSP features.
let connection = createConnection(ProposedFeatures.all);
// Create a simple text document manager. The text document manager
// supports full document sync only
let documents: TextDocuments = new TextDocuments();
// Make the text document manager listen on the connection
// for open, change and close text document events
documents.listen(connection);
// Listen on the connection
connection.listen();
These two pieces are 200 lines apart so it is no wonder that I missed them. In the first part is where the server is actually created. And in the last part is where the listening happens.
5:55pm. I can do it. The past month has not been all for nothing. Without a doubt, I will be able to crack this server thing.
I can see much more now.
What I will do tomorrow is, crack open the debugger and see what let connection = createConnection(ProposedFeatures.all); is doing. Last time I remember having difficulty figuring out how to debug things, but there was an excellent chapter on debugging in the Essential TS book. And I know that I can use the Chrome dev tools to inspect the data structures much like in Pharo.
6pm. Figuring out how LSP sample works will be my test for the studying I've done over the past month it seems. I am back where I started and this time I am going to crack it.
Let me stop for the day here.
I did well all things considered. Tomorrow I will continue mining for insight."
fix minor alignment issues with SSM's header text
I spent a few hours tonight trying to figure out what ddrillini/Simply-Love-SM5#17 might be referring to so that there could be one fewer perceived fault with the theme. This commit contains whatever miscellaneous cleanup was worth keeping after giving up.
I am no closer to divining what "ScreenSummary center header is sized weirdly" might mean, but I am now 104x more confident that bitmap fonts in this theme are a disorganized mess. Neat.
make Simply Love Options more modular
Simply Love started to seriously support more than just English starting with v4.8.0. At that time, one of the testers (Jose or HeySora, I think) found that the Simply Love Options screen did not fully update to use a new language until SM was restarted.
I did not have time to fix it then, so v4.8 shipped with the note:
Please note that immediately after switching the language (for example, from English to Español), it may be necessary to restart to StepMania for all in-game text to be properly translated. This is probably a bug, but thankfully you should only need to change the language once.
Then I forgot about it for a while.
I looked into it today and realized pretty quickly that my SL_CustomPrefs table in ./Scripts/99 SL-ThemePrefs.lua was only being evaluated once, at SM init.
This commit makes SL's use of _fallback's ThemePrefs system more modular by wrapping the existing code in functions.
I added some inline comments and updated the main README.md.
Simplify BucketedSort (#53199)
Our lovely BitArray compactly stores "flags", lazilly growing its
underlying storage. It is super useful when you need to store one bit of
data for a zillion buckets or a documents or something. Usefully, it
defaults to false. But there is a wrinkle! If you ask it whether or
not a bit is set but it hasn't grown its underlying storage array
"around" that index then it'll throw an ArrayIndexOutOfBoundsException.
The per-document use cases tend to show up in order and don't tend to
mind this too much. But the use case in aggregations, the per-bucket use
case, does. Because buckets are collected out of order all the time.
This changes BitArray so it'll return false if the index is too big
for the underlying storage. After all, that index can't have been set
or else we would have grown the underlying array. Logically, I believe
this makes sense. And it makes my life easy. At the cost of three lines.
but this adds an extra test to every call to get. I think this is
likely ok because it is "very close" to an array index lookup that
already runs the same test. So I think it'll end up merged with the
array bounds check.
iommu: rewrite device assignment
This was a mess. The data structures and connections between processes, pci_devices, and iommus were all a mess. The pci device assignment wasn't integrated with the iommu, etc.
The main thing is that processes now have lists of their iommus, which will make things less painful when we do an IOTLB flush. It's still painful, but not as bad.
All of the assignment stuff was changed, so now you call the pci functions, e.g. pci_assign_device(), which will internally deal with the iommu.
When processes are destroyed, we tear down any assigned device. In my current code, all in-kernel device users hold the pdev qlock. For example, when #cbdma tries to use the IOAT driver, it qlocks the device. I think we'd be OK if the device was unassigned out from under the driver, in that the IOMMU would protect us from any wild writes, but the kernel driver would likely get wedged.
I have a bunch of changes to #cbdma, but the easiest thing right now is to just not build it briefly.
Signed-off-by: Barret Rhoden [email protected]
small shit don't even worry bout it
fuck you kid.
just pull from here (moving backgrounds and shit)
fuck you kid you are nothing