advanced Search for Engagement listing page

Issue #:
https://github.com/bcgov/met-public/issues/572
Description of changes:

Back end changes to add the filter conditions needed for advanced search
Front end changes to add the advanced search feature on engagement listing page

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the met-public license (Apache 2.0).

Codecov Report

Merging #1166 (a51a76c) into main (a886d0a) will decrease coverage by 0.14%.
The diff coverage is 54.00%.

@@            Coverage Diff             @@
##             main    #1166      +/-   ##
==========================================
- Coverage   73.80%   73.66%   -0.14%
==========================================
  Files         266      266
  Lines        7479     7504      +25
  Branches      508      508
==========================================
+ Hits         5520     5528       +8
- Misses       1882     1899      +17
  Partials       77       77

Flag
Coverage Δ

metapi
79.38% <41.37%> (-0.32%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

met-api/src/met_api/resources/engagement.py
62.00% <ø> (ø)

met-api/src/met_api/models/engagement.py
56.34% <19.04%> (-8.47%)
:arrow_down:

met-web/src/services/engagementService/index.ts
27.77% <25.00%> (ø)

...et-web/src/components/engagement/listing/index.tsx
88.88% <81.25%> (ø)

met-api/src/met_api/constants/engagement_status.py
100.00% <100.00%> (ø)

met-api/src/met_api/services/engagement_service.py
64.56% <100.00%> (ø)

met-web/src/constants/engagementStatus.ts
100.00% <100.00%> (ø)

met-api/src/met_api/models/membership.py
84.00% <0.00%> (ø)

... and 1 more


Remove python 3.9 from main workflow

resolves #

Description
Similar to (https://github.com/dbt-labs/dbt-core/pull/7095)
Checklist

[x] I have read the contributing guide and understand what's expected of me
[x] I have signed the CLA
[x] I have run this code in development and it appears to resolve the stated issue
[ ] This PR includes tests, or tests are not required/relevant for this PR
[ ] I have opened an issue to add/update docs, or docs changes are not required/relevant for this PR
[ ] I have run changie new to create a changelog entry

I would pull it from setup.py as well, so that we're not advertising that we're supporting py39 when we're not testing for it.
3.9 is still in the setup.py in dbt-snowflake, dbt-redshift and dbt-core. @jtcohen6 should we remove 3.9 across the board?


restructure microSWIFT.py and submodules

Restructuring is complete but needs to be updated in microSWIFT.py.


The --onefile mode ignores --output-dir

Nuitka version, full Python version, flavor, OS, etc. as output by this
command
1.2
Commercial: None
Python: 3.9.5 (tags/v3.9.5:0a7dcbd, May  3 2021, 17:27:52) [MSC v.1928 64 bit (AMD64)]
Flavor: Unknown
Executable: C:\Python39\python.exe
OS: Windows
Arch: x86_64
WindowsRelease: 10

How did you install Nuitka and Python

Installed using pip

The specific PyPI names and versions

pip 22.0.4 from c:\python39\lib\site-packages\pip (python 3.9)

Also supply a Short, Self Contained, Correct, Example

print('hello world')

Provide in your issue the Nuitka options used

python -m nuitka --onefile --output-filename=test.exe --output-dir=.\bin\Release --remove-output main.py

Explanation
When i build main.py with this options, it simply ignore the specified output dir and create the onefile exe in the current directory.

I totally fail to reproduce this, so much so that I think you are confusing it with a previous compilation result.

Sorry i have noticed only now after your comment that i have missed an option in the command use(--output-filename=test.exe). With this option you can reproduce the issue

Well, of course, that is what the option does, it specifies where the onefile binary goes to, so I am not surprised. Question of course then becomes, if your expectation that it should be relative to the output directory. Those code does this:
        output_filename = Options.getOutputFilename()

        if Options.isOnefileMode() and output_filename is not None:
            if onefile:
                result = output_filename
            else:
                result = os.path.join(
                    getStandaloneDirectoryPath(),
                    os.path.basename(output_filename),
                )

So, output directory is not used at all there, but an os.path.join may well make sense, indeed. But for -o we also so far allow specifying a directory and even check if it exists. This is still kind of messy. I need to think some about this.

I think I might settle on disallowing os.path.sep in -o and indeed require giving both options if you wanted to have it in a specific folder. Kind of breaking change, but I guess, that's the only way to keep the sanity, otherwise it will behave differently for the final output of only onefile, which is pretty bad.

Thanks for the answer. I think that forcing both option is a good solution also because the --output-filename don't create the folder tree if don't exists. Instead -o does. So if you use both option in this way -o .\bin\Release --output-filename .\bin\Release\test.exe you obtain an error if .\bin\Release dont exists

Yes, I saw that, and it's much more shy there, for what is probably no good reason. The filename option was added later only, and generally in some cases is not even allowed, or changes behavior, and came late to the party. I guess there will be a breaking change then. I will plan it for the next live stream, where I want to do quality of life improvements.

Streams are being delayed probably until march.

The 4fb72469 commit have broken the workaround for this issue. In fact before 1.4.3 i simply used --output-dir=.\bin\Release --output-filename=.\bin\Release\C-Link_PredictiveMaintenance.exe to obtain the onefile exe in .\bin\Release. But now i obtain this error:
FATAL: Error, output filename for standalone cannot contain a directory part.

That is kind of correct, should probably not have been applied for onefile mode. Dang these things are complex.

Although, I think the issue is still the same. Ignoring --output-dir seems to be the relevant issue in the first place, going to look at this now, how hard can it be.

So, --output-filename now incluences the name of the standalone binary, which is good, and then the onefile binary is created inside the current folder, which is the original issue.

Thanks for your report, this is fixed on the factory branch, which is a development version under rapid development. You can try it out by going here: https://nuitka.net/doc/factory.html
Feedback if this is working is very welcome, just please do not share plans of doing it, but rather confirmations or denials of it working.

I will make it part of the 1.4.4 hotfix release.

Tested and worked, thank you very much!

This is part of the hotfix release 1.4.4 that I just made.


Default Value with Remote do not validate

I am having just 3 fields in a form as contact_person, email and invitation_code
All are textboxes and all has validations as below Code.
But when I submit the Page, it do not validate or don't even show any error on console.
One thing is, I have set default value of the invitation_code textbox to 123456 so that some users can leave it as it is.
If I remove this default value from textbox then this validates properly.
Please advice.
$(document).ready(function(){

			$("#frmAdd").validate({
				errorElement: "label",
				errorClass: "error-input",
				rules: {
					contact_person: {	required: true },
					email: {   required: true, email: true },
					invitation_code: {
						required: true,
						remote: {
							//check if invitation_code exists or not
							url: "check_exists.php",
							type: "post",
							data: {
								invitation_code: function() {
									return $("#invitation_code").val();
								}
							}
						}
					}
				},
				messages: {
					contact_person: {	required: "Please enter Contact Person" },
					email: {   required: "Please enter Email address", email: "Please enter valid Email address" },
					invitation_code: { required: "Please enter User Invitation Code", remote: "User with this Invitation Code already exists" }
				}
			});

		});

I'm sorry for the lack of activity on this issue. Instead of leaving it open any longer, I decided to close old issues without trying to address them, to longer give the false impression that it will get addressed eventually.
To the reporter (or anyone else interested in this issue): If you're affected by the same issue, consider opening a new issue, with a testpage that shows the issue. Even better, try to fix the issue yourself, and improve the project by sending a pull request. This may seem daunting at first, but you'll likely learn some useful skills that you can apply elsewhere as well. And you can help keep this project alive. We've documented how to do these things, too. A patch is worth a thousand issues!


instructions a bit vague around access tokens

Hello,
I'm attempting to use your system for pulling two private repos that are dependencies of the current one.
I should be able to do this as my specialty is cryptology & security, but am having trouble with your documentation.
Assume repo A that has dependencies of repo B and C.
Assume that I'm making all my changes in development branches.
In repo B, I have this in the develop branch in .github/access_token.yml (I kept widening the policy to try and get it to work, so this is not a permanent config)
origin: ORG_HERE/PROJ_A
statements:
  - subjects:
      - repo:${origin}:ref:refs/heads/main
      - repo:${origin}:ref:refs/heads/develop
      - repo:${origin}:ref:refs/tags/v*
      - repo:${origin}:environment:production
      - repo:${origin}:workflow_ref:${origin}/.github/workflows/ci.yml
      - repo:${origin}:workflow_ref:${origin}/.github/workflows/ci.yml@*
      - repo:${origin}:workflow_ref:${origin}/.github/workflows/ci.yml@refs/pull/234/merge
      - repo:${origin}:pull_request
    permissions: # https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps
      contents: read # read or write

And in repo C, I have this in develop branch:
origin: ORG_HERE/PROJ_A
statements:
  - subjects:
      - repo:${origin}:ref:refs/heads/main
      - repo:${origin}:ref:refs/heads/develop
      - repo:${origin}:ref:refs/tags/v*
      - repo:${origin}:environment:production
      - repo:${origin}:workflow_ref:${origin}/.github/workflows/ci.yml
      - repo:${origin}:workflow_ref:${origin}/.github/workflows/ci.yml@*
      - repo:${origin}:workflow_ref:${origin}/.github/workflows/ci.yml@refs/pull/234/merge
      - repo:${origin}:pull_request
    permissions: # https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps
      contents: read # read or write

In repo A, I had something like this:
      - name: Set up access to PROJ_B
        uses: qoomon/actions--access-token@v3
        id: access-token-PROJ_B
        with:
          repository: PROJ_B
          permissions: |
            contents: read
      - name: Checkout repo - PROJ_B
        uses: actions/checkout@v4
        with:
          repository: ORG_HERE/PROJ_B
          token: ${{ steps.access-token-PROJ_B.outputs.token }}
          path: PROJ_B
          ref: develop

However, I was getting the error that the action was denied by (ORG_HERE) owner policy.
There's not a lot more debug info in the stack trace - it was in merge... process ticks ... http request ... get access token.  If you really need it I'll repro and scrub any company-specific info out of it.
I think that this is checking for a .github/access-token.yml in the main branch, and not finding it, and then falling back to the fact we don't have an owner policy repo set up, because none of your several StackOverflow comments mention having to set up an owner policy.  Can you please confirm?
It's not clear at all what the owner policy is... so I'm a bit baffled - but your tool seems very useful!

In repo B, I have this in the develop branch in .github/access_token.yml (I kept widening the policy to try and get it to work, so this is not a permanent config)

the access policy file needs to be named access-token.yaml instead of access_token.yml

I think that this is checking for a .github/access-token.yml in the main branch, and not finding it, and then falling back to the fact we don't have an owner policy repo set up, because none of your several StackOverflow comments mention having to set up an owner policy. Can you please confirm?

Since the latest version you need to have an owner policy repo (OWNER/.github-access-token)

I have updated the README and tried to explicitly added the owner policy setup in the prerequisites section.

And I probably should add support for .yaml and .yml policy file endings. WDYT?

Latest server supports .yaml and .yml file endings (ensure you grant latest permission changes to your app installation)

@travis-infosec how is it going?


clarify deprecation of beacon_block gossip topic in 4844

part of #3088

Thank you! 🙏🏼

This looks good to me!

I think this is ready to go, just needs an approving review


SIGINT (CTRL + C) immediately yields controls of the shell without waiting for the task to complete

Describe the bug
I have a (local/persistent/interactive) task that does some semi-complicated things which include running a few sub-processes. The task itself is a python script which intercepts CTRL+C and performs some teardown/cleanup then lets the user know when the cleanup is complete.
Running this script directly works just fine with CTRL+C. Upon sending the signal, the teardown starts and the user is not returned control of the shell until the teardown is complete.
However, running this task through moon run and pressing CTRL+C immediately returns control of the shell to the user (while the actual task/script is still running in the background and performing cleanup) causing output from the actual task to intermix with the user's shell control.
I understand this may be a design choice but I feel this specific functionality for CTRL+C should be either configurable or totally disabled for interactive tasks, since interaction also includes signals and the task should have control over how it reacts.
Steps to reproduce
Create a python script:
from time import sleep

print("Hello I am a task that is starting")

try:
    sleep(30)
except KeyboardInterrupt as ex:
    print("I am going to do some cleanup and will let you know when I am done")
    sleep(5)
    print("Clean up complete")

Create an associated task like:
  test:
    command: python test.py
    local: true
    options:
      interactive: true

Run the task moon run test and press CTRL+C after seeing "Hello I am a task that is starting". The shell will return immediately and around 5 seconds later output from the task will overwrite the user's shell control.
Expected behavior
The task should be allowed to complete its clean-up after pressing CTRL+C and not yield immediately. Moon should allow disabling the built-in signal handler for interactive tasks.
Screenshots
The correct behavior, when running the script directly

The behavior using moon run

The moment CTRL+C was pressed is highlighted in red
Environment

  System:
    OS: Linux 5.15 Ubuntu 20.04.5 LTS (Focal Fossa)
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
    Memory: 10.65 GB / 15.51 GB
    Container: Yes
    Shell: 3.6.0 - /usr/bin/fish
  Binaries:
    Node: 18.19.0 - /mnt/wslg/runtime-dir/fnm_multishells/11128_1707015305320/bin/node
    Yarn: 1.22.19 - /usr/bin/yarn
    npm: 10.2.3 - /mnt/wslg/runtime-dir/fnm_multishells/11128_1707015305320/bin/npm
    pnpm: 8.15.1 - /usr/bin/pnpm
  Managers:
    Apt: 2.0.9 - /usr/bin/apt
    Cargo: 1.75.0 - ~/.cargo/bin/cargo
    pip3: 20.0.2 - /usr/bin/pip3
  Utilities:
    Make: 4.2.1 - /usr/bin/make
    GCC: 9.4.0 - /usr/bin/gcc
    Git: 2.43.0 - /usr/bin/git
    FFmpeg: 4.2.7 - /usr/bin/ffmpeg
    Curl: 7.68.0 - /usr/bin/curl
  Virtualization:
    Docker: 20.10.12 - /usr/local/bin/docker
  IDEs:
    Nano: 4.8 - /usr/bin/nano
    VSCode: 1.86.0 - /mnt/c/Users/affan.shahid/AppData/Local/Programs/Microsoft VS Code/bin/code
    Vim: 8.1 - /usr/bin/vim
  Languages:
    Bash: 5.0.17 - /usr/bin/bash
    Go: 1.18 - /home/affan/.go/current/bin/go
    Perl: 5.30.0 - /usr/bin/perl
    Python3: 3.8.10 - /usr/bin/python3
    Rust: 1.75.0 - /home/affan/.cargo/bin/rustc

Additional context

I have experienced the current behavior causes hanging Node.js processes.

Yeah right now ctrl+c basically sends an abort to the thread: https://github.com/moonrepo/moon/blob/master/crates/core/action-pipeline/src/pipeline.rs#L237
Let me see if we can work around this.

To be on-par with other task runners I think should just forward any signals to the underlying process (which it already does) and then wait for it to exit.

Ok I made some changes in 1.21, can you give that a shot.

This is fixed!

Sweet


SurfaceUpgradeTool::_show_popup deadlock when loading project imported in 4.1 in 4.2 beta (self-contained editors)

Godot version
4.2.beta5, master (e38686f85b768a451dc06324fe2471adc8665448)
System information
Mageia 9 - Vulkan (Forward+) - dedicated AMD Radeon RX Vega M GL Graphics (RADV VEGAM) () - Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz (8 Threads)
Issue description
I noticed a deadlock in GDScriptCache::get_full_script when trying to open GDQuest's 3D TPS demo in 4.2 beta 5 and latest master (e38686f85b768a451dc06324fe2471adc8665448). I haven't yet tested earlier versions to see whether I can pinpoint a regression time, I'll do that next.
It happens when opening the project in Godot 4.2 after having opened it once in 4.1.3, ensuring that all files in .godot have been generated by 4.1.3.
The editor freezes, and attaching a debugger gives me this stacktrace of where it seems to be stuck, on a mutex in GDScriptCache::get_full_script:
(gdb) bt
#0  0x00007f4c8e85d97c in __lll_lock_wait () from /lib64/libc.so.6
#1  0x00007f4c8e86361f in pthread_mutex_lock@@GLIBC_2.2.5 () from /lib64/libc.so.6
#2  0x00000000056d59b7 in __gthread_mutex_lock (__mutex=0xbae97e8) at /usr/include/c++/12/x86_64-mageia-linux/bits/gthr-default.h:749
#3  0x00000000056d5a07 in __gthread_recursive_mutex_lock (__mutex=0xbae97e8) at /usr/include/c++/12/x86_64-mageia-linux/bits/gthr-default.h:811
#4  0x00000000056d5a3c in std::recursive_mutex::lock (this=0xbae97e8) at /usr/include/c++/12/mutex:108
#5  0x00000000056d6309 in std::unique_lock<std::recursive_mutex>::lock (this=0x7fff39a697a0) at /usr/include/c++/12/bits/unique_lock.h:139
#6  0x00000000056d61d7 in std::unique_lock<std::recursive_mutex>::unique_lock (this=0x7fff39a697a0, __m=...) at /usr/include/c++/12/bits/unique_lock.h:69
#7  0x0000000005f9324a in MutexLock<MutexImpl<std::recursive_mutex> >::MutexLock (p_mutex=..., this=<optimized out>) at ./core/os/mutex.h:122
#8  GDScriptCache::get_full_script (p_path=..., r_error=@0x7fff39a6982c: OK, p_owner=..., p_update_from_disk=false) at ./modules/gdscript/gdscript_cache.cpp:273
#9  0x0000000005f66dcf in ResourceFormatLoaderGDScript::load (this=0xbec68f0, p_path=..., p_original_path=..., r_error=0x221a1d6c, p_use_sub_threads=false, r_progress=0x221a1d60,
    p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE) at ./modules/gdscript/gdscript.cpp:2699
#10 0x00000000099e4b2d in ResourceLoader::_load (p_path=..., p_original_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE, r_error=0x221a1d6c, p_use_sub_threads=false, r_progress=0x221a1d60)
    at ./core/io/resource_loader.cpp:261
#11 0x00000000099e524c in ResourceLoader::_thread_load_function (p_userdata=0x221a1d18) at ./core/io/resource_loader.cpp:319
#12 0x00000000099e5e91 in ResourceLoader::_load_start (p_path=..., p_type_hint=..., p_thread_mode=ResourceLoader::LOAD_THREAD_FROM_CURRENT, p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE)
    at ./core/io/resource_loader.cpp:498
#13 0x00000000088c7ea5 in ResourceLoaderText::load (this=0x7fff39a6a560) at ./scene/resources/resource_format_text.cpp:467
#14 0x00000000088d3afd in ResourceFormatLoaderText::load (this=0xd591dd0, p_path=..., p_original_path=..., r_error=0x229f462c, p_use_sub_threads=false, r_progress=0x229f4620,
    p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE) at ./scene/resources/resource_format_text.cpp:1651
