2,348,808 events, 1,187,295 push events, 1,935,223 commit messages, 140,329,515 characters
Add files via upload
- The video game landscape is predominately male with 84% of gamers falling within this gender.
- However, females tend to spend more person than males
- Most gamers are between the age of 20-24
- SN Lisosia93 made the most total purchases of any gamer
- Despair, Favor of Due Diligence is the most popular item in the game
Refactoring of POSIX netif code, mostly to accommodate BSDs
This code (likely a first attempt, as I'm sure there's some stuff in here that folks will want to change) does the following:
-
provides an implementation to manage networking notices from a PF_ROUTE socket, instead of (the Linux-specific) PF_NETLINK
-
breaks out some of the platform-specific mechanisms for configuring a tunnel device (Linux, mac OS, and NetBSD are all different in some ways)
-
provides handling of I/O to the tun drivers on BSDs (where there's a 4-byte header prepended to identify the IP version)
-
adds some debugging info and more deliberate error handling (I suspect there are some more OpenThread-friendly ways to do some of the debugging, but I didn't try to figure them out)
I've used most of this code for several months on mac OS and NetBSD, and I wanted to get a version of it shared for review. I'd love to see it merged in so that I don't have to maintain it completely by myself (and perhaps others will want to use it on those platforms), but I suspect it'll need some changes first.
fuck this shit socket.io and node is stupid and a mistake /rant over
Change description of --tasks
I have come to the opinion --tasks should be
simpler in how it works.
Before, remake --tasks did some magic to see if a target was
"interesting", and one of the criteria was if it had a description
associated with it.
After years of using, I believe --tasks should just look for targets
with descriptions. If that encourages people to document targets,
all the better.
Overall in this release I have elevated making use of target descriptions.
When we show a target now using the target command, we show any
description it has. And there is a info tasks which shows all targets
with descriptions.
Again, in my own experience here and in other projects, adding comments
and documentation is a good thing (tm); I think remake should be
doing whatever it can to promote this activity.
If limiting the checking that --tasks has to do to find its list of
targets nudges people into using the description comment more often,
then that in my opinion is a good thing.
How can you see into my eyes like open doors? Leading you down, into my core Where I've become so numb, without a soul My spirit's sleeping somewhere cold Until you find it there, and lead it, back, home Wake me up inside Wake me up inside Call my name and save me from the dark Bid my blood to run Before I come undone Save me from the nothing I've become Now that I know what I'm without You can't just leave me Breathe into me and make me real Bring me to life Wake me up inside Wake me up inside Call my name and save me from the dark Bid my blood to run Before I come undone Save me from the nothing I've become Bring me to life Bring me to life Frozen inside, without your touch Without your love, darling Only you are my life Among the dead…
tests: Add uuid_get and uuid_post.
We want a clean codepath for the vast majority
of cases of using api_get/api_post, which now
uses email and which we'll soon convert to
accepting user as a parameter.
These apis that take two different types of values for the same parameter make sweeps like this kinda painful, and they're pretty easy to avoid by extracting helpers to do the actual common tasks. So, for example, here I still keep a common method to actually encode the credentials (since the whole encode/decode business is an annoying detail that you don't want to fix in two places):
def encode_credentials(self, identifier: str, api_key: str) -> str:
"""
identifier: Can be an email or a remote server uuid.
"""
credentials = "%s:%s" % (identifier, api_key)
return 'Basic ' + base64.b64encode(credentials.encode('utf-8')).decode('utf-8')
But then the rest of the code has two separate codepaths.
And for the uuid functions, we no longer have crufty references to realm. (In fairness, realm will also go away when we introduce users.)
For the is_remote_server helper, I just inlined
it, since it's now only needed in one place, and the
name didn't make total sense anyway, plus it wasn't
a super robust check. In context, it's easier
just to use a comment now to say what we're doing:
# If `role` doesn't look like an email, it might be a uuid.
if settings.ZILENCER_ENABLED and role is not None and '@' not in role:
# do stuff
Reversal: got the basic version of it working
? It is sufficiently weird that I think there's some interest to it as a variation. I don't really understand how to play well. One instant observation is that a standard knight move instantly loses the game because it puts you in check right away which is funny.
? It's satisfying of course to just get something working while in the background I'm struggling to understand how to do v r 4. I think making some more chesses is a solid way to just get my brain back in order.
Remove cecil submodule
Cecil is an "interesting" complication: it's a dependency of
Java.Interop, but Xamarin.Android use requires that it be "vendorized"
-- renamed as Xamarin.Android.Cecil.dll -- to avoid previously seen
issues because it's an unsigned assembly, and thus There Can Be Only
One Mono.Cecil.dll loaded into an AppDomain, and whichever is loaded
first "wins", but that version may not be compatible with what other
assemblies in the AppDomain need, and...
Renaming the assembly was just seen as the easiest solution.
This choice hasn't been without its own shortcomings; see e.g. commits 168c94d1 ("priorities"), cfa74d34 (downstream build system changes), 5eeb287b ("rebuilds are hard"), 67172759 ("because of 168c94d1, xamarin-android 'owns' the checkout, but that may not be API compatible, oops"), etc., etc.
Plus, it kinda became moot with xamarin/xamarin-android@0c9f83b7
which removed the mono git submodule from xamarin-android. Instead
of building mono from source -- and, implicitly, building cecil from
source -- mono was instead obtained from a "mono archive" which
contained a prebuilt Mono.Cecil.dll which was "renamed" to
Xamarin.Android.Cecil.dll.
Which meant that in a xamarin-android build, cecil should never be
built from source anymore, which in turn meant that -- give or take
the occasional build system bug --
Java.Interop/src/Xamarin.Android.Cecil and company were "dead code",
as far as the commercial product is concerned.
Meanwhile, the existance of src/Xamarin.Android.Cecil proved to be
an ongoing source of maintenance pain, as -- depending on the IDE --
it couldn't build reliably, or would rebuild when it shouldn't have.
Rethink the whole Cecil relationship. If xamarin-android doesn't require a cecil source checkout, why not ditch it entirely?
Remove the external/cecil git submodule, and the
src/Xamarin.Android.Cecil* projects, and replace them with NuGet
package references to the Mono.Cecil NuGet package.
What this means is that a "pure Java.Interop" build will now have
different assembly references than the "same" utilities built from
xamarin-android. For example, generator.exe, when built from
Java.Interop, will reference Mono.Cecil.dll, while it will instead
reference Xamarin.Android.Cecil.dll when built from xamarin-android.
The $(CecilSourceDirectory) MSBuild property is used to determine
whether the Mono.Cecil NuGet package or the Xamarin.Android.Cecil.dll
assembly reference should be used at build time.
New scientist traitor item: Australian Slime Mutator / Spider Injector (#1307)
- New scientist traitor item: Australian Slime Mutator / Spider Injector (#44559)
cl Floyd / Qustinnus add: New scientist traitor item: Australian Slime Mutator / Spider Injector, use it on a gold slime extract to create 3 neutral broodmother spiders, make them sentient and start your own hive. /cl
'ello mates, Me and my syndicate expedition team have recently returned from my journey to the Australicus sector and crikey the spiders are big there. Fucking the size of a bear. Luckily one of my fellow expeditioners managed to knock one of the fuckers out with a boomerang and we took 'er to our labs. We managed to extract some of their extract which is known to create tame offspring when injected into a gold slime core.
However, if you give it sentience and tell it to do whatever you want, maybe you can use it for a useful purpose?
10 TC item, lets you inject a gold-slime core for some midwife/broodmother spiders that can help you start a spider army. Price can be raised if people think 10 is too little. It spawns 3 instead of 1 to keep consistent, but it can be lowered to 1 spider.
- Removed duplicate mob
Co-authored-by: AWalton 12621257+AWalton@users.noreply.github.com
memset() refactoring (#10656)
I noticed that in some builds we'd end up with memset in JS, instead of in compiled code. That's because we have memset implemented in our JS library code. That was useful in the old days before compiler_rt but today it's risky - it can lead to surprising slowness and bloat. It's also an old hack for fastcomp that we'll want to remove anyhow in time.
This ifdefs out that memset in the JS library for upstream. I didn't try to also fix fastcomp as linking is different there, and it's not worth the effort.
This removes memset from DEFAULT_LIBRARY_FUNCS_TO_INCLUDE which is an old hack. This removal is necessary as otherwise we look for it in the JS library, where it isn't any more, and error. (In fastcomp, we add it back in manually.)
There is a potentially noticeable difference here: in the past you could do x__deps: ['memset'] in a JS library, that is, depend on the JS version of memset. We have to disallow that if we want to always use the compiled optimal version. The fix for JS library code that wants to use memset is the usual: set it up in deps_info.json, that is, tell the linker that if x will be used from the JS library, then memset is needed from the system libraries. Or, without modifying deps_info.json - say, in a user's JS library - adding _memset to EXPORTED_FUNCTIONS will work. This PR adds a warning to help figure that out.
The one slightly annoying thing in this PR is that we need to add code in system_libs.py to handle the sanitizers specifically: sadly the usual deps_info mechanism does not work since we scan only user files for things, and not libraries (to be able to scan libraries, we'd need to somehow figure out which of their object files will actually be linked in - but only lld knows that).
ahead-behind: do not die when we see no INTERESTING pending object
We currently die if we are fed an ahead/behind with zero
objects (foo..foo in the most basic case, but in practice
something like foo@{upstream}..foo, when foo has just
been merged). The problem is that we let
handle_revision_arg parse it, and then pick the pieces out
of the pending object list. So "^foo" looks no different to
us there than "foo".
This patch hacks around it by picking up the UNINTERESTING object in that case. However, this isn't great because:
-
Now we won't notice some types of bogus input.
-
We end up reporting the name of the UNINTERESTING object.
We probably should pick apart the ".." ourselves, or even just change it to ":" or whitespace.
Add files via upload
❤Adult Secret Community❤ Welcoming you to the Adult Secret Community only for one night dates. We already have 5252 active Single female members from your state at this moment. ✔ Join with them, Do some flirty chat and bang her on your bed. You can also get super sexy lady from our escort section. Myprofile: http://kutti69.club/mQg3K It's 100% free to Registration this is limited time offer so Join Now Fast: http://realfuck69.online/34g4W My-profile No credit card required.
Sent from my iPhone
tty: mark Siemens R3964 line discipline as BROKEN
commit c7084edc3f6d67750f50d4183134c4fb5712a5c8 upstream.
The n_r3964 line discipline driver was written in a different time, when SMP machines were rare, and users were trusted to do the right thing. Since then, the world has moved on but not this code, it has stayed rooted in the past with its lovely hand-crafted list structures and loads of "interesting" race conditions all over the place.
After attempting to clean up most of the issues, I just gave up and am now marking the driver as BROKEN so that hopefully someone who has this hardware will show up out of the woodwork (I know you are out there!) and will help with debugging a raft of changes that I had laying around for the code, but was too afraid to commit as odds are they would break things.
Many thanks to Jann and Linus for pointing out the initial problems in this codebase, as well as many reviews of my attempts to fix the issues. It was a case of whack-a-mole, and as you can see, the mole won.
Reported-by: Jann Horn jannh@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org
(cherry picked from commit 942ddc0de8efb52c43250033c7c6091f15e191f5)
Because of OpenGL and their idiotic up-side-down coordinate system, either everyone has to flip their texture coordinates or flip their textures up-side-down. I chose the least insane approach; flipping textures on load. Because this is by far and wide the single most asked question when dealing with SDL and OpenGL, the SDL devs have decided to make this process as painful as possible. Furthermore, converting images to 32 bit RGBA, the single most wanted image format for the past 20-odd years for anyone even peripherally involved with graphics, is a process that could only be made more complicated by not offering a single piece of example code on their Wiki. So they did exactly that.
Created Text For URL [sundiatapost.com/i-love-sx-if-you-dont-satisfy-me-in-bed-i-will-cheat-on-you-beautiful-actress-warns/]
suggested wording changes
Various changes, based on what I have read. I am NOT an immunologist or epidemiologist, and don't always remember where I saw stuff, so DO NOT treat me as more of an expert than you. I'm just trying to help.
The "80% mild" particularly worries me, as it seems pretty clear that that 80% includes an awful lot of stuff that is way way past what I as a layperson would consider "mild". I think "mild" for most people is "Not bad enough to take off of work", not "hospitalized but not intubated", and there are a lot of people (Republicans in particular) who are saying, "enh, it's the flu, no big deal". YES IT IS A BIG DEAL!
It would be nice if we had a number for the % who eventually need hospitalization.
Thank you very much for doing this!
Code cleanup and minor improvements
Ugh, well I just wrote this description but lost it ( °^°)
Ten will now spend energy when shooting blood projectiles, but recovers some when hitting opponents with his veins.
New entity.spendEnergy(energy) method : subtracts energy to the user if it has enough, returns true if successful, false otherwise.
Extracted ugly code from damage interaction, made functions with it, can be used as listeners to the "hit" event (shaking the camera or entities, etc, some of them don't really work).
New vectorTransition.isDone() method (also other transitions I guess), returns true if the transition is over.
Extracted sizeTransition controller, now ends when the transition is over.
Revived some camera dead code, still kinda dead because they're not used yet, but not as much. Camera follows the player/targets more smoothly and with less glitches.
Added poh. It stands for pressed or held. I think. Returns true if the passed value equals 1 or is greater than 16 (with intervals) ; it's supposed to replicate the "Repeat the action if held long enough, or do it just once if briefly pressed".
Extracted the code for map transitions into its own function.