Fix build warning

[  1%] Generating ivi-application-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[  2%] Generating ivi-application-client-protocol.h
[  3%] Building C object protocol/CMakeFiles/ivi-application.dir/ivi-application-protocol.c.o
[  4%] Linking C shared library libivi-application.so
[  4%] Built target ivi-application
[  5%] Generating ivi-wm-server-protocol.h
[  6%] Generating ivi-wm-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[  7%] Building C object weston-ivi-shell/CMakeFiles/ivi-controller.dir/src/ivi-controller.c.o
[  8%] Building C object weston-ivi-shell/CMakeFiles/ivi-controller.dir/ivi-wm-protocol.c.o
[  9%] Linking C shared module ivi-controller.so
[  9%] Built target ivi-controller
[ 10%] Generating ivi-wm-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[ 11%] Generating ivi-input-client-protocol.h
[ 12%] Generating ivi-input-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[ 13%] Generating ivi-wm-client-protocol.h
[ 14%] Building C object ivi-layermanagement-api/ilmControl/CMakeFiles/ilmControl.dir/src/ilm_control_wayland_platform.c.o
[ 15%] Building C object ivi-layermanagement-api/ilmControl/CMakeFiles/ilmControl.dir/src/bitmap.c.o
[ 16%] Building C object ivi-layermanagement-api/ilmControl/CMakeFiles/ilmControl.dir/src/writepng.c.o
[ 17%] Building C object ivi-layermanagement-api/ilmControl/CMakeFiles/ilmControl.dir/ivi-wm-protocol.c.o
[ 18%] Building C object ivi-layermanagement-api/ilmControl/CMakeFiles/ilmControl.dir/ivi-input-protocol.c.o
[ 19%] Linking C shared library libilmControl.so
[ 19%] Built target ilmControl
[ 20%] Building C object ivi-layermanagement-api/ilmCommon/CMakeFiles/ilmCommon.dir/src/ilm_common.c.o
[ 20%] Building C object ivi-layermanagement-api/ilmCommon/CMakeFiles/ilmCommon.dir/src/ilm_common_wayland_platform.c.o
[ 21%] Linking C shared library libilmCommon.so
[ 21%] Built target ilmCommon
[ 22%] Generating ivi-application-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[ 23%] Generating ivi-application-client-protocol.h
[ 24%] Building C object ivi-layermanagement-api/ilmClient/CMakeFiles/ilmClient.dir/src/ilm_client.c.o
[ 25%] Building C object ivi-layermanagement-api/ilmClient/CMakeFiles/ilmClient.dir/src/ilm_client_wayland_platform.c.o
[ 26%] Building C object ivi-layermanagement-api/ilmClient/CMakeFiles/ilmClient.dir/ivi-application-protocol.c.o
[ 27%] Linking C shared library libilmClient.so
[ 27%] Built target ilmClient
[ 28%] Generating ivi-input-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[ 29%] Generating ivi-input-client-protocol.h
[ 30%] Building C object ivi-layermanagement-api/ilmInput/CMakeFiles/ilmInput.dir/src/ilm_input.c.o
[ 31%] Building C object ivi-layermanagement-api/ilmInput/CMakeFiles/ilmInput.dir/ivi-input-protocol.c.o
[ 32%] Linking C shared library libilmInput.so
[ 32%] Built target ilmInput
[ 34%] Building CXX object ivi-layermanagement-examples/LayerManagerControl/CMakeFiles/LayerManagerControl.dir/src/main.cpp.o
[ 35%] Building CXX object ivi-layermanagement-examples/LayerManagerControl/CMakeFiles/LayerManagerControl.dir/src/commands.cpp.o
[ 36%] Building CXX object ivi-layermanagement-examples/LayerManagerControl/CMakeFiles/LayerManagerControl.dir/src/input_commands.cpp.o
[ 37%] Building CXX object ivi-layermanagement-examples/LayerManagerControl/CMakeFiles/LayerManagerControl.dir/src/analyze.cpp.o
[ 38%] Building CXX object ivi-layermanagement-examples/LayerManagerControl/CMakeFiles/LayerManagerControl.dir/src/common.cpp.o
[ 39%] Building CXX object ivi-layermanagement-examples/LayerManagerControl/CMakeFiles/LayerManagerControl.dir/src/control.cpp.o
[ 40%] Building CXX object ivi-layermanagement-examples/LayerManagerControl/CMakeFiles/LayerManagerControl.dir/src/Expression.cpp.o
[ 41%] Building CXX object ivi-layermanagement-examples/LayerManagerControl/CMakeFiles/LayerManagerControl.dir/src/ExpressionInterpreter.cpp.o
[ 42%] Building CXX object ivi-layermanagement-examples/LayerManagerControl/CMakeFiles/LayerManagerControl.dir/src/print.cpp.o
[ 43%] Building CXX object ivi-layermanagement-examples/LayerManagerControl/CMakeFiles/LayerManagerControl.dir/src/sceneio.cpp.o
[ 44%] Building CXX object ivi-layermanagement-examples/LayerManagerControl/CMakeFiles/LayerManagerControl.dir/src/util.cpp.o
[ 45%] Linking CXX executable LayerManagerControl
[ 45%] Built target LayerManagerControl
[ 46%] Generating ivi-application-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[ 47%] Generating ivi-application-client-protocol.h
[ 48%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/Camera.cpp.o
[ 49%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/Car.cpp.o
[ 50%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/Argument.cpp.o
[ 51%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/OpenGLES2App.cpp.o
[ 52%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/Ground.cpp.o
[ 53%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/House.cpp.o
[ 54%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/MockNavi.cpp.o
[ 55%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/Street.cpp.o
[ 56%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/ShaderBase.cpp.o
[ 57%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/ShaderLighting.cpp.o
[ 58%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/main.cpp.o
[ 59%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/TextureLoader.cpp.o
[ 60%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/ShaderTexture.cpp.o
[ 61%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/Sky.cpp.o
[ 62%] Building CXX object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/src/ShaderGradient.cpp.o
[ 63%] Building C object ivi-layermanagement-examples/EGLWLMockNavigation/CMakeFiles/EGLWLMockNavigation.dir/ivi-application-protocol.c.o
[ 64%] Linking CXX executable EGLWLMockNavigation
[ 64%] Built target EGLWLMockNavigation
[ 64%] Generating ivi-application-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[ 65%] Generating ivi-application-client-protocol.h
[ 67%] Building CXX object ivi-layermanagement-examples/EGLWLInputEventExample/CMakeFiles/EGLWLInputEventExample.dir/src/main.cpp.o
[ 68%] Building CXX object ivi-layermanagement-examples/EGLWLInputEventExample/CMakeFiles/EGLWLInputEventExample.dir/src/WLContext.cpp.o
[ 69%] Building CXX object ivi-layermanagement-examples/EGLWLInputEventExample/CMakeFiles/EGLWLInputEventExample.dir/src/WLEGLSurface.cpp.o
[ 70%] Building CXX object ivi-layermanagement-examples/EGLWLInputEventExample/CMakeFiles/EGLWLInputEventExample.dir/src/WLEyes.cpp.o
[ 71%] Building CXX object ivi-layermanagement-examples/EGLWLInputEventExample/CMakeFiles/EGLWLInputEventExample.dir/src/WLEyesRenderer.cpp.o
[ 72%] Building CXX object ivi-layermanagement-examples/EGLWLInputEventExample/CMakeFiles/EGLWLInputEventExample.dir/src/WLSurface.cpp.o
[ 73%] Building C object ivi-layermanagement-examples/EGLWLInputEventExample/CMakeFiles/EGLWLInputEventExample.dir/ivi-application-protocol.c.o
[ 74%] Linking CXX executable EGLWLInputEventExample
[ 74%] Built target EGLWLInputEventExample
[ 75%] Building C object ivi-layermanagement-examples/layer-add-surfaces/CMakeFiles/layer-add-surfaces.dir/src/layer-add-surfaces.c.o
[ 76%] Linking C executable layer-add-surfaces
[ 76%] Built target layer-add-surfaces
[ 77%] Generating ivi-application-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[ 78%] Generating ivi-application-client-protocol.h
[ 79%] Building C object ivi-layermanagement-examples/multi-touch-viewer/CMakeFiles/multi-touch-viewer.dir/src/multi-touch-viewer.c.o
[ 80%] Building C object ivi-layermanagement-examples/multi-touch-viewer/CMakeFiles/multi-touch-viewer.dir/src/util.c.o
[ 81%] Building C object ivi-layermanagement-examples/multi-touch-viewer/CMakeFiles/multi-touch-viewer.dir/src/window.c.o
[ 82%] Building C object ivi-layermanagement-examples/multi-touch-viewer/CMakeFiles/multi-touch-viewer.dir/ivi-application-protocol.c.o
[ 83%] Linking C executable multi-touch-viewer
[ 83%] Built target multi-touch-viewer
[ 84%] Generating weston-debug-server-protocol.h
[ 85%] Generating ivi-application-client-protocol.h
[ 86%] Generating ivi-application-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[ 87%] Generating weston-debug-client-protocol.h
[ 88%] Generating weston-debug-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[ 89%] Building C object ivi-layermanagement-examples/simple-weston-client/CMakeFiles/simple-weston-client.dir/src/simple-weston-client.c.o
[ 90%] Building C object ivi-layermanagement-examples/simple-weston-client/CMakeFiles/simple-weston-client.dir/ivi-application-protocol.c.o
[ 91%] Building C object ivi-layermanagement-examples/simple-weston-client/CMakeFiles/simple-weston-client.dir/weston-debug-protocol.c.o
[ 92%] Linking C executable simple-weston-client
[ 92%] Built target simple-weston-client
[ 93%] Generating ivi-input-server-protocol.h
[ 94%] Generating ivi-input-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
[ 95%] Building C object ivi-input-modules/ivi-input-controller/CMakeFiles/ivi-input-controller.dir/src/ivi-input-controller.c.o
[ 96%] Building C object ivi-input-modules/ivi-input-controller/CMakeFiles/ivi-input-controller.dir/ivi-input-protocol.c.o
[ 97%] Linking C shared module ivi-input-controller.so
[ 97%] Built target ivi-input-controller
[ 98%] Building C object ivi-id-agent-modules/ivi-id-agent/CMakeFiles/ivi-id-agent.dir/src/ivi-id-agent.c.o
[100%] Linking C shared module ivi-id-agent.so
[100%] Built target ivi-id-agent
Install the project...
-- Install configuration: ""
-- Installing: /home/chien/share/install/lib/libivi-application.so.2.3.0
-- Up-to-date: /home/chien/share/install/lib/libivi-application.so
-- Installing: /home/chien/share/install/include/ilm/ivi-application-client-protocol.h
-- Up-to-date: /home/chien/share/install/share/wayland-protocols/stable/ivi-application/ivi-application.xml
-- Up-to-date: /home/chien/share/install/lib/pkgconfig/ivi-application.pc
-- Installing: /home/chien/share/install/lib/x86_64-linux-gnu/weston/ivi-controller.so
-- Installing: /home/chien/share/install/lib/libilmCommon.so.2.3.0
-- Set runtime path of "/home/chien/share/install/lib/libilmCommon.so.2.3.0" to ""
-- Up-to-date: /home/chien/share/install/lib/libilmCommon.so
-- Up-to-date: /home/chien/share/install/include/ilm/ilm_common.h
-- Up-to-date: /home/chien/share/install/include/ilm/ilm_types.h
-- Up-to-date: /home/chien/share/install/include/ilm/ilm_platform.h
-- Up-to-date: /home/chien/share/install/lib/pkgconfig/ilmCommon.pc
-- Installing: /home/chien/share/install/lib/libilmClient.so.2.3.0
-- Up-to-date: /home/chien/share/install/lib/libilmClient.so
-- Up-to-date: /home/chien/share/install/include/ilm/ilm_client.h
-- Installing: /home/chien/share/install/lib/libilmControl.so.2.3.0
-- Up-to-date: /home/chien/share/install/lib/libilmControl.so
-- Up-to-date: /home/chien/share/install/include/ilm/ilm_control.h
-- Up-to-date: /home/chien/share/install/lib/pkgconfig/ilmControl.pc
-- Installing: /home/chien/share/install/bin/LayerManagerControl
-- Set runtime path of "/home/chien/share/install/bin/LayerManagerControl" to ""
-- Installing: /home/chien/share/install/bin/EGLWLMockNavigation
-- Up-to-date: /home/chien/share/install/share/wayland-ivi-extension/textures
-- Up-to-date: /home/chien/share/install/share/wayland-ivi-extension/textures/car.bmp
-- Up-to-date: /home/chien/share/install/share/wayland-ivi-extension/textures/base.bmp
-- Up-to-date: /home/chien/share/install/share/wayland-ivi-extension/textures/street.bmp
-- Up-to-date: /home/chien/share/install/share/wayland-ivi-extension/textures/sources.txt
-- Up-to-date: /home/chien/share/install/share/wayland-ivi-extension/textures/skyscrapers
-- Up-to-date: /home/chien/share/install/share/wayland-ivi-extension/textures/skyscrapers/facade01.bmp
-- Up-to-date: /home/chien/share/install/share/wayland-ivi-extension/textures/skyscrapers/facade00.bmp
-- Up-to-date: /home/chien/share/install/share/wayland-ivi-extension/textures/skyscrapers/facade03.bmp
-- Up-to-date: /home/chien/share/install/share/wayland-ivi-extension/textures/skyscrapers/facade02.bmp
-- Installing: /home/chien/share/install/bin/EGLWLInputEventExample
-- Installing: /home/chien/share/install/bin/layer-add-surfaces
-- Set runtime path of "/home/chien/share/install/bin/layer-add-surfaces" to ""
-- Installing: /home/chien/share/install/bin/multi-touch-viewer
-- Installing: /home/chien/share/install/bin/simple-weston-client
-- Installing: /home/chien/share/install/lib/libilmInput.so.2.3.0
-- Set runtime path of "/home/chien/share/install/lib/libilmInput.so.2.3.0" to ""
-- Up-to-date: /home/chien/share/install/lib/libilmInput.so
-- Up-to-date: /home/chien/share/install/include/ilm/ilm_input.h
-- Up-to-date: /home/chien/share/install/lib/pkgconfig/ilmInput.pc
-- Installing: /home/chien/share/install/lib/x86_64-linux-gnu/weston/ivi-input-controller.so
-- Installing: /home/chien/share/install/lib/x86_64-linux-gnu/weston/ivi-id-agent.so
-- Set runtime path of "/home/chien/share/install/lib/x86_64-linux-gnu/weston/ivi-id-agent.so" to ""

@chienpv1 ,
Another way to solve this problem is to not to declare and initialize at the same time i.e. declare the the listener variable and then in a function set it to 0 (e.g. using memset) and then assign callback function pointers one by one. This will avoid any warnings when protocol version is upgraded in future.

@chienpv1 ,
Another way to solve this problem is to not to declare and initialize at the same time i.e. declare the the listener variable and then in a function set it to 0 (e.g. using memset) and then assign callback function pointers one by one. This will avoid any warnings when protocol version is upgraded in future.

Hello. we also can avoid these warning when I try to initialize more explicit, it is more simple. I also changed another initialized listener of wayland protocol in library with this way. with examples or tests, I see that we initialized as NULL for unsupported events in several places (link_example), so I did the same. If you think we should also avoid assign NULL value for function pointers in tests and examples, I will update them in another commit.

Hello @efriedrich @HarshaMM . we also can avoid these warning when I try to initialize more explicit, it is more simple. I also changed another initialized listener of wayland protocol in library with this way. with examples or tests, I see that we initialized as NULL for unsupported events in several places (link_example), so I did the same. If you think we should also avoid assign NULL value for function pointers in tests and examples, I will update them in another commit.

I vote to change the current initialization of tests and demos to new explicit initialization.

Reviewed-by: Khang Tran<EMAIL_ADDRESS>


Add permutationsT and combinationsT operators to ReactiveSeq

These should return StreamT monad transformers

Released in 2.0.0-MI3


Upgrade packages to remove dependency on the vulnerable package minimist 0.0.8

This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/242
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/241
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/240
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/239
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/238
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/237
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/236
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/235
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/234
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/233
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/232
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/231
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/230
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/229
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/228
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/227
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/226
This PR fixes #https://github.com/microsoft/azuredatastudio/security/dependabot/224
test build:
https://mssqltools.visualstudio.com/CrossPlatBuildScripts/_build/results?buildId=154941&view=ms.vss-test-web.build-test-results-tab

Comparing to the latest insider build:
https://mssqltools.visualstudio.com/CrossPlatBuildScripts/_build/results?buildId=154891&view=ms.vss-test-web.build-test-results-tab

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.008%) to 42.07%

Files with Coverage Reduction
New Missed Lines
%

extensions/notebook/src/book/bookTreeView.ts
2
38.21%

Totals

Change from base Build<PHONE_NUMBER>:
0.008%

Covered Lines:
28004

Relevant Lines:
62270

💛  - Coveralls


In react view, when a set of filters result in "No results found." in the left pane, the center pane loads the first every application received and the right pane has endless loading gifs

The ideal behaviour would be to load/show No results found. across all panes.

@danblah Could you share the screenshot of the error?


jaeger query es failed

related issues: https://github.com/jaegertracing/jaeger/issues/2976

Resolved by shutdown all jaeger collectors, delete the bad indexes, then restart the collectors.
So old trace data will lost.


Build seems to require FPU

Reading the README, it seems as if the build in bin/ should work without an FPU, however on my 386SX without FPU I get this error:

Did I misread the README and FPU emulation is in fact off in the default kernel?

Hi. Thank you very much for reporting.
You are correct. It's a bug in the configuration. I currently have a 386 with an additional math coprocessor, so this must have slipped through the cracks.

Hello.
Would you please take a look at:
https://github.com/marmolak/gray386linux/commit/e2a83073f3e9bc123fcd6ab25ff731d944e32629
?
I just enabled FPU emulation and as a bonus, some DMA :).

Hi. Great to hear that booting works.
BTW: what exact model of machine do you have? I'm not familiar with Yggdrasil devices :/. I was only able to find Yggdrasil copyright in some usb drivers in linux kernel.

I meant Yggdrasil as the old CD-ROM Linux. They made a BIOS-routine driver for at least storage devices. There is a good explanation here: https://retrocomputing.stackexchange.com/a/16435
The exact device I'm using is a Pocket386, basically a modern Vortex86 386SX-class processor built into a subnotebook/netbook form factor.

Thank you. I have something to study.
Would we open new feature request to add support for Pocket386 HW?
Would be nice to support this device.
I see there's even a USB controller present, and I'm wondering if the keyboard is not internally connected as a USB HID device.

The USB port is connected to a CH375, not a classical USB controller (and it is only that one port).
What I suspect they actually did is connect the keyboard internally via I2C or SPI or some other low-level protocol.
And then just wrote BIOS routines to access the data in whatever way.
Which makes sense, the keyboard has a mouse emulation mode, which can be configured via the screen's OSD, so clearly the BIOS must be quite involved in making things happen on this device.

Hello. I opened new bug so we can move investigation to better place.
Closing this as finished.


Error message appearing in operator log: Failed to watch *v1.PackageManifest

Bug Report

What did you do?
A clear and concise description of the steps you took (or insert a code snippet).

Incorporated OLM support into the syndesis operator.
Executing the syndesis operator on openshift, successfully queries for CSVs, subscriptions & if necessary installs the desired jaeger subscription. This all works.
In the syndesis operator log, the following error message is generated repeatedly:

E0519 20:18:59.338786       1 reflector.go:382] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to watch *v1.PackageManifest: unknown (get packagemanifests.packages.operators.coreos.com)

This does not impact the functionality in any way so is just noise in the logs but obviously something is not totally happy.

What did you expect to see?
No errors
What did you see instead? Under which circumstances?
The error being generated seems to bear little relation to the code actually being called. Is it perhaps due to the inclusion of the operator-lifecycle-manager packages?
Environment

operator-lifecycle-manager version:

k8s.io/client-go v0.17.4
github.com/operator-framework/operator-lifecycle-manager v0.0.0-20200321030439-57b580e57e88
github.com/operator-framework/operator-marketplace v0.0.0-20200424213926-c53c1e365d90
github.com/operator-framework/operator-sdk v0.17.0

Also, upgraded to following here & still get the same error messages:

k8s.io/client-go v0.18.2
github.com/operator-framework/operator-lifecycle-manager v0.0.0-20200508205316-9ffa1fdb8dcf
github.com/operator-framework/operator-marketplace v0.0.0-20200515051804-e0148822df25
github.com/operator-framework/operator-sdk v0.0.0-20200428193249-b34ae44ff198

Kubernetes version information:

Client Version: 4.3.13
Kubernetes Version: v1.16.2

Kubernetes cluster kind:

crc version: 1.9.0+a68b5e0
OpenShift version: 4.3.10

Possible Solution

Additional context
Add any other context about the problem here.
Please feel free to ask for far more information, if required.

Hi @phantomjinx,
PackageManifests are supplied by an aggregated API that doesn't support watch. The error you're encountering seems to be from an informer trying to list/watch this resource. The message also indicates that this is occurring in controller-runtime -- my guess is that it happens on Get with the dynamic client to maintain the cache (see the go-docs).
We can revisit watch on PackageManifest resources to clear the message, but for now you can probably construct a client that doesn't use the cache.
Hope that helps some. Please let me know if you run into any roadblocks and I'll try to help further.

The issue is stale. Closed. Please feel free to reopen if needed.


APIBroker Service stops unexpectedly

After a few requests are successful, APIBroker stops execution occasionally. Checked using netstat with port.

This issue has been experience with the RecoEngine as well. Not sure of its cause

@BBaggines @tylerthedeveloper @chetan253 @maheshbelnekar Please note that this is one of the major issues we are facing currently. We are actively working on fixing the same.
Due to the APIBroker service shutting down unexpectedly (not sure when or why), some features will break in the current build.

Not sure if i am facing this issue but it seems to bet currently down, please let me know if this is true

@tylerthedeveloper Checking the same.

@tylerthedeveloper Yep. It seems to be out again. netstat tells me that the service is listening on that port but for some reason, requests are timing out.
I am running Jenkins Job_ZK_Clean now to do a fresh build. Please wait for a while (~2mins) for the jobs to finish executing. This might solve it

This problem has been resolved. Closing the issue.


chore(sfc-playground): add item key of versions list

I see https://vuejs.org/style-guide/rules-essential.html#use-keyed-v-for ,
So, maybe can add a key to the version list item?

key is not really important here because the list order never changes.


Add life-cycle events for GVRSceneObject and GVRScene

Create ILifeCycle events which define interface for life-cycle events
common to all event-receiving classes (GVRScript, GVRScene, GVRSceneObject, etc.)
Add onStep handler for GVRScene to recursively deliver the event to scene objects.
Clean up GVRSceneObject constructors: use a general constructor to handle all specific
constructors, and only call super from one constructor. This ensures there is only one
exit-point of all constructors, and any common code can be easily added.
Allow GVRSceneObject to be scriptable and receive ISceneObjectEvents via GVREventReceiver.

Can be tested with https://github.com/gearvrf/GearVRf-Demos/pull/52

I believe we should not expand the public APIs unless absolutely necessary and we do mean it. Are these interfaces required to be implemented by the class itself? Is there no other option?
From a developer's perspective it will be inevitably confusing when they start seeing methods like getEventReceiver, onInit, etc being available on their objects. I doubt these are supposed to be called by end-users but the methods will be there, expanding the public API.
Is GVREventReceiver an implementation detail or entity that end-users can/should use for something?
Code looks pretty good otherwise but please try to hide the methods from the public API space.

This is a big topic to discuss. The design considers many factors including extensibility, efficiency, reduction of boilerplate code, and also possible use and misuse of public classes and methods by developers. It is hard to go over all of them here. I can say I agree that public API should not be abused or confusing by developers.
Can you please specify an alternative implementation for discussion?

For API abusing issue, let me propose another way of thinking.

Java language's "public" keyword is not designed to distinguish a framework's API and internal methods. So it's essentially impossible to make sure every public API is "public", and every internal class/method is non-"public". Consider a simple framework with two layers stored in package A and B. B is not designed to be accessible to developers but is accessible by package A. Should you declares the classes/methods in B as "public" or not "public"? If "public", would it be understood as public API? If not "public", how is it accessible by package A?

In multithreading environments, some public methods are protected by callers' thread ID / process ID and user privileges. They only govern interface level. If one abuses (or just re-use) some internal interface that is meant for system, it is not harmful, if they only use it for their apps, instead of gaining access into system resources.

Difference of misuse and abuse. Users might occasionally find a creative way to access a method to do something not recommended by framework designers. Sometimes, it is valid but we are not aware of them. Sometimes, it is not so reliable as using the recommended API. Developers do not always know what is the case. If the exposed API could be misused, it should be better documented (I doubt a library without documentation can guarantee all functionalities be properly used without misuse). Still, the latter 'misuse' case should be distinguished from 'abuse' or gives user privilege that they don't have, which is more serious. Occasional misuse of API happens, even in APIs that are supposed to be used by users. There could be issues in calling sequence, parameter range, thread affiliation, etc.

Back to the code, the API "getEventReceiver()" is a public API, for users to attach their own event handlers (I*Events interface) to customize a class without subclassing it.

Ok, for example ISceneEvents in GVRScene. Could be moved to an inner class. If we can't avoid the IEvents interface then we could add a method to it to query for specific interfaces: like IEvents getEventSink(InterfaceClass.class) or something. Returns an instance of InterfaceClass if applicable, manager calls into it with applicable events. GVRScene.getEventSink would return an instance of its inner class implementing ISceneEvents when asked for it.
We are already using reflection so the getEventSink method could be an implicit protocol to avoid tagging classes and exposing even IEvents. That could be considered too loose by some.
Or if this events framework is so fundamental maybe IEvents belongs to the base class.
Also the distribution of events seems a bit wide to me (the recursive part). There is a danger we may start spending more and more time broadcasting and propagating events.

I think the inner class can solve some issues, which are possible access of the event handlers by developers. However, event handlers are sometimes not sensitive code to protect -- some times, users even want to call those event handlers to invoke some functionality -- like adding a key release event for working around some issues, etc.
When an inner class is added, developers might not be able to subclass those inner class and outer classes in a consistent and convenient way, which may make code hard to maintain. Also, the outer class "might" become a proxy for inner class, resulting in abundance of less useful code -- and make the working code hard to debug and checked.
So I doubt the inner class is needed here. However, if you could provide a prototype, we can look at it more thoroughly.

We should actively discourage third-party developers from deriving from key classes like GVRSceneObject and GVRScene.
I have noted what I had to. Will let other reviewers decide.

Updated per code review

Looks nice. Tested with the sample.
Planning to merge it sometime in the afternoon if there are no objections by then.


DirectX Debug runtimes crashing on memory leaks

Memory leaks would explain why the need for computer reboots after build testing every 25-75 client restarts or so.
Zapper and Imago have identified over 50 unique memory leaks in the client, they are now tagged for fixing: Search for "memory leak" in the code.
These are not harming FZRetail builds very much at all. This may also be the cause of wine crashing, if this is the case, it's more important to fix.
Imported from trac ticket #44,  created by fuzzylunkin1 on 01-08-2010 at 09:08, last modified: 02-24-2012 at 01:21

i've caught a few more of these, search for REVIEW or memleak
Trac comment by Imago on 07-05-2010 at 06:23

requires investigation


kernel-signed: define a new kernel subpackage

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[ ] The toolchain has been rebuilt successfully (or no changes were made to it)
[ ] The toolchain/worker package manifests are up-to-date
[ ] Any updated packages successfully build (or no packages were changed)
[ ] All package sources are available
[ ] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/tools/cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json)
[ ] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[ ] All source files have up-to-date hashes in the *.signatures.json files
[ ] sudo make go-tidy-all and sudo make go-test-coverage pass
[ ] Documentation has been updated to match any changes to the build system
[ ] Ready to merge

Summary

This spec purpose is to take an input kernel rpm and input secure-boot-signed
kernel binary from the same build and generate a new "kernel" rpm with the
signed kernel binary + all of the other original kernel files, triggers,
scriptlets, requires, provides, etc.
We need to ensure the kernel modules and kernel binary used are from the exact
same build because at build time the kernel modules are signed with an
ephemeral key that the kernel enrolls in its keyring. We enforce kernel
module signature checking when we enable security features like kernel
lockdown so our kernel can only load those specific kernel modules at runtime.
Additionally, to complete the UEFI Secure Boot chain, we must PE-sign the
kernel binary. Ideally we would enable secure-boot signing tools like pesign
or sbsign to be callable from inside the rpmbuild environment, that way we can
secure-boot sign the kernel binary during the kernel's rpmbuild. It is best
practice to sign as soon as possible. However there are issues getting that
secure boot signing infrastructure in place today. Hence we sign the
resulting kernel binary and "repackage" the kernel RPM (something rpm itself
actively tries to make sure you never do...generally for good reasons).
To achive this repackaging, this spec creates a new subpackage named
"kernel". To retain all of the initial kernel package behaviors, we make sure
the subpackage has the same requires, provides, triggers, post steps, and
files as the original kernel package.
This specific repackaging implementation leaves room for us to enable the
more ideal secure-boot signing flow in the future without introducing any
sort of breaking change or new packaging. Users still install a "kernel"
package like they normally would.
Maintenance Notes:

This spec's "version" and "release" must reflect the unsigned version that
was signed. An important consequence is that when making a change to this
spec or the normal kernel spec, the other spec's version version/release must
be increased to keep the two versions consistent.

Make sure the kernel subpackage's Requires, Provides, triggers, post/postun
scriptlets, and files match the normal kernel spec's. The kernel subpackage
should contain the same content as the input kernel package but replace the
kernel binary with our signed kernel binary. Since all the requires, provides,
etc are the same, this new kernel package can be a direct replacement for the
normal kernel package and RPM will resolve packages with kernel dependencies
correctly.

To populate the input sources:

Build the unsigned packages as normal
Sign the desired binary
Place the unsigned package and signed binary in this spec's folder
Build this spec

Signed-off-by: Chris Co<EMAIL_ADDRESS>Does this affect the toolchain?

YES
Associated issues

Links to CVEs
Test Methodology

Local build, pipeline build

Opening draft to continue discussion from #779


Added Project: Image Classification Using CNN (CIFAR-10 Dataset) under the Neural Networks Folder

Related Issues or bug
This pull request addresses the feature request to add an example of image classification using Convolutional Neural Networks (CNN) on the CIFAR-10 dataset under the Neural Networks folder.
Fixes: #822
Proposed Changes

Implemented an end-to-end image classification project using CNN on the CIFAR-10 dataset.
Added code for loading, preprocessing, and augmenting CIFAR-10 images.
Built a CNN model with key layers, including Conv2D, MaxPooling2D, and Dense, for effective classification.
Included training, validation, and evaluation code with metrics display.
Documented the project to guide users through each step.

Additional Info
This project serves as a hands-on example for understanding CNNs and implementing image classification. It helps users learn by working with a widely-used dataset and builds practical skills in deep learning.
Screenshots

Original
Updated

No image classification project on CIFAR-10 dataset
new project added

README.md looks something like this (updated )

@UppuluriKalyani, @Neilblaze, and @SaiNivedh26 please review my PR #823 . I've solved the issue #822
Looking forward to getting the PR merged and assignment of level and labels.
Awaiting your response. Thank you!


Add support for multiple values for x-forwarded-proto header

Reopened from https://github.com/django/django/pull/15488 since the ticket is now accepted
This pull request adds support for multiple, comma-separated, values for the x-forwarded-proto header.
When Django is deployed behind more than one proxy, the proxy behavior is sometimes to list the protocol as a comma-separated list. However, currently, Django expects only one value for the x-forwarded-proto header, instead of parsing it as a list of values and setting the protocol accordingly.
cc: @felixxm, @apollo13, @carltongibson, @kezabelle who reviewed the original Pull Request

Docs changes are missing. We also agree to take the leftmost value, see comment.

@heyts Thanks :+1: Welcome aboard :boat: I improved docs.
@apollo13 Can you take a look?

buildbot, test this please.


Use JSON instead of YAML for deserialization if Yajl is not available.

Use JSON as deserializer if Yajl gem isn't available.
Description
History:

2013: https://github.com/github/linguist/pull/806  and https://github.com/github/linguist/pull/809 - JSON was added as preferred deserializer
2014: https://github.com/github/linguist/pull/1608 - Yajl replaced JSON as a deserializer since it was a development dependency.

The problem is that many repos don't require Yajl, so they fallback to YAML now instead of JSON, which is slower at parsing Linguist's JSON files.
I think JSON was added to Ruby's stdlib in 1.9.0, so it should be safe to assume JSON will always be available (?).
This change falls back to JSON instead of YAML. In my app that doesn't have Yajl, this sped up Rails boot time by ~2 seconds.

From a quick glance this makes sense to me, though I'll need to test it to be sure the change doesn't conflict with some GitHub usage (I don't think it will). I'll try test this next week.

This change falls back to JSON instead of YAML. In my app that doesn't have Yajl, this sped up Rails boot time by ~2 seconds.

Out of curiosity, what effect would using Yajl in your project have on the Rails boot time?

From a quick glance this makes sense to me, though I'll need to test it to be sure the change doesn't conflict with some GitHub usage (I don't think it will). I'll try test this next week.

This change falls back to JSON instead of YAML. In my app that doesn't have Yajl, this sped up Rails boot time by ~2 seconds.

Out of curiosity, what effect would using Yajl in your project have on the Rails boot time?

Out of curiosity, what effect would using Yajl in your project have on the Rails boot time, ie JSON vs Yajl?

When the gem is required, the "samples.json" file is loaded and parsed via the Linguist module:
https://github.com/github/linguist/blob/9edd34988273d307180a1bfc4dfa30a9f2f79105/lib/linguist/language.rb#L498
The improvement here is that the change uses a JSON parser instead of a YAML parser to parse the JSON. That JSON could be parsed either with the json library or the yajl gem (depends on if the dependent app requires yajl), but either one is faster than using the yaml library:
YAML.load(File.read("lib/linguist/samples.json"))
# => 2.359655

Yajl.load(File.read("lib/linguist/samples.json"))
# => 0.212212

JSON.load(File.read("lib/linguist/samples.json"))
# => 0.173794

I also changed the code that loads the languages.{yml,json} files in the Linguist module to be consistent, but that change didn't make much of a speed difference.

Out of curiosity, what effect would using Yajl in your project have on the Rails boot time, ie JSON vs Yajl?

When the gem is required, the "samples.json" file is loaded and parsed via the Linguist module:
https://github.com/github/linguist/blob/9edd34988273d307180a1bfc4dfa30a9f2f79105/lib/linguist/language.rb#L498
The improvement here is that the change uses a JSON parser instead of a YAML parser to parse the JSON. That JSON could be parsed either with the json library or the yajl gem (depends on if the dependent app requires yajl), but either one is faster than using the yaml library:
YAML.load(File.read("lib/linguist/samples.json"))
# => 2.359655

Yajl.load(File.read("lib/linguist/samples.json"))
# => 0.212212

JSON.load(File.read("lib/linguist/samples.json"))
# => 0.173794

I also changed the code that loads the languages.{yml,json} files in the Linguist module to be consistent, but that change didn't make much of a speed difference.

Sorry, just realized that I read your question the wrong way 😆 Could've been a shorter answer: it's generally about the same using Yajl vs JSON.

Sorry, just realized that I read your question the wrong way 😆 Could've been a shorter answer: it's generally about the same using Yajl vs JSON.


Change edxorg models to use edx BigQuery source tables with fingerprint

User Story

Due to the size of some BigQuery edx tables, DevOps set up AirByte to sync large source tables incrementally (incremental | Append) to only replicate new or modified data.  person_course_fp is configured to sync incrementally using fingerprint (a hash of all the fields), but this would introduce duplicated rows for the user_id+course_id combination if any field is changed from the source, so we need to look into these raw tables synced by incremental mode, and de-dup the redundant rows in dbt
One possible solution is

add a timestamp field to these raw tables in Airbyte .e.g. raw__irx__edxorg__bigquery__mitx_person_course_fp (https://github.com/mitodl/ol-data-platform/issues/547)
in dbt model stg__edxorg__bigquery__mitx_person_course , use the window function to figure out which row is the most recent one per course_id+user_id combination order by this timestamp field desc

Acceptance Criteria

[ ] Review these raw tables with fingerprint fields: person_course_fp, mitx_user_info_combo_fp, and email_opt_in_fp
[ ] Change the dbt models to use these source tables with the fingerprint fields raw__irx__edxorg__bigquery__mitx_person_course_fp (requires implementing logic to dedup the rows with most recent info per course_id and user_id combination)

The _fp tables seem to be less than the full table, we will have to wait until it's resolved or at least know why these fp tables contain less rows before we switch to use _fp tables
-----13096726
SELECT COUNT(*) FROM "ol_data_lake_qa"."ol_warehouse_qa_raw"."raw__irx__edxorg__bigquery__mitx_person_course_fp" ;
-----13107767
SELECT COUNT(*) FROM "ol_data_lake_qa"."ol_warehouse_qa_raw"."raw__irx__edxorg__bigquery__mitx_person_course";

---12874595
SELECT COUNT(*) FROM "ol_data_lake_qa"."ol_warehouse_qa_raw"."raw__irx__edxorg__bigquery__email_opt_in";
---12857554
SELECT COUNT(*) FROM "ol_data_lake_qa"."ol_warehouse_qa_raw"."raw__irx__edxorg__bigquery__email_opt_in_fp";

Per Tobias, the fingerprint field is not useful as a cursor field because there is no deterministic, ascending ordering of the field since it is just a hash.https://docs.airbyte.com/understanding-airbyte/connections/incremental-append/#known-limitations
So we need some sort of timestamp field record_updated_at or something similar. For now, we can't use incremental sync until we figure out a solution


Breadcrumbs for CDS

The current chicago.gov website uses breadcrumbs on every page to help users stay oriented and navigate the site.

USWDS does not have a breadcrumb component. If we choose to add breadcrumbs to CDS, we can borrow from the bootstrap breadcrumb. Keep in mind accessibility best practices.

I think this is already done?

It is in there right now (bootstrap default), we just need to review it and agree on the current style. I also believe that we can change the font to Roboto and it will look better.

Modified font to Roboto and it looks better.

Removed the background color and added.


Another batch of variadic templates support

This time for local::packaged_task, dataflow, invoke_when_ready and packaged_action.

LGTM. This is marvelous! Thanks!


GE: Lookup Component malfunctions on RecordType Lookups

Steps to Reproduce:

Enable Gift Entry
Edit the default template, add RecordTypeId to the form
Start a new gift using this form
Attempt to search, no results will appear and an error message may display in the chrome console.

Suggested Fix:
Add special handling to fall back to SOQL instead of SOSL whenever dealing with Record Type fields in the doSearch function of GE_LookupController.

**lurch: attach W-042326

Tracking W-042326


SMS verification does not work for my 2nd phone

Keybase GUI Version: 6.2.8-20240306193933+e38523abbe
I tried to verify my 2nd phonenumber, as keybase complains it is not verified, but the expected SMS does not arrive.
The first time I tried was months ago,maybe even more that a year, and I retried it several times, months between tries (as I expected that maybe there is a limit to the number of verifications per country, per day or such).  I checked if I can receive SMS on that number and that just works. I also verified that my number is correct, no typo's detected by me.

Same here @roheve. Most likely a common issue for a long time which they have not prioritized fixing.

If you have been scammed by crypto investment, bitcoin lost, or bank transfer. I recommend to reach out to (hack4net8@gmail .com), for your money recovery solution.


Update career section

[x] Remove Technical Lead card
[x] For Junior Developer update 'Salary range: 3.5 - 4.5 Lac per annum (depending on skills)'
[x] Update link for 'Apply' button to https://forms.office.com/r/8jKDRh51na

Implemented and merged into master


cloning the repository giving a error

so basically. when i clone the repository and run npm run dev it gives a error saying something about not being able to find "express"

Read https://docs.turbowarp.org/development/extensions/better-development-server in full

i will see if it helps


Connecting to servers without mods

Hi
Thanks for creating this project! I'm excited to finally get to (attempt to) play my favourite game on my favourite OS :)
Not entirely sure if this is an real issue or plain user error:
I'm trying to connect to a vanilla Cherno server that does not require any mods, which results in the following error:
[dayz-launcher.sh][error] Missing mods data from API response
Feels like the launcher can maybe not distinguish between an empty and a missing mods list?
Server data at https://dayzsalauncher.com/api/v1/query/<IP_ADDRESS>/27016
Regards,
mrebw

Fixed via feafd7460fa7929f10fbbee9fab873e1e667cc7d
https://github.com/bastimeyer/dayz-linux-cli-launcher/blob/0.5.1/CHANGELOG.md#051---2022-05-25

Thanks for the super quick reply and fix!
Works like a charm!


Credentials for MSIX packaging tool to connect to created VM unclear

I created a VM using Hyper-V Quick Create and the MSIX VM template.
In the MSIX packaging tool I can select the VM and then I need to supply credentials to access the VM. What are those credentials?

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

ID: 3ca58f5e-1347-f9de-b102-ac0be796858a
Version Independent ID: 6a087cdf-5ac1-0f9b-a6f3-219982821120
Content: MSIX packaging environment on Hyper-V Quick Create - MSIX
Content Source: msix-src/packaging-tool/Quick-Create-VM.md
Product: msix
GitHub Login: @c-don
Microsoft Alias: cdon

The credentials are used to login to the VM. so provide the credentials that you would generally use to login.

After the creation of the VM I understood that you have to create a local account and for that setup it works.
If you create a VM using Windows Pro yourself using a personal Microsoft account rather than a local account - how do you supply those credentials to the MSIX packaging tool in that case?

You should be able to provide the domain\username and then the password.
@sharlaakers can you correct me if i am wrong?

So if people have an @hotmail.com or @outlook.com personal Microsoft account, how would that work?

There was a bug that was resolved in the 1904 release of Windows 10 which didnt allow for 'email' format usernames. The current quick create VM is based of 1809 release of Windows 10.
You should be able to connect to VM using the personal microsoft account, as long as the VM is 1904 release of Windows 10.

(I filed that as a bug in Feedback Hub half a year ago, but never got a reply, so I assumed the bug would still exist)


Add a setup keyword to disable normalization.

It should be possible to disable keyword normalization for commands with a setup keyword in setup.py.

This won't be implemented. Normalization is a feature.


Style adjustments to needed to position utility nav links

@benjaminapetersen pr
let me know if you have questions


Re-add serial ('series') dimension data to GA tracking

Who is this for?
@hthair
This reinstates the tracking in the form title:id e.g. The Secret GP:W3RdtCkAACgAF706. Is this still appropriate? Could/should this wait till we have a larger GA discussion/sprint?
What is it doing for them?
Allowing them to track serial performance using a custom GA dimension (erroneously removed when moving to NextJS).

Closing in favour of the work that will shortly commence in #3841


sensor: tdk 42688 driver

Adds a driver for TDK InvenSense 42688 six axis IMU. Verified using the sensor shell sample app via:

sensor info
sensor get icm42688p@0

Collaborated on by Tom Burdick and Yuval Peress

note: attr_set from the sensor API isn't fully implemented in this PR. I will send out a separate PR for that with an extension to the sensor shell that adds the sensor set subcommand so it can be verified easily.


A question when debugging OpenFAST in linux

Dear all
I try to debug openfast in linux system as the document [https://openfast.readthedocs.io/en/main/source/dev/debugging.html] ,my launch.json is written as:
{
"name": "AOC_WSt",
"type": "gdb",
"request": "launch",
"printCalls": false,
"showDevDebugOutput": false,
"valuesFormatting": "prettyPrinters",
"gdbpath": "gdb",
"target": "${workspaceRoot}/build/glue-codes/openfast/openfast",
"cwd": "${workspaceRoot}/build/reg_tests/glue-codes/openfast/AOC_WSt/",
"arguments": "${workspaceRoot}/build/reg_tests/glue-codes/openfast/AOC_WSt/AOC_WSt.fst",
}
but it occurs an error:
Could not start debugger process, does the program exist in filesystem?
Error: spawn gdb ENOENT
It seems like it cannot find gdb.exe ,but I truly has installed gdb.
Then I change the gdbpath to "/usr/bin/gdb",it also occurs an error:
Could not start debugger process, does the program exist in filesystem?
Error: spawn /usr/bin/gdb ENOENT
I am a new to debugging in linux system, I donot know how to solve the problem, could anyone give me some advice?
Thank you.
AsIlll223

Thank you! The problem has been solved.


Helper for live interaction

Hi,
I am working on complex interaction with multiple components supporting drag and drop.
I found out that it was much easier to handle that by wrapping your hook inside and own code, allowing me to handle a "live" state which is not yet part of the history.
For example during a mouse drag, all my components are aware of the new state, but this state is not yet part of the history.
At the end of the mouse interaction it be came part of the history.
I call it "intermediate" state.
Would you be interested in such behavior, or by chance is there a way to setup your hook to behave this way?
Here is my actual code:
import { useMemo, useState } from 'react';
import useUndoable from 'use-undoable';

/**
 * A useUndoable hook featuring an intermediate present state
 * which is not yet archived in the history.
 *
 * This simplifies a lot interaction between multiple components.
 */
export default function useUndoableWithIntermediate<T>(props: T): [
  T,
  (state: Partial<T>, intermediate?: boolean) => void,
  {
    past: T[];
    future: T[];
    undo: () => void;
    canUndo: boolean;
    redo: () => void;
    canRedo: boolean;
    reset: (initialState?: T) => void;
    resetInitialState: (newInitialState: T) => void;
  }
] {
  const [present, setPresent, actions] = useUndoable<T>(props);
  const [intermediate, setIntermediate] = useState<Partial<T> | undefined>(
    undefined
  );

  const state = useMemo(() => {
    return { ...present, ...intermediate };
  }, [present, intermediate]);

  function setState(value: Partial<T>, intermediate?: boolean) {
    if (intermediate) {
      setIntermediate((state) => {
        return { ...state, ...value };
      });
    } else {
      setPresent((state: T) => {
        return { ...state, ...value };
      });
      setIntermediate(() => undefined);
    }
  }

  return [state, setState, actions];
}

And I use it this way:
# During the drag interaction
setState(newState, true);
# At the end of the drag
setState(newState, false);

It works pretty well.

Hey @vallsv, I like this solution! I'm wondering if this achieves the same effect as the ignoreAction param on setState, however. Take a look at this crude example I whipped up in CodeSandbox.
The whole state is tracked via useUndoable here. Every time onMouseMove is called, it'll call setPosition with the final param, ignoreAction, set to true—this way, it'll only update the present state. However, 300 milliseconds after you stop moving the mouse, setPosition is called normally, and the state is updated as you'd expect.
It's a crude and not-very-performant example, but it demonstrates how events with a huge quantity of calls can be handled without polluting the state.
Does this generally fit your requirement or is there something else I'm not considering that your useUndoableWithIntermediate hook covers?
Thanks for opening an issue, by the way! 😄

No worries! Feel free to reopen it when you get back to it :)


[FEATURE] Create geojson countries file from CSV

A CSV file containing mangrove countries has been provided. Write a script to create a geojson file from this CSV for use in the MRTT UI. The bounding box for selected countries will be used to determine the extent of the map described in #17.
Describe the solution you'd like

The CSV contains columns for point coordinates (Latitude and Longitude), along with min and max x and y coordinate columns.
Use Latitude and Longitude to populate the geojson geometry property.
Use the min and max x an y coordinate columns to populate the bbox property.
The output can be validated at geojson.io.
Create a new branch from main named feature/19/countries-geojson.
Add the output file to a new directory: gmw-users/mrtt-ui/src/data.

Here's an example:
{
  "type": "FeatureCollection",
  "features": [
     {
         "type": "Feature",
         "bbox": [70.06346893, 12.41236115, -69.86541748, 12.62402916],
         "geometry": {
             "type": "Point",
             "coordinates": [-69.97027576, 12.50931542]
         },
         "properties": {
             "country": "Aruba",
             "mangroves": 1
         }
     },
     // next feature...
  ]
}

Describe alternatives you've considered
There could be an alternative geojson schema so feel free to propose one.
Geojson is a good format in this case as it is human and machine readable. Properties can be used to populate form elements and the geometry/bbox/properties can be used on a web map.

I wrote something to do create the geojson:
features = []
with open('Mangrove_Countries.csv', newline='', encoding='latin1') as csvfile:
    print(csvfile)
    reader = csv.reader(csvfile, dialect=csv.excel, delimiter=',')
    next(reader, None)  # skip the headers
    for Country,Mangroves,Latitude,Longitude,MIN_POINT_X,MAX_POINT_X,MIN_POINT_Y,MAX_POINT_Y in reader:
        Latitude, Longitude = map(float, (Latitude, Longitude))
        features.append(
            Feature(
                bbox= [MIN_POINT_X, MIN_POINT_Y, MAX_POINT_X, MAX_POINT_Y],
                geometry = Point((Longitude, Latitude)),
                properties = {
                    'country': Country,
                    'mangroves': Mangroves
                }
            )
        )

collection = FeatureCollection(features)
with open("mangrove_countries.json", "w") as f:
    f.write('%s' % collection)

There was one trick with the encoding. It's not actually utf-8 encoding. One of the answers here pointed me in the right direction.

@JBurkinshaw @cpapalaz We'll probably just need the countries with mangrove. That is Magroves = 1 in the csv.

I also created this species per country list.
country_specie.json.zip

@JBurkinshaw @cpapalaz We'll probably just need the countries with mangrove. That is Magroves = 1 in the csv.

So far I've been filtering on the client side but it would be fine to remove before then too.


Scalability of Many Databases

This is not exactly a bug report or a feature request, but more of a discussion.
We will have a fairly large set of databases in a multi-tenant situation. Let's say for sake of argument that we will have 5000 database that are around 20GB each. So, we have 100TB of storage to host these database. Now assume that due to load I need to start adding nodes to the cluster, to scale horizontally. For each node, I want to add I need to add 100TB of storage to my infrastructure. This is not really practical. If I have 10 nodes, I wind up with 1000TB of storage required.  Yikes.
Interestingly, each database itself, doesn't need 10 nodes. Let's say that each user only imposes enough load to consume a tiny fraction of a single database node. In that case, we need to scale the system to support all the databases concurrently, but mainly we are looking at HA for a single database. In that case I really only need an individual database on 2 nodes (or 3 if I want to make sure I can do a majority write quorum).
It would be interesting to be able to specify how many nodes databases should be present on, and not required each node to have a full copy of ALL databases. This is somewhat like the DHT Auto Shading feature in #6256, but at the database level. When I add a node to the cluster, I do NOT want to have to transfer 100TB of data to that node to get it up and running. I would much rather add a node, and have a certain number of databases start to migrate to that node (essentially auto balancing). It's entirely possible that DHT Auto-Sharding could solve this if implemented properly, if all data from all databases just shards across the whole cluster. The only concern, is that presently an EMPTY database that just has the schema and indices seems to take up about 500MB of storage.  If I multiply that by 5000 databases, times 10 nodes. I wind up with 5GB per database times 5000 database for a total of 25TB of data just to store empty databases.
I am not entirely sure how this would interact with node roles (MASTER vs. REPLICA). I suppose the configuration could specify how many masters and replicas required for databases.
In general, I think it would be ideal if one could separate processing scalability and storage scalability / reliability. But in general, if I add a node with storage to the system, the effective storage of the cluster should go up. Now it stays the same. It would also be fantastic if the database could work off of shared storage. We can RAID the storage ourselves for the desired amount of reliability and performance at the storage level. This might be technically challenging for now. It does seem like all read replicas could share the same storage.

@luigidellaquila Perhaps we should add the distributed label to this issue.

Done, thanks!


Add gradleNexusPublishPluginVersion to JavaPackageLanguage

From https://github.com/pulumi/pulumi-command/blob/fd2f53ed5c12a2237037c9d386c4f7635e5c1c94/provider/cmd/pulumi-resource-command/schema.json#L151

Hi, thanks for the contribution! Apologies for the failing CI. Could you rebase your branch onto main and force push?
Btw, I saw that you're using our generator in a project? If you have any questions or feedback, feel free to reach out :)


Fix some flake8 issues.

ping @madhulika95b, @ldko, this is ready for review. Just some flake8 changes.

nvm, it's not ready yet. flake8 also has a problem with breaking before the binary operator.

Back in business. So what happened is that pycodestyle (which flake8 uses) defines warnings for having a break before or after the binary operator, but that those warnings are suppressed by the default configuration. However, we override the default configuration in our tox.ini file when we tell flake8 to ignore the error for blank excepts. That causes the warnings to show up now. The warning both exist because PEP8 used to recommend breaking after the binary operator, but has switched it's mind and now recommends breaking before the binary operator. So, to fix this, I've just told flake8 to ignore the warning about breaking before the binary operator, which is what is recommended now by PEP8.


Printer test: optimize concat.

Optimize concat to minimize allocations.

join text docs early
remove Nil
flatten nested concats
don't allocate unless the resulting list is not the same as the incoming one.

On Napkinscript.res rescript printer:
before:
Allocs/op: 171960

after:
Allocs/op: 120221

Before:

After:

Awesome work


regenerate_auth setting remains enabled after relaunch

The regenerate_auth setting is supposed to be disabled automatically after a successful run.  This is not working.
# curl -s -H "Authorization: Bearer $SUPERVISOR_TOKEN" \
  http://supervisor/addons/c03d64a7_tesla_http_proxy/info | jq .data.options.regenerate_auth
true

Fixed in https://github.com/llamafilm/tesla-http-proxy-addon/commit/d461be2d69596d2d49589ded886260576ad0cacd


[BUG] Race condition when testing with memprovider

Hi! I'm not really sure if this can be considered a bug, but someone could be led to test the code this way.
Consider that I'm testing code and I want to cover both scenarios of a feature flag being enabled and disabled. So we don't want to rely on actual providers, just a stub. The memprovider is the way to go:
func TestParallelSingletonUsage(t *testing.T) {
	t.Parallel()

	type fields struct {
		givenFlagValue bool
	}

	tests := map[string]struct {
		fields fields
		want   bool
	}{
		"test when flag is true": {
			fields: fields{givenFlagValue: true},
			want:   true,
		},
		"test when flag is false": {
			fields: fields{givenFlagValue: false},
			want:   false,
		},
	}

	for name, tt := range tests {
		tt := tt
		name := name
		t.Run(name, func(t *testing.T) {
			t.Parallel()

			err := openfeature.GetApiInstance().SetProvider( // Here we have a race condition! We need to set the provider in parallel to ensure the test runs under the expected condition
				memprovider.NewInMemoryProvider(
					map[string]memprovider.InMemoryFlag{
						"some_cool_feature": {
							State:          memprovider.Enabled,
							DefaultVariant: "variant_1",
							Variants: map[string]any{
								"variant_1": tt.fields.givenFlagValue, // Make sure the provider always returns the value given by the test case
							},
							ContextEvaluator: nil,
						},
					},
				))

			require.NoError(t, err)

			got := theActualCodeUnderTest()

			require.Equal(t, tt.want, got, "uh oh, value is not as expected")
		})
	}
}

func theActualCodeUnderTest() bool {
	return openfeature.GetApiInstance().
		GetClient().
		Boolean(context.Background(), "some_cool_feature", false, openfeature.EvaluationContext{})
}

Running a single test it is not a issue:
$ go test -run ^TestParallelSingletonUsage$ local/goff-tests -count=1
ok      local/goff-tests        0.005s

Running more parallel tests, you can start to see some unpredictable results:
$ go test -run ^TestParallelSingletonUsage$ local/goff-tests -count=20
--- FAIL: TestParallelSingletonUsage (0.00s)
    --- FAIL: TestParallelSingletonUsage/test_when_flag_is_true (0.00s)
        parallel_test.go:57:
                Error Trace:    /home/renato_lima/go/src/local/goff-tests/parallel_test.go:57
                Error:          Not equal:
                                expected: true
                                actual  : false
                Test:           TestParallelSingletonUsage/test_when_flag_is_true
                Messages:       uh oh, value is not as expected
--- FAIL: TestParallelSingletonUsage (0.00s)
    --- FAIL: TestParallelSingletonUsage/test_when_flag_is_true (0.00s)
        parallel_test.go:57:
                Error Trace:    /home/renato_lima/go/src/local/goff-tests/parallel_test.go:57
                Error:          Not equal:
                                expected: true
                                actual  : false
                Test:           TestParallelSingletonUsage/test_when_flag_is_true
                Messages:       uh oh, value is not as expected
FAIL
FAIL    local/goff-tests        0.010s
FAIL

Any suggestion on how to avoid that only using the sdk is appreciated ;).

This is "intended" behavior.
Only one default provider can be set in the API (see specification).
If you want to use multiple providers as in your code sample, you can make use of the domain concept. Here you can isolate providers into domains.
I'm not too deep into the Go SDK, but I think this is realized through the SetNamedProvider() and GetNamedClient() functions.

Hello Guido,
I'm actually not intended to use multiple providers. My intent is to ensure
each test run under a specific feature flag variation.
Do you have any suggestion on how to do that?
On Mon, Oct 14, 2024, 11:30 Guido Breitenhuber @.***>
wrote:

This is "intended" behavior.
Only one default provider can be set in the API (see specification
https://openfeature.dev/specification/sections/flag-evaluation#setting-a-provider
).
If you want to use multiple providers as in your code sample, you can make
use of the domain concept
https://openfeature.dev/specification/glossary#domain. Here you can
isolate providers into domains.
I'm not too deep into the Go SDK, but I think this is realized through the
SetNamedProvider() and GetNamedClient() functions.
—
Reply to this email directly, view it on GitHub
https://github.com/open-feature/go-sdk/issues/293#issuecomment-2411280573,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABAKJQK5VVEOJOHDJFAR2QDZ3PBNTAVCNFSM6AAAAABP32KOXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJRGI4DANJXGM
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hey, I am evaluating our Java approach to see if it is feasible to implement something similar in Golang.
What we are doing is a little bit hacky, but we have not yet devised another solution.
We do have one TestProvider, in which we maintain a map. This map has the test name as a key and its own in-memory provider as a value.
On each test run, we're storing the test name in a thread-local (important, as we can't pass this information on in another way) and, based on this information, delegate to the corresponding provider based on the map.
This approach works because we can utilize many Java specifics (e.g., this is our own test extension). But I need to evaluate whether something like this would be feasible within Golang, and I will get back to you.

I now need feedback on this idea, but what if we generate a TestProvider that prevents parallel execution when used with a Mutex (kudos to @toddbaert for this idea)?
Normally, test execution time is not a critical factor, and this seems like a feasible tradeoff to prevent race conditions. However, I am not really familiar with Golang enough to evaluate this idea properly or see all possible side effects. Wdyt? Could this be a feasible solution?
I tried to do some research to mimic our Java approach, but passing on the test name or any other indicator to our evaluation without a race condition seems to be hard. There would be the Context we can use, but this would require all our users to actually accept a context on each method under test (which is, in my opinion, not feasible; it seems like writing production code purely for testing).

I now need feedback on this idea, but what if we generate a TestProvider that prevents parallel execution when used with a Mutex (kudos to @toddbaert for this idea)?
Normally, test execution time is not a critical factor, and this seems like a feasible tradeoff to prevent race conditions. However, I am not really familiar with Golang enough to evaluate this idea properly or see all possible side effects. Wdyt? Could this be a feasible solution?
I tried to do some research to mimic our Java approach, but passing on the test name or any other indicator to our evaluation without a race condition seems to be hard. There would be the Context we can use, but this would require all our users to actually accept a context on each method under test (which is, in my opinion, not feasible; it seems like writing production code purely for testing).

Ya my TLDR for how this might work is you have a utility of some kind that you open and close (probably with a defer) which will prevent interleaving setProvider calls on the singleton until it's closed; it could even be build into a special test provider which holds a shared lock, and which encapsulates the memory provider; this could prevent tests from interleaving, but the locking could hurt performance a bit. It may be the beset option though.

I think I agree with @toddbaert
So, this is quite easy to achieve, with e.g. a custom TestProvider right?
var TP = TestingProvider{}

type TestingProvider struct {
	memprovider.InMemoryProvider
	sync.Mutex
}

func (t *TestingProvider) Wait() {
	t.Lock()
}

func (t *TestingProvider) Cont() {
	t.Unlock()
}

func (t *TestingProvider) SetProvider(provider memprovider.InMemoryProvider) {
	t.InMemoryProvider = provider
	openfeature.GetApiInstance().SetProvider(t)
}

And using the locking methods in the test:
func TestParallelSingletonUsage(t *testing.T) {
	t.Parallel()

	type fields struct {
		givenFlagValue bool
	}

	tests := map[string]struct {
		fields fields
		want   bool
	}{
		"test when flag is true": {
			fields: fields{givenFlagValue: true},
			want:   true,
		},
		"test when flag is false": {
			fields: fields{givenFlagValue: false},
			want:   false,
		},
	}

	for name, tt := range tests {
		tt := tt
		name := name
		t.Run(name, func(t *testing.T) {
			t.Parallel()
			TP.Wait() //<<<<<<<<<<<<
			TP.SetProvider(memprovider.NewInMemoryProvider(
				map[string]memprovider.InMemoryFlag{
					"some_cool_feature": {
						State:          memprovider.Enabled,
						DefaultVariant: "variant_1",
						Variants: map[string]any{
							"variant_1": tt.fields.givenFlagValue,
						},
						ContextEvaluator: nil,
					},
				},
			))
			got := theActualCodeUnderTest()
			TP.Cont() //<<<<<<<<<<
			require.Equal(t, tt.want, got, "uh oh, value is not as expected")
		})
	}
}

However, this essentially "reverts" the effect of t.Parallel(), which raises the question: "why not simply avoid running these tests in parallel in the first place?" :D

@natenho I’ve submitted a draft PR with a potential solution for this (#295). I’d love to hear your thoughts and see if it meets your needs.


share image

image share option was added
Since enrolling the instance into the domain has been became part of cloudinit, hostmanager module was changed, joining into domain function was removed and user data was added.

Brett advised me to build user data with render_manifest function. I will do the refactoring and ask him to review and only then I will create PR
Thanks,
Petru


skim panic when running from nvim

I have installed it on my silicon Mac with Kitty and it works fine in terminal. Whenever I open nvim in tmux session and try to run it, it will fail with
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IOError(Os { code: 6, kind: Uncategorized, message: "Device not configured" })', /Users/myusername/.cargo/registry/src/ind
ex.crates.io-6f17d22bba15001f/skim-0.9.4/src/lib.rs:317:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Strange. Looks like an upstream error in skim. I'm running short on time (I've got a few PRs I still need to review) and I'm not sure I'll get around to fixing this soon. But what I would like to do is switch to using https://github.com/helix-editor/nucleo
for fuzzy finding. I don't know if it would fix this issue but either way I'll be switching to nucleo at some point and I don't know if there is much reason to fix it in upstream skim.

@hmrc87
We've switched to using nucleo now. I'd be interested to know if this is working now or not.

Since we've completely switched to nucleo for fuzzy finding I'm going to close this issue. If a similar problem now exists with nucleo a new issue would be awesome.


Upgrade to OCaml 4.14

The project should be using a more recent version of OCaml. Since we rely on the compiler libraries at the moment, we depend on a fixed version of OCaml, currently 4.12.
We should update the dune-project file to reflect this change. From there, running dune build api-watch.opam will update the opam file accordingly.
In the current project state I don't expect there to be a breaking change to the parts of the compiler libs we are using between 4.12 and 4.14 but we never know.

From my understanding this task needs an upgrade of the current OCaml version. So updating the dune-project file and running the command dune build api-watch.opam will update opam files in the project.
So we need to upgrade our local environment from 4.12 to 4.14 to be able to complete the task if I'm not mistaken.

Requesting assignment for the project above.

So I am beginning the task and I had an issue concerning the upgrade from 4.12 to 4.14. Is it possible to just upgrade the version without essentially deleting the present version of the switch in OCaml?
Like an upgrade of files to fit the 4.14 version.

Changing the ocaml version will require rebuilding the local switch. You can use
opam switch reinstall .

After building the updated opam file and that should sort you out!

Thank you for the recommendations @shonfeder. I see that this upgrades to the latest available release of OCaml if I not wrong.
The latest version from online Docs is 5.1.1 so for 4.14 do we append the version to the opam switch reinstall phrase?

You can run opam switch reinstall --switch 4.14.1 or whatever switch you are upgrading to

Thank you @dinakajoy. I think I'll go with the 4.14.1 since it has bug fixed from the .14 version before it.

If using a local switch, then the switch should be decided based on the ocaml version specified in the opam file. So if that's now working something may be amiss with your set up? Or maybe you are not using a local switch?

Yes I am using a local sqitch. This is what the .opam file indicates:
 depends: [
    "dune" {>= "2.7"}
    "ocaml" {>= "4.12.0" & < "4.13.0"}
    "logs"

From the above snippet those are the two allowed versions. How do I go about that?

All good at @MungaSoftwiz

The way I would proceed here the following:

Without reinstalling your switch, update dune-project to bump the lower and upper bounds on ocaml
Have dune update the opam file with dune build api-watch.opam
Reinstall your switch and try to build the project under 4.14

For 3 you can probably simply remove the local switch and create a new one from there. Given you're changing compiler version you will have to rebuild everything anyway.

The project relies on the compiler libraries so to avoid compatibility issues we'll stick to allowing only 4.14, i.e. >= 4.14.0 & < 5.0.0.

I am done with this particular task. The builds runs on my local switch as expected.

Awesome work! We'll be ready to review your PR when you are ready with it :)

I still have a simple question though. Do we have to run dune build @fmt --auto-promote after each build we run.

dune build @fmt --auto-promote will reformat OCaml source files (.ml and .mli) and dune files (dune and
dune-project). If you haven't modified or written any new such files there is no need to run the command.
Either way, the CI will fail if the project is not correctly formatted so you can't really miss it.

Thanks for the clear explanation. I was a bit confused about that since I had not done so in my recent PR. I clearly understand when to run the the formatter now.


[10.x] Display error message if json_encode() fails

Adding the error code to the exception isn't useful. Instead, the error message can give details about the problem.

If this needs to be changed, I suggest concat the error code in the string, for backwards compatibility.

@henzeb This is just an error string that's displayed in debug mode if the exception is thrown and not parsed by anyone, so adding the error code makes no sense to me at all.

@aimeos can you rebase your pr against 10.x to fix the tests?

@aimeos changing from using the error code to the error message is a breaking change.
On one project I work on, we log all the exceptions messages, and do some assessments on their frequency.
Some of these assessments, group exceptions by their message. Specially on exceptions that are considered "stable", such ones that have a clear error code in it.
I believe some error tracking platforms also allow a similar workflow for tracking bugs/exceptions.
Although I wouldn't drop the error code altogether, I agree having the message along is useful.
But this change should target Laravel 11, so people who have error tracking mechanisms in place are not surprised.

I guessing it also possible to trigger JsonException here instead and set it as $previous when throwing InvalidPayloadException? https://www.php.net/manual/de/class.jsonexception.php

@aimeos does #48884 fit your requirements?

@crynobone Is the nested exception shown in the Laravel debug view if an error occurs?

@aimeos are you still working on this?


Remove AssumeRoleWithWebIdentity action

Codecov Report

Merging #10 into master will decrease coverage by 0.4%.
The diff coverage is 90.9%.

@@            Coverage Diff             @@
##           master      #10      +/-   ##
==========================================
- Coverage   92.43%   92.03%   -0.41%
==========================================
  Files          18       17       -1
  Lines         291      251      -40
  Branches       16       14       -2
==========================================
- Hits          269      231      -38
+ Misses         22       20       -2

Impacted Files
Coverage Δ

...la/com/ing/wbaa/airlock/sts/api/xml/TokenXML.scala
100% <ø> (ø)
:arrow_up:

...in/scala/com/ing/wbaa/airlock/sts/api/STSApi.scala
100% <100%> (ø)
:arrow_up:

...n/scala/com/ing/wbaa/airlock/sts/api/UserApi.scala
100% <100%> (ø)
:arrow_up:

.../wbaa/airlock/sts/service/db/dao/STSTokenDAO.scala
100% <100%> (ø)
:arrow_up:

.../com/ing/wbaa/airlock/sts/service/db/MariaDb.scala
80% <100%> (ø)
:arrow_up:

.../wbaa/airlock/sts/service/UserTokenDbService.scala
82.85% <75%> (-0.48%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5d063fe...e339678. Read the comment docs.


Add get and set APIs for the ZeRO-3 partitioned parameters

The DeeSpeed currently supports a set of debugging APIs to get and set the full model states (parameters, gradients, and optimizer states). However, in some scenarios, only local states are needed, for example, when pruning some model layers based on a local criterion. After calling model_engine.step(), we need to apply the local mask to the partitioned parameters owned by each process. Therefore, I am submitting this PR to introduce some new APIs for get and set ZeRO-3 partial model states.
APIs intro
def safe_get_local_fp32_param(param):
    """Get the fp32 partitioned parameter."""

def safe_get_local_grad(param):
    """Get the fp32 gradient of a partitioned parameter."""

def safe_get_local_optimizer_state(param, optim_state_key):
    """Get the fp32 optimizer state of a partitioned parameter."""

def safe_set_local_fp32_param(param, value):
    """Update the partitioned fp32 parameter."""

def safe_set_local_optimizer_state(param, value, optim_state_key):
    """Update the fp32 optimizer state of a partitioned parameter."""

Usage
# local API
from deepspeed.utils import (
    safe_get_local_fp32_param,
    safe_get_local_grad,
    safe_get_local_optimizer_state,
    safe_set_local_fp32_param,
    safe_set_local_optimizer_state
    )

TODO

[x] Add local APIs
[x] Add UTs
[ ] Update Docs

@tjruwase

@microsoft-github-policy-service agree company="Intel"

@yiliu30, thanks for this great contribution. We currently don't have API for setting gradient, which is a bit trickier. Do you mind helping with that for both full and local scenarios? It is okay for that to be a separate PR.
A PR for setting gradients will address these requests:

#3310
https://github.com/microsoft/DeepSpeed/pull/4192#issuecomment-1703995117

@yiliu30, thanks for this great contribution. We currently don't have API for setting gradient, which is a bit trickier. Do you mind helping with that for both full and local scenarios? It is okay for that to be a separate PR.
A PR for setting gradients will address these requests:

[REQUEST] How to access to the gradients (to manipulate) while the model is training? #3310
Allow modification of zero partitioned parameters #4192 (comment)

@tjruwase Sure, I'd be happy to support it with a follow-up PR.

@tjruwase, I updated the docs, could you please take a moment to review them, thx

@yiliu30, I noticed that only zero-3 is supported for the local APIs. Is there any reason not to support other zero stages like the full APIs? Thanks

@yiliu30, I noticed that only zero-3 is supported for the local APIs. Is there any reason not to support other zero stages like the full APIs? Thanks

Hi @tjruwase, there is no special reason, just because we are working on some experiments with ZeRO-3.  I can add the support for zero 1 and 2 if needed.

@yiliu30, I noticed that only zero-3 is supported for the local APIs. Is there any reason not to support other zero stages like the full APIs? Thanks

Hi @tjruwase, there is no special reason, just because we are working on some experiments with ZeRO-3. I can add the support for zero 1 and 2 if needed.

@yiliu30, thanks for the explanation. I think it is okay to add zero 1 & 2 support in a separate PR. I don't want to block your work. Your contribution is greatly appreciated.

Hi, is there any plan or update to add "safe_set_full_grad" API? I need this api in my case for manipulate the gradients manually.

@guoxiaoyu-gxy, thanks for your interest. Unfortunately, we currently lack bandwidth to add this API.


More C# coverage

Based on #4416. More coverage for AsyncStreamExtensions and Metadata.

All C# tests green (and this is only adding C# tests).


repository for TopoModelX  not found

error message in trying to copy git clone:
git clone git@github.com:pyt-team/TopoModelX.git                                  128 ↵ ──(Thu,Aug22)─┘
cd TopoModelX
Cloning into 'TopoModelX'...
<EMAIL_ADDRESS>Permission denied (publickey).
fatal: Could not read from remote repository.

Hello,
Your SSH keys are not set up correctly. Either add the correct key to your GitHub account or try HTTPS-based cloning. You can find more information here: https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository
Either way, this is not an issue with TopoModelX, so closing here :)

I was trying to install TopoModelX using the link the was given in the GitHub site for TopoModelX

I understood that, but still you have to have ssh set up correctly or use https-based cloning.

<EMAIL_ADDRESS>Permission denied (publickey).

This is a GitHub permission issue, we don't have anything to do with that :)

I followed your advice and everything is good. I needed to create an SSH key.  THANKS!


At what point in the .NET API code should we set the TotalRecordCount

In the sample code here: https://github.com/begriffs/angular-paginate-anything/wiki/How-To-Configure-ASP.NET-Web-API
The TotalRecordCount is never set, but is required by the code. Upon retrieving that from our database, when and where should we set it in out code to return to the client?

Not sure at first glance. Perhaps @tafs7 knows the answer.

it's been a few months since I looked at this code base, but if the sample doesn't include it, it might be a miss. I took some of this code from a project I was working at the time, and we may not have had the requirement to show total count on the screen, so it may be missing here.
the action filter will enrich the action parameter by injecting the HTTP range header data into the action parameter, so if your client is passing the total count in as part of the request, it will already be set by the model binder - in theory :)

Thanks for the reply, I passed it in when the return is started as pagingModel.TotalRecordCount
So this:
return this.PagedPartialContent(data, pagingModel.From, pagingModel.To, pagingModel.TotalRecordCount);
effectively becomes this:
return this.PagedPartialContent(data, pagingModel.From, pagingModel.To, data.totalCount);
Seems to be working great!

@NickBehrends excellent! Would you mind updating the wiki with what you learned?

Added. The main problem here is that the total count is required on the first run BUT if your client is returning the total count to the web API (mine isnt for some reason, not a huge deal though) you don't have to query the total count again, rather just pass in what the client gave.
While this is faster the problem is that if records are added or removed they will not be included in the count. We opted to just requery every time, it doesn't create any overhead for us. But for future readers, not querying after the first time (just use an if statement to check if its sent from the client) is an option.


fix: Fix cancel issue and form value state persistence

This PR fixes two things

The cancel button not showing the dialog after a change has been made.
The fields in the datasource form retaining values changed by the user without the user saving those changes.

Fixes #25333

Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Also list any relevant details for your test configuration.
Delete anything that is not relevant

[ ] Manual
[ ] Jest
[x] Cypress

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test

/build-deploy-preview skip-tests=true

/ok-to-test

/ok-to-test

/build-deploy-preview skip-tests=true

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test


训练报错

root@hanbing-XPS-8960:/home/hanbing/project/RT-DETR/rtdetr_paddle# python3 tools/train.py -c configs/rtdetr/rtdetr_r50vd_6x_coco.yml --eval
Error: Can not import paddle core while this file exists: /usr/local/lib/python3.10/dist-packages/paddle/fluid/libpaddle.so
Traceback (most recent call last):
File "/home/hanbing/project/RT-DETR/rtdetr_paddle/tools/train.py", line 30, in
import paddle
File "/usr/local/lib/python3.10/dist-packages/paddle/init.py", line 25, in
from .framework import monkey_patch_variable
File "/usr/local/lib/python3.10/dist-packages/paddle/framework/init.py", line 17, in
from . import random  # noqa: F401
File "/usr/local/lib/python3.10/dist-packages/paddle/framework/random.py", line 16, in
import paddle.fluid as fluid
File "/usr/local/lib/python3.10/dist-packages/paddle/fluid/init.py", line 36, in
from . import framework
File "/usr/local/lib/python3.10/dist-packages/paddle/fluid/framework.py", line 37, in
from . import core
File "/usr/local/lib/python3.10/dist-packages/paddle/fluid/core.py", line 338, in
raise e
File "/usr/local/lib/python3.10/dist-packages/paddle/fluid/core.py", line 274, in
from . import libpaddle
ImportError: libcudart.so.10.2: cannot open shared object file: No such file or directory

貌似是paddle没安装对  请先根据机器的软件信息找到对应的paddle正确安装


[Cosmos] updating versions for stable release

updating versions for stable release

API change check
API changes are not detected in this pull request.


Edde\Protocol: Handle ElementQueue faults properly

Now there is only log and no response to the element queue which should be appropriate.

This has been improved a bit.


Fix generated unit tests for MarkLogic Server 9.0 release

On internal Jenkins CI env, it is seen that many of generated unit tests for Data Services throw Assert failures such as ones given below. Failures are seen when MarkLogic Server release 9.0 (nightly builds) is used.
Same tests runs fine when MarkLogic Server release 10.0 (nightly builds) is used.
moduleInitMjs service.initializer endpoint (from Mocha Tests)
Stacktrace:
AssertionError: expected false to deeply equal true
AssertionError: AssertionError: expected false to deeply equal true
    at /space/jenkins/workspace/NodeAPIUnitTests_develop_b9_0/test-basic-proxy/lib/generated/moduleInitMjsTest.js:18:18
    at tryCatcher (node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (node_modules/bluebird/js/release/promise.js:547:31)
    at Promise._settlePromise (node_modules/bluebird/js/release/promise.js:604:18)
    at Promise._settlePromise0 (node_modules/bluebird/js/release/promise.js:649:10)
    at Promise._settlePromises (node_modules/bluebird/js/release/promise.js:725:18)
    at _drainQueueStep (node_modules/bluebird/js/release/async.js:93:12)
    at _drainQueue (node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (node_modules/bluebird/js/release/async.js:102:5)
    at Immediate.Async.drainQueues [as _onImmediate] (node_modules/bluebird/js/release/async.js:15:14)
    at processImmediate (internal/timers.js:439:21)

postOfMultipartForText service.postOfMultipartForTextDateTime1 endpoint (from Mocha Tests)
Stacktrace:
AssertionError: expected <Buffer 27 75 73 65 20 73 74 72 69 63 74 27 3b 0a 2f 2f 20 64 65 63 6c 61 72 65 55 70 64 61 74 65 28 29 3b 20 2f 2f 20 4e 6f 74 65 3a 20 75 6e 63 6f 6d 6d 65 ... 773 more bytes> to deeply equal '2018-01-02T10:09:08+07:00'
AssertionError: AssertionError: expected <Buffer 27 75 73 65 20 73 74 72 69 63 74 27 3b 0a 2f 2f 20 64 65 63 6c 61 72 65 55 70 64 61 74 65 28 29 3b 20 2f 2f 20 4e 6f 74 65 3a 20 75 6e 63 6f 6d 6d 65 ... 773 more bytes> to deeply equal '2018-01-02T10:09:08+07:00'
    at /space/jenkins/workspace/NodeAPIUnitTests_develop_b9_0/test-basic-proxy/lib/generated/postOfMultipartForTextTest.js:95:18
    at tryCatcher (node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (node_modules/bluebird/js/release/promise.js:547:31)
    at Promise._settlePromise (node_modules/bluebird/js/release/promise.js:604:18)
    at Promise._settlePromise0 (node_modules/bluebird/js/release/promise.js:649:10)
    at Promise._settlePromises (node_modules/bluebird/js/release/promise.js:725:18)
    at _drainQueueStep (node_modules/bluebird/js/release/async.js:93:12)
    at _drainQueue (node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (node_modules/bluebird/js/release/async.js:102:5)
    at Immediate.Async.drainQueues [as _onImmediate] (node_modules/bluebird/js/release/async.js:15:14)
    at processImmediate (internal/timers.js:439:21)

Following up on the previous comment, @georgeajit , which resolution seems best?

Tests that rely on .mjs modules are not run in an environment containing MarkLogic Server build 9.x releases.


Add support for collapsing on multiple fields

The FieldCollapsingSearcher is currently only able to collapse on a single field.
This PR adds support to collapse on an arbitrary amount of fields.
State of the PR:
The PR shows a possible solution, which needs feedback for the implemented approach.
Test Cases are missing, Code Review is needed, but later.
First goal is to clarify if we agree on the general idea.
We agree on the general idea.
Code Review was done.
Test Cases are in progress.
I think that multi-field collapsing can be understood in multiple ways:

collapse by the fields one by one, looking at their values & collapsesizes separately after each other
collapse by the combination of the fields, meaning the value-combinations of the fields all at once

This PR implements the first understanding.

Changes in FieldCollapsingSearcher:

Allow passing a comma-separated list of fields in collapsefield
Use collapsesize to override the default for all fields
Use collapsesize.fieldname to override the size for a specific field
collapse the result multiple times by iterating through the collapsefields

This means that the collapsesize for field foo is determined like this:

IF collapsesize.foo is set: use that
ELSE IF collapsesize is set: use that
ELSE: use default collapsesize

Closed topics:

The order of fields is important (see testCollapsingWithMultipleFields), opinions towards that?

This is fine.

The parameter is still called collapsefield (to keep backwards-compatibility), is that a deal-breaker?

It is not.

Regarding the different understandings from the top: Do you agree on those? Which should we support, both?

We support the first understanding - use the fields sequentially.

Thoughts about the field-order topic:
If the order of the fields would not matter, how should we determine which hits are kept? Should we try to keep as many hits per collapsefield as possible (reaching as close as possible to collapsesize)?
What happens if there is no clear "winner", meaning we can only get n hits, no matter how we combine the collapsefields?
In short: I think that the collapse-logic can become very complex if we don't simply take the fields in the order they are configured.
You are welcome to challenge that. :)

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

Update for the documentation: https://github.com/vespa-engine/documentation/pull/3051

yes


Virtual folder / Rewriting to different folder?

I think, i do not need to write much:
ws --rewrite '/assets/* -> ../Core/assets/$1' --directory www
I need this to avoid copying my assets into the www development environment. However, it seems this gets always blocked by the resolve-path module. Any way to implement this behavior without copying the assets?
More explanation: I have a multi platform project. /Core contains the assets and main typescript code. /Web contains the browser variant, /Desktop an nwjs build, /Mobile for PhoneGap etc. There is a build process copying files correctly, however while developing, im using the local-web-server as simple "run from source"-solution, so you dont need to rebuild the whole project every time. However this requires me to redirect the assets to their source path, instead of copying all the content over and over.

If you specify that www is the base --directory, then only files within the www folder can be served (this is for security reasons, else a browser user could request any file he liked from a servers file system).
Rewrites to any folder higher up than www will fail, you can only rewrite to a folder within www.

I understand this in a public environment, but im just using this for a local testing environment. Well, thanks for the response, was hoping to find an npm module which allowed me to do that, seems noone allows this. Due to your answer i now hacked it together like this, which is enough for my use case:
const http = require('http');
const fs = require('fs');
const mime = require('mime');

http.createServer(function (request, response) {
    var filePath = request.url;

    if (filePath === '/') {
        filePath = 'www/index.html';
    } else if (filePath.substr(0, 8) === '/assets/') {
        filePath = '../Core' + filePath;
    } else {
        filePath = 'www' + filePath;
    }

    if (!fs.existsSync(filePath)) {
        response.writeHead(404);
        response.end();
    } else {
        fs.readFile(filePath, function (error, content) {
            response.writeHead(200, {'Content-Type': mime.getType(filePath)});
            response.end(content, 'utf-8');
        });
    }
}).listen(8080);

yes, that will do it.
Another solution is to create symlinks under the www directory to folders located elsewhere in the filesystem, then create redirects to resources under the symlink.  E.g.
$ cd www
$ ln -s ../core/something

You now have a www/something path you can re-route to.
The only other way i can think to solve it is to run ws twice, once in each location. So run one server like this (folder names may vary):
$ ws --directory www --port 8000 --redirect '/assets/* -> http://localhost:8010/'

Another server like this.
$ ws --directory core --port 8010

I've used both these techniques in the past.


glue.auto.vars

@gpacix - addressed the issues with the PR.  Will you approve when you get the chance?