File path is lost when translating stack traces

When using node-source-map-support (v0.2.10) via babel-node, file paths are being lost for the files local to the package.  This also occurs when I override babel's copy to<EMAIL_ADDRESS>With the file foo/bar.js:
console.trace();
console.log(new Error().stack);

When running the file via regular node, I get stack traces with full file paths:
> node foo/bar.js
Trace
    at Object.<anonymous> (/babel-repro/foo/bar.js:1:71)
    at Module._compile (module.js:434:26)
    at Object.Module._extensions..js (module.js:452:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:475:10)
    at startup (node.js:117:18)
    at node.js:951:3
Error
    at Object.<anonymous> (/babel-repro/foo/bar.js:2:13)
    at Module._compile (module.js:434:26)
    at Object.Module._extensions..js (module.js:452:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:475:10)
    at startup (node.js:117:18)
    at node.js:951:3

When running with babel-node, the path of the source file is lost:
> babel-node foo/bar.js
Trace
    at Object.<anonymous> (bar.js:1:17)
    at Module._compile (module.js:434:26)
    at loader (/Users/ian/.nvm/versions/node/v4.1.0/lib/node_modules/babel-cli/node_modules/babel-register/lib/node.js:130:5)
    at Object.require.extensions.(anonymous function) [as .js] (/Users/ian/.nvm/versions/node/v4.1.0/lib/node_modules/babel-cli/node_modules/babel-register/lib/node.js:140:7)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:475:10)
    at /Users/ian/.nvm/versions/node/v4.1.0/lib/node_modules/babel-cli/lib/_babel-node.js:161:27
    at Object.<anonymous> (/Users/ian/.nvm/versions/node/v4.1.0/lib/node_modules/babel-cli/lib/_babel-node.js:162:7)
    at Module._compile (module.js:434:26)
Error
    at Object.<anonymous> (bar.js:2:13)
    at Module._compile (module.js:434:26)
    at loader (/Users/ian/.nvm/versions/node/v4.1.0/lib/node_modules/babel-cli/node_modules/babel-register/lib/node.js:130:5)
    at Object.require.extensions.(anonymous function) [as .js] (/Users/ian/.nvm/versions/node/v4.1.0/lib/node_modules/babel-cli/node_modules/babel-register/lib/node.js:140:7)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:475:10)
    at /Users/ian/.nvm/versions/node/v4.1.0/lib/node_modules/babel-cli/lib/_babel-node.js:161:27
    at Object.<anonymous> (/Users/ian/.nvm/versions/node/v4.1.0/lib/node_modules/babel-cli/lib/_babel-node.js:162:7)
    at Module._compile (module.js:434:26)

This occurs at any directory depth; only the file's base name survives. Is there something Babel's doing incorrectly here?
For reference, Babel sets up source-map-support via babel-register
Related Babel issue: https://phabricator.babeljs.io/T6839

I have the same problem. I am just wondering why babel doesn't have correct line numbers if it is including source map support? I only added this node-source-map-support because I saw that the line numbers were wrong with -r babel-core/register…

Scratch that, the absolute paths are also gone without node-source-map-support. This must be squarely babel's fault.
You can verify this yourself by looking at ~/.babel.json, which is the babel cache. The files are missing their full path, it seems.

I am seeing a similar problem with typescript and inlineSourceMaps option. external sourceMaps works fine.

I don't think it's a source map issue. If I am not wrong it is probably generated with stripped file path. You can check it if you open it (decode it if you are using inline maps) and look at the "sources" field.
I was having the same issue and solved it by passing absolute path as "sourceFileName" directly to babel options: https://github.com/babel/babel/blob/master/packages/babel-register/src/node.js#L68-L74

@v3lbloud You are my saver! I was tried your solution some time ago but it didn't help, now I tried it again but first removed babel cache file ~/.babel.json, and it worked!

@ilearnio I am glad I could help :)


Incorrect PowerShell command

on the page https://learn.microsoft.com/en-us/microsoftteams/rooms/rooms-operations, under the section named "Remote Management using PowerShell", the PowerShell command text for "To Get Attached Devices" should read "Camera" and not "Image", as the PNPClass "Image" is not correct. - see below:
invoke-command {Write-Host "VIDEO DEVICES:"
gwmi -Class Win32_PnPEntity | where {$.PNPClass -eq "Camera"} | Format-Table Name,Status,Present; Write-Host "AUDIO DEVICES:"
gwmi -Class Win32_PnPEntity | where {$.PNPClass -eq "Media"} | Format-Table Name,Status,Present; Write-Host "DISPLAY DEVICES:"
gwmi -Class Win32_PnPEntity | where {$_.PNPClass -eq "Monitor"} | Format-Table Name,Status,Present} -ComputerName
Hope that helps...

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

ID: fd52fe62-457b-c9e1-ad13-a9b1f24c9c38
Version Independent ID: 6a8c3285-30e1-15a8-6472-f0cfe5b30e20
Content: Microsoft Teams Rooms maintenance and operations - Microsoft Teams
Content Source: Teams/rooms/rooms-operations.md
Service: msteams
Sub-service: itpro-rooms
GitHub Login: @tonysmit
Microsoft Alias: tonysmit

Hello @docpauluk how are you?
I was able to query filtering both by PNPClass "Image" and "Camera"

Hi Andres,
Thanks for the feedback - whilst "Image" is a valid query, it won't return
any video devices.
With Camera, we see the cameras listed:
[image: image.png]
With Image - no cameras listed for the same Teams Room:
[image: image.png]
I guess for completeness you could add an OR in there so it returned both
Image and Camera devices...
and optionally move from Get-WMIObject to Get-CIMInstance (gcim).
I hope that helps.
Paul Hargrove
On Tue, 18 Jul 2023 at 09:33, Andres Mariano Gorzelany <
@.***> wrote:

Hello @docpauluk https://github.com/docpauluk how are you?
I was able to query filtering both by PNPClass "Image" and "Camera"
—
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/10187#issuecomment-1638916623,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGZEXX5QUJDVMP7VAWXXESDXQWVSXANCNFSM6AAAAAA2MLURUE
.
You are receiving this because you were mentioned.Message ID:
@.***
com>

Hello @docpauluk
Your images weren't attached to your message, can you check so I can compare and investigate further?
Thanks

Sorry about that, I've added the images to the post.
On Wed, 19 Jul 2023 at 01:41, Andres Mariano Gorzelany <
@.***> wrote:

Hello @docpauluk https://github.com/docpauluk
Your images weren't attached to your message, can you check so I can
compare and investigate further?
Thanks
—
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/10187#issuecomment-1640251779,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGZEXX7J5M5HQLHCXAWP2V3XQ2HAZANCNFSM6AAAAAA2MLURUE
.
You are receiving this because you were mentioned.Message ID:
@.***
com>

Thanks.
While something that could be valid for your MTR device maybe can't be valid for another and unfortunately I don't have a way to test every device. I'll try to confirm if we can change the current filters.
Thank you

Ok, thanks.
According to Microsoft docs, PnPClass Image is for still image devices such
as digital cameras and scanners, whilst PnP Class Camera is for universal
Camera drivers.
Also, Teams Rooms need Windows 21H2 or later so cameras should be using the
Class Camera.
References:
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/system-defined-device-setup-classes-available-to-vendors
https://learn.microsoft.com/en-us/microsoftteams/rooms/rooms-lifecycle-support
For some background context, I manage over 500 Teams Rooms from different
vendors and I've never seen one that returns anything using the PnP Class
Image.
Paul Hargrove
On Thu, 20 Jul 2023 at 01:35, Andres Mariano Gorzelany <
@.***> wrote:

Thanks.
While something that could be valid for your MTR device maybe can't be
valid for another and unfortunately I don't have a way to test every
device. I'll try to confirm if we can change the current filters.
Thank you
—
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/10187#issuecomment-1642097660,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGZEXX4BLKWHAFCIPYG7IILXQ7PCJANCNFSM6AAAAAA2MLURUE
.
You are receiving this because you were mentioned.Message ID:
@.***
com>


