WIP: Redesign Create a game window. Offline mode. Scenarios with ordered missions

Closes #2372
Closes #2870
Closes #2877
The https://github.com/FAForever/fa/pull/4516 PR is required

Why is the skirmish pr required for this? For offline couldn't you just start the game as we do now and just not send the server messages?

https://github.com/FAForever/fa/issues/4514
From part of message from the issue:
The /map argument is not suitable, as it run the match immediately. Some will need to configure the lobby (win conditions, mods, etc.)

For offline couldn't you just start the game as we do now and just not send the server messages?

Technically, this is no longer an offline game

Not sure what you mean? For the offline issue I had created all I really meant was that you could start a game that wouldn't be advertised to other players. Nothing about how we start the game now needs you to be online besides the server communication.

For the offline issue I had created all I really meant was that you could start a game that wouldn't be advertised to other players.

Where? Could you point out where it is possible to do this?

Yes you would just modify the hostGame and startGame functions to remove the calls to the lobby server and the replay server  here https://github.com/FAForever/downlords-faf-client/blob/31ba532b0871b0dc8056f8eb7a8adb2d8e85d199/src/main/java/com/faforever/client/game/GameService.java#L278-L299. So specifically the hostGame function and startGame function.
Start game just takes the game parameters so could be easy to build from a newgameinfo object.

Could probably take out the updateifnecessary calls as well to make it truly offline but that might be unnecessary since at this point people have to be logged in and if they are logged in they can update things

Eh... Okay. I'll take a look at it.
I just thought my solution was better. Launched and forgot. No need to change the code related to calls to the lobby server and the replay server. It is just my personal opinion 😃

Well you already have to create a separate start game offline method anyway. This method just wouldn't need to introduce something to the game code as well.

Since creating the offline calls is just removing stuff from the online methods and not modifying anything really

Yes you would just modify the hostGame and startGame functions to remove the calls to the lobby server and the replay server here

Unfortunately, there I'm doing something wrong (nothing does not work), or my skills are not enough to implement the offline feature.
Without offline mode, this PR does not make sense.


Improve blender stereo camera handling

Blender has naming conventions for right and left objects that is used for armatures. We already have support for the "name.left" and "name.right" formats by the looks of the code, but I would propose we take it a step further and implement the naming conventions linked above. This will help provide continuity with Blender and may be more familiar to Blender artists. It should be fairly straightforward to implement a regex script that matches these patterns.

Ah silly me, I totally forgot Blender added native support for stereo rendering a while back. I guess there isn't much of a point to this then. We can't just remove this feature if you want to maintain backwards compatibility, but there isn't much of a point doing any more work here. I'm closing the issue for now, it can be reopened if you still want this done.

I think we have to update our current support for stereo rendering to match the Blender's native features. The only change required is to change mechanism of the active camera selection. And yes, it would be nice to keep the old mechanism as well, to keep backward compatibility. Not sure how the choice between the old and new system will be done (probably, RenderChan will be able to guess the mode by inspecting the camera options). Thanks for bringing this up!

Merged.


migration: probe for existing LUKS devices, and ask the user to unlock them

Although Legacy Aeon didn't officially support LUKS encrypted installations, some users might have nevertheless enabled encryption anyway.
Search for existing crypto_LUKS partitions and, if found, prompt the user to unlock those so that the migration module can find existing data.

Yes, the user will be asked to enter the recovery key in that case. I think it's acceptable in a installation/recovery setting in my opinion, but I will give it a shot in supporting tokens as well, sounds like a cool thing to have

Yeah, note I didn't say "no" or require changes.. I think generally I like the PR..I'm just trying to be careful about encoraging something that ends up being a dead end when we move Aeon where we want it to be with FDE
Becuase this migration module is also used for reinstalls, not just old-Aeon to new-Aeon

I am wondering though - did you actually test this code at all?
Because our current code is only going to show devices in /dev/disk/by-id
And this is going to unlock devices in /dev/mapper which the user can never pick
So they could never probe..so it would never work..no?
Am I missing something?

Becuase this migration module is also used for reinstalls, not just old-Aeon to new-Aeon

Yes, indeed. I started writing this with the "migration from Legacy" mindset (just wanted to try out the new one, really). But it makes sense to add FIDO2 as well if that's going to be the preferred way (and doesn't look that hard to implement)

I am wondering though - did you actually test this code at all?
Because our current code is only going to show devices in /dev/disk/by-id
And this is going to unlock devices in /dev/mapper which the user can never pick

Yes, I migrated from Legacy successfully. The mapped device also shows up in /dev/disk/by-id, so it integrates nicely with the rest of the migration module.
As an example (another Legacy Aeon installation that I daily drive):
eugenio@suse:~> lsblk /dev/nvme0n1 -p -n -r -o ID-LINK,FSTYPE|tr -s ' ' ":"|grep ":crypto_LUKS"|cut -d: -f1
nvme-SAMSUNG_MZVL4512HBLU-00BL7_S67VNF0W385255-part2
eugenio@suse:~>
eugenio@suse:~> lsblk /dev/nvme0n1 -p -n -r -o ID-LINK,FSTYPE|tr -s ' ' ":"|grep ":btrfs"|cut -d: -f1
dm-name-cr_root
eugenio@suse:~> ls -ltha /dev/disk/by-id/dm-name-cr_root
lrwxrwxrwx. 1 root root 10 May 22 09:10 /dev/disk/by-id/dm-name-cr_root -> ../../dm-0
eugenio@suse:~>

