Make network event names conform to Zeek's naming

네트워크 이벤트의 자료구조 이름을 Zeek에서 사용하는 것과 동일하게 맞춥니다.

Codecov Report
Base: 81.12% // Head: 81.09% // Decreases project coverage by -0.03% :warning:

Coverage data is based on head (efbd09f) compared to base (ad96563).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #194      +/-   ##
==========================================
- Coverage   81.12%   81.09%   -0.04%
==========================================
  Files          14       14
  Lines        2331     2327       -4
==========================================
- Hits         1891     1887       -4
  Misses        440      440

Impacted Files
Coverage Δ

src/ingestion/tests.rs
97.89% <ø> (ø)

src/graphql/network.rs
80.07% <100.00%> (ø)

src/ingestion.rs
74.86% <100.00%> (ø)

src/publish/tests.rs
99.13% <100.00%> (-0.01%)
:arrow_down:

src/storage.rs
67.10% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Vulkan functionality is broken in nixos-unstable channel

Recent update to nixos-unstable broke vulkan functionality. vulkaninfo fails with error message
Cannot create Vulkan instance.
This problem is often caused by a faulty installation of the Vulkan driver or attempting to use a GPU that does not support Vulkan.
/build/source/vulkaninfo/vulkaninfo.c:923: failed with VK_ERROR_INCOMPATIBLE_DRIVER

I'm using nvidia driver 435.21
To Reproduce
Steps to reproduce the behavior:

Install vulkan-tools
Run vulkaninfo

Expected behavior
vulkaninfo should not fail with error.
Metadata
- system: `"x86_64-linux"`
 - host os: `Linux 5.2.11, NixOS, 19.09pre191505.7d5375ebf4c (Loris)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3pre6895_84de821`
 - channels(root): `"nixos-19.09pre191505.7d5375ebf4c"`
 - channels(alapshin): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Looks like problem affects native applications as well.
vulkaninfo fails with
Cannot create Vulkan instance.
This problem is often caused by a faulty installation of the Vulkan driver or attempting to use a GPU that does not support Vulkan.
/build/source/vulkaninfo/vulkaninfo.c:923: failed with VK_ERROR_INCOMPATIBLE_DRIVER

I will update bug description to remove Steam mention because it looks like Steam is not a culprit.

Might be related to #67919, but it's strange that you're not getting the assertion error (I didn't have a closer look at the Git history).

Maybe, I'm not sure.
I worked around assertion error using local overlay with
  vulkan-tools = super.vulkan-tools.overrideAttrs (oldAttrs: rec {
    version = "<IP_ADDRESS>";
  });
  vulkan-headers = super.vulkan-headers.overrideAttrs (oldAttrs: rec {
    version = "<IP_ADDRESS>";
  });

I'm thinking it may be caused by nvidia driver update at https://github.com/NixOS/nixpkgs/commit/4b67e77e1596c0e3bccedf408c6674054a6b302d
Will try to downgrade driver, rebuild system and verify this.

You're right, in that case it isn't related to the other issue.

Will try to downgrade driver, rebuild system and verify this.

Thanks :)

Downgrading nvidia driver to 430.40 fixed problem.

cc #67762, @baracoder, @eadwu: FYI ;)
Maybe someone has the time and experience to have a closer look at this issue? (I don't have an Nvidia GPU)


⚠ Bofrost.de has degraded performance

In 627e4df, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1589 ms

Resolved: Bofrost.de performance has improved in d4aa8af after 21 minutes.


DnsNameResolverTest#testNonCachedResolve fails for localhost in IPv6 only network

Expected behavior
DnsNameResolverTest#testNonCachedResolve succeeds.
Actual behavior
DnsNameResolverTest#testNonCachedResolve fails because it wants IPv4:
DnsNameResolver resolver = newNonCachedResolver(InternetProtocolFamily2.IPv4).build();

unresolved=localhost
resolved.hostAddress=0:0:0:0:0:0:0:1
resolved.class=class java.net.Inet6Address
resolver.resolvedAddressTypes=class java.net.Inet4Address

You can check AsyncHttpClient's CI on Travis.
Note that test code lines don't exactly match because I added some more logs as the assertThat in testResolve0 don't provide any reason.
Steps to reproduce
Run test on IPv6 only network, such as Travis.
Minimal yet complete reproducer code (or URL to code)
Netty version
4.1 master
JVM version (e.g. java -version)
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

OS version (e.g. uname -a)
Debian

@slandelle actually this is expected as you use InternetProtocolFamily.IPv4. Maybe we should add some assumeTrue to skip tests that need ipv4 while only ipv6 is present ?

Check that NetUtil.LOCALHOST4 != null?

@slandelle need to think about it... this will not work.

@slandelle so the real problem here is that the HostFileParser will not correctly handle the case where the hosts file contain an entry for ipv4 and ipv6. It will only preserve the first found which is incorrect as it valid to have one for each.
Thinking about a way to fix this without api breakage ...

Ouch, I missed that :(
Do you want me to help on this?
Shouldn't HostsFileParser be annotated @UnstableApi?

@slandelle yes it should but we missed it so we can not easily breaking it...

We could leave existing methods as is and deprecate them, and add new methods that would return a pair of Maps, one for IPv4 and one for IPv6. WDYT?

@slandelle we can not add methods to interfaces that are public in a bug-fix release.

@normanmaurer Interface? HostsFileParser is a final class, so no one can extend it without seriously hacking around.
The only way I see adding new methods there would be harmful is someone having some algorithm based on the number and order of methods fetched from reflection, and I fail to see why someone would do that. Am I missing something?

@slandelle I am talking about the HostNameResolver that uses it here.

@normanmaurer You probably mean HostsFileEntriesResolver. Yeah, got it.
We could introduce a new fixed interface with the new behavior, have DefaultHostsFileEntriesResolver, check type once in DnsNameResolver and downcast.

@slandelle yeah maybe something like this... want to do a pr ?

@normanmaurer Yep. Can't it wait for a few days? Release day on my side...

sure

great! stay tuned :)

@normanmaurer Is it possible to make the resolver module depend on the transport one?
I'd like to introduce a new InetAddress address(String inetHost, InternetProtocolFamily[] resolvedAddressTypes) on DefaultHostsFileEntriesResolver but InternetProtocolFamily is currently not reachable :(

I have the feeling InternetProtocolFamily should sit in commons side to NetUtils :(

@slandelle let me think about it... one thing is for sure, we can not move it :(

I know :)
Anyway, it feels natural that resolving an address against a hosts file would take a parameter indicating which InternetProtocolFamilys the user wants/prefers.
IMO, it also means that DnsNameResolver::DEFAULT_RESOLVE_ADDRESS_TYPES should be a public API. FIY, in order to not duplicate this logic, I created a class in the io.netty.resolver.dns package that exposes it publicly. I was thinking about introducing an enum (4 values) so we wouldn't expose a mutable array.

IIRC the intention is that the entire dns package is unstable. I don't think we should invest much effort in preserving APIs if they are broken. If we forgot to put @UnstableApiin a PR lets fix the API and add this annotation.

👍 I fail to see why someone would expect this class in particular to be stable while all the others in the same module are.

@slandelle @Scottmitch actually it's in the resolver module so not sure it's true tho

the resolver module doesn't exist in 4.0 ... are you saying this module was intentionally not marked as UnstableApi? Much of this code was introduced late in a candidate release for 4.1 [1] ... I think it is more likely we just forgot to annotate the package, no?
[1] https://github.com/netty/netty/commit/8d4db050f36929430e6699eec640de8eab1f3df2

Yes we most likely forgot that said I think we can not just do whatever we want now ;)
That said after a bit more of thoughts I think change from InetAddress to List in this case should not affect people. At least chances are very small, so @slandelle go for it

Am 07.02.2017 um 07:54 schrieb Scott Mitchell<EMAIL_ADDRESS>the resolver module doesn't exist in 4.0 ... are you saying this module was intentionally not marked as UnstableApi? Much of this code was introduced late in a candidate release for 4.1 [1] ... I think it is more likely we just forgot to annotate the package, no?
[1] 8d4db05
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@normanmaurer Actually, what I had in mind was to still only return one single address, but add an array of protocol families array to tell the resolver which is preferred. WDYT?

Yes we most likely forgot that said I think we can not just do whatever we want now ;)

I understand however the @UnstableApi annotations are a nice indicator but they are easy to forget and are not foolproof. I don't think just because we forgot these annotations we should bind ourselves to this API being stable. My preference is to annotate these classes with @UnstableApi (as originally intended) if we can't find a good solution.

@slandelle sounds good.

transport depends on resolver so I can't of course have the other way around 😭 😭 😭

PTAL #6334

@normanmaurer This issue can be closed since #6334 was merged.


Decaffeinate spec/init-spec

Since I work on many files, I edit package.json to add useful shortcut to avoid misspelt filename.
    "test-decaff": "npx coffee --compile --output spec spec/${npm_config_name}.coffee",
    "test-coffee": "jasmine-focused --captureExceptions --coffee spec/${npm_config_name}.coffee",
    "test-js": "jasmine-focused --captureExceptions spec/${npm_config_name}.js"

Steps to reproduce decaffeination (guidelines):

[x] Check package.json for coffee-script version

version: 1.12.7

[x] Decaffeination with official Coffee program

npx coffee --compile --output spec spec/init-spec.coffee
(or my shortcut:  ./bin/npm run test-decaff --name=init-spec)

[x] Quality of Decaffeination

[x] Replace var with const and let if it's possible.
[x] Replace Nested Ternary Operators with if statements.
[x] Remove return when it's not needed.
[x] Remove Result Arrays when they are not needed.
[x] Replace for loops with for-of loops.
[x] Use Arrow Functions to write functions in a single line when it's possible.
[x] Remove unneeded ref variables.
[x] Remove do blocks and use let or const instead.
[x] Tests and assertions should be the same and success like in coffee file

Test from coffee and JS should output same successful result :
From coffee
$ jasmine-focused --captureExceptions --coffee spec/init-spec.coffee
// or my shortcut $ `./bin/npm run test-coffee --name=init-spec`
> 10 tests, 72 assertions, 0 failures, 0 skipped

to js
$ jasmine-focused --captureExceptions spec/init-spec.js
// or my shortcut $ `./bin/npm run test-js --name=init-spec`
> 10 tests, 72 assertions, 0 failures, 0 skipped

Thanks a ton, superseded


fix: use default import for bin name

#126  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @pevisscher and the rest of your teammates on  Graphite


fix Issue 14432 - move construction for RefCounted

add RefCounted!T.this(T) which takes an RValue or a copy
and use move to initialized the refcounted store

add refCounted to infer T from the argument and disable
RefCounted's autoInit, also move initializes the store

Also changed move to use typeid(T).init() instead of an "empty" TLS variable.
This stuff would be way move efficient, if we had destructive move.

Once #3139 is ready, we should specifically handle promoting a Unique!T to a RefCounted!T.

LGTM

Well then go ahead merge it ;).

Ideally a third person would look over it, but it's already been 10 days so...

Auto-merge toggled on

Ideally a third person would look over it

Ideally we'd handle PR within a few days.
I made a best-effort implementation, you did a best-effort review, there is nothing wrong with making mistakes.


[solid3] Add new port

Add new port for collision detection library SOLID (Software Library for Interference Detection)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: rickertm sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


[Question] why recall of Rouge L for pseudo-labels ?

I read your paper again, and couldn't find the reason why you are using the recall of ROUGE-L score to make the pseudo-labels. Specifically :
Why ROUGE-L ? (and not ROUGE-1 for example)
Why precision ?

My intuition is Rouge-L correlates better with language fluency and by using recall we can cover more contents in the ground-truth summary. I think you can try Rouge-1 because at least for my model trained on CNN/DM it correlates well with Rouge-L. I do think recall is better than precision and f1 because we want more content to summarize. Nevertheless, feel free to try them out because this is an open question and I might be wrong.
Please also refer to Sec. 3 of the paper and footnote 6, thanks.


