2,488,036 events, 1,267,124 push events, 2,005,071 commit messages, 155,022,719 characters
Fix compile warnings regarding utf8 in code
Python magic is magic.
import json
lines = r"""memes.add("Sodium, atomic number 11, was first isolated by Peter Dager in 1807. A chemical component of salt, he named it Na in honor of the saltiest region on earth, North America.");
memes.add("(╯°□°）╯︵ ┻━┻ \n ༼ᕗຈل͜ຈ༽ᕗ RAISE YOUR DONGERS ༼ᕗຈل͜ຈ༽ᕗ");
memes.add("Darude- status \n ☐ Not Sandstorm \n ☑ Sandstorm");
memes.add("( ͡° ͜ʖ ͡°) Every 60 seconds in Africa, a minute passes. Together we can stop this. Please spread the word ( ͡° ͜ʖ ͡°) ");
memes.add("YESTERDAY YOU SAID TOMMOROW, Don't let your dreams be memes, Don't meme your dreams be beams, Jet fuel won't melt tomorrow's memes, DON'T LET YOUR STEEL MEMES BE JET DREAMS");
memes.add("If the human body is 75% water, how can you be 100% salt?");
memes.add(" ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ◄▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ \n Sorry, I've dropped my bag of Doritos™ brand chips▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ► ▼ ◄ ◄ ▲▲ ► ▼ ◄▼ ◄ ◄ ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ►");
memes.add("Hey Chat....... \n \n \n \n 123");
memes.add("O-oooooooooo AAAAE-A-A-I-A-U- JO-oooooooooooo AAE-O-A-A-U-U-A- E-eee-ee-eee AAAAE-A-E-I-E-A-JO-ooo-oo-oo-oo EEEEO-A-AAA-AAAA \n O-oooooooooo AAAAE-A-A-I-A-U- JO-oooooooooooo AAE-O-A-A-U-U-A- E-eee-ee-eee AAAAE-A-E-I-E-A-JO-ooo-oo-oo-oo EEEEO-A-AAA-AAAA");
memes.add("Did you just assume this books meme? #Triggered");""".replace(r'memes.add("', "").replace(r'");', "").split("\n")
for line in lines:
escaped = json.dumps(line).replace(r"\\n", r"\n")
print(f'\t\tmemes.add({escaped});')
Hallelujah and God bless all that doesn't have anything to do with filereading and the cursed methods surrounding it.
When updating files in worksheet we now just call the "writeToFile"-method all over again.
Toxin changes
Removed ptoxin, no way to actually get it.
Rebalanced neurotox for stamina to be a more damage-over-time thing. A full injection from an elder sent is roughly 100 ticks now. Removed halloss damage, replaced with one-half the amount of pain, might have to remove if fucked up. All neurotox effects removed except drugginess and stuttering. Staminaloss over time added. If you take a full injection, it's gonna suck. Starting at cycle 20, you start taking stamina damage, half-a-point per tick. Disarms will start becoming more effective over time. At cycle 50-60, this is gonna start to overwhelm your stamina regen rate and you'll crash by cycle 80 regardless.
WAYS TO COUNTER- Don't take the full 40u sting. Once you're stung, pop a pill of antitox to purge it safely at 2u/tick, or a pill of hypervene to make it (and everything in you) go oof. If you have no supplies, find a sink and drink. First OD lowered to 2 oxyloss, second lowered to 1 losebreath. Given as it processes 6x slower, if you crit OD, it's a bad day without a medic.
Added minor jitter to larval toxin as an aid to unga medicine.
I hate my life, I convert to the spaghet
It was 3 lines of code to fix. End my life
debug console
seems like i cant make up my mind, but anyone who works on Tac2 gets debug console access. If they fuck shit up and cause a server crash, then we can look at the rpt file and see who logged in last and deal with it accordingly.
Add files via upload
COVID stay at home pic from pixabay. Licence: https://pixabay.com/vectors/stay-at-home-corona-coronavirus-4956906/ https://pixabay.com/service/terms/#license Images Search images, vectors and videos
Pixabay FAQ
License
Terms of Service
Privacy Policy
About Us
Forum
Terms of Service Date of Last Revision: March 27, 2020
The following is a legal agreement between you ("you" or "User/s") and the owners and operators ("we", "us", or "Pixabay") of the site at pixabay.com (the "Website") and all related websites, software, mobile apps, plug-ins and other services that we provide (together, the "Service"). Your use of the Service, and our provision of the Service to you, constitutes an agreement by you and Pixabay to be bound by the terms and conditions in these Terms of Service ("Terms").
"Content" shall refer collectively to all Images, Videos and Audio uploaded to Pixabay and made available under the Pixabay License and the Pixabay Audio License. "Image/s" includes photographs, vectors, drawings, and illustrations. "Video" refers to any moving images, animations, films, or other audio/visual representations. "Audio" refers to any music or other audio file.
We reserve the right, at our sole discretion, to change or modify portions of these Terms at any time. If we do this, we will post the changes on this page and will indicate at the top of this page the date these Terms were last revised. Any such changes will become effective immediately. Your continued use of the Service after the date any such changes become effective constitutes your acceptance of the new Terms.
Requirements and Registration You may use the Service only if you can form a binding contract with Pixabay, and only in compliance with these Terms and all applicable laws, rules, and regulations. The Service is not available to any Users previously removed from the Service by Pixabay. You may be required to register with us in order to access and use certain features of the Service. If you choose to register for the Service, you agree to provide and maintain true, accurate, and current information as prompted by the Service's registration form. Registration data and certain other information about you are governed by our Privacy Policy. If you are under 16 years old, you may use the Service only with the approval of your parent, guardian, or teacher.
Use of the Service In connection with your use of the Service you must not engage in or use any data mining, robots, scraping or similar data gathering or extraction methods. The technology and software underlying the Service or distributed in connection therewith is the property of Pixabay and our licensors, affiliates and partners and you are granted no license in respect of that Software. You agree not to copy, modify, create a derivative work from, reverse engineer, reverse assemble or otherwise attempt to discover any source code, sell, assign, sublicense, or otherwise transfer any right in such technology or software. Any rights not expressly granted herein are reserved by Pixabay. Large scale or systematic copying of Content, including using any of the methods referred to above, is prohibited except as expressly authorized by Pixabay.
This applies to all Content, including Content, including Content made available as part of the public domain. The Service is protected by copyright as a collective work and/or compilation, pursuant to copyright laws, international conventions, and other intellectual property laws.
License for Content – Pixabay License Content on Pixabay is made available to you on the following terms ("Pixabay License"). Under the Pixabay License you are granted an irrevocable, worldwide, non-exclusive and royalty free right to use, download, copy, modify or adapt the Content for commercial or non-commercial purposes. Attribution of the photographer, videographer, musician or Pixabay is not required but is always appreciated.
The Pixabay License does not allow:
Sale or distribution of Content as digital Content or as digital wallpapers (such as on stock media websites); Sale or distribution of Content e.g. as a posters, digital prints, music files or physical products, without adding any additional elements or otherwise adding value Depiction of identifiable persons in an offensive, pornographic, obscene, immoral, defamatory or libelous way; or Any suggestion that there is an endorsement of products and services by depicted persons, brands, vocalists and organisations, unless permission was granted. Please be aware that while all Content on Pixabay is free to use for commercial and non-commercial purposes, items in the Content, such as identifiable people, logos, brands, audio samples etc. may be subject to additional copyrights, property rights, privacy rights, trademarks etc. and may require the consent of a third party or the license of these rights - particularly for commercial applications. Pixabay does not represent or warrant that such consents or licenses have been obtained, and expressly disclaims any liability in this respect.
Uploading Content By uploading Content to the Website, you grant Pixabay and its users an irrevocable, worldwide, non-exclusive and royalty-free licence to use, download, copy, modify or adapt, the Content (in whole or in part) for any purpose, both commercial and non-commercial. In the case of Audio Content, this includes, without limitation, the right to play the Audio in public and to synchronise the Audio to video content. For the avoidance of doubt, this licence includes the right of Pixabay to distribute the Content under the Pixabay License, the Pixabay Audio License, or any other license offered by Pixabay from time to time, including via the Pixabay API. You acknowledge and confirm that your Content will be made available to the public on and through the Service for personal and commercial use of third parties subject to these Terms without providing you attribution or compensation.
You are solely responsible for the Content you upload. You warrant that:
you own all proprietary rights in the Content you upload to the Website and that the Content does not infringe the copyright, property right, trademark or other applicable rights of any third parties; in the case of Audio Content, use of the Audio as contemplated by these Terms shall not infringe any rights in any underlying musical or literary work subsisting in the Audio; and you have obtained a non-exclusive, perpetual, irrevocable, worldwide, and royalty-free Model and/or Property Release, and/or any other permission necessary concerning the use of this work for any purpose, without any conditions, unless such conditions are required by law. You accept that even though we do our best to prevent it from happening, Pixabay cannot be held responsible for the acts or omissions of its users, including any misuse or abuse of any Content you upload.
We also reserve the right to remove any Content at any time and for any reason, including if we believe it's defective, of poor quality, or in violation of these Terms. Pixabay has adopted a policy of terminating, inappropriate circumstances, users who are deemed to be repeat infringers.
Notice and Takedown Policy Pixabay respects the right of creatives. Accordingly, it is our policy to respond to alleged infringement notices promptly.If you believe that your copyright, trademark, or other right has been infringed by Content that is accessible via the Service, we ask that you write to us and provide the following information:
Identification of the copyright work, trade mark or other right you claim has been infringed; Identification of the material that is claimed to be infringing, including a URL link to where it appears on the Service; Your contact details, such as your email address; A statement that you have a good faith belief that use of the material in the manner complained of is not authorised by the copyright / trademark / other right owner, its agent, or law; and5.A declaration that the above information is accurate and that you are the rights owner (or authorised to act on their behalf). Please submit the information to by email to [email protected]
The preceding does not constitute legal advice. It may be advisable to contact an attorney regarding your rights and obligations under applicable laws.
Termination We may terminate or suspend your account immediately, without prior notice or liability, for any reason whatsoever, including without limitation if you breach the Terms. Upon termination, your right to use the Website will immediately cease.
Indemnification for breach of Terms You agree to indemnify and hold harmless Pixabay from and against any and all loss, expenses, damages, and costs, including without limitation reasonable attorneys fees, resulting, whether directly or indirectly, from your violation of the Terms. You also agree to indemnify and hold harmless Pixabay from and against any and all claims brought by third parties arising out of your use of the Website.
Warranty and liability THE WEBSITE AND ITS CONTENT ARE PROVIDED "AS IS". WE OFFER NO WARRANTY, EXPLICIT OR IMPLIED, REGARDING ANY CONTENT, THE WEBSITE, THE ACCURACY OF ANY INFORMATION, OR ANY RIGHTS OR LICENSES UNDER THIS AGREEMENT INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. PIXABAY DOES NOT REPRESENT OR WARRANT THAT THE WEBSITE OR ITS CONTENT WILL MEET YOUR REQUIREMENTS OR THAT THEIR USE WILL BE UNINTERRUPTED OR ERROR FREE. PIXABAY SHALL NOT BE LIABLE TO YOU OR TO ANY OTHER PERSON OR ENTITY FOR ANY GENERAL, PUNITIVE, SPECIAL, INDIRECT, CONSEQUENTIAL OR INCIDENTAL DAMAGES, OR LOST PROFITS OR ANY OTHER DAMAGES, COSTS OR LOSSES ARISING OUT OF YOUR USE OF THE WEBSITE OR ITS CONTENT.
Learn more Model and Property Release
© 2020 Pixabay Language FAQ Terms Privacy About Us ▲
Get rid of RR_RESERVED_ROOT_DIR_FD
Admittedly, this change is primarily motivated by a philisophical objection to RR_RESERVED_ROOT_DIR_FD, rather than any great practical need. It just seems to me that if the tracee went through all the trouble of hiding the real root, then we shouldn't just give it an easy way to get it back. Of course, I'm not suggesting that this would be the only issue with running an external rr tracer on a sanboxed process without compromising that sandbox's security guarantees - I'm sure there's many others. However, this one's a pretty obvious one, so I'd like to remove it if possible.
That said, there are a couple of minor practical benefits:
- It's more robust to weird setups (weird mount setups, tmp being a symlink).
- It's more robust when recording programs that change uid
- As a result, we can get rid of a few fallbacks that would only get used if we happened to be in one of these weird setups (e.g. where we would fail to map the rr page).
- We can use memfd in more cases. This is a slightly benefit if /tmp happens to not be a tmpfs, which happens occasionally.
- There was a note in the code that things could fail in the nesting scenario if somebody chroot'ed between the outer and the inner rr (e.g. by recording a container that itself launched an rr process). That should work fine now.
- We avoid a corner case where after a setuid, some files in the trace directory would have the wrong uid.
None of these are particularly important, but together, I find them convincing enough that I think this is worth doing (I happened to need the send_fd functionality this depends upon for an unrelated change, which made doing this quite easy).
The one place where this is slightly annoying is in open_mem_fd, because we now need to send an fd and then get a new fd back. However, that only needs to happen if rr fails to open /proc//mem. A comment in the code says that Ubuntu kernels have this behavior. However, I was unable to reproduce on current Ubuntu kernels. It's also counterbalanced by allowing us to do slightly fewer syscalls elsewhere. And lastly, with pidfd_getfd and related functionality, these kinds of file transfers might in the future be quite a bit faster anyway.
8.1.Customize all the Templates! {Exploring the Templates; How to Override Templates} We can do a lot via config... but eventually... we're going to need to really dig in. And that will probably mean overriding the templates used by the bundle.
Exploring the Templates First, let's go look at those templates! Open vendor/easycorp/easyadmin-bundle/src/Resources/views/default. Ah, ha! These are the many templates used to render every single part of our admin. We can override any of these. But even better! We can override any of these for specific entities: using different customized templates for different sections. Or even... different templates to control how individual fields render. Check out layout.html.twig... this is the full admin page layout. It's awesome because it's filled with blocks. So instead of completely replacing the layout, you could extend this and override only the blocks you need. We won't do that for the layout, but we will for list.html.twig. This is responsible for the list view we've been working on. And not surprisingly, there are also new, show and edit templates. But most of the templates start with field_... interesting. Remember how each field on the list page has a "data type"? We saw this in the EasyAdminBundle configuration. The "data type" is used to determine which template should render the data in that column. firstDiscoveredAt is a date type... and hey! It has a template option that defaults to field_date.html.twig. And by opening that template, you can see how the date type is rendered.
How to Override Templates Ok, let's finally override some stuff! How!? On the same List, Search and Show Views Configuration page, near the bottom, you'll see an "Advanced Design Configuration" section. There are a bunch of different ways to override a template... ah... too many options! Let's simplify: (A) you can override a template via configuration - which are options 1 and 2 - or (B) by putting a file in an easy_admin directory - options 3 and 4. We'll try both. Ok, first challenge! I want to override the way the id field is rendered for Genus: add a little key icon next to the number... ya know, because it's the primary key. This means we need to override the field_id.html.twig template, because id is actually a data type. Copy field_id.html.twig. Then, in app/Resources/views, I already have an admin directory. So inside that, create a new fields directory and paste the file there, as _id.html.twig. Now, add the icon: fa fa-key Cool! I put the file here... just because I already have an admin directory. But EasyAdminBundle doesn't automagically know it's there. Nope, we need to tell it. In config.yml, to use this only for Genus, add a templates key, then field_id - the name of the original template - set to admin/fields/_id.html.twig Try that! Yes! It is using our template... and only in the Genus section.
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
3.0.3.1 HOTFIX
- Me, a stupid idiot, forgot to change the spigot resource ID so the plugin updater never worked ... facepalm
Signed-off-by: BuildTools
2020 april 02
holy moly i suck at analog coloring or drawing or anything, at all aaaheh aha... there goes one of my dreams.. (insert silver saying "[Delusion.]")
Engine: Rework texture class
Texture class is a lot more friendly now. Also allows for a lot more flexibility for use in different locations. Also no more stupid fucking inheritance.
Update from Forestry.io frank he deleted _posts/2015-12-22-the-reason-were-gathered-here-on-our-god-given-much-naeeded-day-of-rest-is-that-we-have-a-polish-hostage.markdown frank he deleted _posts/2015-12-22-i-was-not-going-to-stand-by-and-see-another-marine-die-just-to-live-by-rules.markdown frank he deleted _posts/2015-12-21-i-was-not-going-to-stand-by-and-see-another-marine-die-just-to-live-by-those-fucking-rules.markdown frank he deleted _posts/2015-12-21-it-would-be-totally-painless-theyd-just-slip-into-unconsciousness-and-die.markdown
fs: block MAGNETAR
Bye bye. We do not want anyone to fuck with throttling.
Signed-off-by: Yaroslav Furman [email protected] Signed-off-by: Henrique Pereira [email protected] Signed-off-by: PainKiller3 [email protected]
timerfd_create.2: Note a case where timterfd_settime() can fail with ECANCELED
From email discussions with Thomas Gleixner:
======
Hello Thomas, et al,
Following on from our discussion of read() on a timerfd [1], I happened to remember a Debian bug report [2] that points out that timer_settime() can fail with the error ECANCELED, which is both surprising and odd (because despite the error, the timer does get updated).
The relevant kernel code (I think, from your commit [3]) seems to be the following in timerfd_setup():
if (texp != 0) {
if (flags & TFD_TIMER_ABSTIME)
texp = timens_ktime_to_host(clockid, texp);
if (isalarm(ctx)) {
if (flags & TFD_TIMER_ABSTIME)
alarm_start(&ctx->t.alarm, texp);
else
alarm_start_relative(&ctx->t.alarm, texp);
} else {
hrtimer_start(&ctx->t.tmr, texp, htmode);
}
if (timerfd_canceled(ctx))
return -ECANCELED;
}
Using a small test program [4] shows the behavior. The program loops, repeatedly calling timerfd_settime() (with a delay of a few seconds before each call). In another terminal window, enter the following command a few times:
$ sudo date -s "5 seconds" # Add 5 secs to wall-clock time
I see behavior as follows (the /sudo date -s "5 seconds"/ command was executed before loop iterations 0, 2, and 4):
[[ $ ./timerfd_settime_ECANCELED 0 Current time is 1585729978 secs, 868510078 nsecs Timer value is now 0 secs, 0 nsecs timerfd_settime() succeeded Timer value is now 9 secs, 999991977 nsecs
1 Current time is 1585729982 secs, 716339545 nsecs Timer value is now 6 secs, 152167990 nsecs timerfd_settime() succeeded Timer value is now 9 secs, 999992940 nsecs
2 Current time is 1585729991 secs, 567377831 nsecs Timer value is now 1 secs, 148959376 nsecs timerfd_settime: Operation canceled Timer value is now 9 secs, 999976294 nsecs
3 Current time is 1585729995 secs, 405385503 nsecs Timer value is now 6 secs, 161989917 nsecs timerfd_settime() succeeded Timer value is now 9 secs, 999993317 nsecs
4 Current time is 1585730004 secs, 225036165 nsecs Timer value is now 1 secs, 180346909 nsecs timerfd_settime: Operation canceled Timer value is now 9 secs, 999984345 nsecs ]]
I note from the above.
(1) If the wall-clock is changed before the first timerfd_settime() call, the call succeeds. This is of course expected. (2) If the wall-clock is changed after a timerfd_settime() call, then the next timerfd_settime() call fails with ECANCELED. (3) Even if the timerfd_settime() call fails, the timer is still updated(!).
Some questions: (a) What is the rationale for timerfd_settime() failing with ECANCELED in this case? (Currently, the manual page says nothing about this.) (b) It seems at the least surprising, but more likely a bug, that timerfd_settime() fails with ECANCELED while at the same time successfully updating the timer value.
Your thoughts?
Thanks,
Michael
[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947091
[3] commit 99ee5315dac6211e972fa3f23bcc9a0343ff58c4 Author: Thomas Gleixner [email protected] Date: Wed Apr 27 14:16:42 2011 +0200
timerfd: Allow timers to be cancelled when clock was set
[4] /* timerfd_settime_ECANCELED.c */ #include <stdlib.h> #include <unistd.h> #include <stdio.h> #include <inttypes.h> #include <sys/timerfd.h>
#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)
int main(int argc, char *argv[]) { struct itimerspec ts, gts; struct timespec start;
int tfd = timerfd_create(CLOCK_REALTIME, 0);
if (tfd == -1)
errExit("timerfd_create");
ts.it_interval.tv_sec = 0;
ts.it_interval.tv_nsec = 10;
int flags = TFD_TIMER_ABSTIME | TFD_TIMER_CANCEL_ON_SET;
for (long j ; ; j++) {
/* Inject a delay into each loop, by calling getppid()
many times */
for (int k = 0; k < 10000000; k++)
getppid();
if (j % 1 == 0)
printf("%ld\n", j);
/* Display the current wall-clock time */
if (clock_gettime(CLOCK_REALTIME, &start) == -1)
errExit("clock_gettime");
printf("Current time is %ld secs, %ld nsecs\n",
start.tv_sec, start.tv_nsec);
/* Before resetting the timer, retrieve its current value
so that after the timerfd_settime() call, we can see
whether the the value has changed */
if (timerfd_gettime(tfd, >s) == -1)
perror("timerfd_gettime");
printf("Timer value is now %ld secs, %ld nsecs\n",
gts.it_value.tv_sec, gts.it_value.tv_nsec);
/* Reset the timer to now + 10 secs */
ts.it_value.tv_sec = start.tv_sec + 10;
ts.it_value.tv_nsec = start.tv_nsec;
if (timerfd_settime(tfd, flags, &ts, NULL) == -1)
perror("timerfd_settime");
else
printf("timerfd_settime() succeeded\n");
/* Display the timer value once again */
if (timerfd_gettime(tfd, >s) == -1)
perror("timerfd_gettime");
printf("Timer value is now %ld secs, %ld nsecs\n",
gts.it_value.tv_sec, gts.it_value.tv_nsec);
printf("\n");
}
}
=======
Subject: Re: timer_settime() and ECANCELED Date: Wed, 01 Apr 2020 19:42:42 +0200 From: Thomas Gleixner [email protected]
Michael,
"Michael Kerrisk (man-pages)" [email protected] writes:
Following on from our discussion of read() on a timerfd [1], I happened to remember a Debian bug report [2] that points out that timer_settime() can fail with the error ECANCELED, which is both surprising and odd (because despite the error, the timer does get updated). ... (1) If the wall-clock is changed before the first timerfd_settime() call, the call succeeds. This is of course expected. (2) If the wall-clock is changed after a timerfd_settime() call, then the next timerfd_settime() call fails with ECANCELED. (3) Even if the timerfd_settime() call fails, the timer is still updated(!).
Some questions: (a) What is the rationale for timerfd_settime() failing with ECANCELED in this case? (Currently, the manual page says nothing about this.) (b) It seems at the least surprising, but more likely a bug, that timerfd_settime() fails with ECANCELED while at the same time successfully updating the timer value.
Really good question and TBH I can't remember why this is implemented in the way it is, but I have a faint memory that at least (a) is intentional.
After staring at the code for a while I came up with the following answers:
(a): If the clock was set event ("date -s ...") which triggered the cancel was not yet consumed by user space via read(), then that information would get lost because arming the timer to the new value has to reset the state.
(b): Arming the timer in that case is indeed very questionable, but it could be argued that because the clock was set event happened with the old expiry value that the new expiry value is not affected.
I'd be happy to change that and not arm the timer in the case of a
pending cancel, but I fear that some user space already depends on
that behaviour.
Thanks,
tglx
======
Subject: Re: timer_settime() and ECANCELED Date: Thu, 02 Apr 2020 10:49:18 +0200 From: Thomas Gleixner [email protected] To: Michael Kerrisk (man-pages) [email protected]
"Michael Kerrisk (man-pages)" [email protected] writes:
On 4/1/20 7:42 PM, Thomas Gleixner wrote:
(b): Arming the timer in that case is indeed very questionable, but it could be argued that because the clock was set event happened with the old expiry value that the new expiry value is not affected.
I'd be happy to change that and not arm the timer in the case of a pending cancel, but I fear that some user space already depends on that behaviour.Yes, that's the risk, of course. So, shall we just document all this in the manual page?
I think so.
Thanks,
tglx
======
Reported-by: Thomas Gleixner [email protected] Signed-off-by: Michael Kerrisk [email protected]
small stuff dont worry dumb fuck fuck you dumb ass
ignore this bitch
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
💢 docs: Add IRC channel + quotes issue to FAQ (closes #255)
This commit addresses the pain point that @Tjzabel hit this past week
when the IRC channel is not escaped by quotes in the env file. Since
he is probably not the first or last person this will happen to, this
documents it in our FAQ.
💢 emoji because this was really frustrating. 😂
Closes #255.
Signed-off-by: Justin W. Flory [email protected]
recorder: don't use a magic index for mp_recorder_get_sink()
Although this was sort of elegant, it just seems to complicate things slightly. Originally, the API meant that you cache mp_recorder_sink yourself (which would avoid the mess of passing an index around), but that too seems slightly roundabout.
In a later change, I want to change the set of streams passed to mp_recorder_create(), and then I'd have to keep track of the index for each stream, which would suck. With this commit, I can just pass the unambiguous sh_stream to it, and it will be guaranteed to match the correct stream.
The disadvantages are barely worth discussing. It's a new linear search per packet, but usually only 2 to 4 streams are active at a time. Also, in theory a user could want to write 2 streams using the same sh_stream (same metadata, just writing different packets or so), but in practice this is never done.