#15 0x00000000099e4b2d in ResourceLoader::_load (p_path=..., p_original_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE, r_error=0x229f462c, p_use_sub_threads=false, r_progress=0x229f4620)
    at ./core/io/resource_loader.cpp:261
#16 0x00000000099e524c in ResourceLoader::_thread_load_function (p_userdata=0x229f45d8) at ./core/io/resource_loader.cpp:319
#17 0x00000000099e5e91 in ResourceLoader::_load_start (p_path=..., p_type_hint=..., p_thread_mode=ResourceLoader::LOAD_THREAD_FROM_CURRENT, p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE)
    at ./core/io/resource_loader.cpp:498
#18 0x00000000088c7ea5 in ResourceLoaderText::load (this=0x7fff39a6d430) at ./scene/resources/resource_format_text.cpp:467
#19 0x00000000088d3afd in ResourceFormatLoaderText::load (this=0xd591dd0, p_path=..., p_original_path=..., r_error=0x23cdc08c, p_use_sub_threads=false, r_progress=0x23cdc080,
    p_cache_mode=ResourceFormatLoader::CACHE_MODE_REPLACE) at ./scene/resources/resource_format_text.cpp:1651
#20 0x00000000099e4b2d in ResourceLoader::_load (p_path=..., p_original_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REPLACE, r_error=0x23cdc08c, p_use_sub_threads=false, r_progress=0x23cdc080)
    at ./core/io/resource_loader.cpp:261
--Type <RET> for more, q to quit, c to continue without paging--
#21 0x00000000099e524c in ResourceLoader::_thread_load_function (p_userdata=0x23cdc038) at ./core/io/resource_loader.cpp:319
#22 0x00000000099e5e91 in ResourceLoader::_load_start (p_path=..., p_type_hint=..., p_thread_mode=ResourceLoader::LOAD_THREAD_FROM_CURRENT, p_cache_mode=ResourceFormatLoader::CACHE_MODE_REPLACE)
    at ./core/io/resource_loader.cpp:498
#23 0x00000000099e5989 in ResourceLoader::load (p_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REPLACE, r_error=0x7fff39a6fae4) at ./core/io/resource_loader.cpp:415
#24 0x0000000007105359 in EditorNode::load_scene (this=0xe0d48a0, p_scene=..., p_ignore_broken_deps=false, p_set_inherited=false, p_clear_errors=true, p_force_open_imported=false, p_silent_change_tab=false)
    at ./editor/editor_node.cpp:3760
#25 0x0000000007111e3e in EditorNode::_load_open_scenes_from_config (this=0xe0d48a0, p_layout=...) at ./editor/editor_node.cpp:5466
#26 0x000000000710ee30 in EditorNode::_load_editor_layout (this=0xe0d48a0) at ./editor/editor_node.cpp:5090
#27 0x00000000070f05e0 in EditorNode::_sources_changed (this=0xe0d48a0, p_exist=false) at ./editor/editor_node.cpp:1049
#28 0x0000000007304085 in call_with_variant_args_helper<EditorNode, bool, 0ul> (p_instance=0xe0d48a0, p_method=(void (EditorNode::*)(EditorNode * const, bool)) 0x70f0526 <EditorNode::_sources_changed(bool)>,
    p_args=0x7fff39a70480, r_error=...) at ./core/variant/binder_common.h:303
#29 0x00000000072f5101 in call_with_variant_args<EditorNode, bool> (p_instance=0xe0d48a0, p_method=(void (EditorNode::*)(EditorNode * const, bool)) 0x70f0526 <EditorNode::_sources_changed(bool)>, p_args=0x7fff39a70480,
    p_argcount=1, r_error=...) at ./core/variant/binder_common.h:417