Icon: Add new User and Tag icons

Icon: Add new User and Tag icons

This update adds 2 new SVG icons for the Icon component, user and
tag. The Icon component storybook has been updated.

Changes Unknown when pulling 97ee0417db5227c707ba53162cada98db33c4e61 on Icons/add-icons into ** on master**.


Unit test threadpool_queue_work_simple won't stop on nuttx

static void worker(void* arg) needs exit_message to exit loop.


Retry pageserver connections on error.

Steps to reproduce

Start pgbench
While pgbench is running, detach and re-attach the pageserver
The pgbench session dies:

progress: 38.0 s, 95.0 tps, lat 10.517 ms stddev 0.472, 0 failed
progress: 39.0 s, 94.0 tps, lat 10.656 ms stddev 0.895, 0 failed
progress: 40.0 s, 92.0 tps, lat 10.796 ms stddev 0.713, 0 failed
progress: 41.0 s, 91.0 tps, lat 11.059 ms stddev 1.287, 0 failed
progress: 42.0 s, 92.0 tps, lat 10.838 ms stddev 0.911, 0 failed
progress: 43.0 s, 87.0 tps, lat 11.426 ms stddev 2.266, 0 failed
pgbench: error: client 0 script 0 aborted in command 5 query 0: ERROR:  [NEON_SMGR] failed to send page request: ERROR:  Tenant ca08158b38deaa4d76e460395c43aa11 will not become active. Current state: Stopping
no COPY in progress
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 100
query mode: simple
number of clients: 1
number of threads: 1
maximum number of tries: 1
duration: 120 s
number of transactions actually processed: 4017
number of failed transactions: 0 (0.000%)
latency average = 10.678 ms
latency stddev = 1.584 ms
initial connection time = 338.490 ms
tps = 93.533483 (without initial connection time)
pgbench: error: Run was aborted; the above results are incomplete.

When you restart pgbench, it works.
It would be nice for the compute to sleep and retry the connection a few times on failure, and only give up after, say, 30 seconds. That way, if the pageserver is restarted or the tenant is detached and re-attached (*), the queries would not be interrupted.
(*) possibly on a different pageserver although we don't have a way to notify postgres about the change in pageserver address currently

It is addressed by this PR which is already merged in main:
https://github.com/neondatabase/neon/pull/3700


Saving color images

In the 'train.py' code, the input color images are resized and transposed by (1,2,0).
Why did you transposed the original input images when you save the "data" including original images if opt.mode=='test' and opt.save_prediction==True. ?

Hi @nicesonnday , if you asking about this line, the transpose is just for converting the [channel, height, width] format to [height, width, channel] format.


Failed to create Render Manager in Windows 32bit (x86) STANDALONE game

This occurs in 32bit standalone game only, it's OK with Play In Editor (in both x86 and x86_64) and 64bit standalone game.
The log file from 32bit standalone game:
Initialize engine version: 5.3.1f1 (cc9cbbcc37b4)
GfxDevice: creating device client; threaded=1
Direct3D:
    Version:  Direct3D 11.0 [level 11.0]
    Renderer: NVIDIA GeForce GTX 970 (ID=0x13c2)
    Vendor:   NVIDIA
    VRAM:     3072 MB
Cluster Renderer Log : ARG list
D:\work\SDK-PC\UnitySDK\Build\demo.exe
Begin MonoManager ReloadAssembly
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\UnityEngine.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\UnityEngine.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\Assembly-CSharp.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\Assembly-CSharp.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\UnityEngine.UI.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\UnityEngine.UI.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\UnityEngine.Networking.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\UnityEngine.Networking.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\OSVR.ClientKit.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\OSVR.ClientKit.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\UnityEngine.Networking.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\UnityEngine.Networking.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\UnityEngine.UI.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\UnityEngine.UI.dll into Unity Child Domain
- Completed reload, in  0.035 seconds
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\System.Core.dll (this message is harmless)
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo_Data\Managed\System.dll (this message is harmless)
desktop: 1920x1080 60Hz; virtual: 6400x1440 at 0,0
<RI> Initializing input.

<RI> Input initialized.

<RI> Initialized touch support.

The referenced script on this Behaviour (Game Object 'MenuSelection') is missing!

(Filename:  Line: 1655)

The referenced script on this Behaviour (Game Object 'Cube') is missing!

(Filename:  Line: 1655)

UnloadTime: 0.819162 ms
[OSVR-Unity] In OnEnable()

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 37)

[OSVR-Unity] Starting with app ID: com.vrgate.demo

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 37)

[OSVR-Unity] In Start()

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 37)

[OSVR-Unity] Failed to create RenderManager.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 37)

The log file from 64bit standalone game:
Initialize engine version: 5.3.1f1 (cc9cbbcc37b4)
GfxDevice: creating device client; threaded=1
Direct3D:
    Version:  Direct3D 11.0 [level 11.0]
    Renderer: NVIDIA GeForce GTX 970 (ID=0x13c2)
    Vendor:   NVIDIA
    VRAM:     3975 MB
Cluster Renderer Log : ARG list
D:\work\SDK-PC\UnitySDK\Build\demo64.exe
Begin MonoManager ReloadAssembly
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\UnityEngine.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\UnityEngine.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\Assembly-CSharp.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\Assembly-CSharp.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\UnityEngine.UI.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\UnityEngine.UI.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\UnityEngine.Networking.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\UnityEngine.Networking.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\OSVR.ClientKit.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\OSVR.ClientKit.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\UnityEngine.Networking.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\UnityEngine.Networking.dll into Unity Child Domain
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\UnityEngine.UI.dll (this message is harmless)
Loading D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\UnityEngine.UI.dll into Unity Child Domain
- Completed reload, in  0.099 seconds
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\System.Core.dll (this message is harmless)
Platform assembly: D:\work\SDK-PC\UnitySDK\Build\demo64_Data\Managed\System.dll (this message is harmless)
desktop: 1920x1080 60Hz; virtual: 6400x1440 at 0,0
<RI> Initializing input.

<RI> Input initialized.

<RI> Initialized touch support.

The referenced script on this Behaviour (Game Object 'MenuSelection') is missing!

(Filename:  Line: 1655)

The referenced script on this Behaviour (Game Object 'Cube') is missing!

(Filename:  Line: 1655)

UnloadTime: 0.548413 ms
[OSVR-Unity] In OnEnable()

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 37)

[OSVR-Unity] Starting with app ID: com.vrgate.demo

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 37)

[OSVR-Unity] In Start()

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 37)

[OSVR-Unity] Shutting down OSVR.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 37)

OSVR-Unity version: OSVR-Unity-v<IP_ADDRESS>-with-core-v0.6-1194-g0c54f5e-build390

Turn on DebugLog() shows:

[OSVR-Unity] In Start()
UnityEngine.DebugLogHandler:Internal_Log(LogType, String, Object)
UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
UnityEngine.Logger:Log(LogType, Object)
UnityEngine.Debug:Log(Object)
OSVR.Unity.ClientKit:Start() (at D:\work\SDK-PC\UnitySDK\Assets\VRGateUnity\src\ClientKit.cs:130)

(Filename: D:/work/SDK-PC/UnitySDK/Assets/VRGateUnity/src/ClientKit.cs Line: 130)