Indeed, just deployed it to a test image I have here and it seems to work so far..I'm running out of excuses not to merge.. so will if this test run doesn't explode :)


Update README.md

Contributing guidelines
Please read our contribution workflow before submitting a pull request.

Hi @lihua8712051 test received, please open new PR with reasonable updates :)


Run parallel builds and integration tests on all supported platforms

Currently we build and test on Linux only, but release Linux, Windows and Mac versions of the tool.
To be more confident in those, we should run at least the integration tests on all platforms to continuously ensure that these releases function.
In trial we've already seen that there are the following issues with this:

linting check is using a shell script that is not compatible with windows (it does this to get around gofmt not returning error codes on unformated files)
integration tests running in parallel influence each other, resulting in some tests timing out or failing

Closing as OS differences were primarily due to file path/reference handling, which v2 abstracts away.
Running E2E tests that run as a Go test execution on cmd library level, not compiled CLI level, would currently not have a notable benefit.


Probably best to only allow one preference window and stack multiple gogi editor windows (see comments)

can't replicate -- just opened and closed a bunch..

I didn't realize multiple windows were being opened for prefs because they lay on top of each. The window menu was correct! Suggest that we limit to one pref window and bring to front if someone asks for prefs window. The gogi editor I can see having multiple for different objects but they should cascade or something so you can see that there is more than one.

good ideas -- done.


Allow null for knobs

It would be nice to enable adding a null for the knobs, especially for the dates.
for example, i have a calendar with a start date set to null or an actual date.
<MyCalendar
    startDate={date('startDate', null)}
/>

TypeError: Cannot read property 'getTime' of null

I think we support it. Simply don't use null.
use this: date('startDate')
If not, try the latest version or knobs.

I am using the latest version.
not passing any defaults for date results in the following: 01/01/1970 2:00 AM

probably a better approach is provide a "combination" knob, and add a "null" knob. then you can mid between different knob types, if this makes any sense?

@Bamieh That is the unix epoch, which imo the expected value for a date for input null. Sorry but I could not understand what you mean by a "combination" knob and a "null" knob. Could you explain how you expect passing null to a date knob should work?

@roonyh
Issue in hand
Sometimes react props are set to null by default for various reasons. However, there is no way to pass null as an option to the date knob, and possibly some other knobs.
Current result:
Passing null to date knob:

startDate={date('startDate', null)}
Result: TypeError: Cannot read property 'getTime' of null

Passing nothing/undefined to date Knob:

startDate={date('startDate')}
Result: 01/01/1970

Expected result:
Passing null to date knob:

startDate={date('startDate', null)}
Result: null

Passing nothing/undefined to date Knob:

startDate={date('startDate')}
Result: 01/01/1970

@Bamieh yep. You are right.
We should accept null values too for the date.
Here's the related code for this.
Send us a PR, if you can't wait until we fix this :)

@arunoda submitted


Exact reproducibility bug

Summary:
Exact reproducibility is not given when warmup is enabled.
Description:
Output from the sampler is not exactly the same when starting it on the same platform with the exact same seed. This happens whenever warmup is performed. When warmup=0 then the Stan program is again exactly reproducible.
Reproducible Steps:
Attached is a zip file containing an example which used clang on Mac. The problem also happens when using gcc 6 with cmdstan.
normal_exact_repo_bug.zip
Current Output:
The current output. Knowing what is the current behavior is useful.
Expected Output:
It must be exactly reproducible regardless if warmup was performed or not.
Additional Information:
Provide any additional information here.
clang version:
Apple LLVM version 8.0.0 (clang-8<IP_ADDRESS>)
Target: x86_64-apple-darwin16.4.0
Thread model: posix

g++ version:
g++-mp-6 (MacPorts gcc6 6.3.0_0) 6.3.0

Current Version:
v2.14.0

I cannot recover this behavior on the dev branch CmdStan
with clang.  When the same seed is used multiple times
each execution recovers exactly the same output save for
the timing.
> ./normal sample random seed=488338392
> mv output.csv output.1.csv

> ./normal sample random seed=488338392
> mv output.csv output.2.csv

> diff output.1.csv output.2.csv
1044,1046c1044,1046
< #  Elapsed Time: 0.006719 seconds (Warm-up)
< #                0.01308 seconds (Sampling)
< #                0.019799 seconds (Total)
---
> #  Elapsed Time: 0.006626 seconds (Warm-up)
> #                0.013641 seconds (Sampling)
> #                0.020267 seconds (Total)

