2,545,571 events, 1,276,655 push events, 2,038,363 commit messages, 149,666,576 characters
___ <- sync_wiki.sh: Modified: Algorithm.html, AsciiArt/AsciiFunny.html, AsciiArt/AsciiVeronicaKarlsson.html, Assembly.html, Bash.html, Coding-Style.html, Design-Pattern.html, Emoji.html, Firefox.html, Java-HackerRank.html, Java-Module-Standard.html, Java.html, Js-Fuck.html, Jupyter-TroubleShooting-Windows.html, Jupyter.html, Latex.html, Linux.html, Make.html, Perl-HackerRank.html, Perl.html, Perl_Old_Reference.html, Python.html, Quotes.html, Raku-Cheat.html, Raku-Guide.html, Raku-Introspection.html, Raku-Nqp.html, Raku-OneLiner.html, Raku-Regex.html, Raku-Y-Minute.html, Raku.html, Raku_Mem.html, Raky-Style.html, Redaction.html, Regex-Collection.html, Rust.html, Sql.html, Style/Style.html, Style/pydocstring.html, Style/style.html, System-Design.html, Text.html, Tmux.html, Ubuntu.html, Vim-Color.html, Vim-Menu.html, Vim.html, Xterm.html, index.html
CORONAVIRUS UPDATE - Python i hate you so fucking much please fucking die fuck you fuck you fuck you fuck fu jgsh hufdgjdfb ghsjlbfhbdk
merge feature/wigital-discovery into develop, as the latest demo runs off this, and as agreed. Clean up some small matters, errors, remaining references to default images we should use, substituting our solid own, a way they don't add to bundle but will get loaded fast if needed. Left in vuex store bones, as soon we'll elaborate and use them, one or two other things, and these will be pulled back into feature/wigital-discovery for a cns working branch. Tested the result briefly, and it looks good. Will now seek to get in this evening both some of what couldn't get into demo yesterday, in particular static menubar on large screens but preserving their advantages on small, maybe some illuminated buttons. n.b. The issues with larger screens and Viewer images has had a long, deep investigation overnight which gathered interesting facts, but not a fix yet. When one comes, it'll go into develop here.
[MIRROR] [BOUNTY] More logging (#1515)
-
[BOUNTY] More logging (#1459)
-
Merges all required things along with the random name thing
the random name seemed to be required???? unsure why though
- adds the shit
end me
- Update names.dm
github is being a bitch, so i'm using the browser for these small changes
- Update cards_ids.dm
also from the browser, god I really need to start using git kraken or some shit
-
Update cards_ids.dm
-
Update cards_ids.dm
fixed a few indentation errors
- [BOUNTY] More logging
Co-authored-by: Bastian0930 [email protected]
FROM Lori Robinson Dearest, With Due Respect And Humanity, I was compelled to write to you under a humanitarian ground. My name is Sister Lori Robinson 69 yers old from Netherlands a widow reside in Ouagadougou Burkine Faso, please, i do not have formal relationship with you but because of my present predicament and circumstances i am made to contact you.i have been suffering from cancer and have a short life to leave.i have made up my mind to taking this decision to hand you over my late husband in heritance Fund. I am not afraid of death hence I know where I am going.I want you to always remember me in your daily prayers because of my up coming Cancer Surgery. Write back as soon as possible any delay in your reply will give me room in sourcing another person for this same purpose, Hoping to read from you asap. God bless you as you listing to the voice of reasoning, May God met you at any point of your needs. Your Sister In Christ, Sister Lori Robinson
Added rudimentary support for general timeslots..
such as {'breakfast', 'brunch', 'lunch', 'dinner', 'supper', 'morning, 'afternoon', 'night'}.
Arabic files and translation
We might have trouble to the right to left format in Arabic, hebrew etc. I did a light googling https://stackoverflow.com/questions/2258028/rtl-in-markdown Here is one seems-to-simple suggestion:
"""Actually as my friend Aevyz reminded me, Markdown parses HTML in it.
You won't need to change your parser. The quickest path to solve that I could think of is this:
سلام دنیا
مرحبا العالم
שלום בעולם
ہیلو دنیا
18.2.Event Hooks{ Fetching Info off the Event }
Fetching Info off the Event For this event, the important thing is that we have a subject property on GenericEvent... which holds the User object. We can get this via $event->getSubject(). Remember though, this PRE_UPDATE event will be fired for every entity - not just User. So, we need to check for that: if $entity instanceof User, then we know it's safe to work our magic. Since we already took care of setting the updatedAt in the controller, let's do something different. The User class also has a lastUpdatedBy field, which should be a User object. Let's set that here. That means we need to get the currently-logged-in User object. To get that from inside a service, we need to use another service. At the top, add a constructor. Then, type-hint the first argument with TokenStorageInterface. Watch out: there are two of them... and oof, it's impossible to know which is which. Choose either of them for now. Then, name the argument and hit Alt+Enter to create and set a new property. Back on top... this is not the right use statement. I'll re-add TokenStorageInterface: make sure you choose the one from Security\Core\Authentication. In our method, fetch the user with $user = $this->tokenStorage->getToken()->getUser(). And if the User is not an instanceof our User class, that means the user isn't actually logged in. In that case, set $user = null. Then, $entity->setLastUpdatedBy(). So go back, refresh and... no errors! It's always creepy when things work on the first try. Go to the show page for the User id 20. Last updated by is set! Next, we're going to hook into the bundle further and learn how to completely disable actions based on security permissions.
19.5.Conditional Actions{ Controlling the Actions in the show Template }
Controlling the Actions in the show Template But don't worry! With all our knowledge, this should be quick and painless. Inside of the bundle, find the show template. And inside it, search for "actions". Here we go: block item_actions. To control the actions, we can do a very similar thing as the list template. In fact, copy the list template, and paste it as show.html.twig. Because it's in the right location, it should automatically override the one from the bundle. Extend that base show.html.twig template. Before, we overrode the _list_item_actions variable and then called the parent() function to render the parent block. But... that actually won't work here! Bananas! Why not? In this case, the variable we need to override is called _show_actions. And... well... it's set right inside the block. That's different from list.html.twig, where the variable was set above the block. This means that if we override _show_actions and then call the parent block, the parent block will re-override our value! Lame! No worries, it just means that we need to override the entire block, and avoid calling parent. Copy the block and, in show.html.twig, paste. Next, add our filter: set _show_actions = _show_actions|filter_admin_actions. Remember, we need to pass the entity object as an argument to filter_admin_actions... and that's another difference between show and list. Since this template is for a page that represents one entity, the variable is not called item, it's called entity. As crazy as that looks, it should do it! Hold you breath, do a dance, and refresh! Hey! No edit button!
[MERGE] calendar, google_calendar: Refactoring
TL;DR A bit of magic and ... Pouf ... all virtual events are now real records.
The current implementation of recurring events uses "virtual events" to represents all events in the recurrence. Only one event is stored in the database. All other events are dynamically built and sent to the web client which sees them as real records. This implementation is old, difficult to read (6 years of changes and bug fixes) and has become more and more difficult to maintain. A fresh start would be welcome.
When creating a recurring event, a calendar.recurrence.rule record should be created.
This model holds the rrule configuration and is responsible to manage events that result
from the rrule.
When a new recurrence is created, all resulting events are also created (stored in the
database). No more virtual events.
To avoid an explosion of events, a maximum of 720 events is created. With 720 events,
a daily recurrence lasts for 2 years and a weekly recurrence lasts for 15 years.
This strategy is used by Google Calendar and seems acceptable in most cases.
A cron job could eventually be introduced to generated more events as the end comes.
This allows to introduce an new rrule end type: 'Forever'. This is actually a shortcut to create a recurrence running for 720 events.
Inspired by Google Calendar, new possibilities are introduced when modifying a recurring event (e.g. change the name, add an attendee):
- Modify only this particular event (the event is still part of the recurrence)
- Modify this and following events (events are still in the same recurrence)
- Modify all events
In a similar way, when updating the rrule of an event (e.g. from every Monday to every Tuesday), the user can choose to:
- Modify this and following events: the recurrence is split. The first part remains unchanged but now ends when the second recurrence begins. The second parts is the updated rrule.
- Modify only this particular event.
- Modify all events: Forbidden (same as Google Calendar)
Note: when events are "moved" because the rrule changed, the events are not actually moved. They are unlinked and new events are created (See "Some design choices explained" section).
Two options were considered.
-
Store the rrule on an event, each event of the recurrence having a Many2one to the parent_id, aka the Master Event of the recurrence.
-
Store the rrule on another model:
calendar.recurrence.rule. Each event in the recurrence having a Many2one to the recurrence record.
Both options have pros & cons. But there is no clear winner. However the actual business logic of handling the recurrence creation/update would be the same. Where the rrule configuration is stored is the only main difference between both options. And this is probably the easiest part of implementing recurring events.
With that in mind, option 2) is chosen. It allows to clearly separate recurrence logic from the events themselves. It is also the "correct" way of modeling data to avoid many empty columns for most records.
When an rrule is modified, events should also be updated. In most cases, current events are unlinked and new events are created from scratch. Only events exactly at the same time before and after the rrule update are kept. Trying to reuse other events would require an obscure and arbitrary heuristic. (Imagine an rrule every Monday that is changed to every Tuesday and every Friday. What would you do?). This implies that any change to a specific event (name change, attendee added, chatter messages) is lost. This tradeoff seems acceptable as updating an rrule should not be that frequent. Moreover, Google Calendar also works that way so why not Odoo?
On the calendar view, drag and drop an event to shift the entire recurrence.
One way to handle the recurrence shift is to apply the same timedelta to all events. Now events are correctly positioned... except for events that were specifically moved. Those outliers needs special handling. This also introduces some behavior inconsistencies: when an rrule is directly modified, events are not reused, but when the rrule is modified by drag & dropping an event, events are reused. This option needs more code to handle the shift and the behaviors are not consistent.
The chosen option is to find the rrule configuration from the dragged event (this is easy) and update the recurrence with those new rrule values. This brings us back to an rrule update (see above): code reusability yeah; one behavior to rule them all yeah. One downside is that outliers are lost (but Google Calendar also works that way).
This commit refactors calendar synchronization between Odoo and Google after the main calendar application refactoring.
This refactoring takes advantage of two new features from the Google API:
-
New way of synchronizing resources efficiently[1] Incremental sync is performed repeatedly and updates Odoo with all the changes that happened ever since the previous sync. Each time, Odoo provides the previous sync token it obtained from Google and stores the new sync token from the response.
-
Event metadata[2] Ability to set hidden key-value pairs with an event, called extended properties. These extended properties are used to store the related odoo event id and the Odoo owner id (see known limitations)
-
Let A and B be two new users (no tokens available). A creates an event in Odoo and invites B. A is the owner of the event (user_id). Now B authenticates to his Google Calendar account and synchronizes his calendar. We cannot send the event to A's calendar since we don't have any access to his Google Calendar. Hence the event his sent to B's calendar. This leads to data de-synchronisation: The owner is A in Odoo but B in Google. The "real" owner (user A) is stored in the Google event's metadata to be able to reconcile the owner for following synchronizations.
-
Let A and B be two users of Odoo and Google Calendar. And let the Google Calendar of B be private (e.g. if A creates an event in Google Calendar and invites B, B won't see the event in his calendar). If A creates an event in Odoo and invites B. The event is synced to Google Calendar of A. Now B can see the event in Odoo but he can't see it in his Google Calendar.
Task 2126717 PR #42031 PR Enterprise https://github.com/odoo/enterprise/pull/8006
[1] https://developers.google.com/calendar/v3/sync [2] https://developers.google.com/calendar/extended-properties
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Signed-off-by: Yannick Tivisse (yti) [email protected]
Plug and Play work (#6357)
-
start cleaning up banking for some of the SunPlus games (helps when you remember that the port wrirtes supply a mem_mask)
-
banking improvements (nw)
-
further improvements (nw)
-
(nw)
-
make more DRC friendly (nw)
-
cleaner banking for some in here, although mysprtcp doesn't want to behave, the port dirtection bits we need to output to aren't set to output?!
-
new NOT WORKING software list entries
mobigo_cart.xml [TeamEurope] Tinkerbell - Tal der Feen (Germany) (80-250904) Dino-Zug - Erforsche die Welt (Germany) (80-252304) Planes (Germany) (80-253004) Sofia die Erste (Germany) (80-253204) Doc McStuffins - Spielzeugarztin (Germany) (80-253304) Ultimate Spider-Man (Germany) (80-253604)
Created Text For URL [newsverge.com/2020/04/09/i-anchored-my-faith-in-god-says-uch-md-as-he-relives-covid-19-experience/]
Created Text For URL [sundiatapost.com/i-anchored-my-faith-in-god-says-uch-md-as-he-relives-covid-19-experience/]
fix Type::Tiny inflation on old threaded perl
%TYPE_MAP defines how to inflate types from Moo types (code refs) to Moose types. The keys are the code refs, which means they get stringified.
When using threads, the refaddr of refs will change. This means the stringification will change. Because of this, we tie %TYPE_MAP so we can keep real references to the types and fix their stringification when cloning into a new thread. However, %TYPE_MAP is a global that can be added to without loading Moo. If Moo is loaded later, it needs to do something with the existing stringified refs in the mapping. It handles this by using an ugly B hack to turn the refaddr into the real reference.
perl versions before 5.10 attach overloading magic to the reference rather than the referent. When restoring the reference using B, it doesn't re-attach the overloading magic.
Type::Tiny defines a custom stringification which mimics a standard perl ref stringification, but it uses slightly different formatting. The refaddr will represent the same integer, but won't always have the same length. Because it looks like a normal ref, Moo performs its string to ref inflation using B. But because B doesn't add the overloading magic to the ref used in inflation, some references to the type will use Type::Tiny's custom stringification, and some will use perl's standard stringification. This will prevent some operations from matching the strings, and the custom inflation won't trigger.
Reblessing the reference after retrieving it from B will properly apply the overloading magic, fixing the issue.
Lich King Vision Public changelog:
- Added an event chain (no localization yet) where you travel to the heart of Northrend at the call of the mystical Lich King, embracing Death God as your religion.
- Non-evil stubborn people are likely not to do evil doubtful actions like drinking demon blood, summoning demons etc.
Developer changelog:
- Purged unused
fel_presenceinWCFEL.9900.
HOLY SHIT ACTUALLY GOT THE FUCKING THING TO DO A TSP
normal map compression
fuck you overkill this is your fault
some more gutting, reduce warnings
whoever thought it was fine to write nearly 200 NullPointerExceptions needs to be taken to an insane asylum. I'm not fixing all that shit. goddamn 2k+ warnings brought down to just under 600.
Treat LedgerInvariant::Salary as forborne
LedgerInvariant::Salary might alternatively be treated as a BOY vector. The real motivation for treating it as forborne is to exercise the logic for compositing forborne vectors (adding them together without weighting by LedgerInvariant::InforceLives), which is otherwise used only by LedgerVariant::ExperienceReserve (which latter may soon be removed, as experience rating has fallen into disuse).
Here, of course, "forborne" is actuarial argot--see, e.g., Greville, UNITED STATES LIFE TABLES and ACTUARIAL TABLES 1939-1941, p. 85:
| A concrete illustration of the forborne annuity is provided by the | tontine fund, to which a group of individuals contribute regularly | until the end of a specified period of years (or until prior death), | the accumulated fund being then divided equally among the survivors | on a designated date.
which more obviously describes an experience reserve than salary, though the numerical treatment here is the same.
Discord has their stupid fucking updates so i have to update this shit too. Fuck Discord. Fucking furfag pieces of shit.
Merge #18295: scripts: add MACHO lazy bindings check to security-check.py
5ca90f8b598978437340bb8467f527b9edfb2bbf scripts: add MACHO lazy bindings check to security-check.py (fanquake)
Pull request description:
This is a slightly belated follow up to #17686 and some discussion with Cory. It's not entirely clear if we should make this change due to the way the macOS dynamic loader appears to work. However I'm opening this for some discussion. Also related to #17768.
LD64 doesn't set the MH_BINDATLOAD bit in the header of MACHO executables, when building with -bind_at_load. This is in contradiction to the documentation:
-bind_at_load
Sets a bit in the mach header of the resulting binary which tells dyld to
bind all symbols when the binary is loaded, rather than lazily.The ld in Apples cctools does set the bit, however the cctools-port that we use for release builds, bundles LD64.
However; even if the linker hasn't set that bit, the dynamic loader (dyld) doesn't seem to ever check for it, and from what I understand, it looks at a different part of the header when determining whether to lazily load symbols.
Note that our release binaries are currently working as expected, and no lazy loading occurs.
Using a small program, we can observe the behaviour of the dynamic loader.
Conducted using:
clang++ --version
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
ld -v
@(#)PROGRAM:ld PROJECT:ld64-530
BUILD 18:57:17 Dec 13 2019
LTO support using: LLVM version 11.0.0, (clang-1100.0.33.17) (static support for 23, runtime is 23)
TAPI support using: Apple TAPI version 11.0.0 (tapi-1100.0.11)#include <iostream>
int main() {
std::cout << "Hello World!\n";
return 0;
}Compile and check the MACHO header:
clang++ test.cpp -o test
otool -vh test
...
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 16 1424 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE
# Run and dump dynamic loader bindings:
DYLD_PRINT_BINDINGS=1 DYLD_PRINT_TO_FILE=no_bind.txt ./test
Hello World!Recompile with -bind_at_load. Note still no BINDATLOAD flag:
clang++ test.cpp -o test -Wl,-bind_at_load
otool -vh test
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 16 1424 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE
...
DYLD_PRINT_BINDINGS=1 DYLD_PRINT_TO_FILE=bind.txt ./test
Hello World!If we diff the outputs, you can see that dyld doesn't perform any lazy bindings when the binary is compiled with -bind_at_load, even if the BINDATLOAD flag is not set:
@@ -1,11 +1,27 @@
+dyld: bind: test:0x103EDF030 = libc++.1.dylib:__ZNKSt3__16locale9use_facetERNS0_2idE, *0x103EDF030 = 0x7FFF70C9FA58
+dyld: bind: test:0x103EDF038 = libc++.1.dylib:__ZNKSt3__18ios_base6getlocEv, *0x103EDF038 = 0x7FFF70CA12C2
+dyld: bind: test:0x103EDF068 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryC1ERS3_, *0x103EDF068 = 0x7FFF70CA12B6
+dyld: bind: test:0x103EDF070 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryD1Ev, *0x103EDF070 = 0x7FFF70CA1528
+dyld: bind: test:0x103EDF080 = libc++.1.dylib:__ZNSt3__16localeD1Ev, *0x103EDF080 = 0x7FFF70C9FAE6
<trim>
-dyld: lazy bind: test:0x10D4AC0C8 = libsystem_platform.dylib:_strlen, *0x10D4AC0C8 = 0x7FFF73C5C6E0
-dyld: lazy bind: test:0x10D4AC068 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryC1ERS3_, *0x10D4AC068 = 0x7FFF70CA12B6
-dyld: lazy bind: test:0x10D4AC038 = libc++.1.dylib:__ZNKSt3__18ios_base6getlocEv, *0x10D4AC038 = 0x7FFF70CA12C2
-dyld: lazy bind: test:0x10D4AC030 = libc++.1.dylib:__ZNKSt3__16locale9use_facetERNS0_2idE, *0x10D4AC030 = 0x7FFF70C9FA58
-dyld: lazy bind: test:0x10D4AC080 = libc++.1.dylib:__ZNSt3__16localeD1Ev, *0x10D4AC080 = 0x7FFF70C9FAE6
-dyld: lazy bind: test:0x10D4AC070 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryD1Ev, *0x10D4AC070 = 0x7FFF70CA1528Note: dyld also has a DYLD_BIND_AT_LAUNCH=1 environment variable, that when set, will force any lazy bindings to be non-lazy:
dyld: forced lazy bind: test:0x10BEC8068 = libc++.1.dylib:__ZNSt3__113basic_ostreamAfter looking at the dyld source, I can't find any checks for MH_BINDATLOAD. You can see the flags it does check for, such as MH_PIE or MH_BIND_TO_WEAK here.
It seems that the lazy binding of any symbols depends on whether or not lazy_bind_size from the LC_DYLD_INFO_ONLY load command is > 0. Which was mentioned in #17686.
This PR is one of Corys commits, that I've rebased and modified to make build. I've also included an addition to the security-check.py script to check for the flag.
However, given the above, I'm not entirely sure this patch is the correct approach. If the linker no-longer inserts it, and the dynamic loader doesn't look for it, there might be little benefit to setting it. Or, maybe this is an oversight from Apple and needs some upstream discussion. Looking for some thoughts / Concept ACK/NACK.
One alternate approach we could take is to drop the patch and modify security-check.py to look for lazy_bind_size == 0 in the LC_DYLD_INFO_ONLY load command, using otool -l.
ACKs for top commit: theuni: ACK 5ca90f8b598978437340bb8467f527b9edfb2bbf
Tree-SHA512: 444022ea9d19ed74dd06dc2ab3857a9c23fbc2f6475364e8552d761b712d684b3a7114d144f20de42328d1a99403b48667ba96885121392affb2e05b834b6e1c