[OSVR Rendering Plugin] Attempted to create render manager, but device type wasn't set (to a supported type) by the plugin load/init routine. Order issue?
UnityEngine.DebugLogHandler:Internal_Log(LogType, String, Object)
UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
UnityEngine.Logger:Log(LogType, Object)
UnityEngine.Debug:Log(Object)
OSVR.Unity.OsvrRenderManager:DebugWrapper(String) (at D:\work\SDK-PC\UnitySDK\Assets\VRGateUnity\src\OsvrRenderManager.cs:54)
OSVR.Unity.OsvrRenderManager:CreateRenderManagerFromUnity(SafeClientContextHandle)
OSVR.Unity.OsvrRenderManager:CreateRenderManager(ClientContext) (at D:\work\SDK-PC\UnitySDK\Assets\VRGateUnity\src\OsvrRenderManager.cs:232)
OSVR.Unity.OsvrRenderManager:InitRenderManager() (at D:\work\SDK-PC\UnitySDK\Assets\VRGateUnity\src\OsvrRenderManager.cs:126)
OSVR.Unity.DisplayController:SetupRenderManager() (at D:\work\SDK-PC\UnitySDK\Assets\VRGateUnity\src\DisplayController.cs:139)
OSVR.Unity.DisplayController:SetupDisplay() (at D:\work\SDK-PC\UnitySDK\Assets\VRGateUnity\src\DisplayController.cs:175)
OSVR.Unity.DisplayController:Update() (at D:\work\SDK-PC\UnitySDK\Assets\VRGateUnity\src\DisplayController.cs:316)

(Filename: D:/work/SDK-PC/UnitySDK/Assets/VRGateUnity/src/OsvrRenderManager.cs Line: 54)

[OSVR-Unity] Failed to create RenderManager.
UnityEngine.DebugLogHandler:Internal_Log(LogType, String, Object)
UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
UnityEngine.Logger:Log(LogType, Object)
UnityEngine.Debug:LogError(Object)
OSVR.Unity.DisplayController:SetupRenderManager() (at D:\work\SDK-PC\UnitySDK\Assets\VRGateUnity\src\DisplayController.cs:142)
OSVR.Unity.DisplayController:SetupDisplay() (at D:\work\SDK-PC\UnitySDK\Assets\VRGateUnity\src\DisplayController.cs:175)
OSVR.Unity.DisplayController:Update() (at D:\work\SDK-PC\UnitySDK\Assets\VRGateUnity\src\DisplayController.cs:316)

(Filename: D:/work/SDK-PC/UnitySDK/Assets/VRGateUnity/src/DisplayController.cs Line: 142)

I also have this issue. Have even tried using 32bit OSVR runtime installed on system, but still broken for 32bit build and working for 64bit.
Running on Windows 10 64bit

This is a Unity bug.
Patched in https://github.com/OSVR/OSVR-Unity-Rendering/pull/26
See also: https://github.com/OSVR/OSVR-Unity/issues/187


expose runTimersToTime; add to docs; add example

Summary
Jest doesn't currently expose runTimersToTime during test runs, even though it supports it internally.
Test plan
I've added a test to examples/timers that uses this newly exposed functionality.

Current coverage is 87.40% (diff: 0.00%)

Merging #1806 into master will decrease coverage by 0.07%

@@             master      #1806   diff @@
==========================================
  Files            38         38
  Lines          1214       1215     +1
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           1062       1062
- Misses          152        153     +1
  Partials          0          0

Powered by Codecov. Last update fa41c87...9b7ee15


Different behavior between -c and --cwd

The --cwd option works as expected, while the -c one results in:
/usr/bin/bash: line 1: /home/pawamoy/data/dev/griffe: Is a directory