On Feb 15, 2017, at 6:40 AM, wds15<EMAIL_ADDRESS>wrote:
Summary:
Exact reproducibility is not given when warmup is enabled.
Description:
Output from the sampler is not exactly the same when starting it on the same platform with the exact same seed. This happens whenever warmup is performed. When warmup=0 then the Stan program is again exactly reproducible.
Reproducible Steps:
Attached is a zip file containing an example which used clang on Mac. The problem also happens when using gcc 6 with cmdstan.
normal_exact_repo_bug.zip
Current Output:
The current output. Knowing what is the current behavior is useful.
Expected Output:
It must be exactly reproducible regardless if warmup was performed or not.
Additional Information:
Provide any additional information here.
clang version:
Apple LLVM version 8.0.0 (clang-8<IP_ADDRESS>)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
g++ version:
g++-mp-6 (MacPorts gcc6 6.3.0_0) 6.3.0
Current Version:
v2.14.0
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Thanks much Michael! I was really hoping to be wrong. I checked with the cmdstan 2.14.0 and the dev version using clang. Both versions of cmdstan are exactly reproducible.
However, when reading in the cmdstan csv files using read_stan_csv the output is not exactly the same when warmup is enabled. That is, when I read the csv files with basic R facilities, then I also get an exact match between respective files. If you agree, then we can close this issue fortunately. I will verify the issue in rstan on another system and report the problem there. If gcc6 causes any problem remains to be tested, but my working assumption is that this is not the case, but rather the read_stan_csv command is the source of all trouble here.
Sorry for the noise, but these things make me really nervous.
exact_repo_bug.zip

Should anyone want to follow this up what happened:
https://github.com/stan-dev/rstan/issues/393

Thanks for following up on this, @betanalpha.


Upgrade Jupyter Notebook files to use 4.5 format

In testing some reported issues in papermill, I noticed that the VS Code python extension was still outputting version 4.2 notebooks. The current spec is at 4.5 and given the popularity of VSCode for notebook development I think it'd help with tooling and maintenance if specs were caught up to current versions. The spec for older 4.x formats was back-ported to account for some 4.4 features being saved in older versions, but I'd still recommend at a minimum moving to 4.4 and plan / update to 4.5's addition of cell_id.
Happy to help discuss any concerns or details around the spec / upgrade.

Ahh I realized this should be in https://github.com/microsoft/vscode-jupyter -- closing and reopening there


Updated documentation to reduce command duplication

Co-authored-by: Ernesto Garcia<EMAIL_ADDRESS>In our own project we use this method to avoid command duplication.
If the documentation switches to yarn we could write it even shorter, without run and --.

There's native Sass support in next so all this is going away soon. 😄
Thanks for the suggestion, though!


file-assertions: Implement missing tests and fix existing code smells

TODO

[ ] clean up code
[ ] implement missing tests
[ ] fix code smells

Will be dealt with in a general refactoring story.


SSR hydration mismatches

Describe the bug
I added all the playground components to nuxt to test SSR, and noticed 53 warning, most of which were about hydration missmatches.
The reproduction on stackblitz doesn't generate that many warnings.
We should figure out a better way to test ssr.
Reproduction
https://stackblitz.com/edit/nuxt-starter-lqee3m?file=layouts%2Fdefault.vue
Used Package Manager
pnpm
Validations

[X] Have tested with the latest version. This is still alpha version and sometime things change rapidly.
[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

@ptdev could you create a little example on stackblitz? just fork the one linked in this and make it fail like you have? That would help me to focus on your problem and maybe find it faster.

Hey,
Sure, here is a simplified sample of what i'm using.
But note that even without modification, your stackblitz link already shows an hydration error (at least on my end :) )
Thanks, cheers! 👍

@ptdev this will be fixed in 0.16, we hope to get that out soon.

nuxt render teleport elements in the beginning of body, not the end like vue. We'll have to wait for this to be fixed for some of the hydration missmatches: https://github.com/nuxt/nuxt/issues/24207

@xvaara since v3.11.0 nuxt now includes a teleports root element within the body tag.
https://github.com/nuxt/nuxt/releases/tag/v3.11.0
I think the #teleports target ID has to be set by boostrap-vue-next to fix the hydration warnings.

@VividLemon should we default all the teleports to #teleports and maybe add a check to see that it exists and warn about that in dev mode? or could we just create it if missing?

Once global options is supported, the nuxt module could just globally set the teleportTo for nuxt specific envionments

more missmatch stuff from upstream:
nuxt: https://github.com/nuxt/nuxt/issues/27378
vue core: https://github.com/vuejs/core/issues/6638
so if using ssr, set your own id:s for the components

@VividLemon Also noticed that: [nuxt] useId might not work correctly with components that have inheritAttrs: false
so we maybe need to pick the https://github.com/nuxt/nuxt/blob/4d063f1f85cf53f4fa97978f3f8724aacb24174a/packages/nuxt/src/app/composables/id.ts#L5 nuxt attrs and put that to the wrapping element for ids to work. At the moment they aren't working in about half of the components.

I saw that useId doesn't work with inheritAttrs false, which is a problem considering we can't modify what is properly a fragment component.
So, if data-n-ids is the key to fixing this problem, then I'm all for it.
Technically we could pass through a variable from the nuxt module to check if we are in a nuxt environment and selectively add this attr. Or we could just add it regardless, doesn't really matter.

Then we have a problem with all the other ssr/ssg generator.

Other generators won't get first class support. Nuxt is the most popular by far. If an issue comes that is specific to one framework, those will be dealt on a case by case basis, like we shouldn't just ignore problems, but unless other frameworks have a modules system we can build for, its up to the dev in most cases to fix the issues. (They can implement their own useId function)

There seems to be a lot of fixes in vue 3.5 for ssr!
Let's see if it's new useId also fixes our problems. We should maybe use that directly instead of the nuxt one.
3.4.35 has fixes for teleport also.

This seems to have been fixed by Vue 3.5. I checked, not hydration mismatches


docs: Replace references to Large Text with Text View

