Correct GlobalAuthenticationConfigurerAdapter class name in docs

Presumably GlobalAuthenticationManagerConfigurer is meant to refer to GlobalAuthenticationConfigurerAdapter in the docs.

Any reason why this PR not merge yet?

Thanks for the PR @markhobson.
I applied this correction in the gh-pages branch via fe92155.


E2E cleanup Vue and React, add Qwik

Improve the Vue support by working more closely to how the Builder SDKs work.
Simplify React and Solid examples by importing from the "barrel".
Coming next: add Qwik E2E.... once I can get the Mitosis Qwik output accepted by Qwik.

I have Qwik E2E ready to go - after Misko’s PR #536.

I cherry-picked Misko's commit to fix Qwik output, and updated the test snapshot.
Still need to attack a build problem with the Qwik E2E, almost there.

I think this is OK to go… with two caveats:

First, it has some work Misko began on another PR, plus an update of the test case snapshots to pass, which make the Qwik output sufficient for the code under test in the E2E to work. Alternatively this PR could wait for that PR to be merged.
Second, there is a problem with a Qwik application consuming a Qwik library - I've worked around it here by instead consuming the source output, which unfortunately only works in “vite dev”, which this PR uses for the Qwik E2E.

Still, even with these challenges, nonzero E2E coverage of all working targets seems pretty valuable.
Future work beyond this PR includes:

Make a repro and report the problem noted above
Expand the simple program under test here, to be slightly less simple, with whatever additional complexities works across all targets.
The E2E support is sprawling out to quite a few directories in the packages directory. Consider moving it all under /e2e/.
Most importantly, I have a strategy in mind to have many example programs which can then be tested N*M across each target, to produce a "what features work where” test results grid.

Fantastic! We'll wait for Misko's PRs to get merged before this one:

Expand the simple program under test here, to be slightly less simple, with whatever additional complexities works across all targets.

For sure! The "full vision" I have for e2e tests is an automated test generation approach, kind of like what we have for snapshot tests:

create n separate Mitosis programs within the same project
export all of them as part of some hash, export const E2E_APPS: { APP1, APP2, APP3 }
Have a separate playwright test for each app, by opening localhost:3000?app=1, /?app=2, etc.
have each of the e2e apps loads the appropriate component based on the query param

This will allow us to build highly tailored & small programs that test separate/specific aspects of Mitosis, without being stuck with just one enormous app.

The E2E support is sprawling out to quite a few directories in the packages directory. Consider moving it all under /e2e/.

Sounds good to me 👍🏽. Could even be a yarn workspace with nested workspaces 😛

Most importantly, I have a strategy in mind to have many example programs which can then be tested N*M across each target, to produce a "what features work where” test results grid.

Exciting!

This is awesome!

Let me merge https://github.com/BuilderIO/mitosis/pull/536!
I pinged @manucorporat about the NPM and Qwik issue.

This rebase omits the Node 16 upgrade (now already merged).
Incidentally, I am a big fan of:

incrementalism: more, smaller changes
Isolating unrelated changes into separate reviewable branches or PRs
working on task N, discovering task M to go complete first
git rebase

@samijaber yes, next step is to cordon off the e2e stuff in to /e2e/ rather than let it expand any more.


Remove Empty Page Header Links and Add Beta Notice

Overview
Removed header links to the empty terminology and about pages and added a basic beta notice.

Mobile
Desktop

Demo
See description.
Notes
None!
Testing Instructions

Just checked mobile and desktop to make sure the notice looked good and the links were gone

@derekeder - I update the site title, I think "Decarobinze My State" makes sense considering the repo title and the domain name and it's also shorter and thus fits more cleanly on mobil


Enable autoscaling for Goobi worker node Fargate service

remove as this is more or less a dupe of #249


Add system or compatibility information to docs

As a new project, it would be helpful to help inform about system requirements prior to running this.

Python version
OS
Hardware
Drivers

done


Problem with running examples on Fedora 40 with KDE 6.2

Hi,
I am trying to run a sample on Fedora 40 KDE 6.2 with Nvidia RTX 4090 GPU. Validation layer prints such errors. They are reproducible in every single example.
The app draws only one frame without UI.

OS: Linux Fedora 40 6.10.12-200.fc40.x86_64
GPU: Nvidia RTX 4090, Driver version 560.35.03, NVML Version: 12.560.35.03
Wayland
KDE Plasma Version 6.2.0