#30 0x00000000072e2542 in CallableCustomMethodPointer<EditorNode, bool>::call (this=0x1cf69270, p_arguments=0x7fff39a70480, p_argcount=1, r_return_value=..., r_call_error=...) at ./core/object/callable_method_pointer.h:104
#31 0x0000000009afe4e5 in Callable::callp (this=0x21f90c50, p_arguments=0x7fff39a70480, p_argcount=1, r_return_value=..., r_call_error=...) at ./core/variant/callable.cpp:57
#32 0x0000000009e112cc in Object::emit_signalp (this=0xe12b6a0, p_name=..., p_args=0x7fff39a70480, p_argcount=1) at ./core/object/object.cpp:1127
#33 0x0000000007dbc970 in Node::emit_signalp (this=0xe12b6a0, p_name=..., p_args=0x7fff39a70480, p_argcount=1) at ./scene/main/node.cpp:3606
#34 0x000000000659371c in Object::emit_signal<bool> (this=0xe12b6a0, p_name=...) at ./core/object/object.h:922
#35 0x0000000006f4f85b in EditorFileSystem::_notification (this=0xe12b6a0, p_what=17) at ./editor/editor_file_system.cpp:1285
#36 0x0000000006fe5178 in EditorFileSystem::_notificationv (this=0xe12b6a0, p_notification=17, p_reversed=false) at ./editor/editor_file_system.h:146
#37 0x0000000009e0f812 in Object::notification (this=0xe12b6a0, p_notification=17, p_reversed=false) at ./core/object/object.cpp:837
#38 0x0000000007dc1db0 in SceneTree::_process_group (this=0xe065140, p_group=0xe065398, p_physics=false) at ./scene/main/scene_tree.cpp:951
#39 0x0000000007dc2329 in SceneTree::_process (this=0xe065140, p_physics=false) at ./scene/main/scene_tree.cpp:1028
#40 0x0000000007dc0268 in SceneTree::process (this=0xe065140, p_time=0.077858000000000122) at ./scene/main/scene_tree.cpp:508
#41 0x0000000005754650 in Main::iteration () at main/main.cpp:3636
#42 0x00000000056cddce in OS_LinuxBSD::run (this=0x7fff39a70960) at platform/linuxbsd/os_linuxbsd.cpp:933
#43 0x00000000056c6840 in main (argc=2, argv=0x7fff39a70f48) at platform/linuxbsd/godot_linuxbsd.cpp:74

Steps to reproduce

Check out https://github.com/gdquest-demos/godot-4-3d-third-person-controller (commit b4298d4b524a2dfb05daa58c88867980f0ddc83b at the time of writing).
Ensure .godot is deleted, also remove the Godot cache for good measure (~/.cache/godot/ or similar locations) - that last part may not be needed but I haven't tested without that step.
Open the project in Godot 4.1.3, letting it import everything. Close the editor.
Open the project in latest Godot 4.2 - it should deadlock.
If you want to repeat the test, make sure to git checkout any changes made by Godot 4.2, clean .godot, etc.

Minimal reproduction project
Not really minimal, I haven't yet tried to narrow it down.
But the stacktrace suggests an issue with GDScript, possibly preloading or cyclic references.

Did some more testing, I'm not sure anymore whether it's a regression, and it only seems to appear with a somewhat baroque setup.
My Godot 4.1.3 is used self-contained, so it doesn't share its editor data with my 4.2 snapshots / git builds, which are not self-contained and use the editor data installed in the default user folders (notably ~/.cache/godot for the cache).
This seems to be important, and the problem seems related to generating the .godot folder with the self-contained Godot 4.1.3, then opening the project in Godot 4.2 after having deleted ~/.cache/godot - can be done before importing in 4.1.3 or after, that doesn't seem to make a difference (which is logical as the self-contained 4.1.3 won't touch it).

So @YuriSizov and I did some digging, and the problem is indeed tied to using self-contained editors / separate editor caches in the migration from a .godot folder imported in 4.1.x to Godot 4.2.
Our friend SurfaceUpgradeTool seems to be involved, as one of the other waiting threads shows:
Thread 26 (Thread 0x7f8735ffc6c0 (LWP 182795) "godot.linuxbsd."):
#0  0x00007f87a555e756 in __futex_abstimed_wait_common () from /lib64/libc.so.6
#1  0x00007f87a5560dc8 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libc.so.6
#2  0x00000000092164ee in Semaphore::wait (this=0xcc2b368) at ./core/os/semaphore.h:65
#3  CommandQueueMT::push_and_ret<RendererViewport, RID (RendererViewport::*)(RID) const, RID, RID> (this=0xcc2b358, p_instance=0xca121d0, p_method=(RID (RendererViewport::*)(const RendererViewport * const, RID)) 0x91638e0 <RendererViewport::viewport_get_texture(RID) const>, p1=..., r_ret=0x7f8735ff1458) at ./core/templates/command_queue_mt.h:396
#4  0x00000000091f6366 in RenderingServerDefault::viewport_get_texture (this=0xcc2b130, p1=...) at ./servers/rendering/rendering_server_default.h:622
#5  0x0000000007df5a00 in Viewport::Viewport (this=0x7f8724540af0) at ./scene/main/viewport.cpp:4790
#6  0x0000000007e16bb9 in Window::Window (this=0x7f8724540af0) at ./scene/main/window.cpp:2940
#7  0x0000000007f4de16 in AcceptDialog::AcceptDialog (this=0x7f8724540af0) at ./scene/gui/dialogs.cpp:402
#8  0x0000000007f4e6cb in ConfirmationDialog::ConfirmationDialog (this=0x7f8724540af0) at ./scene/gui/dialogs.cpp:460
#9  0x00000000071127be in EditorNode::immediate_confirmation_dialog (p_text=..., p_ok_text=..., p_cancel_text=..., p_wrap_width=500) at ./editor/editor_node.cpp:5539
#10 0x00000000073d2aa4 in SurfaceUpgradeTool::_show_popup (this=0xe585290) at ./editor/surface_upgrade_tool.cpp:84
#11 0x00000000073d290c in SurfaceUpgradeTool::_try_show_popup () at ./editor/surface_upgrade_tool.cpp:70
#12 0x0000000008d9d253 in RenderingServer::fix_surface_compatibility (this=0xcc2b130, p_surface=..., p_path=...) at ./servers/rendering_server.cpp:2135
#13 0x000000000885523a in ArrayMesh::_set_surfaces (this=0x7f87244795c0, p_surfaces=...) at ./scene/resources/mesh.cpp:1643
#14 0x0000000007ec3cdf in call_with_variant_args_helper<__UnexistingClass, Array const&, 0ul> (p_instance=0x7f87244795c0, p_method=(void (__UnexistingClass::*)(__UnexistingClass * const, const Array &)) 0x88542e8 <ArrayMesh::_set_surfaces(Array const&)>, p_args=0x7f8735ff2468, r_error=...) at ./core/variant/binder_common.h:303
#15 0x0000000007ea8ee6 in call_with_variant_args_dv<__UnexistingClass, Array const&> (p_instance=0x7f87244795c0, p_method=(void (__UnexistingClass::*)(__UnexistingClass * const, const Array &)) 0x88542e8 <ArrayMesh::_set_surfaces(Array const&)>, p_args=0x7f8735ff2508, p_argcount=1, r_error=..., default_values=...) at ./core/variant/binder_common.h:450
#16 0x0000000007e90602 in MethodBindT<Array const&>::call (this=0xdf9a400, p_object=0x7f87244795c0, p_args=0x7f8735ff2508, p_arg_count=1, r_error=...) at ./core/object/method_bind.h:335
#17 0x0000000009e04780 in ClassDB::set_property (p_object=0x7f87244795c0, p_property=..., p_value=..., r_valid=0x0) at ./core/object/class_db.cpp:1235
#18 0x0000000009e0d5ba in Object::set (this=0x7f87244795c0, p_name=..., p_value=..., r_valid=0x0) at ./core/object/object.cpp:257
#19 0x00000000099d4bfb in ResourceLoaderBinary::load (this=0x7f8735ff2960) at ./core/io/resource_format_binary.cpp:832
#20 0x00000000099d70a6 in ResourceFormatLoaderBinary::load (this=0xbe72f70, p_path=..., p_original_path=..., r_error=0x7f872407dd6c, p_use_sub_threads=false, r_progress=0x7f872407dd60, p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE) at ./core/io/resource_format_binary.cpp:1196
#21 0x00000000099e4b2d in ResourceLoader::_load (p_path=..., p_original_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE, r_error=0x7f872407dd6c, p_use_sub_threads=false, r_progress=0x7f872407dd60) at ./core/io/resource_loader.cpp:261
--Type <RET> for more, q to quit, c to continue without paging--c
#22 0x00000000099e0f37 in ResourceFormatImporter::load (this=0xbe73270, p_path=..., p_original_path=..., r_error=0x7f872407dd6c, p_use_sub_threads=false, r_progress=0x7f872407dd60, p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE) at ./core/io/resource_importer.cpp:139
#23 0x00000000099e4b2d in ResourceLoader::_load (p_path=..., p_original_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE, r_error=0x7f872407dd6c, p_use_sub_threads=false, r_progress=0x7f872407dd60) at ./core/io/resource_loader.cpp:261
#24 0x00000000099e524c in ResourceLoader::_thread_load_function (p_userdata=0x7f872407dd18) at ./core/io/resource_loader.cpp:319
#25 0x00000000099e5e91 in ResourceLoader::_load_start (p_path=..., p_type_hint=..., p_thread_mode=ResourceLoader::LOAD_THREAD_FROM_CURRENT, p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE) at ./core/io/resource_loader.cpp:498
#26 0x00000000088c7ea5 in ResourceLoaderText::load (this=0x7f8735ff39b0) at ./scene/resources/resource_format_text.cpp:467
#27 0x00000000088d3afd in ResourceFormatLoaderText::load (this=0xcbfcf00, p_path=..., p_original_path=..., r_error=0x7f8724082ccc, p_use_sub_threads=false, r_progress=0x7f8724082cc0, p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE) at ./scene/resources/resource_format_text.cpp:1651
#28 0x00000000099e4b2d in ResourceLoader::_load (p_path=..., p_original_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE, r_error=0x7f8724082ccc, p_use_sub_threads=false, r_progress=0x7f8724082cc0) at ./core/io/resource_loader.cpp:261
#29 0x00000000099e524c in ResourceLoader::_thread_load_function (p_userdata=0x7f8724082c78) at ./core/io/resource_loader.cpp:319
#30 0x00000000099e5e91 in ResourceLoader::_load_start (p_path=..., p_type_hint=..., p_thread_mode=ResourceLoader::LOAD_THREAD_FROM_CURRENT, p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE) at ./core/io/resource_loader.cpp:498
#31 0x00000000088c7ea5 in ResourceLoaderText::load (this=0x7f8735ff6880) at ./scene/resources/resource_format_text.cpp:467
#32 0x00000000088d3afd in ResourceFormatLoaderText::load (this=0xcbfcf00, p_path=..., p_original_path=..., r_error=0x7f8724081bac, p_use_sub_threads=false, r_progress=0x7f8724081ba0, p_cache_mode=ResourceFormatLoader::CACHE_MODE_IGNORE) at ./scene/resources/resource_format_text.cpp:1651
#33 0x00000000099e4b2d in ResourceLoader::_load (p_path=..., p_original_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_IGNORE, r_error=0x7f8724081bac, p_use_sub_threads=false, r_progress=0x7f8724081ba0) at ./core/io/resource_loader.cpp:261
#34 0x00000000099e524c in ResourceLoader::_thread_load_function (p_userdata=0x7f8724081b58) at ./core/io/resource_loader.cpp:319
#35 0x00000000099e5e91 in ResourceLoader::_load_start (p_path=..., p_type_hint=..., p_thread_mode=ResourceLoader::LOAD_THREAD_FROM_CURRENT, p_cache_mode=ResourceFormatLoader::CACHE_MODE_IGNORE) at ./core/io/resource_loader.cpp:498
#36 0x00000000099e5989 in ResourceLoader::load (p_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_IGNORE, r_error=0x0) at ./core/io/resource_loader.cpp:415
#37 0x0000000008882dc7 in PackedScene::reload_from_file (this=0x7f872506c4c0) at ./scene/resources/packed_scene.cpp:1921
#38 0x0000000005f93bd2 in GDScriptCache::get_packed_scene (p_path=..., r_error=@0x7f8735ff8fa4: OK, p_owner=...) at ./modules/gdscript/gdscript_cache.cpp:395
#39 0x0000000005f82225 in GDScriptAnalyzer::reduce_preload (this=0x7f8735ffab60, p_preload=0x7f87245c0620) at ./modules/gdscript/gdscript_analyzer.cpp:4158
#40 0x0000000005f76db4 in GDScriptAnalyzer::reduce_expression (this=0x7f8735ffab60, p_expression=0x7f87245c0620, p_is_root=false) at ./modules/gdscript/gdscript_analyzer.cpp:2466
#41 0x0000000005f7352c in GDScriptAnalyzer::resolve_assignable (this=0x7f8735ffab60, p_assignable=0x7f872419e830, p_kind=0x3bb7d02 "constant") at ./modules/gdscript/gdscript_analyzer.cpp:1890
#42 0x0000000005f741ee in GDScriptAnalyzer::resolve_constant (this=0x7f8735ffab60, p_constant=0x7f872419e830, p_is_local=false) at ./modules/gdscript/gdscript_analyzer.cpp:2003
#43 0x0000000005f6e03b in GDScriptAnalyzer::resolve_class_member (this=0x7f8735ffab60, p_class=0x7f87254d3a00, p_index=0, p_source=0x7f872419e830) at ./modules/gdscript/gdscript_analyzer.cpp:983
#44 0x0000000005f6f478 in GDScriptAnalyzer::resolve_class_interface (this=0x7f8735ffab60, p_class=0x7f87254d3a00, p_source=0x7f87254d3a00) at ./modules/gdscript/gdscript_analyzer.cpp:1185
#45 0x0000000005f6f649 in GDScriptAnalyzer::resolve_class_interface (this=0x7f8735ffab60, p_class=0x7f87254d3a00, p_recursive=true) at ./modules/gdscript/gdscript_analyzer.cpp:1213
#46 0x0000000005f89d03 in GDScriptAnalyzer::resolve_interface (this=0x7f8735ffab60) at ./modules/gdscript/gdscript_analyzer.cpp:5534
#47 0x0000000005f89f43 in GDScriptAnalyzer::analyze (this=0x7f8735ffab60) at ./modules/gdscript/gdscript_analyzer.cpp:5569
#48 0x0000000005f5a970 in GDScript::reload (this=0x7f8724016c00, p_keep_state=true) at ./modules/gdscript/gdscript.cpp:753
#49 0x0000000005f933ce in GDScriptCache::get_full_script (p_path=..., r_error=@0x7f8735ffb10c: OK, p_owner=..., p_update_from_disk=false) at ./modules/gdscript/gdscript_cache.cpp:303
#50 0x0000000005f66dcf in ResourceFormatLoaderGDScript::load (this=0xc35cb30, p_path=..., p_original_path=..., r_error=0x7f872452546c, p_use_sub_threads=false, r_progress=0x7f8724525460, p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE) at ./modules/gdscript/gdscript.cpp:2699
#51 0x00000000099e4b2d in ResourceLoader::_load (p_path=..., p_original_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE, r_error=0x7f872452546c, p_use_sub_threads=false, r_progress=0x7f8724525460) at ./core/io/resource_loader.cpp:261
#52 0x00000000099e524c in ResourceLoader::_thread_load_function (p_userdata=0x7f8724525418) at ./core/io/resource_loader.cpp:319
#53 0x00000000099e5e91 in ResourceLoader::_load_start (p_path=..., p_type_hint=..., p_thread_mode=ResourceLoader::LOAD_THREAD_FROM_CURRENT, p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE) at ./core/io/resource_loader.cpp:498
#54 0x00000000099e5989 in ResourceLoader::load (p_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE, r_error=0x0) at ./core/io/resource_loader.cpp:415
#55 0x000000000745b0ff in EditorResourcePreviewGenerator::generate_from_path (this=0x1d32d870, p_path=..., p_size=..., p_metadata=...) at ./editor/editor_resource_preview.cpp:68
#56 0x000000000745bd1e in EditorResourcePreview::_generate_preview (this=0xf3560f0, r_texture=..., r_small_texture=..., p_item=..., cache_base=..., p_metadata=...) at ./editor/editor_resource_preview.cpp:159
#57 0x000000000745ca9a in EditorResourcePreview::_iterate (this=0xf3560f0) at ./editor/editor_resource_preview.cpp:250
#58 0x000000000745d528 in EditorResourcePreview::_thread (this=0xf3560f0) at ./editor/editor_resource_preview.cpp:337
#59 0x000000000745b6bc in EditorResourcePreview::_thread_func (ud=0xf3560f0) at ./editor/editor_resource_preview.cpp:102
#60 0x00000000098d89ae in Thread::callback (p_caller_id=23, p_settings=..., p_callback=0x745b69c <EditorResourcePreview::_thread_func(void*)>, p_userdata=0xf3560f0) at ./core/os/thread.cpp:61
#61 0x00000000098eb6f9 in std::__invoke_impl<void, void (*)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long, Thread::Settings, void (*)(void*), void*> (__f=@0x21144868: 0x98d8920 <Thread::callback(unsigned long, Thread::Settings const&, void (*)(void*), void*)>) at /usr/include/c++/12/bits/invoke.h:61
#62 0x00000000098eb5c2 in std::__invoke<void (*)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long, Thread::Settings, void (*)(void*), void*> (__fn=@0x21144868: 0x98d8920 <Thread::callback(unsigned long, Thread::Settings const&, void (*)(void*), void*)>) at /usr/include/c++/12/bits/invoke.h:96
#63 0x00000000098eb47d in std::thread::_Invoker<std::tuple<void (*)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long, Thread::Settings, void (*)(void*), void*> >::_M_invoke<0ul, 1ul, 2ul, 3ul, 4ul> (this=0x21144848) at /usr/include/c++/12/bits/std_thread.h:279
#64 0x00000000098e9d50 in std::thread::_Invoker<std::tuple<void (*)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long, Thread::Settings, void (*)(void*), void*> >::operator() (this=0x21144848) at /usr/include/c++/12/bits/std_thread.h:286
#65 0x00000000098e8c02 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long, Thread::Settings, void (*)(void*), void*> > >::_M_run (this=0x21144840) at /usr/include/c++/12/bits/std_thread.h:231
#66 0x000000000a2b9193 in std::execute_native_thread_routine (__p=0x21144840) at ../../../../../libstdc++-v3/src/c++11/thread.cc:82
#67 0x00007f87a55618da in start_thread () from /lib64/libc.so.6
#68 0x00007f87a55dd48c in clone3 () from /lib64/libc.so.6