Twitter og:description doubly escaped by Hugo 0.125.x

If you build this small repro (test-site-2024-04-23.zip) using Hugo 0.124.1 and 0.125.2, you'll see the following difference in the content of <meta property="og:description"> for http://localhost:1313/docs/page:
0.124.1: <meta property="og:description" content="Test line with a single quote: can’t." />
0.125.2: <meta property="og:description" content="Test line with a single quote: can&rsquo;t.">

Notice that 0.125.2 doubly escapes the content, so that:

can’t becomes
can&rsquo;t

This seems wrong to me. WDYT?

Below I include a bit more header context.
Hugo 0.124.1:
<meta name="description" content="Test line with a single quote: can&rsquo;t.">
<meta property="og:title" content="Some page" />
<meta property="og:description" content="Test line with a single quote: can’t." />
...
<meta name="twitter:description" content="Test line with a single quote: can’t."/>

Hugo 0.125.2:
<meta name="description" content="Test line with a single quote: can&rsquo;t.">
<meta property="og:url" content="http://localhost:1313/docs/page/">
  <meta property="og:site_name" content="My New Hugo Site">
  <meta property="og:title" content="Some page">
  <meta property="og:description" content="Test line with a single quote: can&rsquo;t.">
  ...
<meta name="twitter:description" content="Test line with a single quote: can’t.">

I'll look at this again. Here's the challenge in the embedded opengraph template:
{{- with or .Description .Summary site.Params.description | plainify }}
  <meta property="og:description" content="{{ . }}">
{{- end }}

The input can be plain text, markdown, rendered markdown, HTML, or anything else. If rendered markdown, it might be wrapped in a p element or it might not, depending on how the summary was defined.

Going back through issues, PRs, and forum topics, the best that I have come up with for consistent rendering regardless of how the summary is defined (front matter, with summary divider, without summary divider) is:
{{- with or .Description .Summary site.Params.description | .RenderString | plainify | htmlUnescape }}
  <meta property="og:description" content="{{ . }}">
{{- end }}

This handles the following cases the same way:
+++
title = 'Post 1'
summary = "Test line with a **single** quote: can't."
+++

+++
title = 'Post 1'
+++

Test line with a **single** quote: can't.

+++
title = 'Post 1'
+++

Test line with a **single** quote: can't.

All three produce:
<meta property="og:description" content="Test line with a single quote: can’t.">

If this is acceptable:

[ ] Do the same thing for og:site_name and og:title
[ ] Make similar changes to the embedded schema and twitter_cards templates