[warning] (HPPSwapchain) Composite alpha 'Inherit' not supported. Selecting 'Opaque.
[warning] (HPPSwapchain) Present mode 'Mailbox' not supported. Selecting 'Immediate'.
[info] Depth format selected: VK_FORMAT_D32_SFLOAT
[info] Depth format selected: VK_FORMAT_D32_SFLOAT
[info] Depth format selected: VK_FORMAT_D32_SFLOAT
[info] Depth format selected: VK_FORMAT_D32_SFLOAT
VUID-vkResetCommandPool-commandPool-00040(ERROR / SPEC): msgNum: -1254218959 - Validation Error: [ VUID-vkResetCommandPool-commandPool-00040 ] Object 0: handle = 0x35b22c70, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xd10d270000000018, type = VK_OBJECT_TYPE_COMMAND_POOL; | MessageID = 0xb53e2331 | vkResetCommandPool():  (VkCommandBuffer 0x35b22c70[]) is in use. The Vulkan spec states: All VkCommandBuffer objects allocated from commandPool must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkResetCommandPool-commandPool-00040)
Objects: 2
[0] 0x35b22c70, type: 6, name: NULL
[1] 0xd10d270000000018, type: 25, name: NULL
VUID-vkBeginCommandBuffer-commandBuffer-00049(ERROR / SPEC): msgNum: -2080204129 - Validation Error: [ VUID-vkBeginCommandBuffer-commandBuffer-00049 ] Object 0: handle = 0x35b22c70, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x84029a9f | vkBeginCommandBuffer():  on active VkCommandBuffer 0x35b22c70[] before it has completed. You must check command buffer fence before this call. The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)
Objects: 1
[0] 0x35b22c70, type: 6, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum:<PHONE_NUMBER> - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
Objects: 1
[0] 0xd175b40000000013, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-surface-07783(ERROR / SPEC): msgNum: -1391585802 - Validation Error: [ VUID-vkAcquireNextImageKHR-surface-07783 ] Object 0: handle = 0xfa21a40000000003, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xad0e15f6 | vkAcquireNextImageKHR():  Application has already previously acquired 1 image from swapchain. Only 1 is available to be acquired using a timeout of UINT64_MAX (given the swapchain has 3, and VkSurfaceCapabilitiesKHR::minImageCount is 3). The Vulkan spec states: If forward progress cannot be guaranteed for the surface used to create the swapchain member of pAcquireInfo, the timeout member of pAcquireInfo must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-surface-07783)
Objects: 1
[0] 0xfa21a40000000003, type:<PHONE_NUMBER>, name: NULL
VUID-vkQueueSubmit-pCommandBuffers-00071(ERROR / SPEC): msgNum: 774851941 - Validation Error: [ VUID-vkQueueSubmit-pCommandBuffers-00071 ] | MessageID = 0x2e2f4d65 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] VkCommandBuffer 0x35b22c70[] is already in use and is not marked for simultaneous use. The Vulkan spec states: If any element of the pCommandBuffers member of any element of pSubmits was not recorded with the VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT, it must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pCommandBuffers-00071)
Objects: 0
VUID-vkQueueSubmit-pWaitSemaphores-03238(ERROR / SPEC): msgNum: -1258007888 - Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x33732700, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x33732700[]) is waiting on semaphore (VkSemaphore 0xd175b40000000013[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)
Objects: 2
[0] 0xd175b40000000013, type: 5, name: NULL
[1] 0x33732700, type: 4, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum:<PHONE_NUMBER> - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
Objects: 1
[0] 0xd175b40000000013, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-surface-07783(ERROR / SPEC): msgNum: -1391585802 - Validation Error: [ VUID-vkAcquireNextImageKHR-surface-07783 ] Object 0: handle = 0xfa21a40000000003, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xad0e15f6 | vkAcquireNextImageKHR():  Application has already previously acquired 1 image from swapchain. Only 1 is available to be acquired using a timeout of UINT64_MAX (given the swapchain has 3, and VkSurfaceCapabilitiesKHR::minImageCount is 3). The Vulkan spec states: If forward progress cannot be guaranteed for the surface used to create the swapchain member of pAcquireInfo, the timeout member of pAcquireInfo must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-surface-07783)
Objects: 1
[0] 0xfa21a40000000003, type:<PHONE_NUMBER>, name: NULL
VUID-vkQueueSubmit-pCommandBuffers-00071(ERROR / SPEC): msgNum: 774851941 - Validation Error: [ VUID-vkQueueSubmit-pCommandBuffers-00071 ] | MessageID = 0x2e2f4d65 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] VkCommandBuffer 0x35b22c70[] is already in use and is not marked for simultaneous use. The Vulkan spec states: If any element of the pCommandBuffers member of any element of pSubmits was not recorded with the VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT, it must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pCommandBuffers-00071)
Objects: 0
VUID-vkQueueSubmit-pWaitSemaphores-03238(ERROR / SPEC): msgNum: -1258007888 - Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x33732700, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x33732700[]) is waiting on semaphore (VkSemaphore 0xd175b40000000013[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)
Objects: 2
[0] 0xd175b40000000013, type: 5, name: NULL
[1] 0x33732700, type: 4, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum:<PHONE_NUMBER> - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
Objects: 1
[0] 0xd175b40000000013, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-surface-07783(ERROR / SPEC): msgNum: -1391585802 - Validation Error: [ VUID-vkAcquireNextImageKHR-surface-07783 ] Object 0: handle = 0xfa21a40000000003, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xad0e15f6 | vkAcquireNextImageKHR():  Application has already previously acquired 1 image from swapchain. Only 1 is available to be acquired using a timeout of UINT64_MAX (given the swapchain has 3, and VkSurfaceCapabilitiesKHR::minImageCount is 3). The Vulkan spec states: If forward progress cannot be guaranteed for the surface used to create the swapchain member of pAcquireInfo, the timeout member of pAcquireInfo must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-surface-07783)
Objects: 1
[0] 0xfa21a40000000003, type:<PHONE_NUMBER>, name: NULL
VUID-vkQueueSubmit-pCommandBuffers-00071(ERROR / SPEC): msgNum: 774851941 - Validation Error: [ VUID-vkQueueSubmit-pCommandBuffers-00071 ] | MessageID = 0x2e2f4d65 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] VkCommandBuffer 0x35b22c70[] is already in use and is not marked for simultaneous use. The Vulkan spec states: If any element of the pCommandBuffers member of any element of pSubmits was not recorded with the VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT, it must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pCommandBuffers-00071)
Objects: 0
VUID-vkQueueSubmit-pWaitSemaphores-03238(ERROR / SPEC): msgNum: -1258007888 - Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x33732700, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x33732700[]) is waiting on semaphore (VkSemaphore 0xd175b40000000013[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)
Objects: 2
[0] 0xd175b40000000013, type: 5, name: NULL
[1] 0x33732700, type: 4, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum:<PHONE_NUMBER> - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
Objects: 1
[0] 0xd175b40000000013, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-surface-07783(ERROR / SPEC): msgNum: -1391585802 - Validation Error: [ VUID-vkAcquireNextImageKHR-surface-07783 ] Object 0: handle = 0xfa21a40000000003, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xad0e15f6 | vkAcquireNextImageKHR():  Application has already previously acquired 1 image from swapchain. Only 1 is available to be acquired using a timeout of UINT64_MAX (given the swapchain has 3, and VkSurfaceCapabilitiesKHR::minImageCount is 3). The Vulkan spec states: If forward progress cannot be guaranteed for the surface used to create the swapchain member of pAcquireInfo, the timeout member of pAcquireInfo must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-surface-07783)
Objects: 1
[0] 0xfa21a40000000003, type:<PHONE_NUMBER>, name: NULL
VUID-vkQueueSubmit-pCommandBuffers-00071(ERROR / SPEC): msgNum: 774851941 - Validation Error: [ VUID-vkQueueSubmit-pCommandBuffers-00071 ] | MessageID = 0x2e2f4d65 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] VkCommandBuffer 0x35b22c70[] is already in use and is not marked for simultaneous use. The Vulkan spec states: If any element of the pCommandBuffers member of any element of pSubmits was not recorded with the VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT, it must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pCommandBuffers-00071)
Objects: 0
VUID-vkQueueSubmit-pWaitSemaphores-03238(ERROR / SPEC): msgNum: -1258007888 - Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x33732700, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x33732700[]) is waiting on semaphore (VkSemaphore 0xd175b40000000013[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)
Objects: 2
[0] 0xd175b40000000013, type: 5, name: NULL
[1] 0x33732700, type: 4, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum:<PHONE_NUMBER> - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
Objects: 1
[0] 0xd175b40000000013, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-surface-07783(ERROR / SPEC): msgNum: -1391585802 - Validation Error: [ VUID-vkAcquireNextImageKHR-surface-07783 ] Object 0: handle = 0xfa21a40000000003, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xad0e15f6 | vkAcquireNextImageKHR():  Application has already previously acquired 1 image from swapchain. Only 1 is available to be acquired using a timeout of UINT64_MAX (given the swapchain has 3, and VkSurfaceCapabilitiesKHR::minImageCount is 3). The Vulkan spec states: If forward progress cannot be guaranteed for the surface used to create the swapchain member of pAcquireInfo, the timeout member of pAcquireInfo must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-surface-07783)
Objects: 1
[0] 0xfa21a40000000003, type:<PHONE_NUMBER>, name: NULL
VUID-vkQueueSubmit-pCommandBuffers-00071(ERROR / SPEC): msgNum: 774851941 - Validation Error: [ VUID-vkQueueSubmit-pCommandBuffers-00071 ] | MessageID = 0x2e2f4d65 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] VkCommandBuffer 0x35b22c70[] is already in use and is not marked for simultaneous use. The Vulkan spec states: If any element of the pCommandBuffers member of any element of pSubmits was not recorded with the VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT, it must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pCommandBuffers-00071)
Objects: 0
VUID-vkQueueSubmit-pWaitSemaphores-03238(ERROR / SPEC): msgNum: -1258007888 - Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x33732700, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x33732700[]) is waiting on semaphore (VkSemaphore 0xd175b40000000013[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)
Objects: 2
[0] 0xd175b40000000013, type: 5, name: NULL
[1] 0x33732700, type: 4, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum:<PHONE_NUMBER> - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
Objects: 1
[0] 0xd175b40000000013, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-surface-07783(ERROR / SPEC): msgNum: -1391585802 - Validation Error: [ VUID-vkAcquireNextImageKHR-surface-07783 ] Object 0: handle = 0xfa21a40000000003, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xad0e15f6 | vkAcquireNextImageKHR():  Application has already previously acquired 1 image from swapchain. Only 1 is available to be acquired using a timeout of UINT64_MAX (given the swapchain has 3, and VkSurfaceCapabilitiesKHR::minImageCount is 3). The Vulkan spec states: If forward progress cannot be guaranteed for the surface used to create the swapchain member of pAcquireInfo, the timeout member of pAcquireInfo must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-surface-07783)
Objects: 1
[0] 0xfa21a40000000003, type:<PHONE_NUMBER>, name: NULL
VUID-vkQueueSubmit-pCommandBuffers-00071(ERROR / SPEC): msgNum: 774851941 - Validation Error: [ VUID-vkQueueSubmit-pCommandBuffers-00071 ] | MessageID = 0x2e2f4d65 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] VkCommandBuffer 0x35b22c70[] is already in use and is not marked for simultaneous use. The Vulkan spec states: If any element of the pCommandBuffers member of any element of pSubmits was not recorded with the VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT, it must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pCommandBuffers-00071)
Objects: 0
VUID-vkQueueSubmit-pWaitSemaphores-03238(ERROR / SPEC): msgNum: -1258007888 - Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x33732700, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x33732700[]) is waiting on semaphore (VkSemaphore 0xd175b40000000013[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)
Objects: 2
[0] 0xd175b40000000013, type: 5, name: NULL
[1] 0x33732700, type: 4, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum:<PHONE_NUMBER> - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
Objects: 1
[0] 0xd175b40000000013, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-surface-07783(ERROR / SPEC): msgNum: -1391585802 - Validation Error: [ VUID-vkAcquireNextImageKHR-surface-07783 ] Object 0: handle = 0xfa21a40000000003, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xad0e15f6 | vkAcquireNextImageKHR():  Application has already previously acquired 1 image from swapchain. Only 1 is available to be acquired using a timeout of UINT64_MAX (given the swapchain has 3, and VkSurfaceCapabilitiesKHR::minImageCount is 3). The Vulkan spec states: If forward progress cannot be guaranteed for the surface used to create the swapchain member of pAcquireInfo, the timeout member of pAcquireInfo must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-surface-07783)
Objects: 1
[0] 0xfa21a40000000003, type:<PHONE_NUMBER>, name: NULL
VUID-vkQueueSubmit-pCommandBuffers-00071(ERROR / SPEC): msgNum: 774851941 - Validation Error: [ VUID-vkQueueSubmit-pCommandBuffers-00071 ] | MessageID = 0x2e2f4d65 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] VkCommandBuffer 0x35b22c70[] is already in use and is not marked for simultaneous use. The Vulkan spec states: If any element of the pCommandBuffers member of any element of pSubmits was not recorded with the VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT, it must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pCommandBuffers-00071)
Objects: 0
VUID-vkQueueSubmit-pWaitSemaphores-03238(ERROR / SPEC): msgNum: -1258007888 - Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x33732700, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x33732700[]) is waiting on semaphore (VkSemaphore 0xd175b40000000013[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)
Objects: 2
[0] 0xd175b40000000013, type: 5, name: NULL
[1] 0x33732700, type: 4, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum:<PHONE_NUMBER> - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
Objects: 1
[0] 0xd175b40000000013, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-surface-07783(ERROR / SPEC): msgNum: -1391585802 - Validation Error: [ VUID-vkAcquireNextImageKHR-surface-07783 ] Object 0: handle = 0xfa21a40000000003, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xad0e15f6 | vkAcquireNextImageKHR():  Application has already previously acquired 1 image from swapchain. Only 1 is available to be acquired using a timeout of UINT64_MAX (given the swapchain has 3, and VkSurfaceCapabilitiesKHR::minImageCount is 3). The Vulkan spec states: If forward progress cannot be guaranteed for the surface used to create the swapchain member of pAcquireInfo, the timeout member of pAcquireInfo must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-surface-07783)
Objects: 1
[0] 0xfa21a40000000003, type:<PHONE_NUMBER>, name: NULL
VUID-vkQueueSubmit-pCommandBuffers-00071(ERROR / SPEC): msgNum: 774851941 - Validation Error: [ VUID-vkQueueSubmit-pCommandBuffers-00071 ] | MessageID = 0x2e2f4d65 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] VkCommandBuffer 0x35b22c70[] is already in use and is not marked for simultaneous use. The Vulkan spec states: If any element of the pCommandBuffers member of any element of pSubmits was not recorded with the VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT, it must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pCommandBuffers-00071)
Objects: 0
VUID-vkQueueSubmit-pWaitSemaphores-03238(ERROR / SPEC): msgNum: -1258007888 - Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x33732700, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x33732700[]) is waiting on semaphore (VkSemaphore 0xd175b40000000013[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)
Objects: 2
[0] 0xd175b40000000013, type: 5, name: NULL
[1] 0x33732700, type: 4, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum:<PHONE_NUMBER> - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
Objects: 1
[0] 0xd175b40000000013, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-surface-07783(ERROR / SPEC): msgNum: -1391585802 - Validation Error: [ VUID-vkAcquireNextImageKHR-surface-07783 ] Object 0: handle = 0xfa21a40000000003, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xad0e15f6 | vkAcquireNextImageKHR():  Application has already previously acquired 1 image from swapchain. Only 1 is available to be acquired using a timeout of UINT64_MAX (given the swapchain has 3, and VkSurfaceCapabilitiesKHR::minImageCount is 3). The Vulkan spec states: If forward progress cannot be guaranteed for the surface used to create the swapchain member of pAcquireInfo, the timeout member of pAcquireInfo must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-surface-07783)
Objects: 1
[0] 0xfa21a40000000003, type:<PHONE_NUMBER>, name: NULL
VUID-vkQueueSubmit-pCommandBuffers-00071(ERROR / SPEC): msgNum: 774851941 - Validation Error: [ VUID-vkQueueSubmit-pCommandBuffers-00071 ] | MessageID = 0x2e2f4d65 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] VkCommandBuffer 0x35b22c70[] is already in use and is not marked for simultaneous use. The Vulkan spec states: If any element of the pCommandBuffers member of any element of pSubmits was not recorded with the VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT, it must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pCommandBuffers-00071)
Objects: 0
VUID-vkQueueSubmit-pWaitSemaphores-03238(ERROR / SPEC): msgNum: -1258007888 - Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x33732700, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x33732700[]) is waiting on semaphore (VkSemaphore 0xd175b40000000013[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)
Objects: 2
[0] 0xd175b40000000013, type: 5, name: NULL
[1] 0x33732700, type: 4, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum:<PHONE_NUMBER> - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
Objects: 1
[0] 0xd175b40000000013, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-surface-07783(ERROR / SPEC): msgNum: -1391585802 - Validation Error: [ VUID-vkAcquireNextImageKHR-surface-07783 ] Object 0: handle = 0xfa21a40000000003, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xad0e15f6 | vkAcquireNextImageKHR():  Application has already previously acquired 1 image from swapchain. Only 1 is available to be acquired using a timeout of UINT64_MAX (given the swapchain has 3, and VkSurfaceCapabilitiesKHR::minImageCount is 3). The Vulkan spec states: If forward progress cannot be guaranteed for the surface used to create the swapchain member of pAcquireInfo, the timeout member of pAcquireInfo must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-surface-07783)
Objects: 1
[0] 0xfa21a40000000003, type:<PHONE_NUMBER>, name: NULL
VUID-vkQueueSubmit-pCommandBuffers-00071(ERROR / SPEC): msgNum: 774851941 - Validation Error: [ VUID-vkQueueSubmit-pCommandBuffers-00071 ] | MessageID = 0x2e2f4d65 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] VkCommandBuffer 0x35b22c70[] is already in use and is not marked for simultaneous use. The Vulkan spec states: If any element of the pCommandBuffers member of any element of pSubmits was not recorded with the VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT, it must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pCommandBuffers-00071)
Objects: 0
VUID-vkQueueSubmit-pWaitSemaphores-03238(ERROR / SPEC): msgNum: -1258007888 - Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x33732700, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x33732700[]) is waiting on semaphore (VkSemaphore 0xd175b40000000013[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)
Objects: 2
[0] 0xd175b40000000013, type: 5, name: NULL
[1] 0x33732700, type: 4, name: NULL
[error] Error Message: Detected Vulkan error: ERROR_DEVICE_LOST
[error] Failed when running application HDR
terminate called after throwing an instance of 'vk::DeviceLostError'
what():  vk::Device::waitIdle: ErrorDeviceLost

Can you disable all implicit layers and check if the problem persists? It's odd that this happens for all samples and might be something caused by a faulty third-party layer.

I have disabled all validation layers and the problem still exists.

I removed MangoHud and disabled all validation layers.
The problem also repeats in another sample 'ray_tracing_reflection'.
I'm based on commit '6505639cd6d1fddc6c22d9005f278e4ce6cfe2d0'. Interestingly I have no problems on your private examples (https://github.com/SaschaWillems/Vulkan). There the applications run without any problem.
I have my operating system and drivers updated to the latest version. I use a proprietary driver, not an open-source.

That's interesting, and the fact that my samples work does hint a problem at our samples. I don't have a Linux setup right now, so might take a while.

Hi @SaschaWillems,
I managed to find the cause of the problem and a solution. The problem is located in the glfw library. VulkanSample repo is using an old version. Upgrading to version 3.4 solved the problem.

Thanks for that information. Sounds kinda odd, as we only use glfw for windowing, but might be related to Fedora having newer libraries that don't match our included one causing conflicts.
Updating glfw is on our list, we'll probably tackle that a bit earlier to avoid broader issues.


Simulation iteration issue

Describe the bug
When I attempt to run the simulation after setting up all my gear, it will only go through 1 iteration (using Firefox). I can only rerun it if I refresh the page. If I don't refresh and try to run it again it just thinks and never provides any results. I have set it to run 3000 iterations but it simply won't do more than 1.
To Reproduce
Steps to reproduce the behavior:

Go to the website and enter all your gear/spec/etc.
Click on SIMULATE
See error

Expected behavior
It used to run through all 3000 iterations and return a good number with which to judge whether or not an item is an upgrade.
Sim Links and Screenshots
I've attached a screenshot that shows an unusually high dps number after going through only 1 iteration.
Desktop (please complete the following information):

OS: Windows 7
Browser: Firefox
Version: 107

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
I've tried running this in Microsoft Edge and it works. However, if there is any kind of update or fix for Firefox I would prefer to continue using it since that is my browser of choice. It was working in Firefox up until about a week ago.

Hi @strider209 could you give me a link to your setup? I use only firefox for all dev work and it works for me on both desktop and mobile firefox.

You could also see if there was an exception in your console (if you know how to do that)

Not sure how to do that, but it's working now. I don't know if a recent
firefox update fixed it but I tried it a few days later and didn't have any
issues. Thanks though!
On Wed, Nov 30, 2022 at 5:03 PM Ben Echols @.***> wrote:

You could also see if there was an exception in your console (if you know
how to do that)
—
Reply to this email directly, view it on GitHub
https://github.com/wowsims/wotlk/issues/1941#issuecomment-1332914781,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD4IATTAUS445Y4JS3LWG73WK7TMPANCNFSM6AAAAAASLXQ24E
.
You are receiving this because you were mentioned.Message ID:
@.***>


configure images with a UID and set SC in deployments

the hyperfed user is create with UID 1001
the controller and webhook pods are run with a security context setting runAsUser: 1001 so that kubernetes knows it's not running as a root user (supporting restricted pod security policies)
also create the hyperfed user in a named group which seems to be required for chown to apply correctly
also execute chown after copying binaries to hyperfed path as the binaries were ending up owned by root in my testing

Great, thank you!
/approve
/lgtm


All newly release controllers fail to start on OpenShift

Describe the bug
All new controllers with runtime of v0.18.0 fail to start. This appears to be caused by a change in the deployment.yaml.tpl in the code generator, in this PR
Steps to reproduce

Install any operator that was released as part of v0.18.0 runtime in an OpenShift cluster
See that the controller manager pod will CrashLoopBackOff

Logs
Controller pod logs
oc logs ack-rds-controller-d959dc69-6phtd
1.6481558349385543e+09	ERROR	setup	Unable to create controller manager	{"aws.service": "rds", "error": "unable to start service controller as AWS region is missing. Please pass --aws-region flag or set AWS_REGION environment variable"}
main.main
	/github.com/aws-controllers-k8s/rds-controller/cmd/controller/main.go:67
runtime.main
	/opt/bitnami/go/src/runtime/proc.go:255

Config map configuration
 oc get configmap ack-user-config -oyaml
apiVersion: v1
data:
  ACK_ENABLE_DEVELOPMENT_LOGGING: "true"
  ACK_LOG_LEVEL: debug
  ACK_RESOURCE_TAGS: hellofromocp
  ACK_WATCH_NAMESPACE: ""
  AWS_REGION: us-west-2
kind: ConfigMap
metadata:
  creationTimestamp: "2022-01-12T19:22:11Z"
  name: ack-user-config
  namespace: ack-system
  resourceVersion: "3819318"
  uid: befa04f3-fc0c-4f96-bd70-a1872059a708

Snippet from the deployment
 spec:
    containers:
    - args:
      - --aws-region
      - $(AWS_REGION)
      - --aws-endpoint-url
      - $(AWS_ENDPOINT_URL)
      - --enable-development-logging
      - $(ACK_ENABLE_DEVELOPMENT_LOGGING)
      - --log-level
      - $(ACK_LOG_LEVEL)
      - --resource-tags
      - $(ACK_RESOURCE_TAGS)
      - --watch-namespace
      - $(ACK_WATCH_NAMESPACE)
      command:
      - ./bin/controller
      env:
      - name: ACK_SYSTEM_NAMESPACE
        valueFrom:
          fieldRef:
            apiVersion: v1
            fieldPath: metadata.namespace
      - name: AWS_REGION
      - name: AWS_ENDPOINT_URL
      - name: ACK_WATCH_NAMESPACE
      - name: ACK_ENABLE_DEVELOPMENT_LOGGING
        value: "false"
      - name: ACK_LOG_LEVEL
        value: info
      - name: ACK_RESOURCE_TAGS
        value: services.k8s.aws/managed=true,services.k8s.aws/created=%UTCNOW%,services.k8s.aws/namespace=%KUBERNETES_NAMESPACE%
      - name: OPERATOR_CONDITION_NAME
        value: ack-rds-controller.v0.0.20
      envFrom:
      - configMapRef:
          name: ack-user-config
          optional: false
      - secretRef:
          name: ack-user-secrets
          optional: false

Observations
This means that env is taking precedence over envFrom. This also means that kustomize is not propagating the default values that are in the tpl file properly (or possibly operator-sdk). We would need to look at the tmp directories in real time to see which is dropping the default "" empty values.
Expected outcome
I would expect that the controller manager pod would be able to start.
Environment
Production

Kubernetes version: 1.22
Using EKS (yes/no), if so version? no, OpenShift
AWS service targeted (S3, RDS, etc.) - All

Thoughts on fixes/approaches

We need to figure out why "" is being dropped and by which tool, all of my thoughts after this assume this has been fixed.

Approach One

Once defaults are in place and working properly

Change user-env.yaml.tpl to populate env instead of envFrom
Not sure if this will work properly since kustomize is overlaying this file after the fact, ie not sure it will merge two env sections properly, the default one and this one

This approach is in-line with the desired approach of overwriting defaults in deployments found here. This would be the desired approach if kustomize works properly.

Approach Two
If approach one does not work, then

In the olm generation scripts we might have to remove the env section from the deployment file, which would then get replaced with the existing envFrom from the user-env.yaml.tpl file. This approach seems really dirty and prone to errors though and would hide part of the process. I'd hope we can avoid this.

These are just some ideas I thought of quickly, open to other ideas as well, but I'd like input so we can accomplish a normal kustomize install and an OpenShift install with the same files/process/etc.

/assign


runtime: binaries should fail at startup when built with a GOARM64 version not supported on the runtime hardware

Go version
go version go1.23.0 linux/arm64
Output of go env in your module/workspace:
Not relevant

What did you do?
On an arm64 host, I ran
GOARM64=v9.5 go test

on a simple hello world test.
What did you see happen?
The test ran and passed.
What did you expect to see?
This is on an AWS c7g instance. This is a graviton3 chip. I'm not 100% sure what the exact arm64 architecture version of that chip is (anyone know a good way to tell?), but I'm pretty sure it's v8.x. Someone on Hacker News claims that graviton3 is v8.4. In /proc/cpuinfo I see
processor       : 0
BogoMIPS        : 2100.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x1
CPU part        : 0xd40
CPU revision    : 1

Anyway, I'm pretty sure that it does not support arm64 v9.5. Yet, the binary I compiled with GOARM64=v9.5 does not check for CPU capabilities and exit on startup.
By contrast, on my local machine (AMD Ryzen 9 3900X) if I run
$ GOAMD64=v4 go test
This program can only be run on AMD64 processors with v4 microarchitecture support.
exit status 1

because my chip only supports GOAMD64=v3.
From the CL 559555 it sounds like GOARM64 support isn't being used in the compiler to do anything yet. However, it's still important that we fix this, because the arm64.vX.Y build tags are available to user code. I am able to write code today using (for example) the arm64.v9.3 build tag to guard some v9.3-specific feature; when I run this binary on a v8.0 CPU it won't crash on startup but will hit some invalid instruction later.
P.S. It would be good if someone would update some of the wiki pages for GOARM64; in particular, MinimumRequirements and GoArm. I found it a little hard to get info about GOARM64; as far as I can tell, besides the Go 1.23 release notes, the only places it's mentioned are go help environment and go help buildconstraint.
/cc @andreybokhanko @cherrymui

Related Issues and Documentation

cmd/compile: fails to run on some ARMv7 processors #14711 (closed)
vendor/golang.org/x/arch/arm64/arm64asm: Go 1.10.beta1: test failures #23237 (closed)
doc: document that GOARM applies to cmd/gc as well #9672 (closed)
cmd/compile: dynamic checks for atomics should be removed for ARM64 targets that support LSE #66131
GOOS=android GOARCH=arm doesn't compile on amd64 #17736 (closed)
runtime/race: illegal instruction when building for old processor #68251 (closed)
Tests fail on armel (little-endian ARM) #3532 (closed)
runtime:  Add error message when running non GOAMD64=v1 on unsupported hardware #48506 (closed)
compiling on different architectures #30089 (closed)
runtime: go 1.8 + ARM + 64k pages not working #18408 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

@cespare , thanks for reporting this!
I'm the original author of GOARM64 feature, so it's appropriate for me to fix this issue. In general, I fully agree with @cespare proposal -- we should do the same on ARM64 what we do on AMD64, if only for the sake of consistency.
@cherrymui , could you, please, assign this on me?

CL with a fix submitted for review: https://go-review.googlesource.com/c/go/+/610195
Note that it only checks presence of LSE extension if compilation targeted it (which is true for all ARM64>=v8.1). Why not all other extensions? Two reasons:

At the moment, we only use (and pass as a macro to assembler) LSE. Adding a check for other ARM64 extensions (that we don't actually use at the moment) would require adding / passing a slew of additional macros.
The motivation for AMD64 check is program crashing ungracefully when executed on an older CPU (https://github.com/golang/go/issues/49586). Thus, AMD64 runtime checks presence of instruction that can actually be generated and used for newer CPUs targeted by GOAMD64, not all possible AMD64 extensions.

@andreybokhanko Let me highlight something I mentioned in the original report:
Compiling with a particular GOARM64 value does not only have an effect on the instructions generated by the Go compiler. It also is made available to user code via the arm64.vX.Y build tags. That means that users can write assembly code which targets particular arm64 features and guard it with build tags. Even if the compiler never generates some particular v9.5 instruction, I can write some code in a //go:build arm64.v9.5 file which uses that instruction. The resulting binary should check for v9.5 support when it starts up so that that instruction is known to be valid for the chip it's running on.

I also think that checking the required version and features would be better.
What is the best way to check the CPU version and features? From https://go-review.googlesource.com/c/go/+/610195/comment/219aedb1_f5d5dd4e/  it sounds like we can only check individual features, and it would be pretty complex to check the version?

@andreybokhanko Let me highlight something I mentioned in the original report:
Compiling with a particular GOARM64 value does not only have an effect on the instructions generated by the Go compiler. It also is made available to user code via the arm64.vX.Y build tags. That means that users can write assembly code which targets particular arm64 features and guard it with build tags. Even if the compiler never generates some particular v9.5 instruction, I can write some code in a //go:build arm64.v9.5 file which uses that instruction. The resulting binary should check for v9.5 support when it starts up so that that instruction is known to be valid for the chip it's running on.

OK, got it.
Note, though, that while build tags with an arch version number can be used in theory, in practice this happens extremely rare -- for example, there is just one case in the entire Go compiler + runtime source code base that checks for a specific version of amd64 build tag. Check for amd64 tag, without a specific version, is widespread.
I'm not saying that checking for all possible ARM64 versions + extensions would be a bad thing -- just that in case of ARM64 it's quite cumbersome and error-prone see my comment for details) while relatively low in importance.

Note, though, that while build tags with an arch version number can be used in theory, in practice this happens extremely rare -- for example, there is just one case in the entire Go compiler + runtime source code base that checks for a specific version of amd64 build tag. Check for amd64 tag, without a specific version, is widespread.

Sure, it's not a super common need. But I don't think it will be that uncommon -- if you are going to the trouble of writing assembly, it is often because you want to squeeze as much performance as possible out of the hardware for a specialized tasks, and using newer instructions on newer hardware is one aspect of that.
The amd64 build tag has been around forever, but the amd64.vX build tags were only added two years ago in Go 1.20 (see #45454). People haven't had that much time to start using them yet. At my work, we only started using it in the last year.


fix: cache configmap don't create with workflow has retrystrategy. Fi…

I think MemoizationStatus should like inputs, if the executeTmpl has Memoize, the node should have MemoizationStatus.
I test it and if i Set the MemoizationStatus,  the ut pass. If did't，the ut will failed.

Fixes #12490
Motivation

Modifications

Verification

Would also fix the second part of #10426

I'm going to have a build and test of this tomorrow, but the code looks like it does the right thing. Thanks @shuangkun.

Thanks for your review!

This breaks the workflow example from #10426. Without this change the workflow doesn't correctly memoize but does run correctly to completion. With this change you get
level=error msg="Recovered from panic" namespace=argo r="runtime error: invalid memory address or nil pointer dereference" stack="goroutine 307 [running]:\nruntime/debug.Stack()\n\t/usr/local/go/src/runtime/debug/stack.go:24 +0x5e\ngithub.com/argoproj/argo-workflows/v3/workflow/controller.(*wfOperationCtx).operate.func2()\n\t/home/vscode/go/src/github.com/argoproj/argo-workflows/workflow/controller/operator.go:200 +0xb4\npanic({0x20c1e00?, 0x39f0490?})\n\t/usr/local/go/src/runtime/panic.go:920 +0x270\ngithub.com/argoproj/argo-workflows/v3/workflow/controller.(*wfOperationCtx).runOnExitNode(0xc00150a0c0, {0x27b8560, 0x3a5c2c0}, 0x0, 0xc000d07980, {0xc0015265a0, 0x1b}, 0xc000fe9650?, {0xc000aa1db8, 0x14}, ...)\n\t/home/vscode/go/src/github.com/argoproj/argo-workflows/workflow/controller/exit_handler.go:20 +0xa6\ngithub.com/argoproj/argo-workflows/v3/workflow/controller.(*wfOperationCtx).executeDAGTask(0xc00150a0c0, {0x27b8560, 0x3a5c2c0}, 0xc00034b490, {0xc000b92a90, 0xe})\n\t/home/vscode/go/src/github.com/argoproj/argo-workflows/workflow/controller/dag.go:614 +0x2232\ngithub.com/argoproj/argo-workflows/v3/workflow/controller.(*wfOperationCtx).executeDAG(0xc00150a0c0, {0x27b8560, 0x3a5c2c0}, {0xc001526540, 0x1b}, 0xc000404b80, {0xc000acab40, 0x21}, 0xc000adfd40, {0x27bbe20, ...}, ...)\n\t/home/vscode/go/src/github.com/argoproj/argo-workflows/workflow/controller/dag.go:269 +0x42a\ngithub.com/argoproj/argo-workflows/v3/workflow/controller.(*wfOperationCtx).executeTemplate(0xc00150a0c0, {0x27b8560, 0x3a5c2c0}, {0xc001526540, 0x1b}, {0x27bbe20, 0xc000b46000?}, 0x46add3?, {{0x0, 0x0, ...}, ...}, ...)\n\t/home/vscode/go/src/github.com/argoproj/argo-workflows/workflow/controller/operator.go:2120 +0x2d4a\ngithub.com/argoproj/argo-workflows/v3/workflow/controller.(*wfOperationCtx).operate(0xc00150a0c0, {0x27b8560?, 0x3a5c2c0})\n\t/home/vscode/go/src/github.com/argoproj/argo-workflows/workflow/controller/operator.go:364 +0x18cb\ngithub.com/argoproj/argo-workflows/v3/workflow/controller.(*WorkflowController).processNextItem(0xc00042f900, {0x27b8560, 0x3a5c2c0})\n\t/home/vscode/go/src/github.com/argoproj/argo-workflows/workflow/controller/controller.go:802 +0x687\ngithub.com/argoproj/argo-workflows/v3/workflow/controller.(*WorkflowController).runWorker(0xc000d846a0?)\n\t/home/vscode/go/src/github.com/argoproj/argo-workflows/workflow/controller/controller.go:719 +0x88\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1(0x30?)\n\t/home/vscode/go/pkg/mod/k8s.io/apimachinery@v0.24.3/pkg/util/wait/wait.go:155 +0x33\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil(0x0?, {0x27909c0, 0xc000d0a870}, 0x1, 0xc0006b6240)\n\t/home/vscode/go/pkg/mod/k8s.io/apimachinery@v0.24.3/pkg/util/wait/wait.go:156 +0xaf\nk8s.io/apimachinery/pkg/util/wait.JitterUntil(0x0?, 0x3b9aca00, 0x0, 0x0?, 0x0?)\n\t/home/vscode/go/pkg/mod/k8s.io/apimachinery@v0.24.3/pkg/util/wait/wait.go:133 +0x7f\nk8s.io/apimachinery/pkg/util/wait.Until(0x0?, 0x0?, 0x0?)\n\t/home/vscode/go/pkg/mod/k8s.io/apimachinery@v0.24.3/pkg/util/wait/wait.go:90 +0x1e\ncreated by github.com/argoproj/argo-workflows/v3/workflow/controller.(*WorkflowController).Run in goroutine 50\n\t/home/vscode/go/src/github.com/argoproj/argo-workflows/workflow/controller/controller.go:339 +0x185a\n" workflow=memoized-workflow-testgbx2b

That's how it comes out in the logs, sorry it's horridly formatted.
Could you look into this?

This causes the workflow given as an example in #10426 to crash the controller.

Thanks for your good find.   I test it and find the root cause is when the node hit the memoize, it won't has children even though it is a retry type node.  So i think we should change node output from children when it didn't hit memoize.

Can you fix the PR title?

Yes，Is this okay?


Throttling (failed) logins

*** THIS IS A QUESTION; NOT A BUG REPORT / ISSUE ***
Hello,
First of all many thanks for this great authentication library you've developed.
I am sure the throttling mechanism has also been implemented for login; more specifically invalid login attempts. I was curious to know the threshold for this throttling.
The reason I am asking is because, after the initial setup, I found out that multiple "verification" requests did indeed show to "Too many requests" exception; however the same was not true to multiple invalid login attempts - be it E-Mail id or password. I was able to login with a valid login and password after 25+ consecutive attempts with invalid credentials within 5 minutes on the development setup.
One more question is, generally how long does such throttling last ? I do understand that throttling mechanism behaves differently in different situations, which is why I've written generally.
Thank you again.

Excellent question, thank you!
We would have documented this before, but it’s a little bit complicated, and the documentation could quickly become outdated because the numbers could (slightly) change from time to time. But here it is:
First, logins share one throttling mechanism with every action that can be used to enumerate user accounts, such as registration and password reset. That’s because you can use all these to check which accounts exist. Hiding that information entirely is impractical and bad UX. So we limit it – to 75 attempts once and then just 1 per hour. Per IP address. Shared with the other actions or features.
(Yes, these limits are intentionally permissive. You don’t want to impact practical usage by real users ever, while making life harder for bad actors. Perhaps we could reduce these a bit.)
Second, logins cause throttling when they fail. That’s 500 attempts per email address and per username (because you don’t want bad actors to be able to lock out real users), and 20 initially per IP address, then 4 per hour. These are all enforced at the same time.
Does that help?

Hello,
Wonderful explanation! It would be great if these could be
user-configurable. Will see if I can contribute to this in any way, time
permitting.
Thank you again.
Regards,
R. Śivarāmakṛṣṇa Śarmā
|| Tiruchitrambalam ||
On Sat, 29 Aug 2020 at 05:50, Marco<EMAIL_ADDRESS>wrote:

Excellent question, thank you!
We would have documented this before, but it’s a little bit complicated,
and the documentation could quickly become outdated because the numbers
could (slightly) change from time to time. But here it is:
First, logins share one throttling mechanism with every action that can
be used to enumerate user accounts, such as registration and password
reset. That’s because you can use all these to check which accounts exist.
Hiding that information entirely is impractical and bad UX. So we limit it
– to 75 attempts once and then just 1 per hour. Per IP address. Shared
with the other actions or features.
(Yes, these limits are intentionally permissive. You don’t want to impact
practical usage by real users ever, while making life harder for bad
actors. Perhaps we could reduce these a bit.)
Second, logins cause throttling when they fail. That’s 500 attempts per
email address and per username (because you don’t want bad actors to be
able to lock out real users), and 20 initially per IP address, then 4 per
hour. These are all enforced at the same time.
Does that help?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/delight-im/PHP-Auth/issues/225#issuecomment-683200728,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABVL2XHGYF2XZW6TR7NTRUDSDBCUVANCNFSM4QNVOHRA
.

Documenting all those limits (in an understandable way) is hard enough, and making them user-configurable (and again understandable) is hard as well, and there’s rarely a need to change the limits (for most applications). But I’ll see what we can do here.

In general, the library turned out to be excellent. But from time to time they call me and say that they cannot log in, despite the fact that the login attempt was the first. This happens rarely enough, but not pleasant.

@MichaelKheel Thanks! When “they” (I guess your users) call you and complain about the login not working, are you sure that throttling is the cause there? I mean, do they cite a message from your UI that says the account is temporarily throttled, for example? As you know, this is a security measure, so what solution would you suggest? Just disabling this? That would mean that your users’ accounts are “under attack” but any safeguard against that is turned off. I guess what you have here, if throttling is indeed the cause, is either someone on the same IP address as your legitimate user, or someone else, from a different IP address, with more than 500 failed attempts at logging in within a short time. Do you really want to allow that (and more)? Throttling can be disabled entirely, which is documented here. Does that help?

Hello,
sry to write in this post but my question comes here pretty close ... while looking here over the code and read the readme file i nowhere see a db->delete function for table "users throttling" !? How u delete them when they are expired ?


iPad Pro M1 reboots

I need to jailbreak but my iPad reboots

kernel panic is happening for some people plus this is a dev jailbreak so expect everything to go wrong

Maybe its the WiFi-Bug?

Maybe its the WiFi-Bug?

tried turning wifi off still didn’t work

Did you turn it off from settings and not from the control center?

Did you turn it off from settings and not from the control center?

yes i tried that

Me too

I think I will use palera1n but

I have to wait until I get a laptop
it’s gonna be a Windows laptop
I have to dual boot Linux
BRUH

I think I will use palera1n but

I have to wait until I get a laptop
it’s gonna be a Windows laptop
I have to dual boot Linux
BRUH

Palera1n only works on A11 and lower devices

This jailbreak is apple A-chip devices only. Can people f***ing read man, there's at least 20 of the same goddamn issue posted here. And most people are end users who are purposely avoiding the fact that this jailbreak ISNT for end users.

OK THATS IT IM DOWNGRADING TO IOS 14

why repoen


[TEST][FLAKY] float16 test_conv2d_nchw

https://ci.tlcpack.ai/blue/organizations/jenkins/tvm/detail/PR-8687/1/

The error log was pretty strange since the reported max rtol is smaller than the actual number. Perhaps it has something to do with fp 16. cc @Lunderberg since this might related to the recent changes you made

Hmm, that failing test is parametrized to include float16, but the failing case was using float32 values.  It's also running with a fixed random seed to try to prevent any flakiness due to input data.
That particular parametrization was running with cudnn, added to the CI in #8383 and recently merged.  I'm not able to reproduce the failure in my local ci_gpu docker instance, either before or after #8383.  (Ran 100 iterations just no, no issues locally.)

Maybe the CI nodes have harder hardware that isn't compatible with this version of cudnn?  The ci_gpu image uses cuda 11.0 + cudnn 8.0.5, which should be compatible with SM 3.5 or higher.  What hardware are the CI nodes running on?

It looks like the numpy results are returning identically zero for the values around the edge, while the cudnn results have non-zero values.  The numpy results are correct due to the padding used for that value.
Something that might be complicating the investigation is that cudnn attempts to find the most efficient method on its own if nothing is specified.  Last time I touched this file, I hoisted it up to be a configurable knob, but it still defaults to letting cudnn run its own benchmarks and select the fastest.
My current mental model is that in some cases, cudnn's benchmark selects an algorithm that is faster, but has approximations that result in slightly non-zero padding.  If that cudnn implementation is selected, then the test fails in CI.  Unfortunately, of the 18 options that cudnn supports, I only have hardware support to test out 4 of them, and all 4 of them keep the padding identically equal to zero.

And those same 5 are also not supported on kraken, either.

perhaps as a simplest resolution we can swap the numpy and cuddn results. Note that for 0 it matters less

I'm not sure that would make a difference.  The total allowed tolerance is tol = atol + rtol*abs(y), and so that would only increase the total tolerance by a few percent.

@Lunderberg you are right. perhaps a better way is indeed to relax the atol for now then

@tqchen is the consensus to increase the atol?

I'd agree on relaxing the atol, since handling result values near zero is what it is intended to do.

@Lunderberg sounds good!

This test also happens to be flaky in the CI run of #8492 : https://ci.tlcpack.ai/blue/organizations/jenkins/tvm/detail/PR-8492/53/pipeline/

I ran into this same test on #8723 just now, and so I added the atol update for test_conv2d_nchw to it.

close for now as the atol adjustment PR is now merged


Can we treat the method as one of data augmentation?

First, This is a interestion method and thanks for sharing the code.
Just a question about paper's detail.
We all know that data augmentation for tabular regression is hard to implement.
I am wondering if I use this method as data augmentation and compare to SMOGN or others method that augment tabular regression data. Will it be appropriate why or why not?
I am not sure whether this is the right place to talk about the paper, if not I will delete the issue.
Thanks.

Hello! Thanks for considering using REaLTabFormer!
I think REaLTabFormer may be helpful in data augmentation applications as well. One of the works (not public) where we use REaLTabFormer shows that it can generate out-of-data sample observations that could be useful for model generalization. SMOTE/SMOGN may not have this diversity see (https://arxiv.org/pdf/2209.15421.pdf).
However, as in any machine learning problem, cross-validation must be used to judge which parameters and components help improve the performance.
Thanks!

Thanks for the quick reply, if the method works on my project, that will be great.


modify local storage project #942

Related Issue

modify local storage project #942

Closes: #942
Describe the changes you've made

Modify styling.
Change UI of project.
Removed unwanted content.
Make well responsive.
Make code clean.

Describe if there is any unusual behavior of your code
NA
Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[x] New and existing unit tests pass locally with my changes.

Screenshots
Before :

After :

@Vedant-Rahane Are you using any kind of formatter when saving the file?
Script js is changed very much and conflicts are there, Please resolve them, Technically script.js would not required to be changed as you are working only on UI part.

@Vedant-Rahane  That requires only change one line in script.js of Image portion,
But lot of projects are removed what you are pushing, Merging this PR will lead to removal of a lot of existing projects.
Fix the script.js, Let me know If you need any help, DM on discord if not available  on github

@991rajat I am really sorry but I don't know how this happened. While pushing I had only made one change in project image.
I have resolved conflicts is it ok now ?

Yeah Looks Good.

Thanks for this contribution.
Keep Contributing.


[Bug][Framework] fields are empty in table _devlake_subtasks

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
I want to statisticize the subtasks' time cost from table _devlake_subtasks.
What do you expect to happen
I found some subtasks' fields are empty or null.

How to reproduce
run sql select * FROM _devlake_subtasks where began_at is null  order by number asc LIMIT  100.
Anything else
No response
Version
main
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@klesh

closed by https://github.com/apache/incubator-devlake/pull/7959


Bug when using an object as a key

It works greatly if I don't pass any key:

It works OK if I pass a value as a key (string, number):

But it bugs when passing an object as a key:

Looking at the last image, you'll see that it rendered only one item. The curious fact is that when query-selecting the item, its key is the first object of my collection.

I thought it was a bug with the jsx transform, but tried with vanilla idom, and the error persists.
Look at the examples below:
https://jsfiddle.net/nhzg4ft0/ (passing an object)
https://jsfiddle.net/nhzg4ft0/1/ (passing a key)

The code:
function render() {
  IncrementalDOM.elementOpen('ul');
  [
    {
      id: 1,
      name: 'bolinha'
    },
    {
      id: 2,
      name: 'pneu'
    },
    {
      id: 3,
      name: 'aloha'
    }
  ].forEach(item => {
    IncrementalDOM.elementOpen('li', item); // change to item.id and it works as expected
    IncrementalDOM.text(item.name);
    IncrementalDOM.elementClose('li');
  });
  IncrementalDOM.elementClose('ul');
}

IncrementalDOM.patch(document.body, render);

See the API docs for elementOpen:

string key - The key that identifies Element for reuse.

The reason passing an object only renders one item is because we stringify the object to "[object Object]", so all the "keys" match.

OK, thanks!
I think I was misusing the key, since I could use any property I wanted for that purpose, and the key only for tracking/indexing. I'm closing the issue.


Drop refernce to Build Variants in README.md

What

Why

Test Plan

✅ | ❌ I've added unit tests for this change.
✅ | ❌ The reviewer should manually test the changes in this PR.

Demo

How

Current dependencies on/for this PR:

main

PR #113

PR #114

PR #115

PR #116   👈

This comment was auto-generated by Graphite.


[Action] Improve TAG thumbnails

Description
We have TAG thumbnails for youtube which are a bit outdated now. We can use our new branding (and new correct logo) to create new thumbnails keeping some consistency across the TAG.
Current thumbnails: https://drive.google.com/drive/folders/1QLjeOeYRztW4FKWubjYOmzAsoGEJKep3
Outcome
New TAG thumbnails!
To-Do

[ ] WG comms
[ ] WG green reviews (include their new logo!)
[ ] TAG overall meeting
[ ] TAG apac meeting
[ ] sustainability week meetings
[ ] Perhaps a generic one we can add to adhoc meetings/project meetings

Code of Conduct

[x] I agree to follow this project's Code of Conduct

Comments
No response

@Ludovik95 there you go!

@claire-fletcher I created on Google Slide the thumbnails for Youtube with the new design style at this link: https://docs.google.com/presentation/d/1YVvANEO69HI8IyI0c_pj5ycXVuCOtIHaLkp0F4fE3Ek/edit?usp=sharing
If they are okay I can copy them into the presentation you linked above (or into a new one, as you prefer) 😊

These are great! I can pop them into the drive folder I created

If you put it in the same folder as the old ones here: https://drive.google.com/drive/folders/1QLjeOeYRztW4FKWubjYOmzAsoGEJKep3

Done ✨


Show timeline of the bike journey

2 different ways to show the timeline of the bike journey:

Change color GPX track per month (split GPX track in different parts per month)
-> explain difference in colors via legend or hover

Add months as text to the map

Hover function has been added
-Itinerary consists of different colors thanks to GeoJSON data

Hover function has been added
-Itinerary consists of different colors (GeoJSON data)


chore(deps): update ci dependencies

This PR contains the following updates:

Package
Type
Update
Change

common-dev-assets

digest
2e77009 -> d3a341c

github.com/IBM/go-sdk-core/v5
require
patch
v5.17.3 -> v5.17.4

github.com/gruntwork-io/terratest
require
minor
v0.46.15 -> v0.47.0

github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper
require
minor
v1.34.1 -> v1.35.4

go (source)
toolchain
patch
1.22.3 -> 1.22.5

terraform-ibm-modules/common-pipeline-assets
action
patch
v1.22.3 -> v1.22.4

Release Notes

IBM/go-sdk-core (github.com/IBM/go-sdk-core/v5)
v5.17.4
Compare Source
Bug Fixes

tidy Go modules (#221) (5da6409)

This also includes the change to bump go-retryablehttp from v0.7.5 to v0.7.7 to avoid a vulnerability.

gruntwork-io/terratest (github.com/gruntwork-io/terratest)
v0.47.0
Compare Source
Modules affected

packer
aws
helm
azure

Description

Added support for Packer 1.10
Fixed error checking in Azure
Fixed tests and documentation for helm, aws, packer modules

Related links

https://github.com/gruntwork-io/terratest/pull/1395
https://github.com/gruntwork-io/terratest/pull/1419

v0.46.16
Compare Source
Description

Updated github.com/hashicorp/go-getter from 1.7.4 to 1.7.5.

Related links

https://github.com/gruntwork-io/terratest/pull/1415

terraform-ibm-modules/ibmcloud-terratest-wrapper (github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper)
v1.35.4
Compare Source
Bug Fixes

bug with stack arrays (#843) (4e09e9c)

v1.35.3
Compare Source
Bug Fixes

do not destroy the project on failure so schematic workspace logs can remain for debug (#837) (72f3c8e)

v1.35.2
Compare Source
Bug Fixes

bug, fail test on any deploy error (#833) (79923b8)

v1.35.1
Compare Source
Bug Fixes

deps: update gomod (#816) (5918087)

v1.35.0
Compare Source
Features

add hook support (#817) (efe4d67)

terraform-ibm-modules/common-pipeline-assets (terraform-ibm-modules/common-pipeline-assets)
v1.22.4
Compare Source
Bug Fixes

added support for trailing spaces in pipeline run command (#699) (215fa1a), closes #701

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

/run pipeline

:tada: This issue has been resolved in version 1.7.7 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Fix c++11 error converting string literal to char *

Fixes compile error on Ubuntu 16.04 latest

Is it ok if i refactor your code a bit ? mainly the 'exec with arguments' stuff could be made a little bit easier

Yes please do! If you have an idea of a direction you want to take (variadic?) - let me know and I am happy to code it for you one the side as it is a VERY useful feature for us 👍

Feel free to take what you want from these - or you can ignore this and I can send you more meaningful PRs for the pieces that you think are relevant :)


[WIP] Attribute types css

Follow up to #344. And blocked by it.

Closing in favor of https://github.com/denoland/deno_core/pull/402.


im getting errors i dont understand, since alpha12

Godot version
4.0 alpha13
System information
linux
Issue description
dont really know whats happening but heres a screenshot

Steps to reproduce
see screenshot
Minimal reproduction project
No response

@djmaesen Please upload a minimal reproduction project to make this easier to troubleshoot.

@Calinou  here u go
test.zip
it seems to be happening with animated models only


Harmonize miss_forest and mice_forest imputation function names

Currently one has an underscore and the other does not.

I think in data_imputation.py, it is called miceforest_impute and miss_forest_impute.

Yeah. I was thinking that they should be called.
mice_forest_impute and miss_forest_impute
miceforest_impute and missforest_impute
Likely the former. Don't worry :)


chore: switch from yarn to npm

Fixes an issue that prevented lerna from being used on node 8.

Codecov Report

Merging #747 into master will increase coverage by 0.13%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #747      +/-   ##
==========================================
+ Coverage   96.22%   96.36%   +0.13%
==========================================
  Files         208      166      -42
  Lines        9488     6760    -2728
  Branches      809      546     -263
==========================================
- Hits         9130     6514    -2616
+ Misses        358      246     -112

Impacted Files
Coverage Δ

packages/opentelemetry-metrics/src/Meter.ts
97.01% <ø> (ø)
:arrow_up:

...elemetry-tracing/src/export/ConsoleSpanExporter.ts
85.71% <0%> (ø)
:arrow_up:

...es/opentelemetry-tracing/src/MultiSpanProcessor.ts
100% <0%> (ø)
:arrow_up:

...telemetry-tracing/src/export/BatchSpanProcessor.ts
100% <0%> (ø)
:arrow_up:

...ges/opentelemetry-tracing/src/NoopSpanProcessor.ts
66.66% <0%> (-8.34%)
:arrow_down:

...s/opentelemetry-tracing/src/BasicTracerProvider.ts
100% <0%> (ø)
:arrow_up:

packages/opentelemetry-metrics/src/export/types.ts
100% <0%> (ø)
:arrow_up:

packages/opentelemetry-plugin-mysql/src/utils.ts
90.9% <0%> (-4.55%)
:arrow_down:

packages/opentelemetry-metrics/src/types.ts
100% <0%> (ø)
:arrow_up:

packages/opentelemetry-metrics/src/LabelSet.ts
100% <0%> (ø)
:arrow_up:

... and 158 more

@open-telemetry/javascript-approvers I know this has had a lot of updates but I just squashed it all down into two commits. Please take a look and review.


Salesforce component should be able to receive new acess tokens when retrieving platform events

Steps to Reproduce (not sure if fully accurate):

Create a realtime flow to listen to salesforce platform events
Configure a valid credential.
Start the flow.
Execute another flow where the access token is refreshed.
Wait more than an hour for the access token in the platform event  to expire.
Observe that after the first hour, the flow will no longer receive platform events as the tokens are no longer valid.

@jhorbulyk additional question:
I'm not sure that I correctly understood the 4th step:
4. Execute another flow where the access token is refreshed.
Is it enough to create a copy of the same flow and run both of them to observe the issue?

Is it enough to create a copy of the same flow and run both of them to observe the issue?

Likely.  I haven't fully identified the steps needed to reproduce.

Apparently, a similar issue that we run into when doing the Exact Online. Maybe worth speak to platform guys if they have some progress there?
@drobiazko thoughts?

I feel as though a major contributing issue is lack of proper secrets service in the platform.  Is there any update on when we expect to be able to import the OIH version into our platform (or provide a similar microservice with similar features)?  Has such an issue been written up?

The issue is not reproducible with provided list of steps

Suprisingly, it works if you leave the event bus flow on.  The only problems appear if you turn off the flow that consumes things from the event bus.


Verification Statements do not support Printable

Type of issue: feature request
Impact: API addition (no impact on existing code)
Currently the Verification Statements (i.e. assert and assume) can take additional arguments that will result in a message being printed when the condition is violated. However, it only supports the "C"-style printing, i.e.: assert(a, "a=%d", a). In addition it would be nice if it also supported the Scala/Python style of printing like printf already does, i.e. assert(a, p"a=$a").

Agreed, it would also be nice to have Printable support format strings like the Scala f interpolator: https://docs.scala-lang.org/overviews/core/string-interpolation.html.
Maybe pf"a=0x$a%x" rather than the current (horrible) p"a=0x${Hexadecimal(a)}"


Performance enhancements

Just to give it a good back to back test, I just ran the current version of this app against the Terravision breach I've just loaded. This is a 379MB tab delimited text file with half a dozen fields and ~2M email addresses. Here are the results:

My crusty old tool: 1min 43sec
The current version in this repo: 9min

That's a massive perf hit. Just eyeballing the differences, I think it may come down to me using a StreamReader in the original implementation and the newer one using File.ReadLinesAsync.
To give everyone a good reference file without disclosing a whole heap of PII, I've used Red Gate's SQL Data Generator to create a test file with 10M rows: https://mega.nz/file/Ls8U1ADK#c1We1C_CZi44P0k3OB8YpNVN7HMM3gE_4-fH06E454c
I haven't benchmarked the old tool against this yet (I'll update this idea when I do), but there's definitely a massive improvement to be had.

Doing some testing on this, I created a 3.2G file of fake emails. Using File.ReadLinesAsync will consistently read about ~360,000 lines/s. Switching to a StreamReader will consistently read about ~400,000 lines/s, so it's a bit of an improvement.
Continuing to make some tweaks and investing further on what could possibly speed up the Regex Matches;
Taking out the Regex Match and just reading the file directly will do ~1,900,000 lines/s with the StreamReader, where it'll do ~1,560,000 lines/s with the File.ReadLinesAsync. So it definitely helps to use the StreamReader

File.ReadLinesAsync
StreamReader

Raw lines
~1,560,000/s
~1,900,000/s

Regexed lines
~360,000/s
~400,000/s

The Regex really kills the lines/second

Hmmm, interesting, there's obviously a lot more to it than that. Here's the original method I used:
    public List<string> GetEmailsFromString(string source, int maxEmailLength = 256)
    {
      var matches = _regex.Matches(source.Replace(@"\n", Environment.NewLine));
      return (from Match m in matches select m.Value.ToLower())
        .Where(e => e.Length <= maxEmailLength)
        .Distinct()
        .ToList();
    }

Damn, you've nailed it! Here's the output of the last run before this change:
Extraction time: 517,508ms
Addresses extracted: 2,075,606
Read lines total: 2,075,967
Read lines rate: 4,011/s

And after:
Extraction time: 27,273ms
Addresses extracted: 2,075,594
Read lines total: 2,075,955
Read lines rate: 76,106/s

This is against the Terravision data set, I'll do some more tests then hopefully close this out.

Thanks for the suggestion @GStefanowich. Agree with the performance hit issue you commented in #20
The other way I can think of to use regex \.\.|\*|\.@|^\.|@- to eliminate the matches. For rest of the cases we can manage it via specific code itself.

Regex
Description

\.\.
Email having consecutive dot

\*
Email having *

.@
Email having .@

@-
Email having @-

Demo: https://regex101.com/r/MK80iM/1
This also can lead to performance improvement.

Apologies for not turning this into a full pull-request (I rarely use Git, and then found that my latest-commit contained too many changes (formatting-edits, local "experiments")
The primary EmailRegex is a big speed-culprit (using backtrack) - I have modified this:
1 - By doing a "quick test" first, then the full "regex"
2 - By swapping the order of the "Filter out edge case addresses" (quick tests first, then the InvalidRegex afterwards)
If anyone wants to merge in my changes ( https://github.com/HaveIBeenPwned/EmailAddressExtractor/commit/2c18c12491a143a672fcf1ac66bff265e38434b9#diff-86dd578eb0b2b43365b4c838e1a97fa71229c9c1ab5753c5f1644bf874cb3b62 ) you should get a solid 10x performance boost


Fix/todos

:tada: This PR is included in version 0.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Album art - low resolution

Describe the bug
When the widget width is set to 630, the album art is displayed with very low resolution.
To Reproduce
Steps to reproduce the behavior:

Set widget width to e.g. 630.
Open the popup widget.

Expected behavior
Display high quality image.
Screenshots

Environment:

Distro: Ubuntu 24.04
GNOME version 46
Extension Version 2.0.2

What media do you play ?
Is this an mp3 where the album art is included ?
How can the extension show low res album art in high res ?

Chrome (Youtube music) - HQ album art is there included.

Chrome (Youtube music) - HQ album art is there included.

I only have spotify. No youtube music account to check. Spotify works like a charm

Firefox - everything works fine. Chrome - both youtube music & spotify - low resolution.

Firefox - everything works fine. Chrome - both youtube music & spotify - low resolution.

So file a bug at chrome.


"NullReferenceException" in RestrictionProcessor.SecondPass

I am trying to LoadOsmData file europe-latest.osm.pbf (18GB) downloaded from here
http://download.geofabrik.de/europe.html
I get an exception. Stacktrace below:
And my extra question:
I use nuget to reference Itinero (current version is <IP_ADDRESS>). But I do not understand which platform version of referenced library (x63 or AnyCPU)? As far as I am concerned from reading issues it is important for big data files.
Stack trace:
System.NullReferenceException: Object reference not set to an instance of an object.
at Itinero.IO.Osm.Restrictions.RestrictionProcessor.SecondPass(Way way)
at Itinero.IO.Osm.Streams.RouterDbStreamTarget.AddWay(Way way)
at OsmSharp.Streams.OsmStreamTarget.DoPull(Boolean ignoreNodes, Boolean ignoreWays, Boolean ignoreRelations)
at Itinero.IO.Osm.Streams.RouterDbStreamTarget.OnBeforePull()
at OsmSharp.Streams.OsmStreamTarget.Pull()
at Itinero.IO.Osm.RouterDbExtensions.LoadOsmData(RouterDb db, IEnumerable1 source, Boolean allCore, Boolean processRestrictions, IEnumerable1 processors, Vehicle[] vehicles)
at Itinero.IO.Osm.RouterDbExtensions.LoadOsmData(RouterDb db, Stream data, Boolean allCore, Vehicle[] vehicles)

Sorry about that, I've been aware of this issue for a few days now. This is because Itinero is trying to process the file in > 2 passes.
I'm working right now on a fix, reducing memory usage during the process and speeding up the process so this can be done in just two passes. If you disable the restrictions processor things should work for now but obviously without turn restrictions.
Expect a fix somewhere in the next two days...

I fixed the problem but I have a few failing unitesttests so I need to first investigate why they are failing. Will be something for the first week of 2017, sorry!


[Deprecation Warning] -  tf.contrib.layers.xavier_initializer

Hello dear friends,
If you run the following code, you will have a deprecation warning in version 1.7.0
import tensorflow as tf
print("TF Version:", tf.__version__)
a = tf.contrib.layers.xavier_initializer()

TF Version: 1.7.0
WARNING:tensorflow:From /usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/datasets/base.py:198: retry (from tensorflow.contrib.learn.python.learn.datasets.base) is deprecated and will be removed in a future version.
Instructions for updating: Use the retry module or similar alternatives.

For information, this warning did not appear in version 1.6.0, it appears from 1.7.0.
Have a good day,
Jonathan

Can replicate the problem, with an even simpler command:
from tensorflow.contrib.layers import xavier_initializer

Seems like the problem is with the __init__.py in that folder.

Replaced deprecation warning with raising an error, here's the traceback:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/__init__.py", line 35, in <module>
    from tensorflow.contrib import distributions
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/distributions/__init__.py", line 38, in <module>
    from tensorflow.contrib.distributions.python.ops.estimator import *
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/distributions/python/ops/estimator.py", line 21, in <module>
    from tensorflow.contrib.learn.python.learn.estimators.head import _compute_weighted_loss
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/__init__.py", line 95, in <module>
    from tensorflow.contrib.learn.python.learn import *
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/__init__.py", line 28, in <module>
    from tensorflow.contrib.learn.python.learn import *
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/__init__.py", line 29, in <module>
    from tensorflow.contrib.learn.python.learn import datasets
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/datasets/__init__.py", line 31, in <module>
    from tensorflow.contrib.learn.python.learn.datasets import base
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/datasets/base.py", line 198, in <module>
    @retry(initial_delay=1.0, max_delay=16.0, is_retriable=_is_retriable)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/util/deprecation.py", line 243, in new_func
    raise ValueError("dep")
ValueError: dep

Seems to be fixed in master lol. https://github.com/tensorflow/tensorflow/commit/fdec18588d7f8b5f6383601f1030ed71f634d1c0
Recommend close.

@cchan just tested with 1.8.0rc0 you are absolutely right.
Closing this issue


SPI 0 is not working in esp32

Hi
i tried to work with all spi in esp32, I wrote a code to initialize spi and send one data , it is working with both HSPI and VSPI in esp32, but same i tried in normal SPI (Pins 6,7,8,9,10,11), but it is not working. Could you please help to fix this issue
I am attaching my code here in Arduino. please find the attachment.
spi_test.tar.gz

Howdy, if we look at the Overview text found here .. .http://esp-idf.readthedocs.io/en/latest/api/peripherals/spi_master.html
We find that there are four SPIs known as SPI0, SPI1, HSPI and VSPI.  In the overview there is a restriction that states that only HSPI and VSPI may be used for application purposes.

Hi @amallal ,
Sorry it took so long for someone for the IDF team to get back to you here.

The normal SPI pins (SPI0, the pins you mentioned) are used for connection to the internal SPI flash where the program code is located (and mapped via flash cache). It is possible to use this SPI bus to connect to other devices, but it's complex (as code also runs from there) and is not supported in either Arduino or IDF.
For issues with Arduino, in future please open tickets against the Arduino project here: https://github.com/espressif/arduino-esp32/issues/

For now, @nkolban's advice to use HSPI/VSPI only (with multiple CS lines on the same SPI bus if you need to connect multiple devices) is the best advice to follow.
Thanks,
Angus

I have a portion of my project working, I can display graphics on an East Rising 5" SPI Display using VSPI.  When I attempt to connect my DS3234 to the same basic pins EXCEPT a different SS, I'm having interference.  Should I be running both instances of the SPI without attaching the SS pin and then just banging it on and off when needed?  Should I be creating different instances with attach/detach commands?


Environment variables such as PATH only for a workspace, in settings.json

Is there a way to have a workspace specific path, added to settings.json for common executables. Were working on an extension where go is installed in the extension location, it would be nice to have env var support only for the workspace

I see there is terminal.integrated.env does that do what I need it to do

See the EnvironmentVariableCollection API.


clearvoid causing rendering client crash 1.19.2

https://paste.atlauncher.com/view/f9a7fe9a-d181-403e-b808-b50067a3e278
it was fixed the moment i removed the mod

I also found earilier that the way of patching of breaking because the gl fragment for the dark sky is removed. The game crashed when I tried to turn on shaders.
I'll try to fix this soon.

I tried another way to remove the black void and released version 1.3.0. Please try it, and close the issue if the problem is solved.

Seems to work now, thanks for fixing it! I'll let you know if anything comes up.


'MainWindow' is a type, which is not valid in the given context

After i installed WinUIEx and tried to apply it i got this error: 'MainWindow' is a type, which is not valid in the given context. How to fix that?

It seems that this problem is related to WinUIEX
And you have to report in the relevant repository


Deployed create-guest task does not use CMSFS if we're configured for it

The create-guest.yml file put down by the setup-ocp-deployer playbook is still set up for using FTP/curl to send the ZNETBOOT configuration to zVM.  This is supposed to be using CMSFS instead (z/VM FTP server is not started by default for security).

ZNETBOOT files are created by the configure-apace-ignition role when the Bastion is built.  They are in the "bootfiles" directory (/var/www/html/bootfiles in the standard build).
Changing the mount mode of the CMS disk is a bit complex, so the original plan of doing it in the create-guest task is not appealing.  Since the files are created upfront, let's copy all the ZNETBOOT files to CMS n one go at the start of the process.

I believe this is resolved now -- CMSFS and the Ansible copy module do not play well with each other so I've had to use a raw shell command to copy the files.  But it works.


allow custom e-mail server port for notify

Allows to set a custom mail server port via notifyMailPort setting in raspiblitz.conf.

please rebase the PR on the dev branch

OK merging into a v1.7merge branch to then cherry-pick over to dev branch.


Use pattern hints from converters when matching fields

At the time of writing, the CompiledRouter is first matching fields, and then subsequently using converters to validate/adapt them to parameters that are sent to a responder.
However, information such as allowed characters, desired length of a field etc is completely ignored when building routing code and/or regexps. In complex URI patterns with multiple fields in a single path segment, the user may expect these are correctly split, if, for instance, the first field was specified to be a 6-digit integer.
Consider the following example (adapted from the bug report/question Gist https://gist.github.com/comet0/2dd6fc0d08b4468db66b6e5f85af0c2b by @comet0 on Gitter):
import falcon
import falcon.testing
import pytest

class DebugResource():
    def on_get(self, req, resp, **kwargs):
        resp.body = str(kwargs)
        resp.content_type = falcon.MEDIA_TEXT

@pytest.fixture
def client():
    api = falcon.API()
    api.add_route('/{yymmdd:int(6)}-{item_id:uuid}', DebugResource())
    return falcon.testing.TestClient(api)

def test_routing(client):
    resp = client.simulate_get('/190101-59559ee7-e661-43c8-9da1-0ab83b9e0d8e')
    assert resp.status_code == 200

Running pytest fails with assert 404 == 200, whereas the user expectation was that yymmdd was assigned with 190101, and the UUID parameter with the remainder.
However, changing the first hyphen to a different character (let's say, /{yymmdd:int(6)}:{item_id:uuid}', DebugResource()) now allows even the current router to cope with the pattern:
collected 1 item

test.py {'yymmdd': 190101, 'item_id': UUID('59559ee7-e661-43c8-9da1-0ab83b9e0d8e')}

I also added the documentation label -- even if we don't properly fix this in the foreseeable future, documentation should clearer reflect the current limitations.

The also fails /r/{foo:int}-{bar} to match /r/42-foo-bar
The issue is that the regexp created is r'^(?P<foo>.+)-(?P<bar>.+)$' and matches {'foo': '42-foo', 'bar':'bar'} instead of the correct {'foo': '42', bar: 'foo-bar'}
It may make sense to use instead r'^(?P<foo>.+?)-(?P<bar>.+?)$' this regexp, (it would potentially be breaking change, that we may make pass as a bugfix)

IMHO changing to non-greedy matching would not improve anything, it's just a mirror problem.
If your pattern was /path/{foo}-{bar:int}. Using the current version, a path like /path/foo-bar-42 would work correctly (foo-bar and 42 would be matched). Conversely, matching in a non-greedy fashion would introduce a regression.

Indeed, still if we implement this it may be an option to switch che default to nonl-greedy match


Plugin is not reading .solhint.json if the contract is not in the same directory

I have the following directory structure:
$ tree
.
├── contracts
│   └── Contract.sol
└── .solhint.json

The plugin does not read the .solhint.json file. If I move the file to the contracts directory it works as expected.

Got the same problem. Intellij IDEA 2018.2.3, Mac Os 10.13.6


Admin role.?

Bro, how to access admin role. Unable to understand to access it, even i seen ur previous issues about it. After signin i seen i had login like user but not admin.. If i check in mongodb, it shows role as 0

I'm also facing the same, not able to access the admin role