To reproduce this consistently, these are clearer steps:

Prepare two self-contained versions of Godot, one is 4.1.3, one is 4.2-beta (latest master):

$ find godots
godots
godots/4.1.3-stable_sc
godots/4.1.3-stable_sc/._sc_
godots/4.1.3-stable_sc/Godot_v4.1.3-stable_linux.x86_64
godots/4.2-beta_sc
godots/4.2-beta_sc/._sc_
godots/4.2-beta_sc/godot.linuxbsd.editor.dev.x86_64

Clean everything in the TPS demo (no git changes, no .godot folder)
Edit the project with godots/4.1.3-stable_sc/Godot_v4.1.3-stable_linux.x86_64 -e, let it import everything
This generates the .godot folder in the TPS demo, and a bunch of editor data within the self-contained 4.1.3-stable_sc/editor_data folder
Edit the project with godots/4.2-beta_sc/godot.linuxbsd.editor.dev.x86_64 -e, see the deadlock

Not the good way to go probably, but we're seeing more than one "regression" on imported files in the .godot folder. Would it make sense to force a full reimport upon minor release?

@QbieShay Do you have specific issues in mind? Because this one is not about imported assets. It's about threading issues in the resource preview generator, something that we unfortunately always had. A full reimport doesn't help, not directly at least. You may offset timing of some things and "fix" the issue, but this doesn't really address the problem at its core.


Fix GFM link in README.md

Fixes the GFM link on the main README. The title/url are reversed.

Thanks @sehrope


Not available in Logseq v0.7.2

https://github.com/logseq/logseq/issues/5605#issuecomment-1149507079
This is a logseq bug and has been fixed in the new nightly version


Hugo website - Problems on Nodes page

This issue is to track problems on the Concepts -> Kubernetes Architecture -> Nodes page.
https://k8sio-hugo-migration.netlify.com/docs/concepts/architecture/nodes/#manual-node-administration

[ ] Feature Request
[X] Bug Report

Problem:
Bad links

kube-controller-manager
Node API object

Broken links in the site:
"If the Status of the Ready condition is “Unknown” or “False” for longer than the pod-eviction-timeout, an argument is passed to the kube-controller-manager"

The kube-controller-manager and Node API object links are working now.
https://kubernetes.io/docs/concepts/architecture/nodes/


dates as datatype?

obviously i can simulate it as an integer representing seconds since the epoch or something similar, but first-class support would be nice.

We've added Timestamps to 1.6.  They are available here:  http://hyperdex.org/doc/latest/DataTypes/#x7-450008
The user is repsonsible for converting from/to the appropriate time zones.


Refactor commands to be modular

Currently it's a giant match in one file
Make it so each command (or a closely related group like blacklist mgmt) is in its own file and registered to the main handler.
This would allow the help to be generated programmatically instead of being hardcoded.

Also would allow commands to call each other's logic, i.e. set_pins_channel can call blacklist instead of repeating the logic


perf(types): use homomorphic mapped type to reduce conditional branches

…anches
The author should do the following, if applicable

[ ] Add tests
[x] Run tests
[x] bun run format:fix && bun run lint:fix to format the code
[ ] Add TSDoc/JSDoc to document the code

Reduced conditional branches by using homomorphic mapped type.
The number of type instantiation has dropped a bit and the definition became simpler than before
FYI

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-1.html#mapped-types-on-tuples-and-arrays
https://andreasimonecosta.dev/posts/what-the-heck-is-a-homomorphic-mapped-type/

@m-shaka
Good improvement. Thanks!


proto: Add PATCH method to RequestMethod enum

Description: Add PATCH method to protobuf so that ALS can receive and log it properly
Risk Level: Low
Testing: None
Docs Changes: -
Release Notes: -
Fixes #6694

The change looks good. I'm wondering if we can solidify this by adding a test. @junr03 thoughts?

Yes, it would be good. Couldn't think of appropriate place to test it though, will be glad to hear suggestions.

@glebmish somewhere under https://github.com/envoyproxy/envoy/blob/master/test/common/access_log/?

@glebmish somewhere under https://github.com/envoyproxy/envoy/blob/master/test/common/access_log/?

will it be tested there? @junr03 said that text logs work without proto so it seems that tests for access_log will work anyway. It probably makes sense to test the part that works with proto to make sure it really works.
Or do this tests actually work with proto and I'm missing something here?

I think @venilnoronha linked for inspiration, not necessarily suggesting that the test would be written there. Yes, those tests are not for the ALS, they are for text logs. I haven't looked closely at the test suite for the ALS, let me know if you'd like me to take a look for guidance.