Sounds good, thanks @jmooring. The OTel website has descriptions like the following (which I'm hoping to curate at some point to remove the images, but this is what we have now):
description: >-
   A language-specific implementation of OpenTelemetry in Go.

And this (markdown):
description: >-
  _OTel in Practice_ is a _series_ of talks initiated by some members of the End
  User SIG.

Will the solution you propose handle such descriptions as before (or better :)?
/cc @svrnm @theletterf

@chalin
With the proposed changes, the first is rendered to:
<meta property="og:description" content=" A language-specific implementation of OpenTelemetry in Go.">

The second is rendered to:
<meta property="og:description" content="OTel in Practice is a series of talks initiated by some members of the End User SIG.">

Thanks @jmooring, that LGTM.

@chalin
In its current implementation, PR #12425 does this:

the first is rendered to:

<meta property="og:description" content=" A language-specific implementation of OpenTelemetry in Go.">

The second is rendered to:

<meta property="og:description" content="_OTel in Practice_ is a _series_ of talks initiated by some members of the End User SIG.">

In your second example, note that the markdown is not rendered to HTML due to performance concerns related to using .RenderString on every og:description on every page.
If you want to render the markdown and don't care about a performance hit, use this in the override template...
{{- with or .Description .Summary site.Params.description | .RenderString | plainify | htmlUnescape | chomp }}

I have no idea how much this would affect a 10,000 page site.


Godot 4 compiled with MinGW is crashing with a white screen

Godot version
4.0 custom build (bdcc8741e)
System information
Windows 10 21H1
Issue description
The editor is crashing with a white screen on startup, with or without a project. I have been tried some combinations of compilers and options:
MSVC with debug -> OK
MSVC with release_debug -> OK
MinGW with debug -> OK
MinGW with release_debug -> Crash
This issue has been introduced with the 99fe462452be44efa618e83ad9bbecd722ae6ecd commit.

Output of drmingw
godot.windows.opt.tools.64.exe caused an Access Violation at location 00007FF73A4C0000 DEP violation at location 00007FF73A4C0000.

AddrPC           Params
00007FF73A4C0000<PHONE_NUMBER>6FA200 0000003CE61FF5A8 0000003CE61FF5B0
00007FF77C559842<PHONE_NUMBER>400000 00007FF77CA33F03<PHONE_NUMBER>400000  godot.windows.opt.tools.64.exe!RenderingServerDefault::RenderingServerDefault  [E:/path/core/os/thread.h @ 90]
    88: _FORCE_INLINE_ ID get_id() const { return id; }
    89: // get the ID of the caller thread
>   90: _FORCE_INLINE_ static ID get_caller_id() { return caller_id; }
    91: // get the ID of the main thread
    92: _FORCE_INLINE_ static ID get_main_id() { return main_thread_id; }
00007FF77A4DE90B<PHONE_NUMBER>579CC0<PHONE_NUMBER>C1F690<PHONE_NUMBER>0000FF  godot.windows.opt.tools.64.exe!Main::setup2  [E:/path/main/main.cpp @ 1590]
  1588: /* Initialize Rendering Server */
  1589:
> 1590: rendering_server = memnew(RenderingServerDefault(OS::get_singleton()->get_render_thread_mode() == OS::RENDER_SEPARATE_THREAD));
  1591:
  1592: rendering_server->init();
00007FF77A4E479B<PHONE_NUMBER>C20C30<PHONE_NUMBER>000001 000002155F450860  godot.windows.opt.tools.64.exe!Main::setup  [E:/path/main/main.cpp @ 1388]
  1386:
  1387: if (p_second_phase) {
> 1388: return setup2();
  1389: }
  1390:
00007FF77A4C18A7 000002155F153296 0000003CE61FFD4C<PHONE_NUMBER>000001  godot.windows.opt.tools.64.exe!widechar_main  [E:/path/platform/windows/godot_windows.cpp @ 151]
   149: TEST_MAIN_PARAM_OVERRIDE(argc, argv_utf8)
   150:
>  151: Error err = Main::setup(argv_utf8[0], argc - 1, &argv_utf8[1]);
   152:
   153: if (err != OK) {
00007FF77A4C19A0<PHONE_NUMBER>000000<PHONE_NUMBER>000047 00007FF7811164D8  godot.windows.opt.tools.64.exe!_main  [E:/path/platform/windows/godot_windows.cpp @ 185]
   183: }
   184:
>  185: result = widechar_main(argc, wc_argv);
   186:
   187: LocalFree(wc_argv);
00007FF77A4C13B1<PHONE_NUMBER>000000<PHONE_NUMBER>000000<PHONE_NUMBER>000000  godot.windows.opt.tools.64.exe!__tmainCRTStartup  [C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c @ 321]
00007FF77A4C14E6<PHONE_NUMBER>000000<PHONE_NUMBER>000000<PHONE_NUMBER>000000  godot.windows.opt.tools.64.exe!mainCRTStartup  [C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c @ 202]
00007FF8F8997034<PHONE_NUMBER>000000<PHONE_NUMBER>000000<PHONE_NUMBER>000000  KERNEL32.DLL!BaseThreadInitThunk
00007FF8FA1C2651<PHONE_NUMBER>000000<PHONE_NUMBER>000000<PHONE_NUMBER>000000  ntdll.dll!RtlUserThreadStart

Log of the crashing MinGW release_debug build
Godot Engine v4.0.dev.custom_build.bdcc8741e - https://godotengine.org
Using "ICU / HarfBuzz / Graphite" text server...
Vulkan API 1.2.162
ERROR: GENERAL - Message Id Number: 0 | Message Id Name: Loader Message
        loader_get_json: Failed to open JSON file C:\ProgramData\GOG.com\Galaxy\redists\overlay\injected\galaxy_overlay_vklayer_x64.json
        Objects - 1
                Object[0] - VK_OBJECT_TYPE_INSTANCE, Handle<PHONE_NUMBER>880
   at: _debug_messenger_callback (drivers\vulkan\vulkan_context.cpp:157)
WARNING: GENERAL - Message Id Number: 0 | Message Id Name: Loader Message
        ReadDataFilesInRegistry: Registry lookup failed to get layer manifest files.
        Objects - 1
                Object[0] - VK_OBJECT_TYPE_INSTANCE, Handle<PHONE_NUMBER>880
     at: _debug_messenger_callback (drivers\vulkan\vulkan_context.cpp:154)
Using Vulkan Device #0: NVIDIA - NVIDIA GeForce RTX 2080
- Vulkan multiview supported:
  max view count: 32
  max instances: 134217727
- Vulkan subgroup:
  size: 32
  stages: STAGE_VERTEX, STAGE_TESSELLATION_CONTROL, STAGE_TESSELLATION_EVALUATION, STAGE_GEOMETRY, STAGE_FRAGMENT, STAGE_COMPUTE, STAGE_RAYGEN_KHR, STAGE_ANY_HIT_KHR, STAGE_CLOSEST_HIT_KHR, STAGE_MISS_KHR, STAGE_INTERSECTION_KHR, STAGE_CALLABLE_KHR, STAGE_TASK_NV, STAGE_MESH_NV
  supported ops: FEATURE_BASIC, FEATURE_VOTE, FEATURE_ARITHMETIC, FEATURE_BALLOT, FEATURE_SHUFFLE, FEATURE_SHUFFLE_RELATIVE, FEATURE_CLUSTERED, FEATURE_QUAD, FEATURE_PARTITIONED_NV
  quad operations in all stages
Using present mode: VK_PRESENT_MODE_FIFO_KHR
Using "winink" pen tablet driver...

Log of the working MinGW debug build
Godot Engine v4.0.dev.custom_build.bdcc8741e - https://godotengine.org
Using "ICU / HarfBuzz / Graphite" text server...
Vulkan API 1.2.162
ERROR: GENERAL - Message Id Number: 0 | Message Id Name: Loader Message
        loader_get_json: Failed to open JSON file C:\ProgramData\GOG.com\Galaxy\redists\overlay\injected\galaxy_overlay_vklayer_x64.json
        Objects - 1
                Object[0] - VK_OBJECT_TYPE_INSTANCE, Handle<PHONE_NUMBER>080
   at: _debug_messenger_callback (drivers\vulkan\vulkan_context.cpp:157)
WARNING: GENERAL - Message Id Number: 0 | Message Id Name: Loader Message
        ReadDataFilesInRegistry: Registry lookup failed to get layer manifest files.
        Objects - 1
                Object[0] - VK_OBJECT_TYPE_INSTANCE, Handle<PHONE_NUMBER>080
     at: _debug_messenger_callback (drivers\vulkan\vulkan_context.cpp:154)
Using Vulkan Device #0: NVIDIA - NVIDIA GeForce RTX 2080
- Vulkan multiview supported:
  max view count: 32
  max instances: 134217727
- Vulkan subgroup:
  size: 32
  stages: STAGE_VERTEX, STAGE_TESSELLATION_CONTROL, STAGE_TESSELLATION_EVALUATION, STAGE_GEOMETRY, STAGE_FRAGMENT, STAGE_COMPUTE, STAGE_RAYGEN_KHR, STAGE_ANY_HIT_KHR, STAGE_CLOSEST_HIT_KHR, STAGE_MISS_KHR, STAGE_INTERSECTION_KHR, STAGE_CALLABLE_KHR, STAGE_TASK_NV, STAGE_MESH_NV
  supported ops: FEATURE_BASIC, FEATURE_VOTE, FEATURE_ARITHMETIC, FEATURE_BALLOT, FEATURE_SHUFFLE, FEATURE_SHUFFLE_RELATIVE, FEATURE_CLUSTERED, FEATURE_QUAD, FEATURE_PARTITIONED_NV
  quad operations in all stages
Using present mode: VK_PRESENT_MODE_FIFO_KHR
Using "winink" pen tablet driver...
Shader 'VoxelGiSdfShaderRD' SHA256: b6972a55781e21cfbac0dfc035381ee1f65e972c1f7e0bcc6004bfb74cc9dc9e
Shader 'ParticlesShaderRD' SHA256: cbb6a5ce1933875a8e2df4f0cde4684286dedb6737cfbcfdeba745c978a2cc45
Shader 'ParticlesCopyShaderRD' SHA256: 6bd2ea6fca4c3a51f1e9bcd5068315e63820ec68fd8596e20480174c943bb9df
Shader 'CanvasSdfShaderRD' SHA256: 692328d90ee7d404503d304e2464af3f3ac466ebd287762fd8883248f3e2a046
Shader 'SkeletonShaderRD' SHA256: 8f03a2ebc895d833120c3b2341c16e971fb1404dd3ae9e8030bc4bbf63e67fd5
Shader 'CanvasShaderRD' SHA256: a30a00a53b17f4e413dfb1fe109868063f2d67900aaeec66b0f50964108e216b
Shader 'CanvasOcclusionShaderRD' SHA256: fd08d5c92b6537852fb4b8e5fba27f28518faad41a5c21ac9bd51bf49807824c
Shader 'ClusterRenderShaderRD' SHA256: a2924afb04064a1dc42ed9d63721e7d5dd0466f245037ff85b5bef8bd251f515
Shader 'ClusterStoreShaderRD' SHA256: 64c437e6bebba9faa4766b524281310d934fd2a28f26e9a8a7834ca07f09d2dc
Shader 'ClusterDebugShaderRD' SHA256: 0f66ac91d81e6f440ffa804d473579cb5d7ac135b375dce6d120186a65b54204
Shader 'SkyShaderRD' SHA256: dd0dbf614e400cc2f58360d292f85f19237fdd9746b9a46c6fd7c50fe8a2ae43
Shader 'VoxelGiShaderRD' SHA256: 51aa13996be8fb6071160d3ea73d752edcd67ef81e1aec1ec3623a13eee94d0a
Shader 'VoxelGiDebugShaderRD' SHA256: 7fa6be49a459f8891a6e756165f2e9ca7f3ba261f53edf36c2041dc2acbf2a96
Shader 'SdfgiPreprocessShaderRD' SHA256: 056a9e6eaae9cc98093ceec6142bcb4582be0f3443e18402c1e25c293899b104
Shader 'SdfgiDirectLightShaderRD' SHA256: 0707e534eb11aeb7566a94913fe168d96b66896b440650f768f92ec6ed5cc842
Shader 'SdfgiIntegrateShaderRD' SHA256: deacba90b0c075f22f4000295f6a0b846957d2602b5d54b631c089792288e7df
Shader 'GiShaderRD' SHA256: c1d65ee198e82b396759752f26b64ae98d7bb8691aed1bc07924617cf25872c5
Shader 'SdfgiDebugShaderRD' SHA256: 5e9f1e4d567be5c04dacec2ddbddb98638086a1fe7dc1d0260f3a58e93856a0e
Shader 'SdfgiDebugProbesShaderRD' SHA256: a6a825191c0869482f513376305eb79fa16189e65068bf76a484a0e1eb602c1b
Shader 'VolumetricFogShaderRD' SHA256: bc8fa35c7d92fd0353d5458af7d19438bf0c46f8c873b1b5e45f328f988f2d34
Shader 'SceneForwardClusteredShaderRD' SHA256: 300732714cbaf090328e341566d4d056b1bf83a2786d31de56778f6c929d1987
Shader 'CopyShaderRD' SHA256: 4ea51535b5cdcba7ece20ebd074657d05cbde47d1d0e87d3c84a2a1c28aa976f
Shader 'CopyToFbShaderRD' SHA256: 6972e6ea6ece204edb2197ac92f699ad4e7c4b22cac23422dd816a2a9fc11ce3
Shader 'CubemapRoughnessShaderRD' SHA256: 083d83f629fde69ed8e4c482638f30df40144b9e05c8d8243317b1866ff97897
Shader 'TonemapShaderRD' SHA256: cd4d7156689aa910864bd876e2c439c8f2b49dd281df707f93145fec99b9bd67
Shader 'LuminanceReduceShaderRD' SHA256: f8db4abaa10d52974aef5a0443e69f8838eb05f4b4eee120c19ca3b0f8ef6353
Shader 'CubeToDpShaderRD' SHA256: 1ac5646aaebfed0f2fa62c6faa2f87981b8a5acf4748191482448d7fe516cc78
Shader 'BokehDofShaderRD' SHA256: 7ae11ecc5f3863fff19a28c9e41a9ba8016c53f54cc182daa15e6a1e080ce3c6
Shader 'SsaoDownsampleShaderRD' SHA256: 4db35346ca9c82436e993cde3466bee499a8f66f6d58e39d9bed78ee7d835e1f
Shader 'SsaoShaderRD' SHA256: db7ede5f05458aaa5e03db5e62804bcd7e3b4b3eeb556e9eb027a958a96b6bd7
Shader 'SsaoImportanceMapShaderRD' SHA256: a2305d0dc9bed6da701e58b6d6a28bb2a664aedb9de4460c390b21a7f989e8eb
Shader 'SsaoBlurShaderRD' SHA256: 9158ebb0e50201b64d1c1009317e7cf5de0792a82a4d06b393e5db5ec351b54f
Shader 'SsaoInterleaveShaderRD' SHA256: e8d5eda46653d75788db067517688755630bcb40ff6da19c5f039db86df234c3
Shader 'RoughnessLimiterShaderRD' SHA256: fe30b9757ac0d3bbb53ab48bc7e0d48cc760f8212fc723c588c30dc9466539d4
Shader 'CubemapDownsamplerShaderRD' SHA256: 8184770cb634e8d5b7f7d4e801b864caa2972a7a98181a62c196ffa7b882edc3
Shader 'CubemapFilterShaderRD' SHA256: 5c27e7fe5c0fce79c147c7a8ae6984a0a7ae2dd90af07e35a4a34934698a91ca
Shader 'SpecularMergeShaderRD' SHA256: f6dc7afac1a2715cc2f134daff1bddfd6b7ca715d655aca8cafa32798395dec2
Shader 'ScreenSpaceReflectionShaderRD' SHA256: d56b77268d5c239c3886ca85201d733c47ea7e6542969c5eb6d5350b483778ef
Shader 'ScreenSpaceReflectionFilterShaderRD' SHA256: 4cd6afe65db3d97e059daa77702faf2a6e6cccb9c552c61af6055cb5be448b5f
Shader 'ScreenSpaceReflectionScaleShaderRD' SHA256: 89c672345ad85d25a8e9cbc814aac4007cb5fcb29cb8262d0185abd23fdccb9f
Shader 'SubsurfaceScatteringShaderRD' SHA256: c633c5beb82a7102c2849bec06732e4c6c98ebfc17b013f0844089d30beaef52
Shader 'ResolveShaderRD' SHA256: d0c9281d4f856dc19c5c6d14e0b256b28ca5455371db93744c010476572dbf25
Shader 'SortShaderRD' SHA256: 2192a5f1b643af9d53a2a609c7d2a715237ea16c083317a1611af42c6845b99c
Shader 'BlitShaderRD' SHA256: 3c3477999355f834dd2a898d94df5b40ae97299bb1f5e9de2dd2b6caf46055f5
WASAPI: wFormatTag = 65534
WASAPI: nChannels = 8
WASAPI: nSamplesPerSec = 48000
WASAPI: nAvgBytesPerSec = 1536000
WASAPI: nBlockAlign = 32
WASAPI: wBitsPerSample = 32
WASAPI: cbSize = 22
WASAPI: detected 8 channels
WASAPI: audio buffer frames: 1962 calculated latency: 44ms

ERROR: Attempted to free invalid ID:<PHONE_NUMBER>746
   at: _free_internal (drivers\vulkan\rendering_device_vulkan.cpp:8313)
CORE API HASH:<PHONE_NUMBER>0231588744
EDITOR API HASH:<PHONE_NUMBER>925521230
Using present mode: VK_PRESENT_MODE_FIFO_KHR
Loaded builtin certs
EditorSettings: Save OK!
Using present mode: VK_PRESENT_MODE_FIFO_KHR
Using present mode: VK_PRESENT_MODE_FIFO_KHR
Using present mode: VK_PRESENT_MODE_FIFO_KHR
EditorSettings: Save OK!
ERROR: Attempted to free invalid ID: 0
   at: _free_internal (drivers\vulkan\rendering_device_vulkan.cpp:8313)
ERROR: Attempted to free invalid ID: 0
   at: _free_internal (drivers\vulkan\rendering_device_vulkan.cpp:8313)
ERROR: Attempted to free invalid ID: 0
   at: _free_internal (drivers\vulkan\rendering_device_vulkan.cpp:8313)
ERROR: Attempted to free invalid ID: 0
   at: _free_internal (drivers\vulkan\rendering_device_vulkan.cpp:8313)
ERROR: Attempted to free invalid ID: 0
   at: _free_internal (drivers\vulkan\rendering_device_vulkan.cpp:8313)
ERROR: Attempted to free invalid ID: 0
   at: _free_internal (drivers\vulkan\rendering_device_vulkan.cpp:8313)
ERROR: Attempted to free invalid ID: 0
   at: _free_internal (drivers\vulkan\rendering_device_vulkan.cpp:8313)
ERROR: Attempted to free invalid ID: 0
   at: _free_internal (drivers\vulkan\rendering_device_vulkan.cpp:8313)
ERROR: Attempted to free invalid ID: 0
   at: _free_internal (drivers\vulkan\rendering_device_vulkan.cpp:8313)
ERROR: Attempted to free invalid ID: 0
   at: _free_internal (drivers\vulkan\rendering_device_vulkan.cpp:8313)
ERROR: 1 RID allocations of type 'N17RendererStorageRD7TextureE' were leaked at exit.
WARNING: 2 RIDs of type "Texture" were leaked.
     at: finalize (drivers\vulkan\rendering_device_vulkan.cpp:9055)
StringName: 173 unclaimed string names at exit.

Summary of tried combinations and result of it:

Distro
MinGW version
GCC version
Works

Fedora 34
8.0.0
10.3.1
yes

Fedora 35
9.0.0
11.2.1
no

Debian Sid
8.0.0
10.2.1
no

OpenSuse TW
9.0.0
9.2.0
yes

MSYS2
9.0.0
11.2.0
no

Mageia 8
8.0.0
10.2.1
yes[1]

[1] The icon from the executable was missing
Steps to reproduce
For a not working build:
scons platform=windows target=release_debug use_mingw=yes -j12
For a working build:
scons platform=windows target=debug use_mingw=yes -j12
Minimal reproduction project
No response

There's likely the same issue in the 3.x branch, which has been exposed by the first 3.4 beta builds: https://github.com/godotengine/godot/issues/50970#issuecomment-889308948
3.3.x builds already include the Thread modernization work, but they're built on Fedora 33 with MinGW 7.0.0 and GCC 10.2.1.
The new builds (3.4 beta 1 and beta 2, and https://downloads.tuxfamily.org/godotengine/testing/4.0/4.0-dev.20210727/) are built on Fedora 34 with MinGW 8.0.0 and GCC 10.3.1.

@akien-mga  I have just built the 3.x and it's working, it's not crashing when opening the editor. (v3.4.beta.custom_build.7075bb612)
Build from https://downloads.tuxfamily.org/godotengine/testing/4.0/4.0-dev.20210727/ is working too.

Thanks, these might be separate issues in the end then.
Which MinGW versions do you have (both the version of MinGW itself, which should typically be 7.0.0, 8.0.0 or 9.0.0, and the GCC or LLVM version compiled against the MinGW headers)?

I'm using MSYS with MinGW  <IP_ADDRESS>46.ae63cde27-1 and GCC 10.3.0.

gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-10.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --enable-checking=release --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev5, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --with-boot-ldflags='-pipe -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high -Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc' 'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high' --enable-linker-plugin-flags='LDFLAGS=-static-libstdc++\ -static-libgcc\ -pipe\ -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high\ -Wl,--stack,12582912'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Rev5, Built by MSYS2 project)

I tested it again to see if it was still relevant. I tried with 0121ce97df0331235a0517e4deeab66c2289637e and with updated MSYS and MinGW, but the result is exactly same.
MinGW: <IP_ADDRESS>46.6cc97775a-1
GCC: 11.2.0

gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-11.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --enable-checking=release --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --with-boot-ldflags='-pipe -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high -Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc' 'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high' --enable-linker-plugin-flags='LDFLAGS=-static-libstdc++\ -static-libgcc\ -pipe\ -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high\ -Wl,--stack,12582912'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Rev2, Built by MSYS2 project)