Full traceback (click to expand)
% pipx run terminhtml -c $PWD "make format" > output.html
Traceback (most recent call last):

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/lib/python3.10/site-packages/terminhtml/runner/main.py", line 113, in _get_real_output_and_context_from_output_lines
    command_marker_indices = CommandMarkerIndices.find(lines)

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/lib/python3.10/site-packages/terminhtml/runner/main.py", line 204, in find
    raise CannotFindPersistenceLineMarkersException(

terminhtml._exc.CannotFindPersistenceLineMarkersException: Could not find all command markers in lines: [LineOutput(line='/usr/bin/bash: line 1: /home/pawamoy/data/dev/griffe: Is a directory', time=datetime.datetime(2022, 9, 25, 15, 55, 24, 701782), line_ending=<LineEnding.CRLF: '\r\n'>, prompt_output=None), LineOutput(line='', time=datetime.datetime(2022, 9, 25, 15, 55, 24, 701932), line_ending=<LineEnding.CRLF: '\r\n'>, prompt_output=None)]. Markers were: markers=CommandMarkerIndices(begin_persistence=-1, end_persistence=-1, begin_path=-1, end_path=-1, begin_env=-1, end_env=-1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/lib/python3.10/site-packages/terminhtml/runner/main.py", line 34, in run
    return _run(

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/lib/python3.10/site-packages/terminhtml/runner/main.py", line 333, in _run
    real_output, new_context = _get_real_output_and_context_from_output_lines(

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/lib/python3.10/site-packages/terminhtml/runner/main.py", line 117, in _get_real_output_and_context_from_output_lines
    raise CommandInternalException(

terminhtml._exc.CommandInternalException: Command had non-zero exit code

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

Traceback (most recent call last):

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/bin/terminhtml", line 8, in <module>
    sys.exit(main())

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/lib/python3.10/site-packages/terminhtml/cli.py", line 157, in main
    typer.run(run_commands_create_html)

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/lib/python3.10/site-packages/terminhtml/cli.py", line 138, in run_commands_create_html
    term = TerminHTML.from_commands(

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/lib/python3.10/site-packages/terminhtml/main.py", line 59, in from_commands
    command_results = _run_commands_create_command_results(

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/lib/python3.10/site-packages/terminhtml/main.py", line 137, in _run_commands_create_command_results
    return run_commands(

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/lib/python3.10/site-packages/terminhtml/runner/main.py", line 96, in run_commands
    out_command = run(command, last_context, input=this_command_input)

  File "/home/pawamoy/.local/pipx/.cache/78b42e3944fa77f/lib/python3.10/site-packages/terminhtml/runner/main.py", line 56, in run
    raise UserCommandException(

terminhtml.exc.UserCommandException: Command failed: /home/pawamoy/data/dev/griffe due to Command had non-zero exit code as part of running commands=['/home/pawamoy/data/dev/griffe', 'make format'] setup_command='' input=None
context=cwd=PosixPath('/tmp/tmp7csrmz5b') env=None
output:
/usr/bin/bash: line 1: /home/pawamoy/data/dev/griffe: Is a directory

(by the way, it seems that blank lines are inserted between each line, is that expected?)

:tada: This issue has been resolved in version 0.9.3 :tada:
The release is available on:

v0.9.3
GitHub release

Your semantic-release bot :package::rocket:


[CARBONDATA-3572] optimize java code checkstyle for LeftCurly rule

Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[x] Any interfaces changed? NO

[x] Any backward compatibility impacted? NO

[x] Document update required? NO

[x] Testing done YES
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.

[x] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.  NO

Checks for the placement of left curly braces ('{') for code blocks, for a bad style example
org.apache.carbondata.core.datastore.compression.AbstractCompressor
@Override
public boolean supportReusableBuffer() {
  return false;
}

@Override
public boolean supportUnsafe() { return false; }

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/809/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/813/

Build Success with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/816/

LGTM

Thanks for working on this


isic: command not found

Does anybody meet this problem?
I successfully installed this package and I could also see it in the pip list. But somehow when I try to download the dataset using the command begin with isic, it failed and told me that command not found.
Anybody could help?

If you can specify the full location to it it should work.
Assuming you’re on Windows, if you run pip show isic-cli it should show the location it was installed in e.g. c:\users\foo\python\site-packages. Replacing site-packages with scripts should work, so in this example the final path would be c:\users\foo\python\scripts\isic.
So instead of running isic user login you would run c:\users\foo\python\scripts\isic user login.
We have something planned in the future that should hopefully make this much easier, but for now this is the workaround.

I am using the server which in linux. I tried the above one but it didn't work for me

it is actually interesting, because I checked the python/site-packages, the package is there

And isic isn't present in the bin directory for python? You may want to resort to using find / -name "isic" 2> /dev/null to search for the executable directly.

Actually, you might be able to run pip show --files isic-cli | grep bin to get the path.

i dont know why I could not do it this way c:\users\foo\python\scripts\isic user login (replace the path to the path in my end) TAT

hiii sorry to the late reply. yes the problem is solved now. Thanks

(by the way, do you by any chance know where can I find the description of each column in the matadata?

An unofficial/incomplete list of items is documented here but there's nothing published with descriptions of each field, though that is on our roadmap for the future. Were there specific fields you were curious about?


Retention property needs to be updated

As of Prometheus v2.7 the startup property --storage.tsdb.retention has been deprecated in favor of --storage.tsdb.retention.time.
https://prometheus.io/docs/prometheus/latest/storage/#operational-aspects

Fixed at https://github.com/bosh-prometheus/prometheus-boshrelease/pull/297


Support vaulted ApplePay

This adds support for vaulted Apple Pay payment methods. Braintree.PaymentMethod.create/2 can now be called with an Apple Pay nonce. Also, the Braintree.Customer struct now includes an apple_pay_cards field.
I was not able to get the complete integration test suite to pass, but the integration tests in test/integration/payment_method_test.exs worked for me. I added an integration test to this file covering Braintree.PaymentMethod.create/2.
Please let me know if there's anything that you'd like changed.
Thanks ✨

The docs for ApplePayCard can be found here: https://developers.braintreepayments.com/reference/response/apple-pay-card/ruby
I've only included documented fields in the Braintree.ApplePayCard struct, with the exception of billing_address.

Thanks for the improvements @balexand. Everything looks great. Don't sweat the full test suite, from what sources at Braintree have told me that is an issue that they face as well. Rate limiting and integration testing is a poor combination.


Source install on Slackware autogen.sh failure

Hello, I am trying to install colour in Slackware 15 Beta 1 and I am getting this error when I run ./autogen.sh.
autogen.sh: error: Didn't find a git repository (or no tags found).  ``./autogen.sh`` uses git to create changelog and version information.
As I understand it autogen.sh should create a Changelog.rst file needed by setup.py.   However I need to get past the above error.  Any help with this is appreciated.
Thank You.

Ok just a quick update, if I clone the git repo it works fine, this is just happening when downloading the releases (0.1.5).  Which is odd because the release and the latest git commit are basically the same.

Yes, sorry about that, but the auto-release of github (source packaged in a zip or equivalent) are not supported, but I can't deactivate them. The difference is crucial as we need the git history (and tags) so ./autogen.sh can build and get the version information (from tags), and build the changelog (from git history). This happens very rarely as usally, either people will get the distributed package through pip, or will clone it to work on the source.

Not a problem, its easy enough issue to get around.  I'll mark this as solved.


Add wse strategy

Add a strategy for WSE token.

@Norfolks If you just need to call a specific function of a smart contract you dont need to create your own strategy you can use the strategy "contract-all" which allow you to do a custom call see: https://github.com/snapshot-labs/snapshot.js/tree/master/src/strategies/contract-call
Here is an example of a space that is using "contract-call" strategy to get voting score https://hub.snapshot.page/api/spaces/badgerdao.eth

@bonustrack
Looks like the example you provided should fit our requirements.
I'll check it.

@bonustrack
I am not sure we can use the method you provided
We have a uni's fork way of government calculation.
So, we need some fork of their here too.
https://github.com/WhiteSwap/snapshot.js/blob/master/src/strategies/uni/index.ts
Can we specify block we take votes from using this method, including the "latest" option?

The UNI strategy could also be replaced by to "contract-call" strategy. It's much better if you use contract-call instead of making a strategy. The snapshot block is specified when you make a proposal, then in the strategy it's changed to blockTag, you don't need to change that.

@bonustrack
I've made a contract-call strategy with those parameters
https://hub.snapshot.page/api/spaces/wse.eth
But it shows that a valid address, that has tokens doesn't have any voting power.
What could be wrong?

@Norfolks Perhaps the valid address didn't have token at the specific snapshot block number? If you cast a vote and point me to a proposal i could do some test.

@bonustrack please, it would be great.
The proposal:
https://snapshot.page/#/wse.eth/proposal/QmV1bMVM44yfbHzcu3SdQvXZje5rFW7tiEexiZNmHUzdfd
Yes vote was made from the address:
0x77b8ae2E83c7d044d159878445841E2A9777Af38

@Norfolks Are you sure that's a correct address? On Etherscan it also return 0 for that address.

@bonustrack
Seems I found an issue.
Thanks


Add to the README a notice to advice that node 0.12.^ needed

Source code uses extensively path.posix which is only available from node 0.12.0 up. While this is not worth a pull request, you should add this info to the README as the error message that comes out of the console does not state it clear the problem.

This should be taken care of by package.json.


requirements.txt is missing

The README tells us to:

Install all dependencies with: conda install --file requirements.txt

but there is no requirements.txt in the repository.

Thank you for raising this issue. I have now uploaded the requirements.txt file -> https://github.com/stevejpapad/image-text-verification/blob/master/requirements.txt


APIv2: Add preview of elements that will be affected by DELETE

GET apiv2/{model}/{id}/delete_preview
https://owasp.slack.com/archives/C014H3ZV9U6/p1639241564073500
Example
{
  "count": 123,
  "next": "http://DD/api/v2/users/1/delete_preview/?offset=2&limit=4",
  "previous": "http://DD/api/v2/users/1/delete_preview/?offset=10&limit=4",
  "results": [
      {
        "model": "User",
        "id": 1,
        "name": "admin"
      },
      {
        "model": "Product_Type_Member",
        "id": 1,
        "name": "Product_Type_Member object (1)"
      },
      {
        "model": "Alerts",
        "id": 4,
        "name": "Alerts object (4)"
      },
      {
        "model": "Alerts",
        "id": 2,
        "name": "Alerts object (2)"
      }
  ]
}

TODO

[x]  add pagination
[ ]  fix schema

@kiblik I'm not a big fan of these previews. Sometimes the preview are really big and just crash (timeout).
We have this pb at my day job: some projects have so much data that it's impossible to use this "preview" screens.

@kiblik I'm not a big fan of these previews. Sometimes the preview are really big and just crash (timeout). We have this pb at my day job: some projects have so much data that it's impossible to use this "preview" screens.

We can set it as an optional API call (by env variable).
And you don't have to use it before you call DELETE .... It is up to you.

Oops I did not see that tests were not passing. Keeping the approval for now

@Maffooch, I used WIP: in the title because it is not ready
Some parts are not done, tests are failing, there is some new conflict, so please do not merge it yet.
But thanks for the support :)

@Maffooch, I used WIP: in the title because it is not ready
Some parts are not done, tests are failing, there is some new conflict, so please do not merge it yet.
But thanks for the support :)

@kiblik better to use the 'Draft' feature of GitHub => https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request

@Maffooch, I used WIP: in the title because it is not ready
Some parts are not done, tests are failing, there is some new conflict, so please do not merge it yet.
But thanks for the support :)

@kiblik better to use the 'Draft' feature of GitHub => https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request

Thank you. I knew drafts but the "Convert to draft" button was too small and I missed it .

The main part of implementation is done but small help is still needed. I was able to force swagger to add fields for pagination (by adding ...Serializer(many=True)) but this step also added other GET parameters (parameters used in the original Model). For example User:

Is this happening for both Open API 2 and 3 specs? Looks like maybe it gets confused by having both many=True and detail=True on the same method.

Is this happening for both Open API 2 and 3 specs? Looks like maybe it gets confused by having both many=True and detail=True on the same method.

I haven't checked Open API 2 before. Now I see that paging fields are not there - Btw, does it need to be fixed? How long Open API 2 swagger will be there?
detail=True allows to use format /api/v2/users/{id}/delete_preview/ (otherwise there would be /api/v2/users/delete_preview/). many=True is there because API call return list (one only one element) of affected elements and allows to use pagination.
If detail would be False, self.get_object() is not possible to use.

@kiblik lots of changes to drf_spectacular in https://github.com/DefectDojo/django-DefectDojo/pull/6046, could you retry?

Still the same

After better reading of FAQ, I found solution: Add filter_backends=[] to @action.

However, this is the solution only for APIv2 (drf-spectacular). I wasn't able to find a solution for APIv1 (drf_yasg). Should I spend more time digging deeper or is it an acceptable solution?

After better reading of FAQ, I found solution: Add filter_backends=[] to @action.

Nice find!

However, this is the solution only for OpenAPI3 (drf-spectacular). I wasn't able to find a solution for OpenAPI2 (drf_yasg). Should I spend more time digging deeper or is it an acceptable solution?

I think asking the drf-yasg team how this could be solved is a small task we could do? It would be really impractical if we have an incorrect API specs and would have to clear document that or add some description to the affected endpoints.

We have received the reaction https://github.com/axnsan12/drf-yasg/issues/787#issuecomment-1105787846

...

spectacular response suggests there is a pagination_class present on that view/action. The pagination logic gets activated by doing Serializer(many=True).
we make no guarantees about correctness when using both spectacular and yasg decorators at the same time. your mileage may vary.

Maybe I will try to debug yasg how and why the "pagination engine" is not activated in our case even if we are using Serializer(many=True)

I finally found the solution.
More details: https://github.com/axnsan12/drf-yasg/issues/787#issuecomment-1116777245


Dark mode notice about Ghost(Pro) udpate has incorrect BG colour

Issue Summary
When in dark mode, the notice about Ghost(Pro) having been updated to the newest version has an incorrect background colour.

Steps to Reproduce

Set admin to dark mode
Wait for notice about update to come through

Ghost Version
5.48.0+moya
Node.js Version
Whatever Ghost(Pro) is using
How did you install Ghost?
Ghost(Pro)
Database type
MySQL 5.7
Browser & OS version
No response
Relevant log / error output
No response
Code of Conduct

[X] I agree to be friendly and polite to people in this repository

Hi @minimaluminium the issue I found last month has been not fixed yet.
In the Ghost admin panel's "Invite Staff Members" section, the contents of the hover box appear white in dark mode, and this issue still persists in the latest version, 5.49.0. It is crucial to address this problem and prioritize UI improvements for both dark and light modes.

The fix for this has been included in 5.49.1. Thanks for the report @stromfeldt 🙂


WhitestormJS

Github: https://github.com/WhitestormJS/whitestorm.js
Website: http://whitestormjs.xyz/

Awesome.

What does this have to do with this repo?


Unable to login to kibana (5.1.1)

I tripple checked my settings and even copy and pasted from my parameters file and tried multiple user names. No luck, I get 401 failures... I had to select use shield due to my other issue where kibana isn't installed unless you install es plugins.
{"statusCode":401,"error":"Unauthorized","message":"[security_exception] unable to authenticate user [admin] for REST request [/_xpack/security/_authenticate], with { header= } :: {\"path\":\"/_xpack/security/_authenticate\",\"query\":{},\"statusCode\":401,\"response\":\"{\\\"error\\\":{\\\"root_cause\\\":[{\\\"type\\\":\\\"security_exception\\\",\\\"reason\\\":\\\"unable to authenticate user [admin] for REST request [/_xpack/security/_authenticate]\\\",\\\"header\\\":{\\\"WWW-Authenticate\\\":\\\"Basic realm=\\\\\\\"security\\\\\\\" charset=\\\\\\\"UTF-8\\\\\\\"\\\"}}],\\\"type\\\":\\\"security_exception\\\",\\\"reason\\\":\\\"unable to authenticate user [admin] for REST request [/_xpack/security/_authenticate]\\\",\\\"header\\\":{\\\"WWW-Authenticate\\\":\\\"Basic realm=\\\\\\\"security\\\\\\\" charset=\\\\\\\"UTF-8\\\\\\\"\\\"}},\\\"status\\\":401}\",\"wwwAuthenticateDirective\":\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\"}"}

This is a bug, instead of being set to the sheildAdminPassword and adminUserName. It's set to the elasticsearch.username and elasticsearch.password in the /etc/kibana/kibana.yml file

There should be some documentation that the user is elastic and not the adminUserName


change image depends on the contents

Issue title: Change Image - Microverse-Basic-HTML-Proyect-One
Change Image

I think in this case something related to youtube, as the site itself is a clone of youtube

@Israel-Laguan could I mark this issue as done?

I think QA should see it somehow


NodeRED bugs and fixes from deploying to Bluemix

ISSUE: Team goals are backwards
Goal Handling (switch node) --> 2 and 1 are flipped
Location: Top middle
ISSUE: Timeline reports both team shooters as Team Yellow
Set Team Two as Shooter (function node) --> team:1 should be team:2
Location: Middle middle-right
ISSUE: Database records both users as losing
Use 2 global variables instead of 1 to store "winner".
Location: Top right
NodeRED code:
[{"id":"97ef7107.2773c","type":"subflow","name":"Search for Player (3)","info":"","in":[{"x":50,"y":30,"wires":[{"id":"cf627932.667968"}]}],"out":[{"x":520,"y":115,"wires":[{"id":"cf627932.667968","port":0}]}]},{"id":"7f74df07.25574","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"fcb4ac2f.c3109","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"e1504e6.3c3dab","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"2d7fdfc1.17237","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"89ec00b0.9562e","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"34f38525.21617a","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"5aeeb85d.254818","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"cf627932.667968","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"2ae0e15e.d3fcbe","type":"subflow","name":"Update Player 1","info":"","in":[{"x":50,"y":30,"wires":[{"id":"cb448a29.84cd18"}]}],"out":[]},{"id":"14b8ca0e.2433a6","type":"function","z":"2ae0e15e.d3fcbe","name":"Set Cloudant Update Command","func":"gameID = global.get(\"gameID\").toString();\nvar win = global.get(\"winner1\");\nif(win===true){\n    gamesWon = msg.payload.gamesWon + 1;\n    msg.payload.gamesWon = gamesWon;\n}\nelse{\n    gamesLost = msg.payload.gamesLost + 1;\n    msg.payload.gamesLost = gamesLost;\n}\n\n\nvar goals = global.get(\"goals\");\nvar goals2 = global.get(\"goals2\");\nmsg.payload.pointsFor = msg.payload.pointsFor + goals;\nmsg.payload.pointsAgainst = msg.payload.pointsAgainst + goals2;\n\n\nmsg.payload = {\n  \"_id\": msg.payload._id,\n  \"_rev\": msg.payload._rev,\n  \"handle\":msg.payload.handle,\n  \"name\": msg.payload.name,\n  \"photo\": msg.payload.photo,\n  \"gamesWon\": msg.payload.gamesWon,\n  \"gamesLost\": msg.payload.gamesLost,\n  \"pointsFor\": msg.payload.pointsFor,\n  \"pointsAgainst\":msg.payload.pointsAgainst,\n  \"lastPlayed\": global.get(\"endTime\"),\n  \"lastGame\": gameID\n};\n\nreturn msg;","outputs":1,"noerr":0,"x":570,"y":120,"wires":[["3fb83077.455a1"]]},{"id":"3fb83077.455a1","type":"cloudant out","z":"2ae0e15e.d3fcbe","name":"Update","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","payonly":true,"operation":"insert","x":655.5,"y":302,"wires":[]},{"id":"f8290569.f98638","type":"comment","z":"2ae0e15e.d3fcbe","name":"PLAYER 1","info":"","x":301.6666679382324,"y":247.77778244018555,"wires":[]},{"id":"cb448a29.84cd18","type":"subflow:97ef7107.2773c","z":"2ae0e15e.d3fcbe","name":"","x":265.5,"y":101,"wires":[["14b8ca0e.2433a6"]]},{"id":"97ef7107.2773c","type":"subflow","name":"Search for Player (3)","info":"","in":[{"x":50,"y":30,"wires":[{"id":"cf627932.667968"}]}],"out":[{"x":520,"y":115,"wires":[{"id":"cf627932.667968","port":0}]}]},{"id":"7f74df07.25574","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"fcb4ac2f.c3109","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"e1504e6.3c3dab","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"2d7fdfc1.17237","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"89ec00b0.9562e","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"34f38525.21617a","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"5aeeb85d.254818","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"cf627932.667968","type":"cloudant in","z":"97ef7107.2773c","name":"","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","search":"_id_","design":"","index":"","x":246.5,"y":78,"wires":[[]]},{"id":"70778200.0b377","type":"subflow","name":"Update Player 2","info":"","in":[{"x":50,"y":30,"wires":[{"id":"3ee098ef.e8ad88"}]}],"out":[]},{"id":"9eedfc63.c4c47","type":"function","z":"70778200.0b377","name":"Set Cloudant Update Command","func":"gameID = global.get(\"gameID\").toString();\nvar win = global.get(\"winner2\");\nif(win===true){\n    gamesWon = msg.payload.gamesWon + 1;\n    msg.payload.gamesWon = gamesWon;\n}\nelse{\n    gamesLost = msg.payload.gamesLost + 1;\n    msg.payload.gamesLost = gamesLost;\n}\n\n\nvar goals = global.get(\"goals\");\nvar goals2 = global.get(\"goals2\");\nmsg.payload.pointsFor = msg.payload.pointsFor + goals;\nmsg.payload.pointsAgainst = msg.payload.pointsAgainst + goals2;\n\n\nmsg.payload = {\n  \"_id\": msg.payload._id,\n  \"_rev\": msg.payload._rev,\n  \"handle\":msg.payload.handle,\n  \"name\": msg.payload.name,\n  \"photo\": msg.payload.photo,\n  \"gamesWon\": msg.payload.gamesWon,\n  \"gamesLost\": msg.payload.gamesLost,\n  \"pointsFor\": msg.payload.pointsFor,\n  \"pointsAgainst\":msg.payload.pointsAgainst,\n  \"lastPlayed\": global.get(\"endTime\"),\n  \"lastGame\": gameID\n};\n\nreturn msg;","outputs":1,"noerr":0,"x":495.55553436279297,"y":66.66666603088379,"wires":[["61783d53.b5ea34"]]},{"id":"61783d53.b5ea34","type":"cloudant out","z":"70778200.0b377","name":"Update","cloudant":"","database":"players","service":"foosbuzz-cloudantNoSQLDB","payonly":true,"operation":"insert","x":547.7222290039062,"y":232.0000114440918,"wires":[]},{"id":"3ee098ef.e8ad88","type":"subflow:97ef7107.2773c","z":"70778200.0b377","name":"","x":233.5,"y":70,"wires":[["9eedfc63.c4c47"]]},{"id":"a496a767.32fc98","type":"function","z":"2e819c41.e119a4","name":"Update Player 1","func":"msg.payload = global.get(\"idTeamOne\");\n\nvar goals  = global.get(\"goalsTeamOne\");\nglobal.set(\"goals\",goals);\nvar goals2 = global.get(\"goalsTeamTwo\");\nglobal.set(\"goals2\",goals2);\n\n\nvar time = global.get(\"endTime\");\nvar lastGame = global.get(\"gameID\").toString();\n//flipped < sign to >\nif(goals>goals2){\n    global.set(\"winner1\",true);\n}\nelse{\n    global.set(\"winner1\",false);\n}\n\nreturn msg;","outputs":1,"noerr":0,"x":3221,"y":318.8461561936599,"wires":[["ca6555ce.e21778","78d5906e.9868d"]]},{"id":"be5d0cbc.039f8","type":"function","z":"2e819c41.e119a4","name":"Update Player 2","func":"msg.payload = global.get(\"idTeamTwo\");\n//originally had goalsTeamOne and goalsTeamTwo swapped\nvar goals = global.get(\"goalsTeamOne\");\nglobal.set(\"goals\",goals);\nvar goals2 = global.get(\"goalsTeamTwo\");\nglobal.set(\"goals2\",goals2);\n\nvar time = global.get(\"endTime\");\nvar lastGame = global.get(\"gameID\").toString();\n//flipped > sign to <\nif(goals<goals2){\n    global.set(\"winner2\",true);\n}\nelse{\n    global.set(\"winner2\",false);\n}\n\nreturn msg;","outputs":1,"noerr":0,"x":3221,"y":358.8461561936599,"wires":[["7cc7068.cbe1cf8","6c45455f.d546ec"]]},{"id":"6c45455f.d546ec","type":"subflow:70778200.0b377","z":"2e819c41.e119a4","name":"","x":3442.666835784912,"y":357.7350493211013,"wires":[]},{"id":"ca6555ce.e21778","type":"subflow:2ae0e15e.d3fcbe","z":"2e819c41.e119a4","name":"updateplayer 1","x":3441,"y":318.8461561936599,"wires":[]}]

Ah it appears this is due to some changes we made for an event in Austin and I completely forgot to revert the flow back to what it was. I apologize for the error.


Self-managed node group example testing and updates

What does this PR do?
Updates the example so it only creates 3 public and 3 private subnets as described in the readme. This PR also serves to validate that this example still works. This PR also includes a small whitespace fix that was caught by pre-commit.
More

[x] Yes, I have tested the PR using my local account setup  (Provide any test evidence report under Additional Notes)
[ ] Yes, I have added a new example under examples to support my PR
[ ] Yes, I have created another PR for add-ons under add-ons repo (if applicable)
[ ] Yes, I have updated the docs for this feature
[x] Yes, I ran pre-commit run -a with this PR

Note: Not all the PRs required examples and docs except a new pattern or add-on added.
For Moderators

[ ] E2E Test successfully complete before merge?

Additional Notes
Followed the readme deployment and testing steps to validate that it works as expected.

Whoops, I forgot to make some of the other updates for this example. Closing for now and will open a new PR once I fix this.


Consider materialized view also for search

Now that we've got materialised views in place we might as well make search faster as well.
It should be a simple adaptation of the existing machinery but also check performance figures before doing it.

I'm having a quick look at this, because I'd like to get it in before the schema squash.

Our current search query has an execution time for the search term of "foo" (single hit) of ~60ms and about 6-8ms with a materialised view.
For "swift" (~1500 hits), this goes up to ~75ms in our current search and around 10-15ms with the materialised view.
It's a nice speed bump and I think I'd like to bring that in.

Sounds good to me.


datepicker cannot validate using the W3C validator (339 validation errors)

Bug description:
The angular-ui datepicker does not validate very well, because no data- prefix is appended to to the ng or uib attributes.  I get a total of 339 validation errors on the datepicker alone, but i suspect that this is a general problem to angular-ui.
Link to minimally-working plunker that reproduces the issue:
https://plnkr.co/edit/RFAxI1kaF1k8TfSSuMgM?p=preview
(Click the validate button)
Version of Angular, UIBS, and Bootstrap
Angular: 1.5.6
UIBS: 1.3.3
Bootstrap: 3.3.6

Closing as won't support - the W3C validator is not something most frontend developers cares about, it does some meaningless checks such as the data- prefix.


Cypress/E2E: Fix LDAP login and team/channel roles

Summary
Fix LDAP login and team/channel roles
Ticket Link
none, failing on daily tests

@saturninoabril The initial issue that @josephbaylon pointed out is no longer there for me, but seeing some other issues now. The following error always happens when I run the login flow for guest test. Not sure if it's my setup that's missing something if the tests are passing for you and Joseph:


Update howto-policy-approved-app-or-app-protection.yml

Added clarification for app protection controls in first warning section of the document.

@MicrosoftGuyJFlo

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Suggestion to improve adminUI page

I would suggest to improve the adminUI page by adding a shirt description how to get the station id and a link

As there is plenty of space, consider adding something like:
"Retrieve station id from //https://www.umweltbundesamt.de/themen/luft/luftqualitaet#luftdaten"

Yes. a good idea.
Can I format the text 'nicely' here?
And should I - even if the adapter can only be used in Germany - also support other languages?

Please check staticText and (as far as I know) staticURL.
https://github.com/ioBroker/ioBroker.admin/blob/master/packages/jsonConfig/README.md

Instructions for use in GUI added.


Validation error for Text only DAX measure and commented DAX

Facing an issue where I have a measure that is only text (that hasn't been changed in source or target), that is causing the Validate Selection to fail.
I had another measure also failing that had a comment line referencing some columns in the model that also was causing a validation issue. This issue went away went I removed the commented line of DAX. This error was stating that it couldn't find the measure/column in the target model too (similar to the screenshot).

Thanks, I've added to the todo list to take a look when I get the chance.
BTW, the calculation dependencies warning does not affect the actual actions, so it does not make any difference to the actions performed on the target model. I'm considering making them informational so this is clearer.


csp_rtable_static.c, csp_rtable_find_route leads to segfault when an address arrives that does not have a route

this is a list of NULL pointers, except, after initialization, at indices where routes have been defined.
static csp_route_t rtable[CSP_DEFAULT_ROUTE + 1] = {};
If the dest_address route does not exist, then this statement attempts to index to a structure that is still a NULL pointer:
if (rtable[dest_address].iface != NULL)

my bad


Back button in create provider

Se agrego back button con logo en form de providers

⚠ The button and functionality have not been added to this view as mentioned in the task.

Agregar el botón al lado de agregar proveedor

The style is not correct the button must be added but in the correct place it must be in a blank space before the title

Current

Expected result

:+1:  they have added the back button and it works as it should in chrome and firefox
https://user-images.githubusercontent.com/39505782/189228326-2eaffb99-ba17-43e7-8050-f4c90dc2bd80.mp4
https://user-images.githubusercontent.com/39505782/189228760-4fdd2d59-732b-4d7f-b7f8-a0a93e86da1b.mp4

Both buttons using create Product reference as asked.

The buttons work, but they are not located where they should be, so I request that they be placed where they should be, please refer to the layout and note where it should be placed.
Current

Expected result

On the other hand in the task it is mentioned that there should be a back button, in the events view in the main.

Tested locally and in deploy
Come back to the last view now
Similar to design now


Address one intermittent failure in registry_test.go

Fixes #443

Fixes #443

Is that right?
Assuming tests pass, no objection here. :+1:

Ah yes, #433 not #443!


adds OptiKey back in

Will likely make a few more commits here so no need to merge right away.

[x] I followed the contributing guidelines: https://github.com/github/explore/blob/master/CONTRIBUTING.md

I am:

[x] Suggesting edits to an existing topic or collection
[ ] Curating a new topic or collection
[ ] Unaffiliated with the project (not self-promoting as e.g. a maintainer, creator, contractor or employee)

EDITING AN EXISTING TOPIC OR COLLECTION
I'm suggesting these edits to an existing topic or collection:

[ ] Image (and my file is *.png, square, dimensions 288x288)
[x] Content (and my changes are in index.md)

Please explain why these changes are necessary:
OptiKey had been removed due to it not having a Code of Conduct but they now work under the Contributor Covenant.
CURATING A NEW TOPIC

[ ] I've formatted my changes as a new folder directory, named for the topic as it appears in the URL on GitHub (e.g. https://github.com/topics/[NAME])
[ ] My folder contains a *.png image (if applicable) and index.md
[ ] All required fields in my index.md conform to the Style Guide and API docs: https://github.com/github/explore/tree/master/docs

Please explain why you think this topic should be curated:
CURATING A NEW COLLECTION

[ ] I've formatted my changes as a new folder directory, named for the collection as it appears in the URL on GitHub (e.g. https://github.com/collections/[NAME])
[ ] My folder contains a *.png image (if applicable) and index.md
[ ] All required fields in my index.md conform to the Style Guide and API docs: https://github.com/github/explore/tree/master/docs

Please explain why you think this collection should be curated:
Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.

Will likely make a few more commits here so no need to merge right away.

@bescalante this is live thank you! ✨


 When I turned my computer back on it came up saying that Tatsumaki is offline.
I am wondering how do I get Tatsumaki back online?

Are you referring to our hosted version of Tatsumaki?
If so you can join the support Discord server here: https://discordapp.com/invite/0xyZL4m5TyYTzVGY

link expired


Do the checkin also for parse function

https://github.com/rolodato/dotenv-safe/blob/78f290eca78c700b580082b079c63f9866004192/index.js#L46
parse() function is used directly from dotenv, without doing the checking for the entries in the .env.example file. Add the checkings so it could be used in arbitrary objects instead of only process.env.

Hi @piranna, could you describe your use case for this? I've never used parse directly, just included it in case others depend on it.


Update timeout for .github/workflows/codeql.yaml

This is an automated pull request to update default timeouts for all jobs in .github/workflows/codeql.yaml that do not currently contain a default timeout property.
Please review these changes closely to ensure that all jobs have sufficient time to run. If a job needs more time, please add a timeout property to that job to override the organization default.
Additionally, please be attentive to unintended changes to the workflow YAML file, as the parser is not perfect.
Lastly, note that it is up to the reviewer to merge this pull request and delete the PR branch once they are satisfied with the changes.

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

Closing in favour of already merged #5733


spring-native example fails to build with GraalVM 22

spring-native example fails to build with GraalVM 22. It builds fine with GraalVM 21.
Errors found in build logs:
(...)
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.
(...)
Error: An object of type 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.
(...)
Error: An object of type 'io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.
(...)

Full logs
spring-native % ../gradlew nativeCompile
Picked up JAVA_TOOL_OPTIONS:

> Task :opentelemetry-examples-spring-native:processAot
Picked up JAVA_TOOL_OPTIONS:

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/

 :: Spring Boot ::                (v3.3.1)

2024-07-21T13:42:10.932+02:00  INFO 46353 --- [           main] i.o.example.graal.Application            : Starting Application using Java 21.0.1 with PID 46353 (/Users/57139H/dev/2-repos/opentelemetry-java-examples/spring-native/build/classes/java/main started by 57139H in /Users/57139H/dev/2-repos/opentelemetry-java-examples/spring-native)
2024-07-21T13:42:10.933+02:00  INFO 46353 --- [           main] i.o.example.graal.Application            : No active profile set, falling back to 1 default profile: "default"
2024-07-21T13:42:11.310+02:00  INFO 46353 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JDBC repositories in DEFAULT mode.
2024-07-21T13:42:11.317+02:00  INFO 46353 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 5 ms. Found 0 JDBC repository interfaces.

> Task :opentelemetry-examples-spring-native:generateResourcesConfigFile
[native-image-plugin] Resources configuration written into /Users/57139H/dev/2-repos/opentelemetry-java-examples/spring-native/build/native/generated/generateResourcesConfigFile/resource-config.json

> Task :opentelemetry-examples-spring-native:nativeCompile
[native-image-plugin] Quick build environment variable is set.
[native-image-plugin] GraalVM Toolchain detection is disabled
[native-image-plugin] GraalVM location read from environment variable: GRAALVM_HOME
[native-image-plugin] Native Image executable path: /Users/57139H/Library/Java/JavaVirtualMachines/graalvm-jdk-22.0.2/Contents/Home/lib/svm/bin/native-image
Warning: The option '-H:ResourceConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-core/tomcat-resource.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:ReflectionConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-core/tomcat-reflection.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:ReflectionConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-websocket/tomcat-reflection.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:ReflectionConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-el/tomcat-reflection.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:ResourceConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-el/tomcat-resource.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:ResourceConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-websocket/tomcat-resource.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: Please re-evaluate whether any experimental option is required, and either remove or unlock it. The build output lists all active experimental options, including where they come from and possible alternatives. If you think an experimental option should be considered as stable, please file an issue.
========================================================================================================================
GraalVM Native Image: Generating 'opentelemetry-examples-spring-native' (shared library)...
========================================================================================================================
For detailed information and explanations on the build output, visit:
https://github.com/oracle/graal/blob/master/docs/reference-manual/native-image/BuildOutput.md
------------------------------------------------------------------------------------------------------------------------
[1/8] Initializing...                                                                                (5,2s @ 0,18GB)
 Java version: 22.0.2+9, vendor version: Oracle GraalVM 22.0.2+9.1
 Graal compiler: optimization level: b, target machine: armv8-a, PGO: off
 C compiler: cc (apple, arm64, 15.0.0)
 Garbage collector: Serial GC (max heap size: 80% of RAM)
 2 user-specific feature(s):
 - com.oracle.svm.thirdparty.gson.GsonFeature
 - org.springframework.aot.nativex.feature.PreComputeFieldFeature
------------------------------------------------------------------------------------------------------------------------
 2 experimental option(s) unlocked:
 - '-H:ResourceConfigurationResources': Use a resource-config.json in your META-INF/native-image/<groupID>/<artifactID> directory instead. (origin(s): 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-websocket/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-websocket/10.1.25/efd7848a9677e9a7cf8367b43213805eca70805/tomcat-embed-websocket-10.1.25.jar', 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-core/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-core/10.1.25/c1e5ee12f537e6b4fea2b98a7160dcf0db610561/tomcat-embed-core-10.1.25.jar', 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-el/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-el/10.1.25/2f030e4971e29245c10e58723fb6b364ce23933b/tomcat-embed-el-10.1.25.jar')
 - '-H:ReflectionConfigurationResources': Use a reflect-config.json in your META-INF/native-image/<groupID>/<artifactID> directory instead. (origin(s): 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-websocket/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-websocket/10.1.25/efd7848a9677e9a7cf8367b43213805eca70805/tomcat-embed-websocket-10.1.25.jar', 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-core/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-core/10.1.25/c1e5ee12f537e6b4fea2b98a7160dcf0db610561/tomcat-embed-core-10.1.25.jar', 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-el/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-el/10.1.25/2f030e4971e29245c10e58723fb6b364ce23933b/tomcat-embed-el-10.1.25.jar')
------------------------------------------------------------------------------------------------------------------------
Build resources:
 - 18,14GB of memory (75,6% of 24,00GB system memory, determined at start)
 - 8 thread(s) (100,0% of 8 available processor(s), determined at start)
SLF4J(W): No SLF4J providers were found.
SLF4J(W): Defaulting to no-operation (NOP) logger implementation
SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further details.
[2/8] Performing analysis...  [*****]                                                                   (30,1s @ 2,23GB)
   25 281 reachable types   (90,3% of   27 991 total)
   38 766 reachable fields  (61,5% of   63 063 total)
  130 816 reachable methods (65,9% of  198 538 total)
    8 555 types,   862 fields, and 9 724 methods registered for reflection
       66 types,    72 fields, and    57 methods registered for JNI access
        5 native libraries: -framework CoreServices, -framework Foundation, dl, pthread, z

Error: Unsupported features in 10 methods
Detailed message:
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.
------------------------------------------------------------------------------------------------------------------------

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.CODE_FILEPATH
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.CODE_FUNCTION
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.CODE_LINENO
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.CODE_NAMESPACE
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.LOG_MARKER
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.THREAD_ID
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.THREAD_NAME
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' are persisted in the image heap, add

    '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use

    '--trace-object-instantiation=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.attributeKeys
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' are persisted in the image heap, add

    '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use

    '--trace-object-instantiation=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

                        3,2s (8,7% of total time) in 584 GCs | Peak RSS: 2,84GBIf you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
 | CPU load: 6,19
To fix this, include '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.
========================================================================================================================

Failed generating 'opentelemetry-examples-spring-native' after 35,9sThe following detailed trace displays from which field in the code the object was reached.
.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.mdcAttributeKeys
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue' are persisted in the image heap, add

    '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use

    '--trace-object-instantiation=io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap.DISCARDING_QUEUE
    at <unknown-location>
  registered as read because: null

> Task :opentelemetry-examples-spring-native:nativeCompile FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':opentelemetry-examples-spring-native:nativeCompile'.
> Process 'command '/Users/57139H/Library/Java/JavaVirtualMachines/graalvm-jdk-22.0.2/Contents/Home/bin/native-image'' finished with non-zero exit value 1

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.9/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD FAILED in 45s
9 actionable tasks: 5 executed, 1 from cache, 3 up-to-date
WARNING: The following functionality has been deprecated and will be removed in the next major release of the Develocity Gradle plugin. Run with '-Ddevelocity.deprecation.captureOrigin=true' to see where the deprecated functionality is being used. For assistance with migration, see https://gradle.com/help/gradle-plugin-develocity-migration.
- The deprecated "gradleEnterprise.server" API has been replaced by "develocity.server"
- The deprecated "gradleEnterprise.buildScan.uploadInBackground" API has been replaced by "develocity.buildScan.uploadInBackground"
- The deprecated "gradleEnterprise.buildScan.publishAlwaysIf(condition)" API has been replaced by "develocity.buildScan.publishing.onlyIf { condition }"
- The deprecated "gradleEnterprise.buildScan.capture.taskInputFiles" API has been replaced by "develocity.buildScan.capture.fileFingerprints"
- The "com.gradle.enterprise" plugin has been replaced by "com.gradle.develocity"
spring-native %

Adding --trace-object-instantiation=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache as suggested in the logs gives:
The culprit object has been instantiated by the 'io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper' class initializer with the following trace:
        at io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache.<init>(MapBackedCache.java:16)
        at io.opentelemetry.instrumentation.api.internal.cache.Cache.bounded(Cache.java:38)
        at io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.<clinit>(LoggingEventMapper.java:51)

Adding --initialize-at-run-time=io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper gives:
Error: Incompatible change of initialization policy for io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper: trying to change RUN_TIME from 'META-INF/native-image/io.opentelemetry/opentelemetry-examples-spring-native/native-image.properties' in 'file:///Users/57139H/dev/2-repos/opentelemetry-java-examples/spring-native/build/libs/opentelemetry-examples-spring-native-0.1.0-SNAPSHOT-plain.jar' with 'io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper' to BUILD_TIME from 'META-INF/native-image/io.opentelemetry.instrumentation/opentelemetry-logback-appender-1.0/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/io.opentelemetry.instrumentation/opentelemetry-logback-appender-1.0/2.5.0-alpha/97b4682432fb4295b075707a8bf38da8e7caeea4/opentelemetry-logback-appender-1.0-2.5.0-alpha.jar' with 'io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper'

Excluding native configuration with the following arguments makes the build pass but I'm not sure it's the right thing to do:
--exclude-config .*opentelemetry-logback-appender.*\.jar .*native-image\.properties \
--exclude-config .*opentelemetry-instrumentation-api.*\.jar .*native-image\.properties

I stumbled upon this issue as well. It doesn't feel right to tune build process by having --initialize-at-build-time=x.y.x.package (solution from my codebase) or --exclude-config as the author pointed out.
any updates on this one? ETA?

@super7ramp maybe this ticket should be reported in different repo of the OTEL. This repo is just for the examples and maybe it doesn't have the traction and the attention.

@super7ramp could you please provide a link to the GraalVM you've used to successfully build this?

@jack-berg could this problem be related to the https://github.com/open-telemetry/opentelemetry-java/issues/6127 and similar solution as https://github.com/open-telemetry/opentelemetry-java/pull/6139 could be applied for the java instrumentation https://github.com/open-telemetry/opentelemetry-java-instrumentation?

cc @jeanbisutti

transferring to instrumentation repo at @jeanbisutti's request


[Feature] add LAVA policy

Describe the feature
add LAVA policy model
Expected behavior

Add LAVA under convlab2/policy.
Report the model performance on Policy & E2E simulation.

Additional context
Code should be tested in the following environment:

python >= 3.6
torch >= 1.6
transformers >= 4.0

done