Added test similar to the part below that checks METHOD_UNSPECIFIED
However, I see that in the part below "request_headers" is initialized but not passed to access_log_->log (nullptr is passed instead). And when I modified it to pass headers, new field "request_headers_bytes" appeared in the result and test failed. I guess it just doesn't work correctly right now, what do you think?

@glebmish what if:
Create a void expectLogRequestMethod(const std::string& request_method) as a member method of HttpGrpcAccessLogTest class and have a TEST_F e.g.
TEST_F(HttpGrpcAccessLogTest, LogWithRequestMethod) {
  InSequence s;
  expectLogRequestMethod("GET");
  expectLogRequestMethod("HEAD");
  expectLogRequestMethod("POST");
  expectLogRequestMethod("PUT");
  expectLogRequestMethod("DELETE");
  expectLogRequestMethod("CONNECT");
  expectLogRequestMethod("OPTIONS");
  expectLogRequestMethod("TRACE");
  expectLogRequestMethod("PATCH");
}

The body of expectLogRequestMethod skeleton surely can be as simple as:
    NiceMock<StreamInfo::MockStreamInfo> stream_info;
    stream_info.host_ = nullptr;

    Http::TestHeaderMapImpl request_headers{
        {":scheme", "scheme_value"},
        {":authority", "authority_value"},
        {":path", "path_value"},
        {":method", request_method},
    };

    expectLog(fmt::format(R"EOF(
// !!!TODO: replace with the expected structured log here (yes in yaml format). The `fmt::format` helps you to build the string. hint: {} as placeholder, while {{}} to escape.
)EOF",
                          request_method, /* more parameters here, hint: related to `request_headers_bytes` */ ));
    access_log_->log(&request_headers, nullptr, nullptr, stream_info);

@dio it looks good, I can do that.
Do you think it also make sense to move METHOD_UNSPECIFIED there? Something like expectLogRequestUnspecifiedMethod("WHACKADOO"); which is basically the same method but checks that result is METHOD_UNSPECIFIED.
If you think it make sense, can you please explain the difference between two tests that check METHOD_UNSPECIFIED? One of them seems more complicated but it's not clear for me why two separate tests are needed there

You can be as creative as you want 😄.

can you please explain the difference between two tests that check METHOD_UNSPECIFIED?

I think those two tests check different things i.e. the second one checks on marshaling tls_properties.

@dio added changes you proposed, thanks! Decided to leave METHOD_UNSPECIFIED tests as it is, just fixed them there.

I see failed test suites, but I can't understand the reason. Can somebody help me with this?

@glebmish I think you need to run the formatter. In this case against this file: test/extensions/access_loggers/http_grpc/grpc_access_log_impl_test.cc.
$ ./tools/check_format.py fix test/extensions/access_loggers/http_grpc/grpc_access_log_impl_test.cc

And add and commit that.

@dio thank you! fixed

I see that coverage suite is failing with exit code 36. I took a look on bazel exit codes and it seems like it some environment issue, I guess some process is not stopping correctly. What can I do about it?
https://docs.bazel.build/versions/master/guide.html

36 - Local Environmental Issue, suspected permanent.

/retest

Well, it doesn't seem to be healed by restart :(
And the only error I see is

FATAL: Attempted to kill stale server process (pid=83) using SIGKILL, but it did not die in a timely fashion.
Did you see this in other PRs? If it's something with environment it should probably fail everywhere

@glebmish hum, while investigating the build errors, would you mind to merge master?

@dio it definitely helped, thanks! Now I understand what's the problem there, coverage is less than threshold. This is funny, I added 1 line of code and several tests and somehow decreased coverage :)

thanks @mattklein123 !


No -x bit on flashall.sh for Intel Edison

flashall.sh from resin.io is not executable (no -x bit), but our official docs on the download page say to run "sudo ./flashall.sh". Probably using "install" instead of "cp" in meta-resin-edison/recipes-core/edison-dfu/edison-dfu_1.0.bb will do the trick.

#connect https://github.com/resin-os/resin-edison/pull/74


Unable to set OpenVPN Client config protocol to TCP via UI

Hello,
I'm trying out the stack here but seem to have run into a small bug. For some reason I'm unable to change the OpenVPN client protocol to TCP via the UI.
After changing "Proto" to "tcp" and clicking the Save Config button, the client.conf always retains "udp".   If I manually edit the client.conf file to "tcp" I don't see the change updated in the UI form for Proto even after a container re-start/re-create.
Changing other parameters for for the client config seem to work and save properly (address, port, etc)
Thanks!

Hi James,
Indeed it looks like a bug, thanks for the reporting.
Could you let me know which openvpn-server and openvpn-ui images do you use and for which arch:
hiphopapapa@chapa:~ $ docker ps
CONTAINER ID   IMAGE                          COMMAND                  CREATED      STATUS        PORTS                    NAMES
cdcc47e4d7ea   d3vilh/openvpn-server:latest   "/bin/sh -c ./docker…"   6 days ago   Up 20 hours   <IP_ADDRESS>:1194->1194/udp   openvpn
572b4c4cd071   d3vilh/openvpn-ui:latest       "/bin/sh -c /opt/sta…"   6 days ago   Up 20 hours   <IP_ADDRESS>:8080->8080/tcp   openvpn-ui
hiphopapapa@chapa:~ $ docker inspect --format='{{json .Config.Labels}}' d3vilh/openvpn-ui:latest
{"maintainer":"Mr.Philipp <d3vilh@github.com>","version":"<IP_ADDRESS>"}
hiphopapapa@chapa:~ $ docker inspect --format='{{json .Config.Labels}}' d3vilh/openvpn-server:latest
{"maintainer":"Mr.Philipp <d3vilh@github.com>","version":"0.5.3"}
hiphopapapa@chapa:~ $ uname -a
Linux chapa 6.6.30-v8+ #1761 SMP PREEMPT Thu May  2 16:54:52 BST 2024 aarch64 GNU/Linux

Meanwhile I'll try to reproduce it on my arm64 test system.

Sure..  I'm running the "latest" tag for openvpn-server and openvpn-ui.  It's on a x86_64 install at Linode (Ubuntu 24).

Confirmed, as a bug, let me fix it.

@Codelica fixed in <IP_ADDRESS>.
All Docker hub images rebuild (except armv61, as Google did not build golang 1.22.3 images yet, for this legacy arch).
Thank you for the reporting!


Allow raw /rmeta output

The parse option uses /rmeta and then conflates all the keys together so that users can't tell which metadata goes with the primary file and which metadata goes with which embedded file.
Would it be possible to warn users of the current behavior and offer an option to get the raw json from the /rmeta endpoint?

will test/evaluate as part of the next release (not 1.24.2 which I will release today but ) 2.6.x which I will release next week.

Fixed in https://github.com/chrismattmann/tika-python/commit/ca2a692193307feec4277142f88fd1afd819f140


Unmapped exceptions resulting in SEHException in C#

To reproduce:
Move schemas folder so that MALMO_XSD_PATH is wrong.
Open the C# sample run_mission project.
Attempt to use the xml construction for MissionSpec, eg:
MissionSpec mission = new MissionSpec();
string xml = mission.getAsXML(false);
MissionSpec mission2 = new MissionSpec(xml, true);

Malmo will throw an exception somewhere, but the user will only see a generally unhelpful SEHException.

Fixed by a5fe2a9


Make it possible to pick nested objects

Hello @acdlite, in pick it is not possible to get nested objects.
I tend to namespace the actions and state wrapped by connect.
So a stateless component could receive props shape like this:
{
  state: {
    container1: { ... },
    container2: { ... }
  },
  actions: {
    container1: { ... },
    container2: { ... }
  }
}

// ...

// this wont work, because you cannot select nested objects with the current implementation of `pick`
onlyUpdateForKeys(['actions.todos', 'state.todos'])(App);

Please read https://github.com/acdlite/recompose/issues/166
As mostly this issue is a duplicate.

As @istarkov says, this is a duplicate of #166.


Partially outdated tutorial

Screenshots are very old (Excercise 1, 2, 3), the tutorial is probably written originally for Azure Functions v1

If the function.json is not removed from the output directory, then the runtime throws an error - this is the case in Excercise 5:
The 'Adder' function is in error: Configuration error: all functions in /Users/xxxx/Projects/tmp-local/SolutionName/ProjectName/bin/Debug/netcoreapp3.1/bin/ProjectName.dll must have the same value for 'configurationSource'.

Excercise 5 / Step 2: the return attribute cannot be applied, because the nuget package Microsoft.Azure.WebJobs.Extensions.Storage (4.0.5) or Microsoft.Azure.WebJobs.Extensions.Tables need to be added.
[return: Table("Results")]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7374155f-a387-9625-bc29-c38fd0c35bae
Version Independent ID: dc64e04a-b1cf-3334-a5cc-65db6986f72a
Content: Tutorial: Azure Functions & Visual Studio for Mac - Visual Studio for Mac
Content Source: mac/azure-functions-lab.md
Product: visual-studio-mac
Technology: vs-ide-install
GitHub Login: @jmatthiesen
Microsoft Alias: jomatthi

@StrictLine -- Miklos, thank you for your well-researched feedback.  Please consider these resources:

Visual Studio on Microsoft Q&A
Visual Studio MSDN Forum
Stack Overflow
Reddit

@jmatthiesen -- Jordan, please look into this issue.


Image Upload not working properly

Thanks for this wonderful editor.
I am struggling with the imageUpload function.
For test purposes, I have 1 simple method in my imageUploadController:
public function upload(Request $request)
{
    //ignore the request, just return a test image that exists on the server

    return response()->json(['result' => ['url' => '/images/test.jpg', 'name' => 'test.jpg', 'size' => '10000']]);
}

The image exists on my server.
However, when I use the imageUploadDialog and select a random image file on my computer, I expect that the json above will be returned. That's the case. This is the result:
{"result":{"url":"\/images\/test.jpg","name":"test.jpg","size":"10000"}}

The mediaUploadUrl also returns a 200 OK status, but the image is not showing up in my editor.
What am I missing here?

@TutanRamon result is must be array type.
{"result":["url":"\/images\/test.jpg","name":"test.jpg","size":"10000"]}

@JiHong88 Unbelievable :-)
Thanks for the prompt reply. It's working now.
Can you also update your answer @ https://github.com/JiHong88/SunEditor/issues/369#issuecomment-626702667

@TutanRamon I didn't write that comment.🤣

@JiHong88 Haha, sorry. Thanks again for the help.


5.0 release plan

This is the current plan for 5.0 release:

[ ] switch to JupyterLab's 4.0 @jupyterlab/lsp package
[ ] turn on more eslint rules, including camelCase #47
[ ] split up features into packages https://github.com/jupyter-lsp/jupyterlab-lsp/issues/76
[ ] add a scaffold for new features:

