1,949,074 events, 1,165,643 push events, 1,664,496 commit messages, 91,636,223 characters
gdb: make string-like set show commands use std::string variable
String-like settings (var_string, var_filename, var_optional_filename,
var_string_noescape) currently take a pointer to a char * storage
variable (typically global) that holds the setting's value. I'd like to
"mordernize" this by changing them to use an std::string for storage.
An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management.
Another interesting reason is that, with char *, nullptr and an empty
string often both have the same meaning of "no value". String settings
are initially nullptr (unless initialized otherwise). But when setting
them to nothing, they point to an empty string. For example,
solib_search_path is nullptr at startup, but points to an empty string
after doing "set solib-search-path". This leads to some code that needs
to check for both to check for "no value". Or some code that converts
back and forth between NULL and "" when getting or setting the value. I
find this very error-prone, because it is very easy to forget one or the
other. With std::string, we at least know that the variable is not
"NULL". There is only one way of representing an empty string setting,
that is with an empty string.
I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional anyway.
Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests).
Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function.
In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects.
This patch started by changing all relevant add_setshow_* commands to
take an std::string * instead of a char ** and fixing everything
that failed to build. That includes of course all string setting
variable and their uses.
string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options).
The add_path function in source.c is really complex and twisted, I'd
rather not try to change it to work on an std::string right now.
Instead, I added an overload that copies the std:string to a char *
and back. This means more copying, but this is not used in a hot path
at all, so I think it is acceptable.
Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX lsix@lancelotsix.com
lightning defaults 9 pierce, rain ench non-pierce projs make 3-pierce lightning eri nebula reticle spins down a bit eri meteors ignore tiles abom flaming scythes has more delay between them, max 8 (was 9) restored abom life to 1.3M devi telegraph for shadowbeams is purple line plus ring adjusted visuals for eri/ml chain explosions eri, life, earth, spirit have cool spawn anims (see spirit anim in a world without spirit defeated first btw, its more comedic) fixed(?) eow never doing sync u-turn if only 1 head and you keep killing head reduced nerf for proj cooldown (crystal bullet, holy stars, etc), can now spawn up to 5 times per sec (was 4) earth fireball attack is now anti-run by hands raining explosions on either side wof mouth defense buff removed but it has 66% DR life champ contact damage disabled while its dropping down for a rising dash life champ has a timing telegraph on rising dash spirit causes a mash indicator to appear when you're grabbed
PsychOpenHMDVR: Fixup for recent Linux kernels and distros.
Turns out that at least on Ubuntu 20.04-LTS with modern Linux kernels, which are HMD aware, for at least the Oculus Rift CV1, our old approach with PsychOpenHMDVR() does not work well anymore. The Oculus Rift CV1 and later Oculus models go into a power-saving mode at the end of a session when our driver closes the USB connection to the HMD device and no more USB keep-alive packets are sent anymore.
When entering power-save, the HMD's video output, e.g., HDMI, is hot-unplugged from the system. On hot-replug (ie. when a new session is started, our driver connects vie USB, and the Rift fully powers up), the Rift video display does not fully turn on anymore. It seems that the panel stays powered down due to some "stuck" DPMS power setting. This may be a quirk of the specific Rift CV1 HMD, or it may be because the HMD is marked as non-desktop display by Linux 4.16+, and either the kms driver or the X-Server somehow gets confused by the hot-unplug without proper DPMS handshaking, or some other problem of some other component. In any case, this problem was observed on the Rift CV1 with Ubuntu 20.04-LTS, standard distro kernel 5.8, X-Server 20.0.9. The problem does not happen as often and reproducible on a Linux 5.13 kernel, but sometimes it still happens.
Typically the Rift works for exactly one session after reboot, then not anymore.
I found the following workaround implemented in this commit:
During the device open sequence / driver session startup:
- Explicitely turn off the RandR video output assigned to the HMD.
- Wait a second.
- Turn on the HMD RandR output again, at the correct native HMD panel mode and refresh rate. Also label the output as standard desktop display, overriding the Linux kernels classification/labelling as non-desktop special purpose display, which is applied to known HMD's since Linux 4.16.
- Wait another second or two.
What this output-off --> output-on sequence implicitely does is, that it first sends a DPMS standby signal to the HMD, then a DPMS on signal, enforcing a toggle of the panels DPMS state. This gets the display unstuck. We could also just use calls to force DPMS standby -> DPMS on, without the need for a full modeset, but as DPMS acts globally on all X-Screens and outputs, this causes flicker and short display blanking on all active displays, not just the HMD, so it is more intrusive / annoying.
Note we use xrandr system() callouts for this, as our own builtin Screen() modesetting code doesn't deal with turned off outputs yet, and just updating Screen() for this seems a bit too much overkill at the moment.
Another note: In order to make multi-X-Screen configurations work at all, which is needed with our current Linux VR drivers for good timing and performance, the xorg.conf Monitor section for the HMD's ZaphodHeads HMD output needs an explicit...
Option "Enable" "on"
...to force the X-Server to enable the output despite it being marked as non-desktop by the Linux kernel. Otherwise the server will not find any connected outputs, is left with an X-Screen without outputs and then deletes that X-Screen, and we are left with a single-X-Screen setup that is unusable for VR HMD's.
XOrgConfCreator will need an update to deal with this.
Another note: If one wants to use the monado-service VR compositor for OpenXR on Linux, one needs a bug-fixed monado implementation and Linux kernel 5.13 or later - or at least it is verifed to work with 5.13 and to not work with 5.8. Current monado master will only work on single-X-Screen setups which are unsuitable for parallel use with our old VR drivers.
Another note: Getting at least the Rift working under these circumstances on a single X-Screen setup proved to be painful to the point of being unworkable. The Rift's power-saving collaborates with the Linux 4.16 non-desktop display labelling to create a perfect shit-show of pain. Not impossible to get working, but painful enough that i won't bother, so i doubt any normal users will. Of course this doesn't matter much, as the single-X-Screen config is only useful for the most basic testing, if one is to lazy to do a logout -> Switch to dual-x-screen -> login transition. Performance is by design so bad, it is not useful for actual VR experiments, and setting up a dual-X-Screen setup only takes a minute, so there...
-> This is all quite a bit of a hack, but given that i am working on a new VR driver anyway, which intends to supersede all our existing drivers, and does not suffer any of these problems, i guess patching this up a tiny bit more should do for the time being to bridge the time-gap between now and the completion of the new driver in a few months.
PsychOpenHMDVR: Fixup for recent Linux kernels and distros.
Turns out that at least on Ubuntu 20.04-LTS with modern Linux kernels, which are HMD aware, for at least the Oculus Rift CV1, our old approach with PsychOpenHMDVR() does not work well anymore. The Oculus Rift CV1 and later Oculus models go into a power-saving mode at the end of a session when our driver closes the USB connection to the HMD device and no more USB keep-alive packets are sent anymore.
When entering power-save, the HMD's video output, e.g., HDMI, is hot-unplugged from the system. On hot-replug (ie. when a new session is started, our driver connects vie USB, and the Rift fully powers up), the Rift video display does not fully turn on anymore. It seems that the panel stays powered down due to some "stuck" DPMS power setting. This may be a quirk of the specific Rift CV1 HMD, or it may be because the HMD is marked as non-desktop display by Linux 4.16+, and either the kms driver or the X-Server somehow gets confused by the hot-unplug without proper DPMS handshaking, or some other problem of some other component. In any case, this problem was observed on the Rift CV1 with Ubuntu 20.04-LTS, standard distro kernel 5.8, X-Server 20.0.9. The problem does not happen as often and reproducible on a Linux 5.13 kernel, but sometimes it still happens.
Typically the Rift works for exactly one session after reboot, then not anymore.
I found the following workaround implemented in this commit:
During the device open sequence / driver session startup:
- Explicitely turn off the RandR video output assigned to the HMD.
- Wait a second.
- Turn on the HMD RandR output again, at the correct native HMD panel mode and refresh rate. Also label the output as standard desktop display, overriding the Linux kernels classification/labelling as non-desktop special purpose display, which is applied to known HMD's since Linux 4.16.
- Wait another second or two.
What this output-off --> output-on sequence implicitely does is, that it first sends a DPMS standby signal to the HMD, then a DPMS on signal, enforcing a toggle of the panels DPMS state. This gets the display unstuck. We could also just use calls to force DPMS standby -> DPMS on, without the need for a full modeset, but as DPMS acts globally on all X-Screens and outputs, this causes flicker and short display blanking on all active displays, not just the HMD, so it is more intrusive / annoying.
Note we use xrandr system() callouts for this, as our own builtin Screen() modesetting code doesn't deal with turned off outputs yet, and just updating Screen() for this seems a bit too much overkill at the moment.
Another note: In order to make multi-X-Screen configurations work at all, which is needed with our current Linux VR drivers for good timing and performance, the xorg.conf Monitor section for the HMD's ZaphodHeads HMD output needs an explicit...
Option "Enable" "on"
...to force the X-Server to enable the output despite it being marked as non-desktop by the Linux kernel. Otherwise the server will not find any connected outputs, is left with an X-Screen without outputs and then deletes that X-Screen, and we are left with a single-X-Screen setup that is unusable for VR HMD's.
XOrgConfCreator can not auto-generate such files, so i updated the "help PsychOpenHMDVR" text with setup instructions. We also ship a new sample xorg.conf file demonstrating this under:
Psychtoolbox/PsychHardware/LinuxX11ExampleXorgConfs/xorg.conf_DualXScreen_OculusRift_amdgpu.conf
Another note: If one wants to use the monado-service VR compositor for OpenXR on Linux, one needs a bug-fixed monado implementation and Linux kernel 5.13 or later - or at least it is verifed to work with 5.13 and to not work with 5.8. Current monado master will only work on single-X-Screen setups which are unsuitable for parallel use with our old VR drivers.
Another note: Getting at least the Rift working under these circumstances on a single X-Screen setup proved to be painful to the point of being unworkable. The Rift's power-saving collaborates with the Linux 4.16 non-desktop display labelling to create a perfect shit-show of pain. Not impossible to get working, but painful enough that i won't bother, so i doubt any normal users will. Of course this doesn't matter much, as the single-X-Screen config is only useful for the most basic testing, if one is to lazy to do a logout -> Switch to dual-x-screen -> login transition. Performance is by design so bad, it is not useful for actual VR experiments, and setting up a dual-X-Screen setup only takes a minute, so there...
-> This is all quite a bit of a hack, but given that i am working on a new VR driver anyway, which intends to supersede all our existing drivers, and does not suffer any of these problems, i guess patching this up a tiny bit more should do for the time being to bridge the time-gap between now and the completion of the new driver in a few months.
Create Ishaan Loves Chocolates.c++
As we know, Ishaan has a love for chocolates. He has bought a huge chocolate bar that contains N chocolate squares. Each of the squares has a tastiness level which is denoted by an array A[]. Ishaan can eat the first or the last square of the chocolate at once. Ishaan has a sister who loves chocolates too and she demands the last chocolate square. Now, Ishaan being greedy eats the more tasty square first. Determine the tastiness level of the square which his sister gets.
rs,html
Mt krna baat abse.. pr nafrat bhi nhi krna Me last msg kr rha me apni sari galtiya maan rha hu haa bhut jada gussa h hurt bhi aur mt krna baat abse qki hadd ki bhi hadd kr di mene mene bs sorry bolne ko msg kiya hai kyoki meri hi mistakes h aur mene agress kr liya ki mene tujhe kafi hurt kiya, mere se handle nhi ho pa rha pr yr dhukh mujhe milna chiye aur tu ek loyal friend h mene koi aim se defame krne ka try nhi kiya h kabhi bhi gussa tha bs me hamesha kisi se teri burai kruga na sunuga qki tune mere liye itna sb kiya h jb me bimar tha h utna pyar mummy ke bad tu hi kr sakti h mujhese tune jo kuch bhi kiya mere liye me us baat ko yad rakh kr tujhe hamesha protect kruga abhi se hi aur mujhe yad h tu sil ki saaf h qki gussa whi krta h jo dil ka saaf hota h jutha pyar ya mzak nhi kiya tune mere se hamesha mujhe family jesa pyar diya is baat ko me kabhi nhi bhuluga is baat ko yad krke hi tujhe protect kruga tujhe jo krna ho kr ab me khi bhi msg nhi kruga free mind set se rehna ab se acha kiya tune spam msg mail se block kra diye dimag me hate a jaye ek dusre ke liye pr dil me nhi a sakti kabhi qki mene bhi pda h phela pyar bhulne se bhi nhi bhulaya ja sakta... realtion me reh kr tune ek bf se bhi jada pyar diya h mujhe har ek baat yad h to ab dur ho kr bhi me tujhe protect kruga na shak kruga na kuch bhi msgs, na defame etc... jo bhi hua sorry maybe family issues h dono ke isliye hum proper time nhi de paye ek dusre ko aur fir mene bhi bemani ki tere sath bhut jada tu mujhe kabhi maaf nhi krna future me blog etc likhte rehna.. mera dimag hate kr le tujhse pr dil nhi kr sakta tu mera first and last love h to ab mujhe value h teri tujhe jo krna ho kr enjoy kr song sun aur padai kr bate kr dosto se i love you forever me hamesha tera wait krugaa bcoz ur my firstnd last love nd dont worry ab by miskate bhi msg krke problmes jo h aur nhi bdauga me bhut jada yad krta hu i love you forever dhyan rakhna apna meri aloo sad, dipress hu pr khush bhi hu ki tu khush rhaegi abse coco aur me tujhese bhut pyar krte h dhyan rakhan apna abse khi koi preshani nhi hogi tujhe i miss u and love u forever like kr dena msg pad le to taki dil ko shanti mil jaye..
NCR + Legion getting some attention (#429)
There is a need for more sex appeal for these two gangs. More text will come.
TL:dr 2 ranger slots down, 1 explorer slot down, Venator slot zero. Focus on making the regular stuff work, less special forces/solo stuff. Forget any illusion of perfect balance, good enough is key, and keeping nice themes.
Split Forgemaster and Slavemaster again since their intended function are so incompatible Forgemaster gets less advanced toolbelt (was an oversight) and a chainsaw, he is getting armor too when done spriting but it can wait.
Style: NCR gets bayonet knives and leg holsters as standard, not hunting knives and shoulder holsters.
NCR Gets service rifles, better rifles for LT, Medic. MP on steroids. Lose Trekking (rangers keep it of course). Captain made more interesting with smoke grenades and a frag, not just LT +. Legion gets trekking for primes, one recruit, lifegiver for senior roles, explorers lose armor rating. Loadouts given a work over, theme simple guns except Frontline Cent who gets a M1919 Mg, some firebombs/molotovs/smoke grenades and melee stuff added to give more possible tactics. Bunch of various adjustments in loadouts, police shotguns gone from NCR, tribal Legion recruit gets his spear and nothing else, put together it will provide more meaningful choices and more viable loadouts while improving their style points.
Less Rangers/Explorer because too many special scout troops encourage solo running off and playing like a waster + and not interacting with your faction uncool. Venator goes to fix the very dumb command flow for Legion where Venator is shoehorned in making even more of a command mess, and the night vision + super heavy armor/vet ranger mirror concept is just no good.
New toolbelts for Forgemaster/Medicus, Chainsaw can be used for sawing off shotguns, cleans the 2h file from some obsolete stuff and updates a bunch of 2h onmob sprites for shading etc. Parts of the melee tweaks got sucked into this, so some minor value tweaks to swords/knives and scrap sabre added. New tool : hand saw. Circular saw slightly faster now. New Event role, personal aide, NCR role to support the Colonel and carry the banner of the Republic. NCR banner sprites made by Dioclex.
audio: merge pull/push ring buffer glue code
This is preparation to further cleanups (and eventually actual improvements) of the audio output code.
AOs are split into two classes: pull and push. Pull AOs let an audio callback of the native audio API read from a ring buffer. Push AOs expose a function that works similar to write(), and for which we start a "feeder" thread. It seems making this split was beneficial, because of the different data flow, and emulating the one or other in the AOs directly would have created code duplication (all the "pull" AOs had their own ring buffer implementation before it was cleaned up). Unfortunately, both types had completely separate implementations (in pull.c and push.c). The idea was that little can be shared anyway. But that's very annoying now, because I want to change the API between AO and player.
This commit attempts to merge them. I've moved everything from push.c to pull.c, the trivial entrypoints from ao.c to pull.c, and attempted to reconcile the differences. It's a mess, but at least there's only one ring buffer within the AO code now. Everything should work mostly the same. Pull AOs now always copy the audio data under a lock; before this commit, all ring buffer access was lock-free (except for the decoder wakeup callback, which acquired a mutex). In theory, this is "bad", and people obsessed with lock-free stuff will hate me, but in practice probably won't matter. The planned change will probably remove this copying-under-lock again, but who knows when this will happen.
One change for the push AOs now makes it drop audio, where before only a warning was logged. This is only in case of AOs or drivers which exhibit unexpected (and now unsupported) behavior.
This is a risky change. Although it's completely trivial conceptually, there are too many special cases. In addition, I barely tested it, and I've messed with it in a half-motivated state over a longer time, barely making any progress, and finishing it under a rush when I already should have been asleep. Most things seem to work, and I made superficial tests with alsa, sdl, and encode mode. This should cover most things, but there are a lot of tricky things that received no coverage. All this text means you should be prepared to roll back to an older commit and report your problem.