Checklist

[ ] Used only camelCase variable names.
[ ] If functionality is added or modified, also made respective changes to the
README.md and the internal workflow documentation.

Ah, right. I should really get in the habit of writing less sourcing docs. If I had just written "display information" back then without specifying how that info is displayed, this change wouldn't have been necessary 😅


Install Bug in python3.8+cuda11.3+torch1.12.0

I run pip install git+https://github.com/ashawkey/cubvh to install cubvh.
I have updated eigen to 3.3.7 by running sudo apt install libeigen3-dev.
I successfully install cubvh in virtual environment (python3.8+cuda11.7+torch2.0.0).
However, I fail to install cubvh in virtual environment (python3.8+cuda11.3+torch1.12.0).
Error message:
pip install git+https://github.com/ashawkey/cubvh
Collecting git+https://github.com/ashawkey/cubvh
  Cloning https://github.com/ashawkey/cubvh to /tmp/pip-req-build-0bzjdsmk
  Running command git clone --filter=blob:none --quiet https://github.com/ashawkey/cubvh /tmp/pip-req-build-0bzjdsmk
  Resolved https://github.com/ashawkey/cubvh to commit 7f935a0fd3d8168c45b671f3e9cff9b206fdf32b
  Running command git submodule update --init --recursive -q
  Preparing metadata (setup.py) ... done