A few more things I found out:
If I compile with mingw from OpenSuse it's works. It has gcc 9.2.0.
I tried with mingw from Debian testing, but I have no success with it. It has gcc 10.
I believe (but cannot prove) that there are compatibility problems with the newer versions of the compiler.

OpenSuse gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-suse-linux-gnu --host=x86_64-suse-linux-gnu --target=x86_64-w64-mingw32 --with-gnu-as --with-gnu-ld --verbose --without-newlib --disable-multilib --enable-shared --disable-plugin --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-threads=posix --enable-version-specific-runtime-libs --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --enable-languages=c,c++,fortran,objc,obj-c++ --without-x --enable-hash-synchronization --enable-fully-dynamic-string --enable-libgomp --enable-linker-build-id --disable-vtable-verify --with-pkgversion='SUSE Linux'
Thread model: posix
gcc version 9.2.0 (SUSE Linux)

Debian gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/10-posix/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --enable-threads=posix --program-suffix=-posix --program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as --with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic --enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10-posix 20210110 (GCC)

@MmAaXx500 I can compile Godot's master branch just fine with GCC 11.2 provided in the Fedora repositories.

@Calinou Thanks for the suggestion about Clang. I will use it while this gets sorted out.

I can compile Godot's master branch just fine with GCC 11.2 provided in the Fedora repositories. This is likely specific to MinGW.

I can compile it too, but cannot launch. Here is a gif about the issue.
I read in the docs that gcc is recommended for release build, that's why I'm trying to get it working.
What is your opinion, is it a viable option to use Clang for release builds?

Clang might be a decent option for release builds on Windows too, though I don't have much experience with it (official builds use GCC as provided in Fedora 34 - at least an image from 5 months ago).
I'd still be interested to figure out what's the exact component that causes the issue you're experiencing, so we can make sure it won't affect official builds too.

Tried with Fedora 34, it's works as expected, but with Fedora 35 I can reproduce this issue. (so do not update the official build server 😄)
Fedora 34 has gcc 10.3.1
Fedora 35 has gcc 11.2.1

Fedora 34 gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/10.3.1/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose --without-newlib --disable-multilib --disable-plugin --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-languages=c,c++,objc,obj-c++,fortran --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-threads=posix --with-isl --enable-libgomp --target=x86_64-w64-mingw32 --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.1 20210422 (Fedora MinGW 10.3.1-2.fc34) (GCC)

Fedora 34 gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/11.2.1/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose --without-newlib --disable-multilib --disable-plugin --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-languages=c,c++,objc,obj-c++,fortran --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-threads=posix --with-isl --enable-libgomp --target=x86_64-w64-mingw32 --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.1 20210728 (Fedora MinGW 11.2.1-3.fc35) (GCC)