[ ] symbol navigation (sidebar panel, + modal) https://github.com/jupyter-lsp/jupyterlab-lsp/issues/43
[ ] code actions and commands (#676)

[ ] typdoc documentation

If time permits:

[ ] multiple language servers per document (will close https://github.com/jupyter-lsp/jupyterlab-lsp/issues/437)
[ ] https://github.com/jupyter-lsp/jupyterlab-lsp/issues/681

Is there a timeline for jupyterlab-lsp 5.0 release?

There is no timeline yet - it may depend on community contributions.

Jupyterlab V4.0.2 is released. Looking forward to V4 support.

Could you prioritize " switch to JupyterLab's 4.0 @jupyterlab/lsp package", maybe add other features as time permits?

I am working on JupyterLab 4.0 support; it requires a substantial rewrite due to a different editor (CodeMirror 6), the @jupyterlab/lsp package which does not know about things, and virtual notebook. I will probably share some version for testing before 5.0 release so that anyone who is impatient can try it out and report bugs, while other things on agenda get addressed (but yes, we can push some things to next release).

First pre-release supporting JupyterLab 4.0 is now available: v5.0.0a0. There is a number of known issues, including many around completer, which will need fixing upstream and require a new JupyterLab release.

First beta is out: v5.0.0b0. Please report any bugs you see, this will help accelerate the final release.

Have started https://github.com/conda-forge/jupyter-lsp-feedstock/pull/50
Some packaging thoughts:

we could look to use some of the approaches from e.g. bqplot to avoid shipping duplicate copies of the labextension static files in the .whl

a major release might be an appropriate time to adopt flit or hatch

we could go further and consider dropping the .js.map files from the .whl

have considered some patterns in conda-land to do split packages, e.g. jupyterlab-lsp-with-sourcemaps

this could theoretically be done in the .whl level, too, but would be... more complicated

Also, perhaps an npm 5.0.0-beta.0 release would be useful for downstreams to start kicking tires?

Tried kicking all the future tires with this gist on binder:
I had the 4.1.0 alpha in there, but it didn't like it:
Unsatisfied version 4.1.0-alpha.1 from @jupyterlab/application-top of shared singleton module @jupyterlab/lsp (required ^4.0.5)

At least during the pre-release cycle, we should probably allow that case...

Lots of other weirdness underway... maybe we try to carve out some time after the wednesday call to take a look at some things.

This is because of strictVersion in:
https://github.com/jupyter-lsp/jupyterlab-lsp/blob/98a8794f1d6fa2205f57abb7628b66dfd9d7983a/packages/jupyterlab-lsp/package.json#L150-L156
I will disable it for 5.0.0b1.

npm 5.0.0-beta.0 release

this will need bumping version and somewhat stabilising APIs. I am still somewhat tempted to break up features into packages but it is becoming increasingly less likely without resources and with other more pressing deadlines. Anyways, once the completer issues are fixed upstream (and if there are no further issues found in beta1) I think we can publish an RC with npm packages.

Once https://github.com/jupyter-lsp/jupyterlab-lsp/pull/978 is in, the only remaining blocker for RC will be upstream JupyterLab completer work, which had 1 PR merged, 1 in review, and 1 in the works; if we are lucky this could happen in the upcoming week.
This is was the most difficult version transition so far, with many things subtly breaking due to the way the core LSP was merged into JupyterLab. I am glad this is nearly over.

Is it possible to install 5.0.0b1 (or any other pre-release) from repo itself? pip still have only released version. Thanks.

pip still have only released version.

No, it does not: https://pypi.org/project/jupyterlab-lsp/5.0.0b1/ use -U --pre switches to install latest pre-release. A release candidate is likely to show up by Monday.

Also available on conda-forge:
mamba install -c conda-forge/label/jupyter_lsp_beta -c conda-forge jupyterlab-lsp
# stuff happens ...
# + jupyterlab-lsp                      5.0.0b0  pyhe83ca6f_0        conda-forge/label/jupyter_lsp_beta/noarch      568kB

Release candidate is up:

https://pypi.org/project/jupyterlab-lsp/5.0.0rc0/
<EMAIL_ADDRESS>
If nothing major comes up I will publish the final release one week from this moment.

Note: a release blocker has been identified (crash of the browser on editing of large notebooks with magic transculsions, like %%sql due to memory/websocket leak - https://github.com/jupyter-lsp/jupyterlab-lsp/issues/988) which is why there was no final release early this week. This is related to the transition of LSP machinery to core JupyterLab chopping off an implicit cache mechanism of webocket connections, see #959. The upstream issues are:

https://github.com/jupyterlab/jupyterlab/issues/15144
https://github.com/jupyterlab/jupyterlab/issues/15126

There may be a way to workaround it in jupyterlab-lsp by rewriting the update manager, but this defeats the purpose of migrating the code upstream for easier reuse, so ideally the fix would be applied upstream too. The best course of action would probably be developing a fix here and then applying it upstream for 4.1 release as it would likely extend API surface. This might take more time. CC @hbcarlos (for awareness).
Alternatively, we could release 5.0 without transculsions disabled by default. This would lead to worse UX but should avoid the crashes. What do you all think?

I've been using the rc for some time and works like a charm, maybe disable transculsions (what a word 😄)? But I'm not a user of those, so I don't have the complete picture

Since fixing magic transclusions is expected to take some time, I would advocate releasing 5.0 with magic transclusions turned off, and putting it on known regressions and 5.1/5.2 to-do lists. If the jupyterlab-lsp API is expected to be affected by this work (not sure if it will be), maybe put a warning in the docs that this area is WIP (although this may not be critical since the rest of the API docs may not have been updated per #962 anyway).

Note: a release blocker has been identified (crash of the browser on editing of large notebooks with magic transculsions, like %%sql due to memory/websocket leak - #988) which is why there was no final release early this week. This is related to the transition of LSP machinery to core JupyterLab chopping off an implicit cache mechanism of webocket connections, see #959. The upstream issues are:

Virtual document updates may lead to a memory leak jupyterlab/jupyterlab#15144
Problems extending virtual LSP documents downstream jupyterlab/jupyterlab#15126

There may be a way to workaround it in jupyterlab-lsp by rewriting the update manager, but this defeats the purpose of migrating the code upstream for easier reuse, so ideally the fix would be applied upstream too. The best course of action would probably be developing a fix here and then applying it upstream for 4.1 release as it would likely extend API surface. This might take more time. CC @hbcarlos (for awareness).
Alternatively, we could release 5.0 with transculsions disabled by default. This would lead to worse UX but should avoid the crashes. What do you all think?

We will put resources towards fixing this in the next couple of weeks, hopefully fixing the last outstanding issues.

Thank you so much @SylvainCorlay! Collaborating with your team on bringing this upstream is amazing and I am grateful for open communication.

If I were to do this again, I would have advocated on moving some features upstream immediately, because the approach that we mutually agreed on - of porting the core machinery to core and only then porting the extension - turned out to be painful because code was not integration tested along the way (but then there was also a moving piece of CodeMirror 6 so I understand that it would be difficult anyways).

I applied a workaround in the extension by force-overwriting a private method from upstream (@jupyterlab/lsp) for now and will release 5.0 with it, but hopefully this will not be needed for the next version :)

v5.0.0 is now available on npm and PyPI. Thank you all for testing and support!

also from conda-forge.


Turn restrictions are ignored

While testing the online version, I got a quite broken route: http://map.project-osrm.org/6G
All turn restrictions are mapped properly, but aren't taken into account.
Mapquest Open gets it right: http://mapq.st/shFaBv
Note: mapquest doesn't use the latest data, but the restriction relations should still be correct.

seems to be a problem in the latest dev version too.
my speedprofile (bicycle routing) include "useRestrictions = yes", and during extraction (copenhagen area) i see: "[info extractor.cpp:292] usable restrictions: 32"
yet during contraction i see "[info Contractor/EdgeBasedGraphFactory.cpp:241] Edge-based graph obeys 0 turn restrictions, 0 skipped", which seems to indicate that the restrictions file is empty. but in fact the size of the file is 516 bytes.

added some (failing) cucumber tests for turn restrictions: https://github.com/emiltin/Project-OSRM/commit/65036a1f7fe54fe0f775136cfecdb50573f0d191

The demo is running on old data. Once this is running on a recent extract the turn restrictions show up.

but i seem to have the same problem even with the latest version and newly extracted data?

i'm not sure i understand quite what you mean. an example is
http://www.openstreetmap.org/?lat=55.664213&lon=12.549544&zoom=18&layers=M
going south on Sigerstedgade, you're not allowed to turn left. the restriction is present in the osm data. as i wrote above, the extractor reports some restrictions, but the contractor says 0 restrictions. and osrm allows be to turn left, even though it should be forbidden.

latest version seem to work!
~/code/Project-OSRM$ cucumber --tags @restrictions
@routing @restrictions
Feature: Turn restrictions
OSRM should handle turn restrictions
Scenario: No left turn when crossing a oneway street                                            # features/restrictions.feature:5
When I request a route from 55.689741159238,12.574720202639 to 55.689741159232,12.57455927015 # features/step_definitions/routing.rb:9
Then I should get a route                                                                     # features/step_definitions/routing.rb:60
And the route should start at "Sølvgade"                                                      # features/step_definitions/routing.rb:70
And the route should end at "Øster Farimagsgade"                                              # features/step_definitions/routing.rb:74
And the route should not include "Sølvgade, Øster Farimagsgade"                               # features/step_definitions/routing.rb:128
And no error should be reported in terminal                                                   # features/step_definitions/launch.rb:76
Scenario: No left turn at T-junction: Don't turn left from side road into main road           # features/restrictions.feature:13
When I request a route from 55.66442995717,12.549384056343 to 55.664218154805,12.5502638209 # features/step_definitions/routing.rb:9
Then I should get a route                                                                   # features/step_definitions/routing.rb:60
And the route should start at "Sigerstedgade"                                               # features/step_definitions/routing.rb:70
And the route should end at "Ingerslevsgade"                                                # features/step_definitions/routing.rb:74
And the route should not include "Sigerstedgade, Ingerslevsgade"                            # features/step_definitions/routing.rb:128
And there should be more than 1 turn                                                        # features/step_definitions/routing.rb:100
Scenario: No left turn at T-junction: OK to turn right from side road into main road            # features/restrictions.feature:21
When I request a route from 55.66442995717,12.549384056343 to 55.664060815164,12.548944174065 # features/step_definitions/routing.rb:9
Then I should get a route                                                                     # features/step_definitions/routing.rb:60
And the route should start at "Sigerstedgade"                                                 # features/step_definitions/routing.rb:70
And the route should end at "Ingerslevsgade"                                                  # features/step_definitions/routing.rb:74
And the route should include "Sigerstedgade, Ingerslevsgade"                                  # features/step_definitions/routing.rb:124
And there should be 1 turn                                                                    # features/step_definitions/routing.rb:92
Scenario: No left turn at T-junction: OK to go straight on main road                            # features/restrictions.feature:29
When I request a route from 55.66419092299,12.550333558335 to 55.664060815164,12.548944174065 # features/step_definitions/routing.rb:9
Then I should get a route                                                                     # features/step_definitions/routing.rb:60
And the route should stay on "Ingerslevsgade"                                                 # features/step_definitions/routing.rb:132
Scenario: No left turn at T-junction: OK to turn right from main road into side road            # features/restrictions.feature:34
When I request a route from 55.664060815164,12.548944174065 to 55.66442995717,12.549384056343 # features/step_definitions/routing.rb:9
Then I should get a route                                                                     # features/step_definitions/routing.rb:60
And the route should start at "Ingerslevsgade"                                                # features/step_definitions/routing.rb:70
And the route should end at "Sigerstedgade"                                                   # features/step_definitions/routing.rb:74
And the route should include "Ingerslevsgade, Sigerstedgade"                                  # features/step_definitions/routing.rb:124
And there should be 1 turn                                                                    # features/step_definitions/routing.rb:92
Scenario: No left turn at T-junction: OK to turn left from main road into side road           # features/restrictions.feature:42
When I request a route from 55.664218154805,12.5502638209 to 55.66442995717,12.549384056343 # features/step_definitions/routing.rb:9
Then I should get a route                                                                   # features/step_definitions/routing.rb:60
And the route should start at "Ingerslevsgade"                                              # features/step_definitions/routing.rb:70
And the route should end at "Sigerstedgade"                                                 # features/step_definitions/routing.rb:74
And the route should include "Ingerslevsgade, Sigerstedgade"                                # features/step_definitions/routing.rb:124
And there should be 1 turn                                                                  # features/step_definitions/routing.rb:92
6 scenarios (6 passed)
33 steps (33 passed)
0m0.058s

Thanks for the feedback.


PPA/deb package out of date

Hello,
It seems that there are no recent builds of VSCode.
https://packages.microsoft.com/repos/vscode/pool/main/c/code-insiders/
They stopped like a week ago. Is it intended?
Cheers,
Furai

Thanks for the report, we're investigating.

Started working again. An internal certificate didn’t verify.

It worked for me and then stopped again.

@rajinder-yadav code-insiders_1.30.0-1544221759_amd64.deb i the latest insiders build and it is listed in our repository: https://packages.microsoft.com/repos/vscode/pool/main/c/code-insiders
What do you get for apt-cache policy code-insiders | head?


Support multiple layers of interactivity for Leaflet

Kind of annoying, but it makes a lot of sense to do it.

Is there any guidelines on how to achieve this functionality. I need to draw polylines and circles on a map, but obviously it's impossible because of the lack of multilayer support.


Create Concept Doc re: Speech Recognition Idea

Find open-source solutions that can recognize speech and confirm if children are reading as they should.

Good idea to consider. Opportunity for us to document / outline the general case (we are exploring what is possible out there and found smthg that doesn't exist and looks possible, can add value)
Next steps:

Concept Note that explains tech, use case, value, target audience, resources/internal teams (e.g. unicef intl learning division)

user need validation required
tech validation required

Have reached out to some ed contacts - but waiting to hear from them!

No longer pursuing this idea. Will close this ticket.


Basically Make Website Using Any kind of device but protected and basically one more thing all people try to get a job like IT and securing help them as much you do they will appreciate you

What should we add or change to make your life better?
Why is this important to you?

Spam, closing. Account @abhishekisforyou reported to GH as spam.

Spam, closing. Account @abhishekisforyou reported to GH as spam.


Bottlerocket consumer updater ops tool

Issue #, if available:
Description of changes:
Adds a consumer updater for bottlerocket -- currently just ported over from the existing upater, and uses the local path. We will move this to use in-memory git later
Add a manifest fetcher to the EKS Distro release object in the Ops tool. This makes use of the Release types defined in cmd/release to marshal the Release Manifest JSON into a Go struct and make it available via the Release object.
This can be used to fetch an existing release manifest for a given EKS D version; the functionality will be used in a follow-on PR to determine wether or not we need to invoke the BottleRocket Updater, based on the SHA of the K8s src manifest compared to the SHA in the BR source.
Much of this is based on the work by @kschumy for the bottlerocket updater
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


BmLocalSearch的location属性怎么根据坐标来poi

Auto closed by issues bot. Please create your issue by issue generator.
当前问题由机器人自动关闭，请使用 ISSUE 生成器提交您的问题。


Failed to authenticate token/Token disappearing.

I'm using jwt along with a few other packages, including mongo for user data storage, to create an API, and have encountered what I believe is a bug, although I'm not sure if it's an error on my part. I've created a token for myself about half an hour ago, with this code. https://hastebin.com/umujaterox.js
A few minutes ago when I went to test an endpoint of the API that I'd like to restrict to certain tokens, it fails to authenticate my token, which is what I find weird. Code is https://hastebin.com/ewovodukuw.js.
My endpoint to create a token works just fine, and generates what I assume is a completely valid token, until it doesn't work. If y'all could let me know if this is an issue with my code or an issue with the package, that'd be great.

I ran into the same problem and found the reason.
When you use the numeric value in "expiresIn", it is considered as milliseconds, rather than seconds.
So in your case:
     const token = jwt.sign ({id: user._id}, config.secret, {
       expiresIn: 86400
     });

"expiresIn" is not 1d, but 86400ms / 1000 = 86.4s

Oh, well that stinks. Thanks for letting me know though!

@ziluvatar It does happen when it's a number, as can be seen with my original code, and the snippet that they provided.

When I use a number, it adds 1000 seconds as expected.
> jwt.decode(jwt.sign ({id: 1}, 'aa', { expiresIn: 1000 }));
{ id: 1, iat:<PHONE_NUMBER>, exp:<PHONE_NUMBER> }

When I use a string it adds 1 second (1000 milliseconds) which is the confusing part.
> jwt.decode(jwt.sign ({id: 1}, 'aa', { expiresIn: '1000' }));
{ id: 1, iat:<PHONE_NUMBER>, exp:<PHONE_NUMBER> }

Is it different for you? (I can not see your original code anymore :( )

It was different for me, instead of it being measured in seconds, it was being measured in milliseconds. I don't have the original code myself anymore, as I've since pushed a couple commits to the repo.

I see, ok, well, let's clarify the one about string usage in the readme for now, if we found out the other scenario we can tackle it at that moment.
Thanks @OGNova 👍


Build failure: audio/torchaudio/csrc/decoder/src/decoder/Utils.h:23:40: error: ‘numeric_limits’ is not a member of ‘std’

🐛 Describe the bug
I encountered the following build error after cloning the master branch and attempting to build/install it using CC=gcc-11 CXX=g++-11 python setup.py install --user
[3/44] /usr/bin/g++-11 -DBUILD_CTC_DECODER -DHAVE_BZLIB -DHAVE_XZLIB -DHAVE_ZLIB -DINCLUDE_KALDI -DINCLUDE_SOX -DKENLM_MAX_ORDER=6 -DUSE_C10D_GLOO -DUSE_C10D_MPI -DUSE_C10D_NCCL -DUSE_CUDA -DUSE_DISTRIBUTED -DUSE_RPC -DUSE_TENSORPIPE -Dlibtorchaudio_decoder_EXPORTS -I/home/dkwan/Github/Builds/audio -I/home/dkwan/Github/Builds/audio/third_party/kenlm/submodule -I/home/dkwan/Github/Builds/audio/third_party/zlib/../install/include -I/home/dkwan/Github/Builds/audio/third_party/bzip2/../install/include -I/home/dkwan/Github/Builds/audio/third_party/lzma/../install/include -isystem /home/dkwan/.local/lib/python3.10/site-packages/torch/include -isystem /home/dkwan/.local/lib/python3.10/site-packages/torch/include/torch/csrc/api/include -isystem /opt/cuda/include -Wall -D_GLIBCXX_USE_CXX11_ABI=1 -O3 -DNDEBUG -fPIC -D_GLIBCXX_USE_CXX11_ABI=1 -std=gnu++14 -MD -MT torchaudio/csrc/CMakeFiles/libtorchaudio_decoder.dir/decoder/src/decoder/LexiconFreeDecoder.cpp.o -MF torchaudio/csrc/CMakeFiles/libtorchaudio_decoder.dir/decoder/src/decoder/LexiconFreeDecoder.cpp.o.d -o torchaudio/csrc/CMakeFiles/libtorchaudio_decoder.dir/decoder/src/decoder/LexiconFreeDecoder.cpp.o -c /home/dkwan/Github/Builds/audio/torchaudio/csrc/decoder/src/decoder/LexiconFreeDecoder.cpp
FAILED: torchaudio/csrc/CMakeFiles/libtorchaudio_decoder.dir/decoder/src/decoder/LexiconFreeDecoder.cpp.o
/usr/bin/g++-11 -DBUILD_CTC_DECODER -DHAVE_BZLIB -DHAVE_XZLIB -DHAVE_ZLIB -DINCLUDE_KALDI -DINCLUDE_SOX -DKENLM_MAX_ORDER=6 -DUSE_C10D_GLOO -DUSE_C10D_MPI -DUSE_C10D_NCCL -DUSE_CUDA -DUSE_DISTRIBUTED -DUSE_RPC -DUSE_TENSORPIPE -Dlibtorchaudio_decoder_EXPORTS -I/home/dkwan/Github/Builds/audio -I/home/dkwan/Github/Builds/audio/third_party/kenlm/submodule -I/home/dkwan/Github/Builds/audio/third_party/zlib/../install/include -I/home/dkwan/Github/Builds/audio/third_party/bzip2/../install/include -I/home/dkwan/Github/Builds/audio/third_party/lzma/../install/include -isystem /home/dkwan/.local/lib/python3.10/site-packages/torch/include -isystem /home/dkwan/.local/lib/python3.10/site-packages/torch/include/torch/csrc/api/include -isystem /opt/cuda/include -Wall -D_GLIBCXX_USE_CXX11_ABI=1 -O3 -DNDEBUG -fPIC -D_GLIBCXX_USE_CXX11_ABI=1 -std=gnu++14 -MD -MT torchaudio/csrc/CMakeFiles/libtorchaudio_decoder.dir/decoder/src/decoder/LexiconFreeDecoder.cpp.o -MF torchaudio/csrc/CMakeFiles/libtorchaudio_decoder.dir/decoder/src/decoder/LexiconFreeDecoder.cpp.o.d -o torchaudio/csrc/CMakeFiles/libtorchaudio_decoder.dir/decoder/src/decoder/LexiconFreeDecoder.cpp.o -c /home/dkwan/Github/Builds/audio/torchaudio/csrc/decoder/src/decoder/LexiconFreeDecoder.cpp
In file included from /home/dkwan/Github/Builds/audio/torchaudio/csrc/decoder/src/decoder/Decoder.h:10,
                 from /home/dkwan/Github/Builds/audio/torchaudio/csrc/decoder/src/decoder/LexiconFreeDecoder.h:12,
                 from /home/dkwan/Github/Builds/audio/torchaudio/csrc/decoder/src/decoder/LexiconFreeDecoder.cpp:14:
/home/dkwan/Github/Builds/audio/torchaudio/csrc/decoder/src/decoder/Utils.h:23:40: error: ‘numeric_limits’ is not a member of ‘std’
   23 | const double kNegativeInfinity = -std::numeric_limits<double>::infinity();
      |                                        ^~~~~~~~~~~~~~
/home/dkwan/Github/Builds/audio/torchaudio/csrc/decoder/src/decoder/Utils.h:23:55: error: expected primary-expression before ‘double’
   23 | const double kNegativeInfinity = -std::numeric_limits<double>::infinity();

It seems the problem is a missing #include <limits> import in the Utils.h file? I added this in and then I was able to build successfully.
Versions
(This was collected after a successful build after adding the seemingly missing #include line. Also note that my system default compiler is GCC 12, which I did not use as per the command I ran in the previous section)
Collecting environment information...
PyTorch version: 1.13.0a0+gitac8c6d0
Is debug build: False
CUDA used to build PyTorch: 11.6
ROCM used to build PyTorch: N/A

OS: EndeavourOS Linux (x86_64)
GCC version: (GCC) 12.1.0
Clang version: Could not collect
CMake version: version 3.23.2
Libc version: glibc-2.35

Python version: 3.10.4 (main, May 14 2022, 05:21:19) [GCC 12.1.0] (64-bit runtime)
Python platform: Linux-5.18.1-xanmod1-1-native_amd-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: 11.6.124
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3090
Nvidia driver version: 515.43.04
cuDNN version: Probably one of the following:
/usr/lib/libcudnn.so.8.4.0
/usr/lib/libcudnn_adv_infer.so.8.4.0
/usr/lib/libcudnn_adv_train.so.8.4.0
/usr/lib/libcudnn_cnn_infer.so.8.4.0
/usr/lib/libcudnn_cnn_train.so.8.4.0
/usr/lib/libcudnn_ops_infer.so.8.4.0
/usr/lib/libcudnn_ops_train.so.8.4.0
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] functorch==0.2.0a0+db12967
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.3
[pip3] torch==1.13.0a0+gitac8c6d0
[pip3] torchaudio==0.12.0a0+a63629b
[pip3] torchvision==0.14.0a0+c890a7e
[conda] Could not collect

Hi @kwand
Thanks for the report. This might be the cause.
@carolineechen Can we add this line? It seems hurmless fix.

Fixed upstream as well in https://github.com/flashlight/text/pull/5 — thanks for reporting, @kwand.


Unable to exclude add-ons

Hi there! First of all, thanks for a great add-on.
I am having some issues with the exclusion of some add-ons. When I navigate to the add-on configuration options, there is only a (empty) drop down list for add-ons to exclude. When I enter the add-on manually I cannot save the configuration.
Maybe this happened with a recent release of HA?
Thanks in advance!

Yes you are right. I see this behavior also on other addons which use lists in their configuration. Must have been caused by an update.
As a workaround for now you can switch to yaml mode and enter the addons to exclude manually under exclude_addons.

Ah great. Thanks. I overlooked the yaml option

I don't know which exact version fixed this issue, but it works again directly on the UI without using yaml mode.


“Incorrect padding” when trying to create managed Kubernetes cluster on Azure with AKS

Summary: I get an error when trying to create an AKS cluster from the command line.
Repro:

Installed azure-cli, logged in to account
az aks create --resource-group cb_aks_spike --name cbakscluster (resource group already exists)
I also tried az aks create --resource-group cb_aks_spike --name cbakscluster --generate-ssh-keys

Expected:
The AKS cluster creation to start.
Actual:
Error:
az aks create: error: Incorrect padding
Notes:
I initially posted this on Stack Overflow since I assumed it was something I did wrong, but after working through it with @benofben I think it could be a bug (or at least a confusing error message).
This error doesn't occur when @benofben did it from bash on a Mac, and also doesn't occur for me when I tried it in Cloud Shell-PowerShell
Environment summary
azure-cli (2.0.31)
Windows 10 Enterprise 100.16299
Windows Powershell 5.1.16299.251

Try the following workaround:
ssh-keygen -i -f existing_key.pub > formatted_key.pub
See related issue https://github.com/Azure/azure-cli/issues/2386 where this is confirmed to be a bug.

Closing issue as stale as there have not been additional reports and improvements have been made in this area. If there is still an issue using incorrect SSH/Key formats please reopen

Meanwhile, I ran into this same issue almost a year later. I've pretty sure I've figured out the problem, and I think it is a bug still
--generate-ssh generates a new ssh key in ~/.ssh
I had a hunch that since ~ for me is "C:\Users\Matthew Groves" that the space in the path was causing the problem. Sure enough, I created a new account called "mgroves". ~ is now "C:\Users\mgroves" and voila, I don't get the "incorrect padding" error message anymore.

It's still a bug. Like @mgroves I too have space characters in my username. I have seen buggy behavior because of this  previously.

please reopen this issue as I just installed the latest az cli version 2.7  and I get the same error :
az aks create: error: Incorrect padding
I copied the cli command directly from the Microsoft documentation.
my username also has a space to I suspect this is the same issue.

I also get the same error, when trying to upload a blob to the storage account:
root@2a62be8243f6:/projectfolder# az storage blob upload \
> --account-name billingreports \
> --container-name bill-uploads \
> --name filename.zip \
> --file filename.zip \
> --auth-mode key \
> --account-key 'my blob key'

For a hands on approach:
As correctly stated in the other comments the Azure CLI cannot handle the actual location where the generated SSH keys will be stored if there is a space in the path. I.e. **C:\Users\Admin Account.ssh**.
When using the az aks create command you can either use --generate-ssh-keys to let the Azure CLI handle it, OR you can specify an already existing SSH key with --ssh-key-value.
Git Bash:
ssh-keygen -f ~/.ssh/aks-ssh
Now create the Azure AKS cluster while pointing to this new SSH key with:
az aks create --resource-group YourResourceGroup --name YourClusterName --node-count 3 --ssh-key-value ~\.ssh\aks-ssh.pub
And you are good to go!

I'm a consultant at a customer site.  The directory names have the user name built into the "C:\Users\don airey" and I have no control over the directory name and no option to build my scripts than this directory.  This is still a bug.  Ignoring it is not going to make it go away.


[$500] Mark down - Email with strikethrough is not underlined

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: v1.4.44-0
Reproducible in staging?: y
Issue reported by: Applause - Internal Team
Issue found when executing PR: https://github.com/Expensify/App/pull/36773
Action Performed:

Go to staging.new.expensify.com.
Go to any chat.
Send a message containing email in strikethrough.

Expected Result:
The email with strikethrough mark down will be underlined.
Actual Result:
The email with strikethrough mark down is not underlined.
On Android app, before sending the text, the text preview shows underlined text and the underline disappears after sending the text.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/93399543/eb159d05-d63b-4b70-90c8-d4d2d3043bcb

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01532ae9e71730650e
Upwork Job ID:<PHONE_NUMBER>651248128
Last Price Increase: 2024-02-27

I agree. I don't think it's a bug, but I'll let @isabelastisser and @youssef-lr confirm before closing.
Removing the deploy blocker label for now.

Yeah I'm personally fine with closing this.


networking.md: Add OVN as a networking plugin option.

OVN is an opensource network virtualization solution
developed by the Open vSwitch community.  It lets one
create logical switches, logical routers, stateful
ACLs, load-balancers etc to build different virtual
networking topologies.  The project has a specific
Kubernetes plugin and documentation at
https://github.com/openvswitch/ovn-kubernetes.

This change is

I signed it!

The description looks good to me from an OVN perspective.  Thanks!


[Call of Cthulhu 7th Community sheet] Added clarification on bonus & penalty dice

Changes / Comments
Frequently new users query the bonus & penalty dice on the sheet
Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[ x] Does the pull request title have the sheet name(s)? Include each sheet name.
[ ] Is this a bug fix?
[ ] Does this add functional enhancements (new features or extending existing features) ?
[ ] Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.

Character Sheet Info Roll20 Internal Use only.

?


Allow go_test rules to have a data attribute [phab:D343]

Created by collinw at 2015-06-16 17:50:12:

schroederc commented inline (context lost during migration) at 2015-06-16 18:04:32:
Please make this def go_package(deps=[], test_deps=[], test_data=[], visibility=None):
and pass test_deps as the go_test data field below.

schroederc required changes at 2015-06-16 18:04:32

collinw wrote at 2015-06-16 21:48:55:
Pipe go_test data attribute through go_package

collinw commented inline (context lost during migration) at 2015-06-16 21:49:29:
Done.

schroederc accepted this revision at 2015-06-16 21:49:37

schroederc closed via commit 991f967dee1317f816644355410436d44e0bbb7d at 2015-06-16 22:26:22


Wrappermode

Problem/Motivation
I'm getting this error:
2024-09-10 13:18:46.685309102  mail.info: Sep 10 13:18:46 postfix/smtp[417]: SMTPS wrappermode (TCP port 465) requires setting "smtp_tls_wrappermode = yes", and "smtp_tls_security_level = encrypt" (or stronger)
Expected behavior
Auth to smtp_relayhost
Actual behavior
Rejected
Steps to reproduce
Proposed changes
See if this can be added or if config switch is needed to turn on or off.

Sorry, I have had limited time to work on this project.
I will have to create a new config options for this use case, if you are willing to test.

Hi I got it to work but I’m not sure if this is the most secure way. I have to go through my ISPs outbound SMTP to get mail outbound…_________________________________________________Filippe Åhlund 070-393 11 63 3 okt. 2024 kl. 09:40 skrev Erik Hilton @.***>:
Sorry, I have had limited time to work on this project.
I will have to create a new config options for this use case, if you are willing to test.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>


broken url...

Thank you for the wonderful code.
The "broken RUL" is growing...
Could you pleas provide the entire data set as a drive?

broken url list is
https://www.youtube.com/watch?v=J-j5eIHg8I0
https://www.youtube.com/watch?v=kN-2mc561GY
https://www.youtube.com/watch?v=krPRThe7R4g
https://www.youtube.com/watch?v=JV0D-YkWHD8
https://www.youtube.com/watch?v=CyeT8rEQOpQ
https://www.youtube.com/watch?v=ezY7QrSWeWw
https://www.youtube.com/watch?v=GdyJqgxlSxs
https://www.youtube.com/watch?v=K1r3m5OrmB4
https://www.youtube.com/watch?v=gDjeTHGWX9c
https://www.youtube.com/watch?v=IFhWIS-Gwps
https://www.youtube.com/watch?v=HeK6zbf8I9Y
https://www.youtube.com/watch?v=RASKiMoxhOE
https://www.youtube.com/watch?v=pQdl0apLT70
https://www.youtube.com/watch?v=e3hXj7S3QyA
https://www.youtube.com/watch?v=GJr8wKk8-YA
https://www.youtube.com/watch?v=Jt6_hinpKpk
https://www.youtube.com/watch?v=GDejMONyY4U
https://www.youtube.com/watch?v=Hfs4AlBmg70
https://www.youtube.com/watch?v=Z9K13eBUwJM
https://www.youtube.com/watch?v=ecRog9N1Qf0
https://www.youtube.com/watch?v=DkjTJcCXipY
https://www.youtube.com/watch?v=uO2zGO5ydBc
https://www.youtube.com/watch?v=WWyeuvpHmfc
https://www.youtube.com/watch?v=kld-iYpdjyo
https://www.youtube.com/watch?v=xVfPBzDnI2Q

Hi @RohDonghyeon , thank you for your response! We cannot directloy share these videos so far since we do not own these videos. We are working on this and will get back to you as soon as we have a solution.
At the mean time, I think you can use the existing videos for proof-of-concept experiments since the missing videos are only about 1/10 of the DoTA dataset.
Sorry for the inconvenience.

Thanks for answering.
If so, i can't find the cookies.txt URL too.
Can i get this file?
Also currently i'm having a problem.
In the process of extracting annotated frame, the frame's file disappears immediately after the work is finished.
Can you possibly solve it?

Thank you for answering.
If i have a question later, i will ask again!


Fixes #77 - changed buton click handling

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Refactor expensive Marshals into unsafe calls

No matter how much we try optimizing, the bottleneck with this implementation is using Marshal, which is awfully expensive. The only way to get the library in a performant state is using unsafe - but this will require memory management manually (which we do anyway).
Consider how much experience we have dealing with unsafe code in C#, we can leverage the performance from that by refactoring every Marshal code into an unsafe call.

Closed with https://github.com/vignetteapp/Oxide/commit/8a3b676c0c1b88ceaed1d1391693f0f21e6031e2

There's still a lot of [MarshalAs] and heap allocation going on

There's still a lot of [MarshalAs] and heap allocation going on

We're putting Oxide's development of indefinite hold for now, so we won't be working on this for a while. You're free to open a PR if you wish to.


Ltd 3855 saved filters form based part 2

Aim
Use the case filters form itself to generate a description for the bookmark.
LTD-3855

LGTM just wonder if it can be structured a little cleaner

Yeah. I kind of don't disagree. At the moment this is mostly trying to move away from hardcoded values to build the form description, I already have two more PRs that follow on after this that do more tidying (they don't really move this out though).