Requirement already satisfied: ninja in ./Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages (from cubvh==0.1.0) (<IP_ADDRESS>)
Requirement already satisfied: pybind11 in ./Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages (from cubvh==0.1.0) (2.13.5)
Requirement already satisfied: trimesh in ./Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages (from cubvh==0.1.0) (4.4.0)
Requirement already satisfied: torch in ./Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages (from cubvh==0.1.0) (1.12.0+cu113)
Requirement already satisfied: numpy in ./Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages (from cubvh==0.1.0) (1.24.4)
Requirement already satisfied: typing-extensions in ./Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages (from torch->cubvh==0.1.0) (4.11.0)
Building wheels for collected packages: cubvh
  Building wheel for cubvh (setup.py) ... error
  error: subprocess-exited-with-error

  × python setup.py bdist_wheel did not run successfully.
  │ exit code: 1
  ╰─> [117 lines of output]
      nvcc: NVIDIA (R) Cuda compiler driver
      Copyright (c) 2005-2021 NVIDIA Corporation
      Built on Sun_Mar_21_19:15:46_PDT_2021
      Cuda compilation tools, release 11.3, V11.3.58
      Build cuda_11.3.r11.3/compiler.29745058_0
      Detected CUDA version 11.3
      Targeting C++ standard 17
      running bdist_wheel
      running build
      running build_py
      creating build
      creating build/lib.linux-x86_64-3.8
      creating build/lib.linux-x86_64-3.8/cubvh
      copying cubvh/__init__.py -> build/lib.linux-x86_64-3.8/cubvh
      copying cubvh/api.py -> build/lib.linux-x86_64-3.8/cubvh
      running build_ext
      creating /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8
      creating /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8/tmp
      creating /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8/tmp/pip-req-build-0bzjdsmk
      creating /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8/tmp/pip-req-build-0bzjdsmk/src
      Emitting ninja build file /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8/build.ninja...
      Compiling objects...
      Allowing ninja to set a default number of workers... (overridable by setting the environment variable MAX_JOBS=N)
      [1/3] /usr/local/cuda-11.3/bin/nvcc  -I/tmp/pip-req-build-0bzjdsmk/include -I/tmp/pip-req-build-0bzjdsmk/third_party/eigen -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/torch/csrc/api/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/TH -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/THC -I/usr/local/cuda-11.3/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/include/python3.8 -c -c /tmp/pip-req-build-0bzjdsmk/src/bvh.cu -o /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8/tmp/pip-req-build-0bzjdsmk/src/bvh.o -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_BFLOAT16_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ --expt-relaxed-constexpr --compiler-options ''"'"'-fPIC'"'"'' -std=c++17 --extended-lambda --expt-relaxed-constexpr -U__CUDA_NO_HALF_OPERATORS__ -U__CUDA_NO_HALF_CONVERSIONS__ -U__CUDA_NO_HALF2_OPERATORS__ -Xcompiler=-Wno-float-conversion -Xcompiler=-fno-strict-aliasing -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1013"' -DTORCH_EXTENSION_NAME=_cubvh -D_GLIBCXX_USE_CXX11_ABI=0 -gencode=arch=compute_86,code=compute_86 -gencode=arch=compute_86,code=sm_86
      /tmp/pip-req-build-0bzjdsmk/third_party/eigen/Eigen/src/Core/RandomImpl.h(142): warning: 'long double' is treated as 'double' in device code

      /tmp/pip-req-build-0bzjdsmk/third_party/eigen/Eigen/src/Core/RandomImpl.h(144): warning: 'long double' is treated as 'double' in device code

      [2/3] c++ -MMD -MF /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8/tmp/pip-req-build-0bzjdsmk/src/bindings.o.d -pthread -B /data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/tmp/pip-req-build-0bzjdsmk/include -I/tmp/pip-req-build-0bzjdsmk/third_party/eigen -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/torch/csrc/api/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/TH -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/THC -I/usr/local/cuda-11.3/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/include/python3.8 -c -c /tmp/pip-req-build-0bzjdsmk/src/bindings.cpp -o /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8/tmp/pip-req-build-0bzjdsmk/src/bindings.o -std=c++17 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1013"' -DTORCH_EXTENSION_NAME=_cubvh -D_GLIBCXX_USE_CXX11_ABI=0
      FAILED: /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8/tmp/pip-req-build-0bzjdsmk/src/bindings.o
      c++ -MMD -MF /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8/tmp/pip-req-build-0bzjdsmk/src/bindings.o.d -pthread -B /data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/tmp/pip-req-build-0bzjdsmk/include -I/tmp/pip-req-build-0bzjdsmk/third_party/eigen -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/torch/csrc/api/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/TH -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/THC -I/usr/local/cuda-11.3/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/include/python3.8 -c -c /tmp/pip-req-build-0bzjdsmk/src/bindings.cpp -o /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8/tmp/pip-req-build-0bzjdsmk/src/bindings.o -std=c++17 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1013"' -DTORCH_EXTENSION_NAME=_cubvh -D_GLIBCXX_USE_CXX11_ABI=0
      cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
      In file included from /tmp/pip-req-build-0bzjdsmk/src/bindings.cpp:5:
      /data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/pybind11/eigen.h: In member function ‘bool pybind11::detail::type_caster<Type, typename std::enable_if<decltype (pybind11::detail::is_template_base_of_impl<Eigen::SparseMatrixBase>::check((typename pybind11::detail::intrinsic_type<T>::type*)(nullptr)))::value, void>::type>::load(pybind11::handle, bool)’:
      /data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/pybind11/eigen.h:573:24: error: ‘MappedSparseMatrix’ is not a member of ‘Eigen’; did you mean ‘SparseMatrix’?
        573 |         value = Eigen::MappedSparseMatrix<Scalar, Type::Flags, StorageIndex>(
            |                        ^~~~~~~~~~~~~~~~~~
            |                        SparseMatrix
      /data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/pybind11/eigen.h:573:49: error: expected primary-expression before ‘,’ token
        573 |         value = Eigen::MappedSparseMatrix<Scalar, Type::Flags, StorageIndex>(
            |                                                 ^
      /data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/pybind11/eigen.h:573:76: error: expected primary-expression before ‘>’ token
        573 |         value = Eigen::MappedSparseMatrix<Scalar, Type::Flags, StorageIndex>(
            |                                                                            ^
      [3/3] /usr/local/cuda-11.3/bin/nvcc  -I/tmp/pip-req-build-0bzjdsmk/include -I/tmp/pip-req-build-0bzjdsmk/third_party/eigen -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/torch/csrc/api/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/TH -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/THC -I/usr/local/cuda-11.3/include -I/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/include/python3.8 -c -c /tmp/pip-req-build-0bzjdsmk/src/api.cu -o /tmp/pip-req-build-0bzjdsmk/build/temp.linux-x86_64-3.8/tmp/pip-req-build-0bzjdsmk/src/api.o -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_BFLOAT16_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ --expt-relaxed-constexpr --compiler-options ''"'"'-fPIC'"'"'' -std=c++17 --extended-lambda --expt-relaxed-constexpr -U__CUDA_NO_HALF_OPERATORS__ -U__CUDA_NO_HALF_CONVERSIONS__ -U__CUDA_NO_HALF2_OPERATORS__ -Xcompiler=-Wno-float-conversion -Xcompiler=-fno-strict-aliasing -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1013"' -DTORCH_EXTENSION_NAME=_cubvh -D_GLIBCXX_USE_CXX11_ABI=0 -gencode=arch=compute_86,code=compute_86 -gencode=arch=compute_86,code=sm_86
      /tmp/pip-req-build-0bzjdsmk/src/api.cu:1:9: warning: #pragma once in main file
          1 | #pragma once
            |         ^~~~
      /tmp/pip-req-build-0bzjdsmk/third_party/eigen/Eigen/src/Core/RandomImpl.h(142): warning: 'long double' is treated as 'double' in device code

      /tmp/pip-req-build-0bzjdsmk/third_party/eigen/Eigen/src/Core/RandomImpl.h(144): warning: 'long double' is treated as 'double' in device code

      /data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/c10/core/SymInt.h(84): warning: integer conversion resulted in a change of sign

      /tmp/pip-req-build-0bzjdsmk/src/api.cu:1:9: warning: #pragma once in main file
          1 | #pragma once
            |         ^~~~
      /data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/include/c10/core/SymInt.h(84): warning: integer conversion resulted in a change of sign

      ninja: build stopped: subcommand failed.
      Traceback (most recent call last):
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/utils/cpp_extension.py", line 1808, in _run_ninja_build
          subprocess.run(
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/subprocess.py", line 516, in run
          raise CalledProcessError(retcode, process.args,
      subprocess.CalledProcessError: Command '['ninja', '-v']' returned non-zero exit status 1.

      The above exception was the direct cause of the following exception:

      Traceback (most recent call last):
        File "<string>", line 2, in <module>
        File "<pip-setuptools-caller>", line 34, in <module>
        File "/tmp/pip-req-build-0bzjdsmk/setup.py", line 77, in <module>
          setup(
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/__init__.py", line 155, in setup
          return distutils.core.setup(**attrs)
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/core.py", line 148, in setup
          return run_commands(dist)
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/core.py", line 163, in run_commands
          dist.run_commands()
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/dist.py", line 967, in run_commands
          self.run_command(cmd)
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/dist.py", line 986, in run_command
          cmd_obj.run()
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/wheel/bdist_wheel.py", line 368, in run
          self.run_command("build")
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/cmd.py", line 313, in run_command
          self.distribution.run_command(command)
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/dist.py", line 986, in run_command
          cmd_obj.run()
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/command/build.py", line 135, in run
          self.run_command(cmd_name)
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/cmd.py", line 313, in run_command
          self.distribution.run_command(command)
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/dist.py", line 986, in run_command
          cmd_obj.run()
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/command/build_ext.py", line 79, in run
          _build_ext.run(self)
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/command/build_ext.py", line 339, in run
          self.build_extensions()
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/utils/cpp_extension.py", line 765, in build_extensions
          build_ext.build_extensions(self)
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/command/build_ext.py", line 448, in build_extensions
          self._build_extensions_serial()
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/command/build_ext.py", line 473, in _build_extensions_serial
          self.build_extension(ext)
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/command/build_ext.py", line 202, in build_extension
          _build_ext.build_extension(self, ext)
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/setuptools/_distutils/command/build_ext.py", line 528, in build_extension
          objects = self.compiler.compile(sources,
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/utils/cpp_extension.py", line 586, in unix_wrap_ninja_compile
          _write_ninja_file_and_compile_objects(
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/utils/cpp_extension.py", line 1487, in _write_ninja_file_and_compile_objects
          _run_ninja_build(
        File "/data1/SunXiaoKun/Others/Software/anaconda3/envs/cd113py38tc112/lib/python3.8/site-packages/torch/utils/cpp_extension.py", line 1824, in _run_ninja_build
          raise RuntimeError(message) from e
      RuntimeError: Error compiling objects for extension
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for cubvh
  Running setup.py clean for cubvh
Failed to build cubvh
ERROR: Could not build wheels for cubvh, which is required to install pyproject.toml-based projects

Why? Looking forward to your reply！

I also found this problem

Similar problem encoutered. But I am using Cuda12.1, and python 3.8. It also upgraded numpy, which also conflicts with my another package also installed.


Use to_data_items in dvc/command/merge.py

It is a more proper solution than using DataItem directly.

Duplicate of #260


Project Status?

Hello.
Would it be possible to get an update on the status of this project? Is it done? Is there something lacking to remove the beta label?
It seems to be the encouraged method for ssh agent forwarding when using mosh, do you know if this is still the case?

Guardian Agent was written as part of an academic project, which has been completed, so I'm not currently actively maintaining it. It is done, but since it has never undergone a thorough security review,  the beta label serves mostly as a warning.

Thank you for the quick reply Dima. I hope this isn't an annoying question,
but is there any related works or other similar projects that you're aware
of, maybe that you use or recommend, or is guardian-agent fairly unique?
Cheers!
On Fri, Jun 28, 2019, 15:09 Dima Kogan<EMAIL_ADDRESS>wrote:

Guardian Agent was written as part of an academic project, which has been
completed, so I'm not currently actively maintaining it. It is done, but
since it has never undergone a thorough security review, the beta label
serves mostly as a warning.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/StanfordSNR/guardian-agent/issues/24?email_source=notifications&email_token=AACP25FJOFV2OF42FWBYF5DP4YERTA5CNFSM4H4DN4TKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY2A36Y#issuecomment-506727931,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACP25C7CHJRMUDLSYZTSI3P4YERTANCNFSM4H4DN4TA
.

I guess that despite the beta status, I think that I would still recommend using Guardian Agent as it is better than insecure agent forwarding.


Add read-only joined field to offer serializer

Description:
Add read-only joined field to OfferSerializer - it need to return boolean value that holds information if user attached to request already joined this particular offer.
Current behaviour:
There's no way to determine if user joined offer in API endpoints.
Expected behaviour:
User can access information - if he/she already joined offer.

@Kropkakam


#184581186: delete a product from user's collection

What does this PR do?
This PR will delete a specific item from a user collection
Description of Task to be completed?

creating routes for delete a product
documenting routes in swagger
test the endpoint

How should this be manually tested?

Clone this repo git clone https://github.com/atlp-rwanda/e-comm-team-amigos-bn
Switch your working directory cd e-comm-team-amigos-bn
Create an .env file and update it with .env-example
Install all the dependencies by running npm install
Then run the project by typing npm start

Endpoints to be tested:

/product/delete

Any background context you want to provide?

Have Node Js installed in your local machine
postman (optional)

What are the relevant pivotal tracker/Trello stories?
Story ID: #184581186
Screenshots (if appropriate)
Show us the test coverage screenshot and swagger output in your endpoint documentation
this is the test coverage for the task

sinc it was requireing the crating new product but I tested it before runing tests

this is it swagger endpoint

Questions:

Rebase is required to resolve a conflicts with develop

This PR has a conflict to resolve before merging it to develop

I think permission/delete/Id was implemented in setting the user role not in the product feature.


Raindrop isn't syncing?

Hello,
I installed this plugin and I set it up to have my notes sync in the "raindrop" folder I made on my obsidian. I put the API key into the plugin settings as instructed. For some reason despite setting it for every 60 minutes my raindrop isn't syncing. I am on a windows computer.

Have you selected which collections to sync? Please click the "Manage" button in the settings page to verify.

for some reason I didn't see the manage button at all until you told me about it, thank you for your time!!! Raindrop's syncing now.


Problem matching non-latin characters

This grammar:
root -> .
doesn't match this character: א

Are you sure? It works for me.
$ echo -n "א" | nearley-test <(nearleyc <(echo "root -> ."))
Table length: 2
Number of parses: 1
Parse Charts
Chart: 0
0: {root →  ● /./}, from: 0

Chart: 1
0: {root → /./ ● }, from: 0

Parse results:
[ [ 'א' ] ]

Perhaps you forgot about trailing newlines or something…?

Sorry it's my mistake. Error in debugging...


When two React components make the same urql query with Suspense, one will not unsuspend when query resolves

urql version & exchanges: 1.11.x, default exchanges
Steps to reproduce

Create a <Provider> with a client with suspense set to true.
Create two React components, each of which is individually wrapped in a <React.Suspense>, and each makes the exact same graphql query with useQuery.

Expected behavior
Upon loading the page, both components initially show their loading states (Loading...), but should both end up displaying data once the query resolves.
Actual behavior
When the query resolves, the second component in the page shows its results, but the first does not, it stays in a permanent loading state.
You can see this for yourself with this demo: https://fpp93.csb.app/
Sandbox code is here: https://codesandbox.io/s/fpp93
Do note that in the sandbox, if the urql version is set to version 1.10.3, then the Sandbox will start to work again (see here), so this is a bug that was introduced in 1.11.0 most likely.
Further notes
In case you're wondering why I have two components making the same request in different Suspense wrappers – my app is a  UI for navigating a folder system. There are two components making queries to the project folder system - one in the sidebar which shows the top-level folders all the time, one in the main panel which the user can navigate up and down all levels. Both work fine, unless the user is navigating the top level in the main panel, in which case both components are making the same query and the sidebar will not load on page load.

We've actually recently started talking to the React team to make our implementation more idiomatic according to the constraints they envision for Suspense in the future.
For the meantime, we have an "in-between" branch that follows the expected structure of a new suspense-supporting hook, but not fully. If you're willing to beta test it the PR is here: https://github.com/FormidableLabs/urql/pull/1335
In there you'll find a CodeSandbox CI check that links pre-built packages. If you create a resolution for "urql" in your package.JSON set to the linked package from CodeSandbox CI you can already try it out.
I've tested it against your sandbox and it does seem to work fine. I'm still trying to figure out whether it breaks any of the old edge cases and what the breaking changes may be.

We've actually recently started talking to the React team to make our implementation more idiomatic according to the constraints they envision for Suspense in the future.
For the meantime, we have an "in-between" branch that follows the expected structure of a new suspense-supporting hook, but not fully. If you're willing to beta test it the PR is here: https://github.com/FormidableLabs/urql/pull/1335
In there you'll find a CodeSandbox CI check that links pre-built packages. If you create a resolution for "urql" in your package.JSON set to the linked package from CodeSandbox CI you can already try it out.
I've tested it against your sandbox and it does seem to work fine. I'm still trying to figure out whether it breaks any of the old edge cases and what the breaking changes may be.

@kitten I can confirm this new branch fixes numerous issues I had with suspense (in concurrent mode). Looks great!

@kitten I can confirm this new branch fixes numerous issues I had with suspense (in concurrent mode). Looks great!


Use of WeakReference in Difference class means diff values can get set to null at any time

Small unit tests probably won't trigger a garbage collection. On the other hand, I have a large DTO object with many hundreds of properties, many on nested objects. I have written a fuzzer which sets the fields of this structure to random values. I then run instances of these DTOs through your lib in a loop.
The following behaviour is observed.
After the comparison has completed and the differences have been returned, several diffs are observed to have the old and new values (Difference.Object1 & Difference.Object2) set to null. It can happen with value types as well as object types.
The problem is that the Difference class uses a WeakReference. https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/weak-references A WeakReference does not guarantee the value will be available - the garbage collector can come in under you at any time and collect the object, and your WeakReference will then become null.
n.b. The problem is difficult to reproduce in the debugger because garbage collections do not run at predictable times.
I believe the fix is simply to change the 4 properties in Difference to be object and remove the corresponding new WeakReference calls.

FYI I have made a fork that contains that change. https://github.com/PhilipDaniels/Compare-Net-Objects
I have tested it in my large-DTO code base and it fixes the problem. I cannot easily give you that test though because it contains proprietary information from work.

Took out references to weak reference.  This will be in a future version.


[BugFix] keep comments in sql when audit it (backport #29747)

backport #29747
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[FE Incremental Coverage Report]
:heart_eyes: pass : 4 / 4 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/common/util/LogUtil.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/qe/ConnectProcessor.java
1
1
100.00%
[]


Use Hamcrest assertions instead of JUnit in webserver/http2 (#1749)

Part of #1749
There is no backport 2.x

/trigger


Add content to cumulusci.yml Pydantic models and JSON Schema

Added title, description, and examples to all Pydantic models for the cumulusci.yml json schema to provide better help information in IDEs.
There are a few places where I added enums.

@jlantz Looks like the some test failures due to a schema mismatch. I'll push a copy of your branch to the remote to resolve the lint failure afterwards.


Pressing return keypad on iOS doesn't close the keypad

When I press the return button after typing my query, It doesn't close the keypad. See the video below.
*Note: the zoom issue you see in the video has been fixed in this pr #102 *
https://github.com/bitcoinsearch/bitcoinsearch-app/assets/60826700/422ce735-d206-4423-aa61-cf66d6eebd05

@Emmanuel-Develops what's the status of this issue?

@Emmanuel-Develops what's the status of this issue?

completed!


arpack error, retry= 0

When use your code and command "bash scripts/pretrain.sh  --moco --nce-k 16384" to train the model without any modification, the warning "arpack error, retry= 0" always occurs like this:

And when I use your pretrained model to inference on my own dataset, this warning also occurs.
The relevant code is here:
https://github.com/THUDM/GCC/blob/dev/gcc/datasets/data_util.py#L249
Is it normal? Can I ignore it?

Hi @JiangTanZJU ,
Please feel free to ignore this warning. We will comment it out later.
Best,


Upgrade velero to get "ignore volumes of non-running pods"

What Chart should be upgraded?
/e.g., dexidp/dex 2.15/
Velero 1.8.2 (?) 1.9.0 (?)
The PR https://github.com/vmware-tanzu/velero/pull/4584 has now been merged and since we want to have the feature we should upgrade as soon as the next version is released.
Why should this Chart be upgraded?

[ ] We need to perform a security upgrade.
[ ] We need it for a new feature: which feature (link to blocked issue).
[ ] We need to keep up to prevent future issues.
[x] Other: Write the reason here We want the "ignore volumes of non-running pods" feature

Definition of done

Have a velero version that includes the "ignore volumes of non-running pods" feature

The linked PR has been merged @Xartos.
Give this issue some love in the next planning meeting, i'd like this fixed as it will reduce the number of alerts generated

Yes, it has been merged for some time, we've only waited for it to be a part of a release. But the 1.9 release seems to include it :tada:


multiple instances

Hello . I did two chatbot , one for each customer. I started both on the same server . But when sending a message to the first chatbot , the second chatbot answers and vice versa . How can I have more than one chatbot running on the same server?
Best regards.

Hey @andrecordeiro, what is your current use case? If you want to answer multiple customers at the same time you don't need multiple bots, you can create one and do some dispatching depending on the threadID of the message.
If you need multiple bots, it should still work independently...
@Schmavery Do you think there would be collision between the cookie jars? If all the require("request") point to the same module and we somehow end up using the same jar for everyone then that's a bug. Any other ideas why this might be an issue?

Hey @bsansouci both use:
var login = require("facebook-chat-api");
var request = require("request")
var fs = require("fs");
var moment = require('moment');
var mysql = require('mysql');
I have not changed anything in the way of call , followed his examples:

Are they both logged into the same account?

@bsansouci I'm pretty sure we pass around cookie jars explicitly, so they're not just persisted by the module...  I think this is more likely to be an issue with not filtering messages, as you suggested.

not , are recorded in different accounts.

I decided as follows: the same chatbot.js I make two calls , one for each account. I do not know if it's the right way I understand it, but at first it worked. the problem is that when I stop the script for all customers. hehe , but no problems .
chatbot.js
login({email<EMAIL_ADDRESS>password: "xxxx"}, {pageID: "page1"}, function callback (err, api){ my code 1 }
login({email<EMAIL_ADDRESS>password: "xxxx"}, {pageID: "page1"}, function callback (err, api) { my code 2}

Wait, was that a mistake or are they both logged into page1?

each connects a different pageID . sorry

good morning friends. this is the right way for me to use multiple chatbots? the problem is that I can not stop each. if I stop the script, for everything.

Hey @andrecordeiro we tried to reproduce this and couldn't. When logging in with two different accounts everything worked as expected. Try checking your code once more :/


Fix ingress logic

Proposed changes
This change fix the logic to get the IP or Hostname from ingress.
The current logic do not work with traefik
Types of changes
What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

[ ] New feature (non-breaking change which adds functionality)
[ X] Bugfix (non-breaking change which fixes an issue)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices applies)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[ X] I have read the CONTRIBUTING doc
[ X] I have signed the commit for DCO to be passed.
[ ] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[ ] I have added necessary documentation (if appropriate)

Dependency

Please add the links to the dependent PR need to be merged before this (if any).

Special notes for your reviewer:
fix https://github.com/litmuschaos/litmus/issues/3045

Thanks @Vr00mm , I will test this PR and merge it by today.

Thanks @Vr00mm, Worked fine during the test


better config

Yaml sucks:

No Yaml
YAML is an extremely bad choice for any configuration file because it's wildly unpredictable.

We need something else.

TOML or JSON

S-Expressions

XML ? But we should use json with comment

In my mind json seems to be an ideal candidate.

Yeah json is the best imo


integration with coc.nvim

Is it possible to integrate this plugin with coc.nvim? I prefer this one over the builtin LSP.

Should be possible...

https://github.com/yuki-yano/coc-nav

Been wishing this for a while. I've been sticking to nvim-gps due to that until now, but it has become a problem due to newer nvim, that has deprecated APIs nvim-gps rely on, so it's generating lots of errors messages.
Besides that, I viewed nvim-gps as an alternative, not to be replaced by LSP based projects. Relying on treesitter was a feature because often I don't have LSP for some language, but do have treesitter for it.