I think I found something. F34 uses 8.0.0 and F35 uses 9.0.0 mingw (assuming mingw64-headers package version reflects mingw version).
But, in order to make the situation less clear, OpenSuse TW which uses 9.0.0 mingw (mingw64-headers) it runs fine, but Debian uses 8.0.0 mingw (mingw-w64-common) and not works.
Just to summarize, here is a table:
(at mingw version, I'm assuming package version reflects this)

Distro
MinGW version
GCC version
Works

Fedora 34
8.0.0
10.3.1
yes

Fedora 35
9.0.0
11.2.1
no

Debian Sid
8.0.0
10
no

OpenSuse TW
9.0.0
9.2.0
yes

MSYS2
9.0.0
11.2.0
no

(after I wrote the table, I'm not sure about I really found something)

To clarify, Debian Sid's GCC should be 10.2.1 as of the current package https://packages.debian.org/sid/gcc-mingw-w64
(Though GCC versioning in distros is tricky as .1 patch releases are not releases, it just means "any Git snapshot of the next minor branch", i.e. 10.2.1 can be any commit between 10.2 and 10.3.)

Thanks! Corrected it. I wrote "10" because x86_64-w64-mingw32-gcc -v outputs this: gcc version 10-posix 20210110 (GCC)

I tried a local build on Mageia 9 with MinGW 9.0.0 and GCC 11.2.1 (20211019) which should be pretty much the same as Fedora 35's config as Mageia's mingw-gcc packaging is based on Fedora's.
It works fine for me when running through Wine on Linux, but I have yet to actually test it on Windows (will do asap).
Here's the build if you want to test (note: built with scons p=windows target=release_debug, then stripped with mingw-strip): https://downloads.tuxfamily.org/godotengine/testing/4.0-dev-2021130-mga9-mingw9-gcc11.2.1.zip

Your build works for me.
I built one on Mageia 8 because they don't have a docker image for 9, and it worked too (except it did not have an icon).
Mageia 8 has MinGW 8.0.0 and GCC 10.2.1. (added to the table and moved it to the first post)

gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/10.2.1/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-mageia-linux-gnu --host=x86_64-mageia-linux-gnu --with-gnu-as --with-gnu-ld --verbose --without-newlib --disable-multilib --disable-plugin --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-languages=c,c++,objc,obj-c++,fortran --with-bugurl=https://bugs.mageia.org/ --enable-threads=posix --enable-libgomp --target=x86_64-w64-mingw32 --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20200723 (Fedora MinGW 10.2.1-2.mga8) (GCC)

That's interesting, then the culprit is likely neither MinGW nor GCC but another component. This could be the (mingw-)binutils version.
Fedora 34, Mageia 8 and Mageia 9 have mingw-binutils 2.34, while Fedora 35 and Debian Sid have mingw-binutils 2.37.
What version does MSYS2 provide?

MSYS2 have 2.37

So yeah binutils sounds like a likely culprit. I'll see if I can use Fedora 35's mingw-binutils on Fedora 34 to see if that produces a crashing binary. And then we'd have to try to bisect that with intermediate releases and report the issue upstream, though we'd need to identify a bit more precisely how binutils relates to this (thread-related?) crash.

Can you still reproduce this with binutils 2.38, if MSYS2 provides it?

Yes I can.
Current versions are:

GCC 11.2.0
MinGW <IP_ADDRESS>54.b4445ee52
binutils 2.38

I wonder why no one has reported this in the last half year. Am I alone with this issue?
Anyway, here is a build for anyone who wants to test/examine it.
https://drive.google.com/file/d/1iLaTmZeH57baIhL3O2FXFs-_nbQl2Trp/view?usp=sharing

Another test because MinGW 10 was released, but the result has not changed.

GCC 11.2.0
MinGW 10.0.0.r0.gaa08f56da-1
binutils 2.38

I have also updated the table in the first post with the new tests and added the binutils version column.

@akien-mga I have some good news!
I have bisected the binutils and found out this is the first bad commit: https://sourceware.org/git/?p=binutils-gdb.git;h=514b4e191d5f46de8e142fe216e677a35fa9c4bb
It was first included in 2.36.
I found a way to make it work. Compile binutils with reverted NT_EXE_IMAGE_BASE and use link flags to get correct result.
Scons command:
scons -j12 platform=windows bits=64 target=release_debug LINKFLAGS="-Wl,--disable-dynamicbase -Wl,--disable-high-entropy-va"

Patch here: MmAaXx500/binutils-gdb-godot@b02b5836d58c1fcef7179fff91ac4e59ca432d03
Below, some of my inexperienced observations:

The --disable-high-entropy-va is redundant because the --disable-dynamicbase disables this as well. (this is a fact, not an observation: source)

The flags are required because the above-mentioned commit changes the default dll characteristics from 0 to enable dynamic base, high entropy va and nx compat. The nx compat flag left out from the command on purpose because it does not affect the binary in a way related to this issue.

I think this issue is related somehow to the (dynamic) base address, because if I do not revert the NT_EXE_IMAGE_BASE and disable the dynamic base or do the revert but do not disable the dynamic base the result is the same: this issue

I'd like to note that I don't have much knowledge in this area, so I cannot determine who is "at fault" or what exactly causing this issue.
So, I highly appreciate if someone can dig deeper in that and found out the root cause of the issue.

Another workaround without modifying binutils. Just pass the base address as a parameter.
scons -j12 platform=windows bits=64 target=release_debug LINKFLAGS="-Wl,--disable-dynamicbase -Wl,--disable-high-entropy-va -Wl,--image-base=0x400000"

Thanks for documenting all this! That's an area with @hpvb is probably the most competent to figure out what we need to do exactly / if we have to report a regression upstream.

With the release of the alpha 8 I noticed that the Windows binaries works, although it was compiled on Fedora 36 which has binutils 2.37. This is not in line with the previous assumptions/findings, so I tested again on various distributions.

Fedora 36 (2.37): Works
Debian Sid (2.37): Works
MSYS2 (2.38): Works
Arch (2.38) with gcc 11.2.0-1: Not works
Arch (2.38) with gcc 12.1.0-1: Works

I have looked through the patches of MSYS and the only patch could be related is this, but it was released on 2021 Jul 28, so it is included in all of my test with MSYS (therefore not related). Another thing is the whole binutils package haven't been touched since 2022 Mar 1, the build didn't work on 2022 Apr 20, but it magically started working today (I tested it today, so I do not know when precisely).
Arch currently have mingw-w64-gcc with version 11.2.0-1 in Community and have 12.1.0-1 in Community-Testing. If I compiled and installed the newer gcc from Community-Testing, the issue went away.
I think this issue is neither binutils' nor gcc's solely fault, rather something of a compatibility issue between them, which seems to be resolving itself as the distributions releasing the newer packages.

So after spending some time chasing the wrong issue in #61176, I finally realized that Mono builds for Godot 3.x seem to be affected by the same issue you describe. Windows binaries built on Fedora 35 are crashing, while Fedora 36 is fine.
Thanks a lot for all the debugging you've done so far and documenting your findings. I'm still not sure what we can do to get this actually fixed in the upstream MinGW distributions, but at least we can make sure to use Fedora 36+ for official builds.

For the record, I now think that this issue might have been a GCC regression in 11.2 (maybe 11.1 too), which got fixed in later versions. Because that seems to be the only significant between the mingw-headers, mingw-gcc and mingw-binutils package of Fedora 35 and Fedora 36.

mingw-headers: https://src.fedoraproject.org/rpms/mingw-headers/commits/f35 and https://src.fedoraproject.org/rpms/mingw-headers/commits/f36 - both at 9.0.0 with no additional change in F36 aside from a spec cleanup
mingw-binutils: https://src.fedoraproject.org/rpms/mingw-binutils/commits/f35 and https://src.fedoraproject.org/rpms/mingw-binutils/commits/f36 - same spec files
mingw-gcc: https://src.fedoraproject.org/rpms/mingw-gcc/commits/f35 and https://src.fedoraproject.org/rpms/mingw-gcc/commits/f36 - the main difference here is that F36 has a newer snapshot from the 11.x branch, which is 3 months newer than Fedora 35's 11.2 snapshot: https://src.fedoraproject.org/rpms/mingw-gcc/c/1d2866170abd4045bb9cb282854142c6358ab111?branch=f36

So I suspect this was found and fixed in the 11.x stable branch after 11.2 was released. There was a 11.3 release earlier this year which should also have the fix I suppose.
TL;DR: Avoid GCC 11.1 or 11.2, unless it's a snapshot more recent than the July 2021 11.2 release. GCC 11.3 or 12.1+ should be fine.

Closing as there isn't much more actionable from our side, aside from having this documented here. We could put a note in the compilation docs or add some checks to prevent building with GCC 11.1 or 11.2, but most distros by now should provide either 11.3, a newer GCC, or still be on an older version.


pixi install can't install environment and raises thread 'main' has overflowed its stack.

Checks

[X] I have checked that this issue has not already been reported.

[X] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example
system: windows 10
here is a test pixi.toml .
[project]
name = "Install-Multi-Envs"
platforms = ["win-64"]
channels = ["conda-forge"]

[dependencies]
python = ">=3.10"
[pypi-dependencies]
numpy = ">=1.23"
[feature.py311.dependencies]
python = "3.11.*"
[feature.py312.dependencies]
python = "3.12.*"

[environments]
py312 = ["py312"]
py311 = ["py311"]

command
pixi install

Issue description
using pixi version 0.22.0, this pixi.toml file works fine.
using current main branch, it raise a thread 'main' has overflowed its stack. If move the numpy to [dependencies] table, this problem do not happen.
Also tried https://github.com/prefix-dev/pixi/blob/main/examples/flask-hello-world-pyproject/pyproject.toml and got the same problem.
Expected behavior
the pixi install command works as before.

I did some other trials. thread 'main' has overflowed its stack  only occurs when building pixi by cargo build.
If using cargo build -r, this problem doesn't happen.

Thanks for letting us know @Glatzel !


Rustvmm sync

Description of changes: Bring latest changes from rust-vmm/kvm-ioctls
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

No longer needed since https://github.com/firecracker-microvm/firecracker/pull/2319


[NOTICE] Update NOTICE for 2022

Why are the changes needed?
Welcome to 2022
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

thanks merged to master, 1.4, 1.3


Consolidate output and input utxo behaviour

:clipboard:  https://github.com/omisego/elixir-omg/pull/1212  larger scoped PR
Overview
This is a first pass at integrating our ex_plasma library to consolidate our encoding/decoding protocol with the plasma framework contracts. Currently, the codebase has begun to future code the ALD behavior. This reverts that and encourages the protocol related changes to be moved over to the library.
This is multi-stage integration. This first pass starts offloading the input utxo calculation and cleans up the structure to use more of ex_plasma data modeling. This also consolidates the output utxo modules a bit too. Following the discussion on #1212, this is intentionally a smaller scope as we move towards the integration of said library.
Follow up tasks:

[ ] refactor output utxo behavior/calculations and leverage ExPlasma.Utxo
[ ] refactor transactions to use ExPlasma.Transaction , and it's other types like Payment and Deposit.
[ ] port Fees transaction to ExPlasma and leverage that.
[ ] Remove dispatching module code, like WireTransactionTypes. This behavior should exist in the library.

Changes

Consolidates:

OMG.InputPointer  - this module "represents the data that's used to mention outputs that are intended to be inputs to a transaction"
OMG.InputPointer.UtxoPosition this "represents the utxo position interpreted as an implementation of an input pointer type"
OMG.InputPointer.Protocol - this "captures the varying behavior of how the outputs can be pointed to in child chain transactions"

into OMG.Utxo.Position, a pre-existing module that the modules above invoke in the call stack. This is a "representation of a UTXO position in the child chain, providing encoding/decoding to/from formats digestible in 'Eth' and in the OMG.DB".
Consolidating it into Utxo.Position seems like the best first pass as all the above modules end up calling functions in Utxo.Position in their call stack. Once we've merged the module behaviors, we can start delegating the functionality to ex_plasma more. Currently there are some behaviors that need to be aligned and refactored(OMG.Output error tuple behavior is one such example)

Adds doctests/unit tests for OMG.Utxo.Position. We didn't have unit test coverage for OMG.InputPointer , OMG.InputPointer.Position, OMG.InputPointer.Protocol.

Consolidates:

OMG.Output.Procotocol - This "captures the varying behavior of outputs that build the plasma chain"
OMG.Output.FungibleMoreVPToken - This is a "representation of the payment transaction output of a fungible token currency"

Into OMG.Output, which is "specifically dispatches generic calls to the various specific types". We currently have 1 type of output type so I think we should be wary of this future coding. Additionally, we should begin moving this encoding/decoding protocol behavior into ex_plasma to handle the dispatching.

Refactor functions that have similiar/exact behaviors and remove functions that were not used. Some examples:

OMG.Utxo.Position.decode/1.
OMG.Utxo.Position.blknum/1, OMG.Utxo.Position.txindex/1, OMG.Utxo.Position.oindex/1. These were at most used 1 time and a pattern match directly would have sufficed.
OMG.Output.reconstruct/1  - this merges with OMG.Output.dispatching_reconstruct/1 as the behaviour is now merged.

Testing
Run CI, alternatively, run the commands:
$ mix test

Coverage remained the same at ?% when pulling 381ae014e1f763d88fa5ef6af34bca62c525db4c on achiurizo/ex_utxo_2 into ef84b6e84292dbe11e2669fe1f01da8de57128b9 on master.


Displacement as a load

Hi everyone,
I want to bring a load as a displacement, but I dont know how. Could you help me please?

Hi @Murtaza-hash, you could use the boundary card:
*BOUNDARY
2,1,,0.1
Here I applied a 0.1 displacement at node 2 in the 1st direction.
Good luck!

Hi oldninja,
Thank you very very very x 1000 much. It has helped me. I searched that for days.


Procdump hangs on Windows containers

I want to make a proc dump of a process inside a Windows containers but it just hangs after printing the lines below
ProcDump v10.11 - Sysinternals process dump utility
Copyright (C) 2009-2021 Mark Russinovich and Andrew Richards
Sysinternals - www.sysinternals.com

The base images of my container is mcr.microsoft.com/dotnet/framework/aspnet:4.7.2-20210209-windowsservercore-ltsc2019

I was not providing -accepteula to the tool


使用provider6.0.0的该如何处理

正在使用flutter 2.5.1，dart 2.14.2，provider 6.0.0，但是pub get 一直提示flutter_custom_calendar依赖provider 的4.1.3。
Because every version of flutter_custom_calendar depends on provider ^4.1.3 and fm depends on provider ^6.0.0, flutter_custom_calendar is forbidden.
So, because fm depends on flutter_custom_calendar ^1.0.5, version solving failed.
pub get failed (1; So, because fm depends on flutter_custom_calendar ^1.0.5, version solving failed.)

dependency_overrides:
  provider: ^6.0.1


Spurious semicolon inside closure is not idempotent

Consider the following snippet.
fn foo() -> fn(i32) -> i32 {
    |a| {
        ;
        a
    }
}

Rustfmt starts by removing that spurious semicolon.
fn foo() -> fn(i32) -> i32 {
    |a| {
        a
    }
}

If run again, it notices that the closure fits on one line.
fn foo() -> fn(i32) -> i32 {
    |a| a
}

@rustbot claim


Removal of a DOM with an empty transition is not executed "immediately on next frame"

Vue.js version
2.0.0-rc.2
Reproduction Link
https://jsbin.com/degeceneci/edit?html,js,output
Steps to reproduce
Click any of the 4 buttons to create a corresponding DOM below. The DOM has an empty transition. Click a button whose corresponding DOM is already created to remove that DOM. To reproduce my problem, click the "a" button, and then click it again.
What is Expected?
first click prints:
immediate: []
next tick: [div]
second click prints:
immediate: [div]
next tick: []
What is actually happening?
first click prints:
immediate: []
next tick: [div]
second click prints:
immediate: [div]
next tick: [div.no-transition-leave.no-transition-leave-active]
According to the 2.0 doc:

If no CSS transitions/animations are detected and no JavaScript hooks are provided, the DOM operations for insertion and/or removal are executed immediately on next frame.

The first click(DOM insertion) works fine. But the second(DOM removal) fails. It's not removed on the next tick, and it still has transition-leave classes.

What Browser do you test this in? IT works as expected for me in chrome:

@LinusBorg Chrome 52.0.2743.116
doesn't work in safari or firefox as well

I'm on windows at the office right now, will check on OSX later. But it definitely works for me:

Please check out the console. As I mentioned above, what printed in the console is unexpected.

I see what you mean now, thanks.

no problem.

The reason is that nextFrame !== nextTick.
Next frame is decided by requestAnimationFrame, while nextTick is a mechanism for Vue's internal scheduling queue which uses the microtask queue (via MutationObserver). These are two different concepts.
The "next frame" timing is a implementation detail that you should not care about - instead you should be using the transition events/hooks to perform tasks at desired timings.


Rename RedirectDb to LinkDb

As with commit 7fa7ca9d from #112, this is to match the terminology of the project itself ("Custom Links").

Coverage remained the same at 98.069% when pulling 4b4294a897c35dc1ec32d30b71cbbd8a9b2e7d7d on rename-redirectdb-to-linkdb into 2b9e295c4ef9e6c9db06fe888db1a08d3b3104c2 on master.

Coverage remained the same at 98.069% when pulling 4b4294a897c35dc1ec32d30b71cbbd8a9b2e7d7d on rename-redirectdb-to-linkdb into 2b9e295c4ef9e6c9db06fe888db1a08d3b3104c2 on master.


[BUG]Table layout broken with auto pagination and merged cells

Category

[ ] Enhancement
[x] Bug
[ ] Question
[ ] Documentation gap/issue

Not sure whether this is a bug, or a potential enhancement to be implemented in the future. Please correct me if so.
Version
Please specify what version of the library you are using: [ v3.6.0 ]
Please specify what version(s) of PowerPoint you are targeting: [PowerPoint for Mac v16.50]
Expected / Desired Behavior
Basically, we have a table with different columns of merged cells (like a tree structure).  We have some value that belongs to several types, which further belongs to several categories. As the following table shows.

When data overflows one page, the desired table on the next page should look like this table, which contains the remaining merged cells from the previous page.

Observed Behavior
This is the observed behavior. It seems that when doing pagination, the library is only filling in the new table with solely the data from the previous row without tracing back further to the starting point where the merged cells are defined. (If I got it right, the merged cells are defined at the starting row of it.)

Steps to Reproduce
Running the following code will reproduce the situation.
  let taboptions = { x: 0.6, y: 1.3, w: "90%", h: 3, rowH: 0.1, margin: 0, fontSize: 12, align: "center", valign: "middle", border: { pt: "1" }, autoPage: true };

  let testRows = [
    [
      {text: "Category 1", options: {rowspan: 20}},
      "test"
    ]
  ]
  for (let i=0; i<19; i++){
    testRows.push(["test"])
  }
  slide.addTable(testRows, taboptions)

Any updates on this issue? @gitbrent

Closing this as table auto-paging was completely rewritten in release 3.8.0

Hi Brent,
I am facing same issue and we are using version "^3.9.0" . Any update on this?
Thank you
~TK


[REDO AFTER GH BUG] Add support for quantized models via QNN

This is part of https://github.com/apache/incubator-tvm/issues/5015. I simply reverted the revert done in #5013 .
@anijain2305 @jwfromm @jjohnson-arm Since the original PR, I finished preparing the repo for imagenet evaluation. We can use the 1k subset (data auto downloaded), or full validation set. The script and updated numbers are available here.

Thanks @anijain2305 @jwfromm


⚠ ClamAV has degraded performance

In 18d56e8, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 214 ms

Resolved: ClamAV performance has improved in 676fc21 after 12 minutes.


sig-buildsystem: Set some ownership

Setting some ownership to make it clear who can help to merge stuff
What this PR does / why we need it:
Setting owners for build - mostly bazel - related things.
We want this in order to know who can help, and who should care.
The list is loosely based on the git history on some bazel files.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
What other files/directories should be owned by sig-buildsystem
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[x] Design: A design document was considered and is present (link) or not required
[x] PR: The PR description is expressive enough and will help future contributors
[x] Code: Write code that humans can understand and Keep it simple
[x] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[x] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[x] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[x] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[x] Community: Announcement to kubevirt-dev was considered

Release note:

NONE

@dhiller @brianmcarey FYI

@dhiller @brianmcarey ping?

BUILD-bazel is included, I added workspace file.

@vladikr @davidvossel @dhiller any approvals?

/retest

/approve
As this is not extending any or introducing new permissions I'm self approving this.


more build fixes

Signed-off-by: Doug Davis<EMAIL_ADDRESS>

Disabling until we know if we have an account to use.


Skype Bot Calling not calling my api

I got my bot setup with the new api controller named CallingController with the following method
[Route("call")]
public async Task ProcessIncomingCallAsync()
I set the followings as the Calling Webhook, however they never get hit when i am making the call, any thought?
https://eddybot.azurewebsites.net/api/calling
https://eddybot.azurewebsites.net/api/calling/call

Have you enabled calling for your bot in developer portal and registered the calling endpoint?

Yes, when you say registered the calling endpoint, do you mean put the url in the Calling Webhook?

yes. I recommend testing your bot's endpoints locally by sending a json to it using fiddler or postman and making sure that your endpoints in your controller are exposed correctly.

I also try that by using postman, and the bot can handle the request with no problem

Eventually i figured out what the problem is, my api controller is missing the [BotAuthentication] attribute, it is all good now

I am not getting what to set the 1:1 webhook in developer window of skype and in code. Please help


Add starter for HDRIS

React three fiber starter project can use:
<Environment path="" files={path to hdri} background={true} />

Files that generate code are in src/helpers/code

I can also take this since it is related to #40

Still needs three.js code starter


Paste raw image from clipboard

May PR this myself, but I figured I'd open an issue either way. The #1 feature I would want in a tier list maker would be to copy and paste images directly from an image editor, without having to go through the tedious crop -> save file -> open in tier maker app process for every picture I want to add. It seems like this sort of thing is well supported now, although I haven't tried it myself yet:
https://stackoverflow.com/questions/6333814/how-does-the-paste-image-from-clipboard-functionality-work-in-gmail-and-google-c

Hello,
I tried quickly implementing the code in the SO reply in 4dae650 and it seems to be working well, at least on my browser (Firefox).
Feel free to try it and see if it works for you as well!


Garmin Sync Issue

Sync to Garmin seems to have broken since Monday (last successful sync).
I have seen somewhere that Garmin may have made a change to the API.
Either way, it no longer syncs. I can see that it pulls the data from Withings successfully and creates the *.fit file ok.

Definitely experiencing this as well. Last successful sync was 2024-11-24 (didn't have anything to sync on Monday)
The logs look like they are successful, but the data does not appear in Garmin:
2024-11-29 14:49:00,538 - root - INFO - Fetching measurements from 2024-11-24 00:00 to 2024-11-29 23:59
2024-11-29 14:49:00,917 - withings - INFO - Get Measurements
2024-11-29 14:49:01,234 - root - INFO - No weight data to sync for FIT file
2024-11-29 14:49:01,236 - root - INFO - No TrainerRoad username or a new measurement - skipping sync
2024-11-29 14:49:03,432 - root - INFO - Fit file with blood pressure information uploaded to Garmin Connect

this should be resolved with the last release.
see https://github.com/jaroslawhartman/withings-sync/pull/182


Simplified node internals and creation v3

Supercedes #345.
Rebased and fixed on top of #392 master.

Git etiquette Q: I should had probably removed those signed offs by @ljedrz? Strange it doesn't get done automatically.
Also, I most likely changed how the span is created, or then I just updated to have the default like it's in the latest master.

I don't mind the signed-off bits; as long as it works :ok_hand:.

Waiting for CI, I have two minor doc changes related to the defaults of IpfsOptions::{kad_protocol_name,span} but I'd say this would be ready to go after those.

Now with the Arc<Repo<_>> instead of Ipfs dependency in p2p::Behaviour we've at least discussed internally.

windows build agrees (wasn't sure of it)
bors r+


Missing include to fix unknown type 'uint32_t', uint64_t, etc.

Without this include, I'm getting a bunch of errors like:
/home/bart/meteo/models/microhh/external/kernel_launcher/include/kernel_launcher/utils.h:348:5: error: unknown type name 'uint32_t' [clang-diagnostic-error]
    uint32_t z;
    ^
/home/bart/meteo/models/microhh/external/kernel_launcher/include/kernel_launcher/utils.h:412:16: error: unknown type name 'uint64_t' [clang-diagnostic-error]
using hash_t = uint64_t;
               ^
/home/bart/meteo/models/microhh/external/kernel_launcher/include/kernel_launcher/utils.h:414:1: error: unknown type name 'hash_t' [clang-diagnostic-error]
hash_t hash_string(const char* buffer, size_t num_bytes);
^

Thanks! Seems like these are types are predefined in CUDA, but not by other compilers.


Adding final Icons from Design team

Description
Got the icons from the design team.
Release required?

[x] No release
[ ] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

@bhakta-ibm Can you update the offering_icon_url value in the ibm_catalog.json to point to the icon we want to show in the catalog? Lock into main branch URL so it will always show the latest

Done

/run pipeline

/run pipeline

:tada: This PR is included in version 0.0.4 :tada:
The release is available on:

GitHub release
v0.0.4

Your semantic-release bot :package::rocket:


Add documentation for coverage

Awesome package! I've been in Javascript testing hell for the past week or so. Long story short I wrote my first javascript package and I'm trying to get it hooked into Travis and Coveralls. I was able to use Mocha from the cli but I couldn't cover anything that used jQuery in my code. If I went to a browser based solution I couldn't run from the cli.
Enter mocha-phantomjs. It's exactly what I needed. I'm having trouble figuring out how I can hook into blanket or Istanbul though to produce coverage info for coveralls. I'd like to lend a hand and help out here. I'm going to dig in and try and figure out how to incorporate them but I'd appreciate any advice if someone has already solved this problem.

Yup we need documentation on this. Currently your best documentation is in #99 here

Actually I didn't know this existed until just now - mocha-phantomjs-istanbul

So, how did you solve your problem?

I would also like to know how you solved this, because mocha-phantomjs-istanbul seems to not work anymore.


Sometimes PostStartHookError message is "" even though the event has a error log

I'm using a lot of (container lifecycle hooks)[https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks] and these will output errors if something goes wrong, sometimes the slackbot does not print the message
for example here it printed the bash error in full because the file isn't chmod +x:
Container entered status *PostStartHookError*
```Exec lifecycle hook ([/usr/bin/dumb-init -- /bin/bash -c sleep 10 && /etc/hooks.d/ValidateService.sh]) for Container "k8s-app" in Pod "k8s-app-6d9858ddb7-t2jqp_default(8e650045-641b-11e8-a16d-021a35178fd6)" failed - error: command '/usr/bin/dumb-init -- /bin/bash -c sleep 10 && /etc/hooks.d/ValidateService.sh' exited with 126: /bin/bash: /etc/hooks.d/ValidateService.sh: Permission denied
, message: "/bin/bash: /etc/hooks.d/ValidateService.sh: Permission denied\n"```
default/k8s-app-6d9858ddb7-t2jqp/k8s-app
Container entered status *PostStartHookError*
```Exec lifecycle hook ([/usr/bin/dumb-init -- /bin/bash -c sleep 10 && /etc/hooks.d/ValidateService.sh]) for Container "k8s-app" in Pod "k8s-app-6d9858ddb7-t2jqp_default(8e650045-641b-11e8-a16d-021a35178fd6)" failed - error: command '/usr/bin/dumb-init -- /bin/bash -c sleep 10 && /etc/hooks.d/ValidateService.sh' exited with 126: /bin/bash: /etc/hooks.d/ValidateService.sh: Permission denied
, message: "/bin/bash: /etc/hooks.d/ValidateService.sh: Permission denied\n"```

while when the script was executed and outputted a error slack message is ""
Container entered status *PostStartHookError*
```Exec lifecycle hook ([/usr/bin/dumb-init -- /bin/bash -c sleep 10 && bash /etc/hooks.d/ValidateService.sh]) for Container "k8s-app" in Pod "k8s-app-66f89b584f-5kstg_default(be87b3f7-641b-11e8-a16d-021a35178fd6)" failed - error: command '/usr/bin/dumb-init -- /bin/bash -c sleep 10 && bash /etc/hooks.d/ValidateService.sh' exited with 137: , message: ""```
default/k8s-app-66f89b584f-5kstg/k8s-app
Container entered status *PostStartHookError*
```Exec lifecycle hook ([/usr/bin/dumb-init -- /bin/bash -c sleep 10 && bash /etc/hooks.d/ValidateService.sh]) for Container "k8s-app" in Pod "k8s-app-66f89b584f-5kstg_default(be87b3f7-641b-11e8-a16d-021a35178fd6)" failed - error: command '/usr/bin/dumb-init -- /bin/bash -c sleep 10 && bash /etc/hooks.d/ValidateService.sh' exited with 137: , message: ""```

the event looks perfectly fine in k8s api when i get it with kubectl get events
49m         49m          1         k8s-app-66f89b584f-jhppk.153376985d155a0b   Pod          spec.containers{k8s-app}   Warning   FailedPostStartHook     kubelet, ip-10-0-116-153.eu-west-1.compute.internal   Exec lifecycle hook ([/usr/bin/dumb-init -- /bin/bash -c sleep 10 && bash /etc/hooks.d/ValidateService.sh]) for Container "k8s-app" in Pod "k8s-app-66f89b584f-jhppk_default(58e883ed-6420-11e8-a16d-021a35178fd6)" failed - error: command '/usr/bin/dumb-init -- /bin/bash -c sleep 10 && bash /etc/hooks.d/ValidateService.sh' exited with 1: , message: "{\n\"cmdline\": [\"/opt/k8s-app/k8s-app\"nTest case FAILED!\nExpected:\n{\n  \"labels\": [\n    {\n      \"foo\": 7.9950147\n    }\n  ],\n  \"tokens\": null\n}\nReceived:\nFAIL ME HARD\n"

looks like this is not activly maintained, will look for other solutions


Create signed releases

Reference: Signing releases on GitHub
https://wiki.debian.org/Creating signed GitHub releases

Git sign

setup gpg localy and git https://docs.github.com/en/authentication/managing-commit-signature-verification/associating-an-email-with-your-gpg-key

Go to git account and enabled Vigilant mode
https://github.com/settings/keys

Enable mandatory sign contributes on protected branch (Enabled Require signed commits
Commits pushed to matching branches must have verified signatures.)

Sign commit commands https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits

Sign Tags commands https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-tags

@kchetans Both me & surendra have enabled signed commits. Please enable it for you too, then we can close this issue.

Looks like everyone is using signed commits now, we can close this


libvirt_exporter를 이용한 VM 모니터링

이슈 타입

새 기능 아이디어

컴포넌트 이름

VM, UI

ABLESTACK 버전

ABLESTACK Bronto

구성

VM 모니터링

OS / 환경

CentOS 8.3, Grafana 7.5.5, Prometheus-2.26.0, libvirt_exporter

이슈 내용

node_exporter를 이용하여 VM(CentOS 8.3, Windows10)의 cpu, memory, disk IO, network IO 등의 데이터를 수집하고 Grafana를 통하여 실시간 그래프로 해당 내용을 모니터링 할 수 있는지, 실제 데이터와 수집되는 데이터의 정확성 여부 등을 테스트
재현 과정

기대한 결과

실제 결과

Monitoring VM 구성
Grafana 설치
Grafana는 CentOS 8.3 에서 dnf 명령어를 이용하여 설치합니다. 설치 하기 위해서는 다음 repo가 필요합니다.
grafana release는 Enterprise edition과 Open Source edition이 있으며 Enterprise edition을 권장하지만 별도의 subscription이 필요한 것 같습니다. 테스트에서는 enterprise edition을 이용했습니다.
참고 링크 : https://grafana.com/docs/grafana/latest/installation/rpm/
/etc/yum.repos.d/grafana.repo

[grafana]
name=grafana
baseurl=https://packages.grafana.com/enterprise/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt

dnf install -y grafana
systemctl daemon-reload
systemctl enable --now grafana

Prometheus 설치
Prometheus는 tar 파일을 다운로드 받아 설치합니다.
참고 링크 : https://prometheus.io/download/

promethues는 기본적으로 9090 포트를 사용하며 cockpit과 중복됩니다. 테스트에서는 prometheus 포트를 변경하지 않고 cockpit 서비스를 중지한 환경에서 진행하였습니다.

prometheus.yml 파일에 target vm, port를 지정해야합니다.
예시
    static_configs:
    - targets: ['<IP_ADDRESS>:9100']

libvirt_exporter를 이용한 monitoring 구성
libvirt_exporter 설치
libvirt_exporter는 Alpine linux 환경에서 build를 통하여 실행파일을 생성합니다. 최초 1회 빌드 하여 실행파일을 생성하면, 실행파일만 복사하여 다른 호스트에서 사용할 수 있습니다.
참고 링크 : https://github.com/rumanzo/libvirt_exporter_improved

libvirt_exporter는 prometheus/prometheus-community에서 공식적으로 지원하는 exporter는 아닌 것으로 확인됩니다. 테스트에서는 rumanzo의 git repository를 참조 하였습니다.

libvirt_exporter(파일명:libvirt_exporter)를 호스트에서 실행합니다. libvirt_exporter의 default port는 9177/tcp 입니다.
libvirt_exporter 장점

호스트에만 설치하면 해당 호스트에서 실행되고 있는 모든 VM의 cpu, memory, disk, network 등의 사용량, IO 데이터를 수집할 수 있음
vm이 추가되더라도 prometheus.yml 파일에 설정 값을 추가하지 않아도 됨

libvirt_exporter 단점

libvirt 기반이기 때문에 KVM 환경에서만 사용할 수 있음

libvirt_exporter를 사용하기 위한 필요 조건

memballoon driver를 설치해야 데이터 수집이 가능함
ABLESTACK Mold 소스 수정 및 window vm의 경우 memballoon driver를 설치해야 함

libvirt_exporter 수집 데이터 항목
libvirt_domain_block_stats_allocation

HELP
libvirt_domain_block_stats_allocation Offset of the highest written sector on a block device.

TYPE
libvirt_domain_block_stats_allocation counter

libvirt_domain_block_stats_capacity

HELP
libvirt_domain_block_stats_capacity Logical size in bytes of the block device backing image.

TYPE
libvirt_domain_block_stats_capacity counter

libvirt_domain_block_stats_flush_requests_total

HELP
libvirt_domain_block_stats_flush_requests_total Total flush requests from a block device.

TYPE
libvirt_domain_block_stats_flush_requests_total counter

libvirt_domain_block_stats_flush_total

HELP
libvirt_domain_block_stats_flush_total Total time (ns) spent on cache flushing to a block device, in ns, that is, 1/1,000,000,000 of a second, or 10−9 seconds.

TYPE
libvirt_domain_block_stats_flush_total counter

libvirt_domain_block_stats_physicalsize

HELP
libvirt_domain_block_stats_physicalsize Physical size in bytes of the container of the backing image.

TYPE
libvirt_domain_block_stats_physicalsize counter

libvirt_domain_block_stats_read_bytes_total

HELP
libvirt_domain_block_stats_read_bytes_total Number of bytes read from a block device, in bytes.

TYPE
libvirt_domain_block_stats_read_bytes_total counter

libvirt_domain_block_stats_read_requests_total

HELP
libvirt_domain_block_stats_read_requests_total Number of read requests from a block device.

TYPE
libvirt_domain_block_stats_read_requests_total counter

libvirt_domain_block_stats_read_time_total

HELP
libvirt_domain_block_stats_read_time_total Total time (ns) spent on reads from a block device, in ns, that is, 1/1,000,000,000 of a second, or 10−9 seconds.

TYPE
libvirt_domain_block_stats_read_time_total counter

libvirt_domain_block_stats_write_bytes_total

HELP
libvirt_domain_block_stats_write_bytes_total Number of bytes written to a block device, in bytes.

TYPE
libvirt_domain_block_stats_write_bytes_total counter

libvirt_domain_block_stats_write_requests_total

HELP
libvirt_domain_block_stats_write_requests_total Number of write requests to a block device.

TYPE
libvirt_domain_block_stats_write_requests_total counter

libvirt_domain_block_stats_write_time_total

HELP
libvirt_domain_block_stats_write_time_total Total time (ns) spent on writes on a block device, in ns, that is, 1/1,000,000,000 of a second, or 10−9 seconds.

TYPE
libvirt_domain_block_stats_write_time_total counter

libvirt_domain_info_cpu_steal_time_total

HELP
libvirt_domain_info_cpu_steal_time_total Amount of CPU time stolen from the domain, in ns, that is, 1/1,000,000,000 of a second, or 10−9 seconds.

TYPE
libvirt_domain_info_cpu_steal_time_total counter

libvirt_domain_info_cpu_time_seconds_total

HELP
libvirt_domain_info_cpu_time_seconds_total Amount of CPU time used by the domain, in seconds.

TYPE
libvirt_domain_info_cpu_time_seconds_total counter

libvirt_domain_info_maximum_memory_bytes

HELP
libvirt_domain_info_maximum_memory_bytes Maximum allowed memory of the domain, in bytes.

TYPE
libvirt_domain_info_maximum_memory_bytes gauge

libvirt_domain_info_memory_usage_bytes

HELP
libvirt_domain_info_memory_usage_bytes Memory usage of the domain, in bytes.

TYPE
libvirt_domain_info_memory_usage_bytes gauge

libvirt_domain_info_virtual_cpus

HELP
libvirt_domain_info_virtual_cpus Number of virtual CPUs for the domain.

TYPE
libvirt_domain_info_virtual_cpus gauge

libvirt_domain_info_vstate

HELP
libvirt_domain_info_vstate Virtual domain state. 0: no state, 1: the domain is running, 2: the domain is blocked on resource, 3: the domain is paused by user, 4: the domain is being shut down, 5: the domain is shut off,6: the domain is crashed, 7: the domain is suspended by guest power management

TYPE
libvirt_domain_info_vstate counter

libvirt_domain_interface_stats_receive_bytes_total

HELP
libvirt_domain_interface_stats_receive_bytes_total Number of bytes received on a network interface, in bytes.

TYPE
libvirt_domain_interface_stats_receive_bytes_total counter

libvirt_domain_interface_stats_receive_drops_total

HELP
libvirt_domain_interface_stats_receive_drops_total Number of packet receive drops on a network interface.

TYPE
libvirt_domain_interface_stats_receive_drops_total counter

libvirt_domain_interface_stats_receive_errors_total

HELP
libvirt_domain_interface_stats_receive_errors_total Number of packet receive errors on a network interface.

TYPE
libvirt_domain_interface_stats_receive_errors_total counter

libvirt_domain_interface_stats_receive_packets_total

HELP
libvirt_domain_interface_stats_receive_packets_total Number of packets received on a network interface.

TYPE
libvirt_domain_interface_stats_receive_packets_total counter

libvirt_domain_interface_stats_transmit_bytes_total

HELP
libvirt_domain_interface_stats_transmit_bytes_total Number of bytes transmitted on a network interface, in bytes.

TYPE
libvirt_domain_interface_stats_transmit_bytes_total counter

libvirt_domain_interface_stats_transmit_drops_total

HELP
libvirt_domain_interface_stats_transmit_drops_total Number of packet transmit drops on a network interface.

TYPE
libvirt_domain_interface_stats_transmit_drops_total counter

libvirt_domain_interface_stats_transmit_errors_total

HELP
libvirt_domain_interface_stats_transmit_errors_total Number of packet transmit errors on a network interface.

TYPE
libvirt_domain_interface_stats_transmit_errors_total counter

libvirt_domain_interface_stats_transmit_packets_total

HELP
libvirt_domain_interface_stats_transmit_packets_total Number of packets transmitted on a network interface.

TYPE
libvirt_domain_interface_stats_transmit_packets_total counter

libvirt_domain_memory_stats_actual_balloon

HELP
libvirt_domain_memory_stats_actual_balloon Current balloon value (in KB).

TYPE
libvirt_domain_memory_stats_actual_balloon counter

libvirt_domain_memory_stats_available

HELP
libvirt_domain_memory_stats_available The total amount of usable memory as seen by the domain. This value may be less than the amount of memory assigned to the domain if a balloon driver is in use or if the guest OS does not initialize all assigned pages. This value is expressed in kB.

TYPE
libvirt_domain_memory_stats_available counter

libvirt_domain_memory_stats_disk_cache

HELP
libvirt_domain_memory_stats_disk_cache The amount of memory, that can be quickly reclaimed without additional I/O (in kB).Typically these pages are used for caching files from disk.

TYPE
libvirt_domain_memory_stats_disk_cache counter

libvirt_domain_memory_stats_major_fault

HELP
libvirt_domain_memory_stats_major_fault Page faults occur when a process makes a valid access to virtual memory that is not available. When servicing the page fault, if disk IO is required, it is considered a major fault.

TYPE
libvirt_domain_memory_stats_major_fault counter

libvirt_domain_memory_stats_minor_fault

HELP
libvirt_domain_memory_stats_minor_fault Page faults occur when a process makes a valid access to virtual memory that is not available. When servicing the page not fault, if disk IO is required, it is considered a minor fault.

TYPE
libvirt_domain_memory_stats_minor_fault counter

libvirt_domain_memory_stats_rss

HELP
libvirt_domain_memory_stats_rss Resident Set Size of the process running the domain. This value is in kB

TYPE
libvirt_domain_memory_stats_rss counter

libvirt_domain_memory_stats_unused

HELP
libvirt_domain_memory_stats_unused The amount of memory left completely unused by the system. Memory that is available but used for reclaimable caches should NOT be reported as free. This value is expressed in kB.

TYPE
libvirt_domain_memory_stats_unused counter

libvirt_domain_memory_stats_usable

HELP
libvirt_domain_memory_stats_usable How much the balloon can be inflated without pushing the guest system to swap, corresponds to 'Available' in /proc/meminfo

TYPE
libvirt_domain_memory_stats_usable counter

libvirt_domain_memory_stats_used_percent

HELP
libvirt_domain_memory_stats_used_percent The amount of memory in percent, that used by domain.

TYPE
libvirt_domain_memory_stats_used_percent counter

libvirt_up

HELP
libvirt_up Whether scraping libvirt's metrics was successful.

TYPE
libvirt_up gauge

go_gc_duration_seconds

HELP
go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.

TYPE
go_gc_duration_seconds summary

go_goroutines

HELP
go_goroutines Number of goroutines that currently exist.

TYPE
go_goroutines gauge

go_info

HELP
go_info Information about the Go environment.

TYPE
go_info gauge

go_memstats_alloc_bytes

HELP
go_memstats_alloc_bytes Number of bytes allocated and still in use.

TYPE
go_memstats_alloc_bytes gauge

go_memstats_alloc_bytes_total

HELP
go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed.

TYPE
go_memstats_alloc_bytes_total counter

go_memstats_buck_hash_sys_bytes

HELP
go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table.

TYPE
go_memstats_buck_hash_sys_bytes gauge

go_memstats_frees_total

HELP
go_memstats_frees_total Total number of frees.

TYPE
go_memstats_frees_total counter

go_memstats_gc_cpu_fraction

HELP
go_memstats_gc_cpu_fraction The fraction of this program's available CPU time used by the GC since the program started.

TYPE
go_memstats_gc_cpu_fraction gauge

go_memstats_gc_sys_bytes

HELP
go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata.

TYPE
go_memstats_gc_sys_bytes gauge

go_memstats_heap_alloc_bytes

HELP
go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in use.

TYPE
go_memstats_heap_alloc_bytes gauge

go_memstats_heap_idle_bytes

HELP
go_memstats_heap_idle_bytes Number of heap bytes waiting to be used.

TYPE
go_memstats_heap_idle_bytes gauge

go_memstats_heap_inuse_bytes

HELP
go_memstats_heap_inuse_bytes Number of heap bytes that are in use.

TYPE
go_memstats_heap_inuse_bytes gauge

go_memstats_heap_objects

HELP
go_memstats_heap_objects Number of allocated objects.

TYPE
go_memstats_heap_objects gauge

go_memstats_heap_released_bytes

HELP
go_memstats_heap_released_bytes Number of heap bytes released to OS.

TYPE
go_memstats_heap_released_bytes gauge

go_memstats_heap_sys_bytes

HELP
go_memstats_heap_sys_bytes Number of heap bytes obtained from system.

TYPE
go_memstats_heap_sys_bytes gauge

go_memstats_last_gc_time_seconds

HELP
go_memstats_last_gc_time_seconds Number of seconds since 1970 of last garbage collection.

TYPE
go_memstats_last_gc_time_seconds gauge

go_memstats_lookups_total

HELP
go_memstats_lookups_total Total number of pointer lookups.

TYPE
go_memstats_lookups_total counter

go_memstats_mallocs_total

HELP
go_memstats_mallocs_total Total number of mallocs.

TYPE
go_memstats_mallocs_total counter

go_memstats_mcache_inuse_bytes

HELP
go_memstats_mcache_inuse_bytes Number of bytes in use by mcache structures.

TYPE
go_memstats_mcache_inuse_bytes gauge

go_memstats_mcache_sys_bytes

HELP
go_memstats_mcache_sys_bytes Number of bytes used for mcache structures obtained from system.

TYPE
go_memstats_mcache_sys_bytes gauge

go_memstats_mspan_inuse_bytes

HELP
go_memstats_mspan_inuse_bytes Number of bytes in use by mspan structures.

TYPE
go_memstats_mspan_inuse_bytes gauge

go_memstats_mspan_sys_bytes

HELP
go_memstats_mspan_sys_bytes Number of bytes used for mspan structures obtained from system.

TYPE
go_memstats_mspan_sys_bytes gauge

go_memstats_next_gc_bytes

HELP
go_memstats_next_gc_bytes Number of heap bytes when next garbage collection will take place.

TYPE
go_memstats_next_gc_bytes gauge

go_memstats_other_sys_bytes

HELP
go_memstats_other_sys_bytes Number of bytes used for other system allocations.

TYPE
go_memstats_other_sys_bytes gauge

go_memstats_stack_inuse_bytes

HELP
go_memstats_stack_inuse_bytes Number of bytes in use by the stack allocator.

TYPE
go_memstats_stack_inuse_bytes gauge

go_memstats_stack_sys_bytes

HELP
go_memstats_stack_sys_bytes Number of bytes obtained from system for stack allocator.

TYPE
go_memstats_stack_sys_bytes gauge

go_memstats_sys_bytes

HELP
go_memstats_sys_bytes Number of bytes obtained from system.

TYPE
go_memstats_sys_bytes gauge

go_threads

HELP
go_threads Number of OS threads created.

TYPE
go_threads gauge

process_cpu_seconds_total

HELP
process_cpu_seconds_total Total user and system CPU time spent in seconds.

TYPE
process_cpu_seconds_total counter

process_max_fds

HELP
process_max_fds Maximum number of open file descriptors.

TYPE
process_max_fds gauge

process_open_fds

HELP
process_open_fds Number of open file descriptors.

TYPE
process_open_fds gauge

process_resident_memory_bytes

HELP
process_resident_memory_bytes Resident memory size in bytes.

TYPE
process_resident_memory_bytes gauge

process_start_time_seconds

HELP
process_start_time_seconds Start time of the process since unix epoch in seconds.

TYPE
process_start_time_seconds gauge

process_virtual_memory_bytes

HELP
process_virtual_memory_bytes Virtual memory size in bytes.

TYPE
process_virtual_memory_bytes gauge

process_virtual_memory_max_bytes

HELP
process_virtual_memory_max_bytes Maximum amount of virtual memory available in bytes.

TYPE
process_virtual_memory_max_bytes gauge

promhttp_metric_handler_requests_in_flight

HELP
promhttp_metric_handler_requests_in_flight Current number of scrapes being served.

TYPE
promhttp_metric_handler_requests_in_flight gauge

promhttp_metric_handler_requests_total

HELP
promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code.

TYPE
promhttp_metric_handler_requests_total counter


Add container hostname to /etc/hosts

Add the container hostname to /etc/hosts as localhost addresses (127.1 and ::1).
This is a quick fix for bridged container networks where the source and destination ip would otherwise be the same (seen from the bridge) and thus cause a socket collision. A caveat is if the container has logic that explicitly needs to resolve the DNS entry for itself (but I don't think that is the the case).
An alternative using iptables in the container will also be implemented together with a revamped ACL implementation.

Superseded by https://github.com/vespa-engine/vespa/pull/5513


feat: Expose tick functions

This introduces methods to Timestream to create tick-streams, and allows passing a function to construct such a tickstream as the predicate for since and sliding windows.

This looks like a good pattern

@jordanrfrazier

This looks like a good pattern

Yeah -- I think this makes sense for the Rust side. As noted in #697, we can discuss encapsulating the ticks themselves in the windows:
e.sum(window = kd.windows.hourly())
e.sum(window = kd.windows.Session(3, kd.windows.hourly()))

as a way of reducing the number of concepts (no such thing as ticks are exposed) and a way to let us experiment with richer windows. For instance, I think we can define both since hourly and outputting once at the end of the hour nearly in Python (using some of the shift-by-1-nanosecond style tricks), and it would let us experiment with the way those concepts fit together over time.

Looks good, the lambda is really clever. I still think we'll want to go the route of offering explicit parameters to the windows themselves, like tumbling(units, duration, offset), which I suppose we could do in a builder pattern
kd.window.Tumbling().duration(5).units(kd.units.Second)

I think if we go that route, I'd be more inclined to do kd.window.Tumbling(seconds = 5) or taking a timedelta, etc. Specifically, we shouldn't define units ourselves.


Weight should popup a numerical keyboard instead of a text keyboard

and perhaps a way to set the units.

Fixed, but now the problem is that the unit is not properly set. Perhaps a dropdown with common units ?

Certainly, I can do it

Fix in 630e2fa415d2c87a7d485266c9756dea58d59c54


Duplicates

There are a few duplicates in the list, I'll either list them here for you, or dive into the source code and edit them later if you don't mind :)

Thanks @AdhamNasr :)
I've pushed an update in d3fb62828d7606663276e3cb99bf8e7c533377ea which better removes duplicates (I think all of them, except where configs are very different).
Right now, the order of the sources determines which template will take president, maybe there's a better method?

Not sure if there is, I couldn't check the sourcecode this weekend, but I'll try to squeeze sometime in and get back to you as soon as I can 😊


Feature/game2.0

Now the game has one Spaceship with multiple Dice with custom faces and is played on a custom board with custom position of wormhole

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

37 of 37 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
113

Relevant Lines:
113

💛  - Coveralls


read multiple registers

Hi,
I want to use Modbux RTU to communicate with 4 slave devices where I want to read multiple registers with one request. I can't find that this is possible in the documentation. Is it? Right now I am filling the map to map correctly values to keys with Task.asyncs where each of them has a master request in it. But I am getting a lot of timeouts. And then when all results are back I fill those into struct then. Sometimes I don't get value on a request, but if I then repeat request I do. My boudrate is 19200 which should be ok.
Can you please suggest what would be the best approach for this? Is this possible with Modbux library?
Thank you in advance.
Tomaz

Hi,
Are you trying to communicate with the 4 slave at once? Or the question is just to read multiple registers?
To read multiple registers, you can use:
# Starts the Master at "ttyUSB1" (in the example is connected to ttyUSB1)
{:ok, m_pid} = Modbux.Rtu.Master.start_link(tty: "ttyUSB1")
# Read 2 holding registers at 1 (memory address) from the slave 80
resp = Modbux.Rtu.Master.request(m_pid, {:rhr, 80, 1, 2})
# resp == {:ok, [102, 103]}

If you are trying to communicate with the 4 slave at once, I'm afraid it is not possible, since in Modbus RTU, each communication request is directed to a single slave at a time, and the registers being read or written belong to that specific slave. There is no single command in Modbus RTU that allows you to request multiple registers from multiple slaves in one operation. Also, you have to be aware of the physical layer, assuming you are using RS485, since this is a bus, it does not inherently handle multiple messages simultaneously.  The only way in which this might work is to have multiple masters connected, each one directly to one slave on different buses. Modbus does support broadcast, but the slaves won't answer any read request.
I hope this helps you.

Hi,
I'm afraid that in Modbus RTU, it is not possible to request non-contiguous registers with a single command. The register read commands (such as Read Holding Registers or Read Input Registers) allow you to specify a range of contiguous registers.
If you need to read registers that are not contiguous, you must send multiple commands, one for each contiguous range of registers you need to read.
Alternatively, if you can read a wider range that includes all the registers you are interested in, you could do that and then simply extract the specific register values you need. This might be more efficient than sending multiple separate commands, depending on the situation and the slave capabilities.

Hi,
I tried to request multiple addresses at once (like 50 of them), but when I get back {:ok, [value1, value2, .... value N]}, the values are not in order. So I can't know what value is for what address. Is there any way to do that? If I knew that values are returned in order, I could easily pattern-match them to get the needed values. But at first glance, I can see values are not being returned in order (of Modbus addresses).

As far as I know the values should be in order, can you share any logs of those frames??

Ok, I found the typo. My bad. Can I ask about multiple register write command here? Or should I open new "issue"?
In the documentation I can see this
{:fc, slave, address, value} force single coil.
{:phr, slave, address, value} preset single holding register.
{:fc, slave, address, values} force multiple coils.
{:phr, slave, address, values} preset multiple holding registers.
So I assume I can use the last one to write multiple registers (which are in continuous order). So how would a command be for write to registers 14, 15, 16 and 17 a value of 0?
Thank you.

Yes, you can, there is an example of use case for Modbus TCP here.
So, can I close this issue??

Great, thank you. I will close it yes.