3,428,522 events, 1,571,742 push events, 2,422,565 commit messages, 192,654,907 characters
fuck this bullshit i dont even use rust and it just adds a shitty error message fuck this
Fixes footprint stacking (#58918)
-
Fixes footprint stacking, replace_decal needed to return parent, and just, didn't. I'm not sure where the fuck this came from, or even how to test for it, but here you are
-
Adds a unit test to prevent regressions on this error in future
-
Uses TEST_ASSERT_EQUAL instead of TEST_ASSERT
Thank you moth man
Co-authored-by: Mothblocks [email protected]
-
Updates a comment to more accurately describe my pain
-
maybe fixes it?
Co-authored-by: Mothblocks [email protected]
text borders
primarily updated the text borders to look like the swedish flag
bitch -> bonsai (not that he isn't a bitch)
if you do "FECAL FUNNY DOT COM" in the questionnaire it triggers a funny event in the mart
to do: scott into bonsai, tried to do the palette but it didn't work??; re-alphabetize the phrase thing and add more funnies into it.
sync: Make sync() satisfy many requests with one invocation
Dave Jones reported RCU stalls, overly long hrtimer interrupts, and amazingly long NMI handlers from a trinity-induced workload involving lots of concurrent sync() calls (https://lkml.org/lkml/2013/7/23/369). There are any number of things that one might do to make sync() behave better under high levels of contention, but it is also the case that multiple concurrent sync() system calls can be satisfied by a single sys_sync() invocation.
Given that this situation is reminiscent of rcu_barrier(), this commit applies the rcu_barrier() approach to sys_sync(). This approach uses a global mutex and a sequence counter. The mutex is held across the sync() operation, which eliminates contention between concurrent sync() operations. The counter is incremented at the beginning and end of each sync() operation, so that it is odd while a sync() operation is in progress and even otherwise, just like sequence locks.
The code that used to be in sys_sync() is now in do_sync(), and sys_sync() now handles the concurrency. The sys_sync() function first takes a snapshot of the counter, then acquires the mutex, and then takes another snapshot of the counter. If the values of the two snapshots indicate that a full do_sync() executed during the mutex acquisition, the sys_sync() function releases the mutex and returns ("Our work is done!"). Otherwise, sys_sync() increments the counter, invokes do_sync(), and increments the counter again.
This approach allows a single call to do_sync() to satisfy an arbitrarily large number of sync() system calls, which should eliminate issues due to large numbers of concurrent invocations of the sync() system call.
Changes since v1 (https://lkml.org/lkml/2013/7/24/683):
o Add a pair of memory barriers to keep the increments from bleeding into the do_sync() code. (The failure probability is insanely low, but when you have several hundred million devices running Linux, you can expect several hundred instances of one-in-a-million failures.)
o Actually CC some people who have experience in this area.
Reported-by: Dave Jones [email protected] Signed-off-by: Paul E. McKenney [email protected] Cc: Alexander Viro [email protected] Cc: Christoph Hellwig [email protected] Cc: Jan Kara [email protected] Cc: Curt Wohlgemuth [email protected] Cc: Jens Axboe [email protected] Cc: [email protected]
Signed-off-by: Paul Reioux [email protected]
top of mountain demo (DEMO) [demo] {DEMO} its a fucking demo it looks like shit fuck you
Refactor the tests against published results
I'm basically starting from nothing on the test coverage front. I think locking down the final output of the program is going to be the most efficient way to begin addressing that. I previously added some tests against the published results to do this, but they were a bit ugly and a little thin.
These tests are kind of difficult. The published numbers are basis set converged results, and they were obtained from large and expensive calculations. I've built some machinery to try and evaluate how much we've converged when we use a small test basis set. Then we can compare just what has converged, and if we don't have any converged digits we just skip the test.
Doing this takes a long time though, so these tests are now skipped unless an extra flag is passed in. It was also a giant pain to get working for some reason, counting converged digits in code is really annoying.
Update 06-strings.mkd
Alternatively, you can use negative indices, which count backward from
the end of the string. The expression fruit[-1] yields the
last letter, fruit[-2] yields the second to last, and so
on.
Sorry if my previous correction was kinda unreadable, I've just started with GitHub. As per Python 3.9.7, expression 'fruit[-1]' returns not the last letter, but the one before last. To get last one, we have to use 'fruit[-0]'.
i386: Fix up xorsign for AVX [PR89984]
Thinking about it more this morning, while this patch fixes the problems revealed in the testcase, the recent PR89984 change was buggy too, but perhaps that can be fixed incrementally. Because for AVX the new code destructively modifies op1. If that is different from dest, say on: float foo (float x, float y) { return x * __builtin_copysignf (1.0f, y) + y; } then we get after RA: (insn 8 7 9 2 (set (reg:SF 20 xmm0 [orig:82 _2 ] [82]) (unspec:SF [ (reg:SF 20 xmm0 [88]) (reg:SF 21 xmm1 [89]) (mem/u/c:V4SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S16 A128]) ] UNSPEC_XORSIGN)) "hohoho.c":4:12 649 {xorsignsf3_1} (nil)) (insn 9 8 15 2 (set (reg:SF 20 xmm0 [87]) (plus:SF (reg:SF 20 xmm0 [orig:82 _2 ] [82]) (reg:SF 21 xmm1 [89]))) "hohoho.c":4:44 1021 {*fop_sf_comm} (nil)) but split the xorsign into: vandps .LC0(%rip), %xmm1, %xmm1 vxorps %xmm0, %xmm1, %xmm0 and then the addition: vaddss %xmm1, %xmm0, %xmm0 which means we miscompile it - instead of adding y in the end we add __builtin_copysignf (0.0f, y). So, wonder if we don't want instead in addition to the &Yv <- Yv, 0 alternative (enabled for both pre-AVX and AVX as in this patch) the &Yv <- Yv, Yv where destination must be different from inputs and another Yv <- Yv, Yv where it can be the same but then need a match_scratch (with X for the other alternatives and =Yv for the last one). That way we'd always have a safe register we can store the op1 & mask value into, either the destination (in the first alternative known to be equal to op1 which is needed for non-AVX but ok for AVX too), in the second alternative known to be different from both inputs and in the third which could be used for those float bar (float x, float y) { return x * __builtin_copysignf (1.0f, y); } cases where op1 is naturally xmm1 and dest == op0 naturally xmm0 we'd use some other register like xmm2.
On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote:
I'm curious why we need the post_reload splitter @xorsign3_1 for scalar mode, can't we just expand them into and/xor operations in the expander, just like vector modes did.
Following seems to work for all the testcases I've tried (and in some generates better code than the post-reload splitter).
2021-09-08 Jakub Jelinek [email protected] liuhongt [email protected]
PR target/89984
* config/i386/i386.md (@xorsign<mode>3_1): Remove.
* config/i386/i386-expand.c (ix86_expand_xorsign): Expand right away
into AND with mask and XOR, using paradoxical subregs.
(ix86_split_xorsign): Remove.
* config/i386/i386-protos.h (ix86_split_xorsign): Remove.
* gcc.target/i386/avx-pr102224.c: Fix up PR number.
* gcc.dg/pr89984.c: New test.
* gcc.target/i386/avx-pr89984.c: New test.
Project Discription
A client has come to Sophie, Kim, & Rita in desperate need of help. We are passing this task on to you, our very capable students. The client could really benefit from the data science services of a skilled practitioner like you. How can you help them reach their goals?
Sophie, Kim, & Rita -
It was great to meet with you and chat at the event where we recently met and had a nice chat. We’d love to take some next steps to see if working together is something that would make sense for both parties.
As we mentioned, we are interested in harnessing the power of data and analytics to optimize the effectiveness of our street team work, which is a significant portion of our fundraising efforts.
WomenTechWomenYes (WTWY) has an annual gala at the beginning of the summer each year. As we are new and inclusive organization, we try to do double duty with the gala both to fill our event space with individuals passionate about increasing the participation of women in technology, and to concurrently build awareness and reach.
To this end we place street teams at entrances to subway stations. The street teams collect email addresses and those who sign up are sent free tickets to our gala.
Where we’d like to solicit your engagement is to use MTA subway data, which as I’m sure you know is available freely from the city, to help us optimize the placement of our street teams, such that we can gather the most signatures, ideally from those who will attend the gala and contribute to our cause.
The ball is in your court now—do you think this is something that would be feasible for your group? From there we can explore what kind of an engagement would make sense for all of us.
Best,
Karrine and Dahlia
WTWY International
For this project, you are going to deliver a preliminary analysis to your client. Your goal is to address their needs so that they can use data to inform their business choices.
To do this, you will take advantage of free, accessible data about the patterns of transit traffic in New York City: MTA turnstile data. Using this data source, as well as any other relevant dataset(s) of your choosing, perform an exploratory analysis in Python and SQL that offers insightful and actionable quantitative findings (including visualizations) to your client. Communicate your process and findings in a 5 minute presentation at the end of week 2 and a short written description.
Components Metis projects are broken down into 5 component parts -- design, data, algorithms, tools, and communication -- that are each scored individually. Below is a description of each component as it relates to this project. For more detail on how these components are graded and how extra points are rewarded, refer to the project success guide.
Design: The project should include a rationale for the steps you take which address a specific need for the client organization. It should be centered around discovering useful, actionable insights that inform your client about the movement of people in the city. All deliverable deadlines should be met, reflecting professionalism and effective scoping and workflow Data: The primary data source should be MTA turnstile data Aim to use at least 3 months worth of data; consult with an instructor if you are considering deviating from this rule of thumb, which may vary depending on your use case You are welcome and encouraged to incorporate any additional, relevant data sources Algorithms Perform a thorough Exploratory Data Analysis of the MTA turnstile data; clean, explore, aggregate, and visualize the data as appropriate to address the client's problem The MTA Analysis Pairs 1, 2, and 3, which we'll cover over the next few days, will help you get started with your data exploration Tools Ingesting the raw data into a SQL database is required. We provide two options for this:
The Quick Setup is highly recommended The Manual Setup is more in-depth Querying from that database into Python via SQLAlchemy is required
You must correctly use at least four of the following commands: GROUP BY, JOIN, WHERE, HAVING, LIKE, CASE ... END, PARTITION BY, RANK ... OVER, CREATE TABLE, AND / OR / NOT, INSERT, UNION, ROW_NUMBER, a subquery, a common table expresssion Exploratory data analysis in pandas is required
Python visualization libraries (such as matplotlib and seaborn) are required
Other tools not covered in the course are optional but welcome
Major examples of applicable tools not covered in the course:
Processing tools could include Google Cloud or Amazon Web Services for cloud computing resources Visualization tools could include more advanced Python libraries such as Bokeh and Plotly or resources outside of python such as Tableau Communication: Students will deliver a 5 minute slide presentation at the end of the course. These should be given in a compelling, clear manner and include effective visuals for communicating your objectives and findings. You will also submit a ~1 page written description summarizing your work: it should begin with a ~100 word abstract to be followed by a breakdown of your project along the 5 major components. Deliverables: Please submit all project deliverables through the Student Submissions Form. All project deliverables and code should be uploaded to a personal, project-specific GitHub repository. Click here for instructions on how to set up a personal repo.
For exact deliverable dates, refer to the main schedule here.
For exact deliverable details, refer to the (linked) Metis Fundamentals project deliverable templates.
Project proposal: short description shared with instructors Additionally, students may meet with an instructor for a scope meeting Minimum Viable Product (MVP) submission Written description, presentation slides PDF, and project code Project Presentation. Do not wait to start your slides. Start with an outline, and make incremental changes to guide your story (and thereby your analysis) as you go. Also, don't forget to practice at least once with a classmate or a TA! You should have content (at least a slide) for each of the following: Introduction (think motivation) Methodology Results Conclusion (think impact)
"2:05pm. Let me resume.
using Omega
using UnicodePlots
nflips = 4
weight = β(2.0, 2.0)
coinflips_ = [bernoulli(weight, Bool) for i = 1:nflips]
coinflips = randarray(coinflips_)
observations = [true, true, true, false]
condition = coinflips ==ᵣ observations
weight_samples = rand(weight, condition, 10000; alg = RejectionSample)
histogram(weight_samples)
mean(weight_samples)I am playing around with this. Let me move to the next example.
2:10pm.
x1 = uniform(0.0, 1.0)
x2 = uniform(0.0, 1.0)
rand((x1, x1, x1 + x1))Let me go through this.
2:05pm.
function liftnoesc(fnm::Union{Symbol, Expr}, isrv::NTuple{N, Bool}) where N
args = [isrv ? :($(Symbol(:x, i))::RandVar) : Symbol(:x, i) for (i, isrv) in enumerate(isrv)]
quote
function $fnm($(args...))
Omega.lift($fnm)($(args...))
end
end
endThis is quite a function.
2:30pm.
using Omega
function x_(rng)
if bernoulli(rng, 0.5, Bool)::Bool
normal(rng, 0.0, 1.0)::Float64
else bernoulli(rng, 0.5, Bool)
betarv(rng, 2.0, 2.0)::Float64
end
end
~x_Let me step through this. This is what I've been wondering about the most.
I know I said I would go through all the examples, but I am not getting much out of stepping through the code.
2:50pm.
using Omega
x = normal(0.0, 1.0)
x_cond = cond(x, x > 0.0)
histogram(rand(x_cond,100;alg=RejectionSample))2:55pm. Sigh, I am not getting much out of this. Programming is the kind of thing you get the most out of by doing instead of reading.
My conclusion from being able to observe Julia in action is that the coding style it encourages is too complex. The language features are too powerful and Zenna did not hold back at all while writing the library.
As a rule of thumb, even in a dynamic language the way to get the most out of it is to write as if the language had a first order type system.
Macros, overloading, indirection are all poison to understandability. In this library everything happens everywhere else.
3pm. In order to learn, I need to do it myself. I'll use the documentation for Omega as the basis and try to replicate the examples I've seen with a library of my own making. That is the best kind of homework.
Though I'll admit, if I got paid work to modify some part of the library right now, I am not sure how I would handle it. I am not ready for it right now.
I thought that if I ever got a job and got a task like that I'd just isolate the functionality that needs to be done from the rest of the system, implement it and then find a way to merge it without disturbing the rest.
3:05pm. Right now I am feeling down, but things are going as well as one would expect when studying a complex system done by somebody else. I am sure that studying Spiral's source would be hard to other people too.
With effort I should be able to achieve enlightenment.
3:15pm. I reading the ML sub instead of working. Let me check out the paper I talked about.
https://arxiv.org/abs/1809.10756 An Introduction to Probabilistic Programming
It seems it did not get updated since it was released 3 years ago. Ok, fine.
It is 218 pages. I should dedicate time to seriously studying it. Let me spend the rest of the day like this. Tomorrow, I'll open work on the Omega clone. I'll name it the Helix library.
4pm. > Let us momentarily consider alternative ways to solve such a “Captcha problem.” A non-probabilistic programming approach would require gathering a very large number of Captchas, hand-labeling them all, then designing and training a neural network to regress from the image to a text string (Bursztein et al., 2014). The probabilistic program�ming approach in contrast merely requires one to write a program that generates Captchas that are stylistically similar to the Captcha family one would like to break – a model of Captchas – in a probabilistic programming language. Conditioning such a model on its observable output, the Captcha image, will yield a posterior distribution over text strings. This kind of conditioning is what probabilistic programming evaluators do.
I suppose going in this direction for the next few years would not be bad. I literally have nothing better to do with my life.
5pm. Focus me. I seem to be taking a break to lurk /a/ threads. I need to get this done.
37/2018. Right now I've finished the first chapter, and it is time to get going with the second. Though it is also kind of late.
Reading books is boring as usual. I should get this out of the way and then do some programming. What the book says about...
Let me backtrack a little so I can quote a paragraph.
Actually, it is several pages near the end of ch 1 of essentially giving examples. Maybe there is something I could do for poker here.
Let me take a short break here. I think I'll just have lunch in fact.
6:20pm. 52/218. For hold long will chapter 2 continue? Ah 2 more pages. Ok, let me finish it then.
6:25pm. 54/218. Let me stop here at the start of chapter 3. I should be able to make quick progress through this book. After that I will give implementing my own probabilistic programming library a try. Hopefully a combination of having such a goal and using Omega as a reference will let me push through the obstacle and help me understand both.
I am very limited in how much understanding I can attain just from reading. Maybe other people could get more out just reading the source, but I can't.
6:30pm. Once I failed my second run, I became very obsessed about AI chips, but looking at it more broadly they will have many uses than just pure NNs. So it is fine if I delay this to produce something that along these lines. I'll do the Bayesian thing safe in the knowledge that these skills will be useful future computational regime. If this turns out useful I will be porting my PPL to those chips.
I believed from the very start that making a decent player should be a viable goal even with my current hardware. Sure, it might not be an AI chip, but the CPU and the GPU that I have are extremely fast in an absolute sense. I should not have nothing.
I've put in 6.5 years without achieving my goals, but so what? Why not put in a few more to master probabilistic programming?
There is nothing better in life than the path towards AI. The struggle to end the era of man is the story of the first half of the 21st century."
modpost: file2alias: go back to simple devtable lookup
commit ec91e78d378cc5d4b43805a1227d8e04e5dfa17d upstream.
Commit e49ce14150c6 ("modpost: use linker section to generate table.") was not so cool as we had expected first; it ended up with ugly section hacks when commit dd2a3acaecd7 ("mod/file2alias: make modpost compile on darwin again") came in.
Given a certain degree of unknowledge about the link stage of host programs, I really want to see simple, stupid table lookup so that this works in the same way regardless of the underlying executable format.
Signed-off-by: Masahiro Yamada [email protected] Acked-by: Mathieu Malaterre [email protected] [nc: Omit rpmsg, sdw, fslmc, tbsvc, and typec as they don't exist here Add of to avoid backporting two larger patches] Signed-off-by: Nathan Chancellor [email protected] Signed-off-by: Sasha Levin [email protected] Signed-off-by: Kevin F. Haggerty [email protected] Change-Id: Ic632eaa7777338109f80c76535e67917f5b9761c
chore: Clean-up copy-pasted Compass styles from all the packages
This was not as straightforward as initially expected, but brings a few benefits:
- All plugins are now referencing compass styles from the single source
- No need for download-akzidenz scripts in any package except for Compass
- Just cleans up a bunch of cobweb covered code in the repo that is hard to justify now
- Fixes fonts and icons when running plugins as a standalone playgroud
This change required updating all less loaders in all the packages and more explicitly providing information what is a css module and what is not based on the file name, so almost all less files god renamed.
This change also required to hackily refer to mongodb-compass as a library in a few places creating a recursive dependency, but imo this clean up is worth it and eventually we can move all things that are actually shared between plugins and compass in their own, separate place
Extremely sorry in advance for a massive diff that this generated, I'm happy to go through the whole thing together with whoever feels brave enough to review it
sched/core: Implement new approach to scale select_idle_cpu()
Hackbench recently suffered a bunch of pain, first by commit:
4c77b18cf8b7 ("sched/fair: Make select_idle_cpu() more aggressive")
and then by commit:
c743f0a5c50f ("sched/fair, cpumask: Export for_each_cpu_wrap()")
which fixed a bug in the initial for_each_cpu_wrap() implementation that made select_idle_cpu() even more expensive. The bug was that it would skip over CPUs when bits were consequtive in the bitmask.
This however gave me an idea to fix select_idle_cpu(); where the old scheme was a cliff-edge throttle on idle scanning, this introduces a more gradual approach. Instead of stopping to scan entirely, we limit how many CPUs we scan.
Initial benchmarks show that it mostly recovers hackbench while not hurting anything else, except Mason's schbench, but not as bad as the old thing.
It also appears to recover the tbench high-end, which also suffered like hackbench.
Tested-by: Matt Fleming [email protected] Signed-off-by: Peter Zijlstra (Intel) [email protected] Cc: Chris Mason [email protected] Cc: Linus Torvalds [email protected] Cc: Mike Galbraith [email protected] Cc: Peter Zijlstra [email protected] Cc: Thomas Gleixner [email protected] Cc: [email protected] Cc: kitsunyan [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar [email protected] Signed-off-by: Raphiel Rollerscaperers [email protected]
at this point i have already lost fucking track of what in fucking hell im doing, confused and bored trying to solve shit im not comfortable with ffs
About me :)
Assalam o alaikum and Hello everyone😊 I hope you are well. This is your friend Sypher. I'm an amateur coder/programmer. I'm creating this blog project so I can better remember what I have learnt :) Have a nice day/night ❤❤❤
Building work
BUILDING WORK note: Chaos Buildings could do with more work but it's acceptable for them to be overpowered in the next release. Will revise them if time permits.
*Reversed some legacy troop inflation on vanilla buildings *Adjusted Chaos Dwarf buildings (downwards) to be closer value to vanilla
- Tweaked Imperial Castle buildings after discovering how new firearms are in the Empire (1991 IC)
- Set up new Building lines for Human Temples: +Templar Barracks replaces Elite Barracks, because Warhammer is full of templar orders running around in heavy armour. Some of them are pikemen because Myrmidia ++ 2nd replacement chaos_barracks fits in here. ++ 2nd replacement, Djinni Treasure Trove for Ormazdic Group (they shouldn't have a lot of Heavy Infantry) ++ 2nd replacement Fenbeasts for Old Faith ++ 2nd replacement Grave Guard for Necromantic Group. Technically this is the vanilla Elite Barracks but we get to show the lore and can apply a special is_active_trigger ++ 2nd replacement Sons of Stromfels for Stromfels. Whatever.
- Zealots replace Temple Barracks ++ 2nd replacement Crypt Ghouls for Necromantic
- Morr's Garden replaces Library. (Note that the lore suggests education becoming less religious across the Old World, so a Temple School is pretty old hat. The Garden allows for lore on the necromantic threat.) ++ 2nd replace Apprentice Necromancers for Necromantic Group
- Converted Estalian "special buildings" to Great Works
- Added some port upgrades for Human City great work
- Threw out some obsolete Dark & High Elf building definitions. (This stuff would need reworking even in the unlikely event that we bring them back.)
+FIXES
- Saw Witch Hunters failing to burn their victims. Corrected typo in witch hunter events. Observed behavior still a bit wonky but heretics are getting burned.
- Allow construction of new Dwarf Holds. The scripts have at least seen a lot of alpha-testing at this point, and allowing somewhat free construction should make for better feedback
- Red Duke set to a plausible age for a dude who fought in the Crusades. His mortal family has been deleted because there ain't no way those ladies were around in this time frame. (Duke himself shouldn't be playing the role he does in the mod but that's a bigger change.) *Duke Otto of Aquitaine moved to D'Aquitaine dynasty (same as Red Duke, because he's very likely one of the vampire's descendants) *Switch Aquitaine to Primogeniture Succession to prevent Red Duke being heir (this seems to be more accurate than Seniority anyway) *Add setup event to make the modern d'Aquitaines members of the Red Duke bloodline
- Fixed up some localisation
- Akendorf special building removed. No replacement wonder because it's a village of less than a thousand people.
Chrome
Strapped up the Morr's Garden situation by excluding it for chaos_gods_group and ormazd_group. They should replace but this is adequate.
Added a raft of extra wonder upgrades. Reduced cost impact for multiple wonders of the same type
Added high end society powers:
- Engineers and Inventors can now spend huge amounts of society currency to improve the new Great Works.
- Shallyans can self-sacrifice to set back the Doom counter. (They need a full rework but this gives the society a bit more flair.)
Did some reworking of Myrmidian Religion so it's different from Geheimnisnacht. Some of these changes are strict improvements.
- Moved Cult of Myrmidia to default capital in the Blighted Marshes (Tylos). Not right, not wrong either. (The setup with the Cult capitaled in Magritta is based on the specific situation in the Karl Franz era and we're told that's unusual.)
- Moved Myrmidian holy site from Istrabul (why?) to Couronne (center of Shallya's faith - the sister of Myrmidia!)
- Moved Myrmidian pentarchy site from Thakos to Couronne (this and the Altdorf site should probably should get a fancier treatment but this will do for now), removed Bilbali pentarchy site.
- Deactivated the High Temple titles. They don't really work as intended right now so we're better off with default Pentarchy behavior until a comprehensive rework
Caught some typos in previous work
Tried bugfixing the rare issue with the legendary journeys events. It looks like the problem (inherited from vanilla) is re-calling HF.12000 as a character event even though it's a province event.
Used error log to patch up some issues with events. (Still had some no MTTH/no trigger events, including one of mine :( )
docker-compose: log tailing robustness fixes
The core issue this aims to solve is that for a stopped container,
docker-compose logs exits, and Tilt would continuously attempt
to re-launch it, resulting in high CPU usage due to repeatedly
invoking the command.
However, there were actually several intermingled issues that this
exposed/worsened. These mostly tie back to the behavior of
docker-compose logs: there is no built-in support for time
filtering (unlike docker logs --since ...), and since it exits
when a container stops, once invoked again, all the old logs will
be returned again. This means if a container crashes/restarts,
we'd re-emit all the old logs each time. Similarly, if there is
a "job" container that naturally runs to completion, whenever
re-triggered from the UI to run it, all the logs from prior
invocations would be re-logged. (This could also mean when attaching
on start up that you'd get a bunch of logs prior to the last
[re]start, which isn't super useful either.)
To solve this issue, docker-compose logs is now invoked with the
--timestamps argument, which prepends an RFC3339Nano timestamp
before each log line. Of course, there are caveats: first, Compose
v2 includes a whitespace before the timestamp and second, meta logs
from Compose itself about container events do NOT have a timestamp.
As a result, the attempt to parse/filter by the timestamp is very
forgiving. (There's an additional wrinkle which is that evidently
the StartedAt time reported by Docker for a container is not
precise, so you can actually get logs with earlier timestamps!)
Tying back to the original problem that once docker-compose logs
exits, Tilt tries to continuously re-invoke it, the watcher behavior
has been altered to more closely mirror the Pod log stream watcher.
When reading, if EOF is reached and/or the context is canceled,
it stops. The former case means that docker-compose logs exited
normally, indicating that the container is no longer running. The
latter case means the manifest is being torn down, so we no longer
want logs. Any errors during reading will cause it to retry, e.g.
if docker-compose logs crashes or is terminated abnormally.
(To support propagating process execution errors, the way that
logs are read has been adjusted slightly, which actually resolves
a race condition on reading logs and the docker-compose logs
process terminating, which ensures that short-lived containers
get all their logs!)
In the subscriber, when looking at already created watchers, if
the watcher has stopped running, a new one will only be created
if the corresponding container's start time is AFTER the last
time it started. This is the key to not continuously starting
up new docker-compose logs processes! (Finally.) We can't
key off container ID because that's consistent across restarts,
including both crashes and job containers that are run multiple
times without changes.
Finally, there is a fix for the Docker Compose event watcher
which was inadvertently broken (by yours truly) a while back.
It was not actually ever running, so Tilt wouldn't notice
external changes (e.g. docker-compose restart foo), which
meant state was out of sync. This was not really noticeable
before since we were insanely aggressive about re-establishing
docker-compose logs sessions. After these fixes, however,
it meant that any container events not initiated via Tilt
would go unnoticed, so the logs would not get resumed, as the
new container start time would never get picked up.
TL;DR Docker Compose logs should behave much nicer now both in terms of CPU usage as well as under various common scenarios like container restarts or job containers
use shell primitives for /etc/default/evm
using sed and xargs is not that slow, but since we source this quite a lot, getting every second out of it
this is no longer sh friendly, thought to be honest, I'm not
sure if traditional bash (without [[ ]] linking to test) exists
Updating: 9/8/2021 11:00:00 PM
- Added: Australian Breaking News Headlines & World News Online | SMH.com.au (https://www.smh.com.au/)
- Added: About (https://mentor-crypto-2021.github.io/)
- Added: The Secret Entrepreneurs of North Korea – Mr. Steinberg (https://mrsteinberg.com/secret-entrepreneurs-of-north-korea/)
- Added: How to drive away your best engineers. | padraigobrien.com (https://padraigobrien.com/posts/2021/09/how-to-drive-away-your-best-engineers/)
- Added: Daily Confirmed Cases in NSW - COVID LIVE (https://covidlive.com.au/report/daily-cases/nsw)
- Added: Norway COVID: 171,719 Cases and 826 Deaths - Worldometer (https://www.worldometers.info/coronavirus/country/norway/)
- Added: What they don’t tell you when you translate your app (https://ericwbailey.design/writing/what-they-dont-tell-you-when-you-translate-your-app/)
- Added: The Adjacent User Theory at andrewchen (https://andrewchen.com/the-adjacent-user-theory/)
- Added: The Compiled Future of Front End (https://www.arahansen.com/the-compiled-future-of-front-end/)
- Added: Challenge to VS Code Python? JetBrains Tests Data Science IDE -- Visual Studio Magazine (https://visualstudiomagazine.com/articles/2021/09/08/jetbrains-dataspell.aspx)
- Added: Restrictions for Impacted Areas – South East Queensland (https://www.qld.gov.au/health/conditions/health-alerts/coronavirus-covid-19/current-status/public-health-directions/restrictions-impacted-areas)
- Added: Should you delete social media? That’s the wrong question. (https://mehretbiruk.com/delete-social-media/)
- Added: The mystery of load average spikes (https://blog.nicolas17.xyz/posts/load-average-spikes.html)
- Added: Transparency in startups (https://tushar.posthaven.com/transparency-in-startups)
Generation took: 00:08:47.5247223 Maintenance update - cleaning up homepage and feed