Clean up debug connection information

Codecov Report
Attention: Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.

Project coverage is 48.89%. Comparing base (6bf0732) to head (ad118aa).

Files with missing lines
Patch %
Lines

libs/base/src/ecflow/base/ssl_connection.cpp
0.00%
3 Missing :warning:

libs/base/src/ecflow/base/Connection.cpp
0.00%
2 Missing :warning:

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #142   +/-   ##
========================================
  Coverage    48.88%   48.89%
========================================
  Files         1188     1188
  Lines        98304    98305    +1
  Branches     14745    14745
========================================
+ Hits         48059    48065    +6
+ Misses       50245    50240    -5

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Make tegola config generator more generic

Hi Russss, this PR to make Tegola config generator more generic and allow to build several tegola configs on the same project.
It involves an additional tegola.yml file to use different cache paths, different ports and different db if required.
It allows to use a layer in several map as well with layers.yml like:
- name: power_line
    map:
      - openinframap
      - gespot

Looks reasonable, thanks!


body_behavior: find a way to determine whether we stopped walking

There are (at least) two ways to do this:

Add a binary message that is published by the walking.
Use the move_base action interface instead of the message interface.

It is possible to subscribe to /robot_state and check whether the state is WALKING

It is possible to subscribe to /robot_state and check whether the state is WALKING

This was implemented in be02314d064a5059dc40278fa0e6c3e8c1f63ef4


mono-2.0-bdwgc.dll crash

unity 2018.4.36f
Mono Mode is Process Crashed
UnityResolve::Init(GetModuleHandle(L"mono-2.0-bdwgc.dll"), UnityResolve::Mode::Mono);

i tried to fix this, but failed :D

Most crashes come from within Unity, and currently there is no better way other than using SEH.


Adds styles and behaviour changes in response to user discussions

Note that issues with hamburger icon and placement of stages bar is inherited from current production code:

"Back to..." instead of "Return"


Add healthcheck

See https://github.com/drud/ddev-pdfreactor/pull/10#issuecomment-1201476333

Yes, ddev waits for the healthcheck, so the healthcheck is probably a better approach to solve the test problems. It will likely solve some user problems as well.

@rfay Okay 👍🏼  Than I will merge it and create a new release 😃


[SPARK-15753][SQL] Move Analyzer stuff to Analyzer from DataFrameWriter

What changes were proposed in this pull request?
This patch moves some codes in DataFrameWriter.insertInto that belongs to Analyzer.
How was this patch tested?
Existing tests.

Test build #59926 has started for PR 13496 at commit 83b2e6e.

Test build #59926 has finished for PR 13496 at commit 83b2e6e.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/59926/
Test FAILed.

Test build #59931 has started for PR 13496 at commit c809cc6.

Test build #59931 has finished for PR 13496 at commit c809cc6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/59931/
Test PASSed.

cc @cloud-fan @yhuai

also cc @rxin

ping @cloud-fan @rxin again this should be simple, can you take a look quickly? Thanks.

LGTM except one minor comment, thanks for working on it!

Test build #60183 has started for PR 13496 at commit 6888e0a.

Test build #60183 has finished for PR 13496 at commit 6888e0a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/60183/
Test PASSed.

Merged build finished. Test PASSed.

Test build #60206 has started for PR 13496 at commit 40a7f31.

LGTM, cc @liancheng

Test build #60206 has finished for PR 13496 at commit 40a7f31.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/60206/
Test PASSed.

ping @liancheng

try to ping @yhuai

LGTM, merging to master and branch-2.0. Thanks!


World context ignored after server change

Description
I run a couple of servers behind Velocity and want to use the RememberMe plugin to auto connect to the last connected server. But that also causes players to get connected into the lobby on a reconnect if they got sent there due to the actual game server going down.
I wanted to fix this by introducing a new permission to RememberMe rememberme.notracking which would be true for the lobby server.
Without any contexts set on the permission my modification of RememberMe works as expected: it doesn't track any server changes at all.
With a context for world=lobby however it would still track players in the lobby. I also adding the permission for every server with the corresponding context to check if that would disable the tracking again but it didn't.
When checking for the permission ingame it showed correctly.
Reproduction steps

Velocity server setup with 2 backend servers
LuckPerms installed on the Velocity server
Compile the modified RememberMe from here and install it on Velocity
Set the permission rememberme.notracking to true with corresponding contexts to test
Use /lpv user USERNAME meta info to check the last-server info

Expected behaviour
Respect the permissions context even immediately after a server change.
Environment details

Server type/version: Velocity version 3.0.0
LuckPerms version: v5.3.57

Any other relevant details
The server context is not ignored (but is not useful since its only 1 "server" aka proxy)
Code responsible for the behaviour in RememberMe:
@Subscribe
public void onServerChange(ServerConnectedEvent serverConnectedEvent) {
    if (!serverConnectedEvent.getPlayer().hasPermission("rememberme.notracking")) {
        handler.setLastServerName(serverConnectedEvent.getPlayer().getUniqueId(), serverConnectedEvent.getServer().getServerInfo().getName());
    }
}

Using verbose to further inspect this issue indeed confirms that at the time when the permission gets checked neither the old nor the new world context are set.
https://luckperms.net/verbose/bwjkR0UD8f
note: I changed the onServerChange eventlistener to @Subscribe(order = PostOrder.LAST) but this didn't change anything.
Is there some way I can properly wait for LuckPerms to update contexts after a server change?

It should be invalidating when that event fires.
https://github.com/lucko/LuckPerms/blob/master/velocity/src/main/java/me/lucko/luckperms/velocity/context/VelocityPlayerCalculator.java#L74
Does serverConnectedEvent.getPlayer().getCurrentServer().getServerInfo() return the expected value during that event?

Ah, I see - we should both (I think) be using ServerPostConnectEvent.

Can confirm that this fixed it.
(I also changed the event on the rememberme plugin to ServerPostConnectEvent)
https://luckperms.net/verbose/FoyJGysUqw


Should Cesium.ExtrapolationType.HOLD consider last known orientation?

I'm using a SampledPositionProperty for position, VelocityOrientationProperty for orientation, and a forwardExtrapolationType of Cesium.ExtrapolationType.HOLD to model the movement of a 3D entity. Once the time advances past the window of sample data, I would expect the HOLD to maintain not only position, but also last known orientation (with zero velocity and acceleration).  It seems to only hold the last position, while returning orientation to default.
In my case, I'm calculating waypoints on the fly (which takes <1 second), but there is sometimes a gap where my entities reach the last sample before I can add a new future sample.  This results in the entity pausing at the last sample and waiting for the next sample to arrive (which is what I would expect), but the reset of orientation to default causes the motion to look less smooth as the entity briefly faces in the default heading.
Am I doing this incorrectly?  Or is there a way to specify that the HOLD applies not only to position but also last know orientation?

Hello, is there a solution to this problem, I also encountered this problem. @Mendanbar

Orientation is independent of position but can be made to match.  Assuming you are using SampledProperty to defined orientation, set the entity.orientation property to use the same extrapolation settings as you are setting for entity.position.
Sorry the original post here never went answered, we recommend posting to our forum, https://community.cesium.com, for help like this because it will most likely get a faster response.


Use from command palette

This PR makes the extension work from the command palette, where there is no PathObj passed in by VSCode. It also hides the "open from explorer" variant of the commands from the command palette.

I don't have write/commit permissions to merge it, but thanks for the review and catching that debugger!

Published a new version that includes this change :shipit:
Thanks again for the fix!


Sticky scroll and centered Layout retains width of full-screen editor

Type: Bug
Somehow when switching to Centered Layout the contained editor retains the width of the expanded editor. This happens in or after full-screen mode. The result is annoying horizontal scrolling even though there's no need because lines are not that long.
VS Code version: Code 1.85.0 (Universal) (af28b32d7e553898b2a91af498b1fb666fdebe0c, 2023-12-06T18:18:04.614Z)
OS version: Darwin arm64 23.2.0
Modes:

System Info

Item
Value

CPUs
Apple M2 (8 x 24)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
2, 2, 1

Memory (System)
24.00GB (0.72GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (12)

Extension
Author (truncated)
Version

Bookmarks
ale
13.4.2

todo-tree
Gru
0.0.226

git-graph
mhu
1.30.0

remote-ssh
ms-
0.107.1

remote-ssh-edit
ms-
0.86.0

remote-explorer
ms-
0.4.1

rust-analyzer
rus
0.3.1766

crates
ser
0.6.5

rewrap
stk
1.16.3

even-better-toml
tam
0.19.2

errorlens
use
3.15.0

vscode-lldb
vad
1.10.0

(1 theme extensions excluded)

/gifPlease

Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, .gif files are preferred as they are displayed inline on GitHub. You may find https://gifcap.dev helpful as a browser-based gif recording tool.
If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording (Developer: Toggle Screencast Mode in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue.
Happy coding!

I narrowed it down to "editor.stickyScroll.enabled": true. Just setting this in a vanilla vscode (1.85.1) will reproduce it. Switching full-screen mode, centered mode and between two two open editors will quickly make the horizontal scrollbar appear (I don't know yet which order) and the editor can be scrolled horizontally as if it's still non-centered and in full screen.

Centered editor layout does not change the width of the text editor, only the outer container.

The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our issue reporting guidelines.
Happy Coding!

Again, there's no content there, lines are hard-wrapped at 80 columns. There's no reason to scroll horizontally. The line 157 you see in the screenshot is the longest and there's nothing in the sticky scrolling area that requires horizontal scrolling this far to the right.

Ok reopening for Aiday to consider if this is indeed related to sticky scroll.
Can you give exact steps how you reproduce this with which editor contents?

Open VSCode in regular windowed mode (MacOS) without centered layout.
Put the following into settings.json:{
   "editor.stickyScroll.enabled": true,
}

Open some structured file where sticky scrolling is used, like this main.rs:fn main() {
    //
    //
    //
    //
    //
    //
    //
    //
    //
    //
    //
    //
}

If necessary, widen the window horizontal so that there's no horizontal scrollbar.
Scroll down in main.rs a bit so that fn main() { moves into the sticky scroll area.
(Shrink window vertically, if necessary.)
Enable centered layout.
Now you should see a vertical scrollbar and you can scroll to right.

This works 100% for me. Turns out that going into full-screen mode is not even needed. If you skip step 5 everything is okay.

Hi thank you for posting the steps needed to reproduce the issue. I tried the steps but I was not able to reproduce the issue. You can find below a GIF showing my steps:
https://github.com/microsoft/vscode/assets/61460952/c93e3ed0-80ad-451a-a835-bbd8654eded8
Could you post below a screen recording of you following the same steps?

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.
Happy Coding!

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Document Messaging class

Documentation on all classes is important.
However it seems critical that this class in particular is documented. IN particular the send method is a critical piece of the Verida API that has many options.
Please add @kalanamt and @tahpot to the review when this is done.

@nick-verida
It turns out messaging is documented: https://github.com/verida/verida-js/blob/e3fb778c510a6f148013c32ee177fb3fe7476ae2/packages/client-ts/src/context/messaging.ts#L26
Do we have auto-deployment of API docs in place?

No, auto-deployment of API docs isn't in place.
We need to keep docs synced to the code releases, and both are manual at the moment.
I'd like to see both of these things automated, but not sure what the release process for the code is at the moment.
There is a script in client-ts to generate and redeploy the docs: https://github.com/verida/verida-js/blob/main/packages/client-ts/generate-and-deploy-docs.sh
I'll run this now.

Hmm @tahpot none of those annotations docs are showing up in the docs.
Further investigation is required...

This is now fixed


⚠ Bofrost.de has degraded performance

In 6ee3bfd, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1875 ms

Resolved: Bofrost.de performance has improved in 25d99f9 after 13 minutes.


LAPACK test failures with NVHPC 23.7

Hi,
I am trying to build OpenBLAS using

NVHPC 23.7
CUDA 12.1.1

Environment variables:

CFLAGS -O2 -tp=host -Mflushz
CXXFLAGS -O2 -tp=host -Mflushz
FCFLAGS -O2 -tp=host -Mflushz
FFLAGS -O2 -tp=host -Mflushz
F90LAGS -O2 -tp=host -Mflushz

while running the LAPACK test suite with
make lapack-test  BINARY='64'  CC='nvc'  FC='nvfortran'  MAKE_NB_JOBS='-1'  USE_OPENMP='1'  USE_THREAD='1'

after a minor patch to the Makefile inside lapack-netlib/INSTALL/Makefile by adding -Mnomain to the testlsame and testsecond build recipes (to solve a multiple definition of `main' error) (Not sure if this is worth a separate issue, if the test there is wrongly compiling C sources for Fortran exes or if it is supposed to be like that and the compiler would normally automatically disable the fortran main when needed)
i was able to  get it to complete but i get several numerical (and also other) failures tested with the following versions of OpenBLAS.

0.3.23

			-->   LAPACK TESTING SUMMARY  <--
SUMMARY             	nb test run 	numerical error   	other error
================   	===========	=================	================
REAL             	1108743		286	(0.026%)	0	(0.000%)
DOUBLE PRECISION	1255005		280	(0.022%)	0	(0.000%)
COMPLEX          	762259		153	(0.020%)	0	(0.000%)
COMPLEX16         	699834		350	(0.050%)	0	(0.000%)

--> ALL PRECISIONS	3825841		1069	(0.028%)	0	(0.000%)

0.3.24

			-->   LAPACK TESTING SUMMARY  <--
SUMMARY             	nb test run 	numerical error   	other error
================   	===========	=================	================
REAL             	1108743		286	(0.026%)	0	(0.000%)
DOUBLE PRECISION	1255005		280	(0.022%)	0	(0.000%)
COMPLEX          	746859		189	(0.025%)	0	(0.000%)
COMPLEX16         	684434		386	(0.056%)	0	(0.000%)

--> ALL PRECISIONS	3795041		1141	(0.030%)	0	(0.000%)

0.3.27

			-->   LAPACK TESTING SUMMARY  <--
SUMMARY             	nb test run 	numerical error   	other error
================   	===========	=================	================
REAL             	1108743		37171	(3.353%)	0	(0.000%)
DOUBLE PRECISION	1255005		37165	(2.961%)	0	(0.000%)
COMPLEX          	762259		1448	(0.190%)	0	(0.000%)
COMPLEX16         	671348		37391	(5.570%)	14	(0.002%)

--> ALL PRECISIONS	3797355		113175	(2.980%)	14	(0.000%)

What is your cpu here (and does it help if you leave out the -tp host and/or -Mflushz) ? The LAPACK testsuite is a bit fragile with respect to optimizations, but seeing this many deviations is unusual.

As an updated this is with -O2 -tp=zen, so i guess -tp=host is picking up the correct architecture as it gives the same result
                        -->   LAPACK TESTING SUMMARY  <--
SUMMARY                 nb test run     numerical error         other error
================        ===========     =================       ================
REAL                    1328283         36885   (2.777%)        0       (0.000%)
DOUBLE PRECISION        1329105         36885   (2.775%)        0       (0.000%)
COMPLEX                 779587          16929   (2.172%)        0       (0.000%)
COMPLEX16               752168          37135   (4.937%)        14      (0.002%)

--> ALL PRECISIONS      4189143         127834  (3.052%)        14      (0.000%)

Test results are basically the same when one builds https://github.com/Reference-LAPACK/LAPACK (from which almost all LAPACK in OpenBLAS is imported) with NVHPC - the big jump in numerical errors comes about from the addition of the ?GEQP3RK functions ( truncated QR with column pivoting, https://github.com/Reference-LAPACK/lapack/pull/891 ) in LAPACK-3.12 that was picked up by OpenBLAS 0.3.26

?GEQP3RK failures can probably be fixed by applying https://patch-diff.githubusercontent.com/raw/Reference-LAPACK/lapack/pull/961.diff (which I thought I had merged already, but apparently hadn't - note that the PR is still open as there appear to be more problems with these tests)

Testing results with NVHPC 24.3 after applying the current version of PR 961
                        -->   LAPACK TESTING SUMMARY  <--
SUMMARY                 nb test run     numerical error         other error
================        ===========     =================       ================
REAL                    1347924         298     (0.022%)        0       (0.000%)
DOUBLE PRECISION        1252821         58584   (4.676%)        0       (0.000%)
COMPLEX                 1002430         159     (0.016%)        0       (0.000%)
COMPLEX16               914135          425     (0.046%)        18      (0.002%)

--> ALL PRECISIONS      4517310         59466   (1.316%)        18      (0.000%)

and
                        -->   LAPACK TESTING SUMMARY  <--
SUMMARY                 nb test run     numerical error         other error
================        ===========     =================       ================
REAL                    1347924         298     (0.022%)        0       (0.000%)
DOUBLE PRECISION        1494186         316     (0.021%)        0       (0.000%)
COMPLEX                 959365          159     (0.017%)        0       (0.000%)
COMPLEX16               914135          425     (0.046%)        18      (0.002%)

--> ALL PRECISIONS      4715610         1198    (0.025%)        18      (0.000%)

after fixing the obviously unintentional commenting of the fix for the double precision case, as mentioned in the discussion thread for this PR)

Corresponding results with GCC 13.2
                        -->   LAPACK TESTING SUMMARY  <--
SUMMARY                 nb test run     numerical error         other error
================        ===========     =================       ================
REAL                    1569648         0       (0.000%)        0       (0.000%)
DOUBLE PRECISION        1570470         0       (0.000%)        0       (0.000%)
COMPLEX                 979363          5       (0.001%)        0       (0.000%)
COMPLEX16               994955          91      (0.009%)        62      (0.006%)

--> ALL PRECISIONS      5114436         96      (0.002%)        62      (0.001%)

and some of these failures may be related to further inconsistencies in the test that are addressed by Reference-LAPACK PR 1005

I just tested with the mentioned patch (both as is and without the 3 commented lines and i can confirm i can reproduce the lower number of errors.
Thanks, fell free to close the issue or keep it open to track the merging of the LAPACK PR
Patch as is
                        -->   LAPACK TESTING SUMMARY  <--
SUMMARY                 nb test run     numerical error         other error
================        ===========     =================       ================
REAL                    1569648         0       (0.000%)        0       (0.000%)
DOUBLE PRECISION        1329105         58268   (4.384%)        0       (0.000%)
COMPLEX                 1021282         24      (0.002%)        0       (0.000%)
COMPLEX16               993863          250     (0.025%)        14      (0.001%)

--> ALL PRECISIONS      4913898         58542   (1.191%)        14      (0.000%)

uncommented lines
                        -->   LAPACK TESTING SUMMARY  <--
SUMMARY                 nb test run     numerical error         other error
================        ===========     =================       ================
REAL                    1569648         0       (0.000%)        0       (0.000%)
DOUBLE PRECISION        1570470         0       (0.000%)        0       (0.000%)
COMPLEX                 1021282         24      (0.002%)        0       (0.000%)
COMPLEX16               993863          250     (0.025%)        14      (0.001%)

--> ALL PRECISIONS      5155263         274     (0.005%)        14      (0.000%)


Change to "--framework netcoreapp2.1"

Turns out netcoreapp3.0 creates a test bot that does not work. Specifying 2.1 does work.

Pull Request Test Coverage Report for Build 98959

0 of 0   changed or added relevant lines in 0 files are covered.
1922 unchanged lines in 267 files lost coverage.
Overall coverage decreased (-1.6%) to 77.829%

Files with Coverage Reduction
New Missed Lines
%

/libraries/Adapters/Microsoft.Bot.Builder.Adapters.Facebook/FacebookAdapterOptions.cs
1
86.67%

/libraries/integration/Microsoft.Bot.Builder.Integration.ApplicationInsights.Core/ApplicationBuilderExtensions.cs
1
71.43%

/libraries/Microsoft.Bot.Builder.AI.LUIS/LuisApplication.cs
1
96.36%

/libraries/Microsoft.Bot.Builder.AI.LUIS/V3/LuisApplication.cs
1
96.43%

/libraries/Microsoft.Bot.Builder.AI.LUIS/V3/LuisUtil.cs
1
96.35%

/libraries/Microsoft.Bot.Builder/BotStateSet.cs
1
85.0%

/libraries/Microsoft.Bot.Builder.Dialogs.Adaptive/Actions/BaseInvokeDialog.cs
1
90.0%

/libraries/Microsoft.Bot.Builder.Dialogs.Adaptive/Actions/Case.cs
1
87.5%

/libraries/Microsoft.Bot.Builder.Dialogs.Adaptive/ActionState.cs
1
50.0%

/libraries/Microsoft.Bot.Builder.Dialogs.Adaptive/Generators/TemplateEngineLanguageGenerator.cs
1
87.1%

Totals

Change from base Build 98951:
-1.6%

Covered Lines:
20774

Relevant Lines:
26692

💛  - Coveralls

:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.Luis.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.QnA.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.ApplicationInsights.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Azure.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Dialogs.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.ApplicationInsights.Core.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.AspNet.Core.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.TemplateManager.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Testing.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Configuration.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Connector.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Schema.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Streaming.dll compared against version 4.6.3


cdc_acm example doesn't work on nrf52840_pca10059

Describe the bug
CDC_ACM example doesn't work in nrf52840_pca10059.  The USB device doesn't appear.
To Reproduce
I build using the workaround in #14945:

west build -d build/nRF52/mcuboot -s mcuboot/boot/zephyr -b nrf52840_pca10059 -- -DCONFIG_FLASH_LOAD_OFFSET=0x1000 -DCONFIG_FLASH_LOAD_SIZE=0xf000
west build -d build/nRF52/cdc_acm -s zephyrproject/zephyr/samples/subsys/usb/cdc_acm -b nrf52840_pca10059 -- -DCONFIG_FLASH_LOAD_OFFSET=0x10000 -DCONFIG_FLASH_LOAD_SIZE=0x5E000
west sign  -d build/nRF52/cdc_acm/ -t imgtool -- --key mcuboot/root-rsa-2048.pem
Load build/nRF52/mcuboot/zephyr/zephyr.hex and zephyr.signed.hex simultaneously with nRF Connect app.

Expected behavior
A device appears in lsusb output.  A tty device appears as /dev/ttyACM*
Actual behavior
No device appears in lsusb.  No USB messages appear in dmesg.
Impact
I am stuck in my development without a working serial port.
Environment

OS: Ubuntu 18.04
Toolchain: zephyr-sdk-0.10.0
Commit: c3cf543452ca57c37e5ffb2a06731f23ed9d297e

Here's backtrace:
#0  0x00017edc in cdc_acm_line_ctrl_get (dev=0x20003764 <__device_cdc_acm_0>,
    ctrl=4, val=0x2000239c <_main_stack+980>)
    at /home/markrages/zephyr/zephyrproject/zephyr/subsys/usb/class/cdc_acm.c:878
#1  0x0001154c in z_impl_uart_line_ctrl_get (val=0x2000239c <_main_stack+980>,
    ctrl=4, dev=0x20003764 <__device_cdc_acm_0>)
    at /home/markrages/zephyr/zephyrproject/zephyr/include/uart.h:1112
#2  uart_line_ctrl_get (ctrl=4, val=0x2000239c <_main_stack+980>,
    dev=0x20003764 <__device_cdc_acm_0>)
    at zephyr/include/generated/syscalls/uart.h:41
#3  main ()
    at /home/markrages/zephyr/zephyrproject/zephyr/samples/subsys/usb/cdc_acm/src/main.c:89

Waiting for DTR is like #13662. Except I am sure the device is plugged in to USB -- that's how I loaded the code.

Except I am sure the device is plugged in to USB -- that's how I loaded the code.

micro USB connector labeled as "nRF USB" is also connected to the host?

@jfischer-phytec-iot the '59 is the dongle, see picture on this unrelated bug: https://github.com/NordicSemiconductor/pc-nrfconnect-programmer/issues/116#issuecomment-477321052

So, this worked once.
I did the git bisect dance, and learned two things:

usb is not working with the #1495 workaround. Instead compile with west build -d $BUILDDIR -s $SOURCEDIR -b nrf52840_pca10059 -- -DCONFIG_FLASH_LOAD_OFFSET=0x1000 -DCONFIG_FLASH_LOAD_SIZE=0x1f000
cdc_acm example works before 5977b3db2f29d169adcf032149be4cab94964829, and is broken from then on.

Tested with reel board and frdm-k64f, works fine.

Hi @markrages, could you please check if https://github.com/zephyrproject-rtos/zephyr/pull/14978 fixes this issue. Thank you.

@lemrey yes, #14978 fixes it.

The #14945 workaround did not work for USB example, I assume because https://github.com/zephyrproject-rtos/zephyr/pull/14875

@markrages is this one fixed too by #14875? If so, could you please close it? Thanks!

Everything appears to work with #14978 and #14875 merged.


#3476 Fix ADS dropdown flickering

#3476
Fix dropdowns flickering every other time they're opened. The hide message code was being invoked which called hideContextView (the actual dropdown part) even if no message was ever displayed. Now we'll delay setting the message to null and only call hideContextView if we actually had a message to display.
Also fixed small issue where messages that didn't have a container would throw an error when trying to call removeClass (since this.element is pulled from the container and thus was undefined.
Tested that the flicker is gone and that messages still show up correctly

Y
E
S


Update empack

Looks like this will require a new release of jupyterlite-xeus-python as it seems to be breaking at the moment:
https://readthedocs.org/projects/scipy-2022-jupyterlite-virtual-poster/builds/17286700/
TypeError: pack_python_core() missing 1 required positional argument: 'download_emsdk'

Yes 👍🏽 Pushing a jupyterlite-xeus-python release this morning

Sorry for the inconvenience


ModuleNotFoundError: No module named 'mmcv._ext'

I did 'pip install mmcv-full=1.3.6'

I checked the 'conda list' that mmcv-full was installed as shown in the picture. Afterwards, the demo file was run, and the error "no moule named 'mmcv_ext'" appeared as follows. How do we solve this?

Did you try to reinstall the mmcv?

yes, I tried it many time

You can try to install a higher version of MMCV, and then test whether the runtime version is the version just installed.
I guess there is a problem with path coverage.

sorry I don't understand "and then test whether the runtime version is the version just installed.
I guess there is a problem with path coverage."
I tried install mmcv=1.3.8 but it also failed
Do you have any recommendations about versions? Cudatoolkit, pytorch, torchvision, mmcv, all of them.

'tail' is not recognized as an internal or external command,
operable program or batch file.
'gcc' is not recognized as an internal or external command,
operable program or batch file.
sys.platform: win32
Python: 3.7.11 (default, Jul 27 2021, 09:42:29) [MSC v.1916 64 bit (AMD64)]
CUDA available: True
GPU 0: GeForce GTX 980
CUDA_HOME: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2
NVCC: Not Available
GCC: n/a
PyTorch: 1.7.0
PyTorch compiling details: PyTorch built with:

C++ Version: 199711
MSVC 192729112
Intel(R) Math Kernel Library Version 2020.0.0 Product Build 20191125 for Intel(R) 64 architecture applications
Intel(R) MKL-DNN v1.6.0 (Git Hash 5ef631a030a6f73131c77892041042805a06064f)
OpenMP 2019
CPU capability usage: AVX
CUDA Runtime 10.2
NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_61,code=sm_61;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_37,code=compute_37
CuDNN 7.6.5
Magma 2.5.3
Build settings: BLAS=MKL, BUILD_TYPE=Release, CXX_FLAGS=/DWIN32 /D_WINDOWS /GR /EHsc /w /bigobj -openmp:experimental -DNDEBUG -DUSE_FBGEMM -DUSE_VULKAN_WRAPPER, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, USE_CUDA=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=OFF, USE_NNPACK=OFF, USE_OPENMP=ON,

TorchVision: 0.8.0
OpenCV: 4.5.3
MMCV: 1.3.12
MMCV Compiler: n/a
MMCV CUDA Compiler: n/a
MMDetection: 2.13.0+a8c681d
(mmcv_cpu3) PS C:\Users\kim\Desktop\mmcv_cpu2\mmdetection> nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2019 NVIDIA Corporation
Built on Wed_Oct_23_19:32:27_Pacific_Daylight_Time_2019
Cuda compilation tools, release 10.2, V10.2.89
**use mmdet.utils.collet_env.py, I got that output.
I don't think I told you that I'm going to install it on Windows 10. I'm sorry.
I know mmdetection supports experiments on Windows. Still, I've seen a lot of people succeeding in running demo.py files on Windows 10.
I think the mmcv._ext installation is not working well on Windows 10. The first error relates to that.
And I've also tried to build mmcv as a source, but there's an error in _ext.
Please recommend the versions available in Windows 10.**

Ok, I suggest you create an issue in MMCV and Quote this issue.

I already opened ISSUE in MMCV.
However, I succeeded in running the DEMO file by installing the latest version.
Thank you.


Lzmq not found by Lua

I have some trouble integrating lzmq into my lua script, which is called by the Lua/C++ API.
I use Lua version 5.4 under Ubuntu 20.04.
This is my Lua Code:
#!/usr/local/bin/lua

local function test()
	local lzmq = require "lzmq"
end

local ok, err_msg = pcall(test, 42)
if not ok then
    print(err_msg)
end

This prints the following error message:
error loading module 'lzmq' from file '/usr/local/lib/lua/5.4/lzmq.so':
/usr/local/lib/lua/5.4/lzmq.so: undefined symbol: lua_checkstack
lzmq is located under /usr/local/lib/lua/5.4/.
I use the following C++ code to load and execute my Lua file:
#include <iostream>
#include <lua.hpp>

using namespace std;

lua_State* L;

int main()
{
	L = luaL_newstate();
	luaL_openlibs(L);
        luaL_dofile(L, "controller.lua");
        lua_close(L);
        cout << "Error? " << error << endl;
}

What can be the reason for this error?

Seems like I could resolve the issue by switching Lua to version 5.3.6.
I guess it is a compatibility issue with the newest Lua version (5.4.2), and some functions/symbols were removed from Lua.
This should explain the error message discussed above.

How did you compile lzmq library? I did not test lzmq with Lua 5.4, but I expect it should work. Also, I believe that lua_checkstack stay intact in the Lua 5.4.

I think I installed it via luarocks and moved the .so files manually to /usr/local/lib/lua/5.3. This is included in my cpath, where Lua 5.3.6 looks for modules. This way it worked for Lua 5.3, but not for 5.4...

I think I installed it via luarocks and moved the .so files manually to

This should not work for any Lua module written on C (or ny other compiled language)
Lua module have to build against correct Lua version.
If you whant to try lzm wit the Lua5.4 you can download rockspec file an updete version in there. There high chance that it works. Ofcourse you have to have LuaRocks configured for Lua 5.4

Okay, thank your for your assistance so far. I'm happy at the moment, maybe I will try it with 5.4 later again.

 apt-get install libzmq3


OK! this bug should now be fixed in the latest release. Update your theme and let me know if the font size slider doesn't work! Closing for now :)

Changing the font size in Settings -> Appearance has no effect, the font size in preview as a whole remains the same.but font-size in edit mode is changed
Applies for desktop 0.13.14. Theme version is latest

I can confirm it's still having no effect for me in reading view, confirmed latest version of theme and latest non-Insider version of Obsidian.

This issue still is present for mobile -- at least on iOS.

I just pushed an update yesterday. Can you try now and see if the font size slider in "Appearance" is working?

Yep, the font size is consistent, thanks!


Rename normalize -> normalized in linear referencing functions

This PR renames the argument normalize to normalized for line_locate_point and line_locate_point linear referencing functions. This brings the argument name in-line with Shapely (see object.interpolate and object.project) and the underlying GEOS functions GEOSProjectNormalized_r and GEOSInterpolateNormalized_r.

One question is if the former "normalize" keyword argument should be supported/deprecated (as is currently implemented via **kwargs), or should the argument be simply renamed?

Thanks @mwtoews . I think it is good that this DeprecationWarning is in place, we can remove it on a major version bump (or when pygeos is merged into shapely)


PublishPipelineArtifact does not allow multiple uploads to the same artifact

Required Information
Entering this information will route you directly to the right team and expedite traction.
Question, Bug, or Feature?
Type: Feature
Enter Task Name: PublishPipelineArtifact
list here (V# not needed):
https://github.com/microsoft/azure-pipelines-tasks/tree/master/Tasks/PublishPipelineArtifactV1
Issue Description
This is more of a status update request because issues have been created an then closed after a comment saying something is happening.
I see there was a comment from @herenhuang saying that:

We're now tracking this request on our backlog to add functionality to the PublishBuildArtifacts task. No ETA right now but we can update when there is one.

I am just wondering if there has been any progress on this. I am also scared about the deprecation as maybe someone decides that it is a long time deprecate and stops maintaining it. And I have been seeing a bunch more publish and download failures on the old ones. So, just wondering what is happening .
Related issues closed due to inactivity:

https://github.com/microsoft/azure-pipelines-tasks/issues/14598
https://github.com/microsoft/azure-pipelines-tasks/issues/12480
https://github.com/microsoft/azure-pipelines-tasks/issues/16403

Just bumping this to keep it alive.

Did we accidentally lay off our Azure team? 😱

Is someone working on a solution for this?
It's a very common situation especially in scenarios bigger than a hello-world example.

We are also affected by this and need to know whether a fix is planned. We are blocked from restarting failed jobs and are forced to restart the entire pipeline because of this.
Being able to upload more files to existing artifacts would be nice to have – but as a simpler solution, we would like to be able to override the entire artifact when a collision occurs.

Yes, this feature will be helpful if people would like to updated the same artifact through different stages without changing the name of it in each stage that needs to use the updated artifact in previous version.

In order to parallelize the build of a large project, we split up the build into many small steps and use publish artifact to store the results.
But when the "main" build needs to run it needs to download every separate artifact with a unique name, resulting in many unique download steps that each download a couple of small files
my build would speedup allot being able to download 1 single larger artifact
i don't mind a "i-know-what-im-doing: this-is-can-cause-issues" flag
all the files im pushing to the artifact storage have their own unique names

Similar issue here. I want to be able to have a temporary file to gather all output reports across the pipeline and then use them at the end. I'm going to try using build artifacts for now, but this would be very nice for us and simplify (and DRY up) our pipeline.

Bump.

Bump

Bump

Same issue here, trying to gather all the testing reports from different jobs and publish to the artifact, is there any update?

Bump!

Bump


[BUG] AsyncSession.base_url uses domain instead of whole init path

Code:
from curl_cffi.requests import AsyncSession

BASE_URL = 'https://example.com/default'

async with AsyncSession(base_url=BASE_URL) as session:
    print(session.base_url)
    response = await session.get('/page', impersonate='chrome')
    print(response.url)

Output:
https://example.com/default
https://example.com/page

Expected output:
https://example.com/default
https://example.com/default/page

Versions

OS: macOS 15.0
curl_cffi version 0.7.1

What you described is actually the behavior of current httpx, which sliently adds an ending slash at the end of base url.
>>> import httpx
>>> c = httpx.Client(base_url="https://example.com/default")
>>> print(c.base_url)
https://example.com/default/
>>> r = c.get("/page")
>>> r.url
URL('https://example.com/default/page')
>>> r = c.get("")
>>> r.url
URL('https://example.com/default/')

Actually, I don't think httpx behaves correctly, with or without the ending slash can be totally different for some servers, I'm not sure that we should alter the url implicitly.
What curl_cffi did is a simple urljoin of the urls you provided, which is what httpx did originally, and I found it is more simple and aligns with the stdlib.
If you want to build an url as what you expected above, you should change your url to:
BASE_URL = 'https://example.com/default/'  # note the ending slash
session.get('page')  # note there is NO leading slash

If you have more real world evidence that the current httpx behavior is actually more prevelant, feel free to reopen the issue.

I switched from httpx and got used to put slash at the beginning of each URL, and for some reason I didn't check slash at the end of base_url. I agree, it's better that way.


SWS/wol: Set selected envelope height to maximum not working correctly with Reaper v6

Before, it would center the maximized envelope in the arrange view. Now, in v6, last SWS, it does not.

Closing as duplicate of #1240.


Temporal fusion

Hi,
It's me again. I've noticed you have some parts of the code containing functions for training with previous frames. Have you run some tests with these and could share some numbers on them?
Best regards,
Pham

Hello, we have debugged it earlier, so it should work properly. However, we haven't conducted any experiments or obtained any results for it yet.

Thanks for the quick response xD


OctopOS Prime Mascot Design-21

Make an OctopOS Prime mascot with the concept you want.
Page size should be 1080x1080.


add control for CRISPR (or other gene perturbation types)

Adding a gRNA control option for CRISPR experiments to more explicitly describe control samples.

@allaway I made some changes. You can confirm that this is better (?) and merge.


Metric size limit is much too small

I often get an error: Metric Document is too large, xxxxb is larger than the max metric size 3000b
I don't understand why there is a limit on the size of the metric document, and why it's so small. But it means that if I train for 400 epochs then the size of the list of loss values is too large to be uploaded on it's own. This fails the run after training and prevents other metrics being tacked, please add a kwarg to "log", "loglist" etc to allow continue on fail. Or even better please remove this limit and just charge me for the storage.
Also please add this limit to the documentation so that someone doesn't end up training for a whole weekend only to find they have no useful metrics to investigate.

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

ID: 9190938a-63d6-5b03-ff00-9bc3bf31e27f
Version Independent ID: 6e9f9c7d-69c3-0a20-f94f-710771255ec6
Content: Log ML experiments & metrics - Azure Machine Learning
Content Source: articles/machine-learning/service/how-to-track-experiments.md
Service: machine-learning
Sub-service: core
GitHub Login: @heatherbshapiro
Microsoft Alias: hshapiro

@AndrewLouw
Thanks for the feedback! We are currently investigating and will update you shortly.

@AndrewLouw  Thank you for reaching out again. I will forward this suggestion to product team. @heatherbshapiro  could you please also take a look of this issue? Thanks.

could you elaborate on how you log the loss? The intended way to log series is by calling run.log(key, value) repeatedly, in your case once per epoch.

I've been using log_list, so I can use graphing tools in the portal ui. Does the metric size limit apply to each individual metric? Or to the whole collection of metrics?

#reassign:@danielsc

@danielsc @nishankgu - any response here?

#reassign:@rastala @wbaumann-microsoft
Can you help here please?

There was a similar question on Stack Overflow: the answer is to break the list of metrics into smaller pieces, and let service concatenate them.
https://stackoverflow.com/questions/58691120/metric-document-is-too-large-in-azure-ml-service

@AndrewLouw did this help answer your questions?

@AndrewLouw  The workaround to the issue has been documented and should go live in few hours. a We shall proceed to close this issue.
#please-close
If you feel that your issue has not been resolved, please reopen the documentation issue and provide additional context. For product issues, contact technical support.

@rastala where can I find the workaround documented? Also is there are plan of providing actual fix?

@madhuraprasanna please see this documentation:
https://docs.microsoft.com/en-us/azure/machine-learning/how-to-save-write-experiment-files#where-to-save-input-files

@madhuraprasanna please see this documentation:
https://docs.microsoft.com/en-us/azure/machine-learning/how-to-save-write-experiment-files#where-to-save-input-files

Thank you @nibaccam , but doc seems to point at the limit set for the script themselves, but I am interested in the limit set for the log/metrics(which is being discussed in the thread above)


Create Email List for users and developers of Beaker

Create public community email lists for users and/or developers of Beaker on google groups / nabble / or similar.
Creating an issue in github isn't the ideal way to surface this -- which is a nice example of why a mailing list is needed.
If a mailing list exists and I just missed it somehow, please point me to it as well as update the beaker website to reference it.

hi marc, there is no community email list, just the announcement email list. however the community can post here on github, on facebook, and on twitter, so I'm not convinced we need more places. for example, this github issue seems fine to me.  what do you feel like we are missing?
i do want to

there is currently no way to communicate with the beaker community at large for user questions or development discussion.
all the same reasons that these exist:
https://zeppelin.incubator.apache.org/community.html
https://groups.google.com/forum/#!forum/jupyter
http://spark.apache.org/community.html
etc.
in particular, user questions for "how do i do X?", "advice regarding Y?", "can't get X to work, help!" do not have a forum, especially in a way that is archived and searchable.
i believe the perceived lack of a community (and community support) is holding back adoption of beaker.
questions like this on StackOverFlow would have a proper channel: http://stackoverflow.com/questions/34769103/how-to-load-node-modules-in-beaker-notebook
and would not go unanswered.

github issues like this indicate demand:
https://github.com/twosigma/beaker-notebook/issues/3472

https://groups.google.com/forum/#!forum/beaker-user

great!

to be added as a link on http://beakernotebook.com/community ?

https://github.com/twosigma/beaker-notebook-www/commit/7688d3d1ad647cd03466fa6b32b832a9d738ba6d

thanks!


The HTMLEditorExtender cannot handle certain html tags

Suppose I put in some "MathML" tags (MathML produces mathematical formulas).  So I put:
<mrow class="MJX-TeXAtom-ORD">
<mstyle displaystyle="true" scriptlevel="0">
</mstyle>
</mrow>

The result, unfortunately, is this:
<mrow class="MJX-TeXAtom-ORD"</mstyle></mrow>

Notice that the end bracket is missing from the mrow tag, and the “mstyle” tag is gone completely.
When I click a SUBMIT button and read out the text into a variable, the contents of the variable have the messed-up result.
This means that the extender can’t handle language additions such as MathML (used to portray math formulas), and probably not SVG (vector graphics) either.
MathML is not supported by all browsers, and often people use JavaScript libraries to fudge a result that looks OK on those browsers.  But even if the A.C.T encounters new or unknown tags, they should be left as is,  as opposed to merging some and deleting others.
There are two views in the HTML Editor Extender – one of them is SOURCE view – that is how I pasted in the tags.
The above of course is just a snippet of math, a full formula (that it was taken from) looks like:
<math xmlns="http://www.w3.org/1998/Math/MathML" alttext="upper F left-parenthesis x right-parenthesis equals integral Subscript a Superscript x Baseline f left-parenthesis t right-parenthesis d t period">
<mrow class="MJX-TeXAtom-ORD">
<mstyle displaystyle="true" scriptlevel="0">
<mi>F</mi>
<mo stretchy="false">(</mo>
<mi>x</mi>
<mo stretchy="false">)</mo>
<mo>=</mo>
<msubsup>
<mo>?</mo>
<mi>a</mi>
<mi>x</mi>
</msubsup>
<mi>f</mi>
<mo stretchy="false">(</mo>
<mi>t</mi>
<mo stretchy="false">)</mo>
<mi>d</mi>
<mi>t</mi>
<mo>.</mo>
</mstyle>
</mrow>
</math>

So if I have a page with an extender as follows:
<asp:TextBox ID="TextBoxContents" runat="server" TextMode="MultiLine"
                 Height="500px" Width="900px" style="max-width:900px" ></asp:TextBox>

        <ajaxToolkit:HtmlEditorExtender ID="HtmlEditorExtender1"  EnableSanitization="false"
            TargetControlID="TextBoxContents" DisplaySourceTab="true"   runat="server">
          </ajaxToolkit:HtmlEditorExtender>
</asp:TextBox>

and  a SUBMIT button that submits the contents of the textbox – that’s when I run into the bug..
Is there any way to quickly fix this?

Hi @gidmeister2,
The issue lies in this line of code and there is no way to quickly overcome this behavior.

I would think that it could be fixed by replacing:
result = Regex.Replace(result, "[^<]<[^>]*script[^>]*>", "", RegexOptions.IgnoreCase | RegexOptions.ECMAScript); by something like: result = Regex.Replace(result, "[^<]<[\s]script[^>]>", "", RegexOptions.IgnoreCase | RegexOptions.ECMAScript);`
But I am not sure.  Or, the regex could be replaced by a custom function that is more specific.
I have forked the Ajax Control Toolkit and will try replacing the line, and see if it helps, but I would suggest that the main coders of the ACT take a look at it.

@gidmeister2  thank you for the advice, we'll take it into account.


Improvement: Button Hover effect and Cursor: pointer

Improvement

The Calculate button in the love calculator project don't have any hover effect and cursor pointer effect. It can be implemented easily by adding some CSS.


Chart should validate extensions config to avoid missing health_check

In case the extensions are defined in the values.yaml for the collector, then the health_check extension which is required will be omitted if the users do not explicitly include it. The result of this will be that the collector Pods will fail to become ready because the probe will never succeed. This is explained in detail at https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/29558#issuecomment-1831999316.
It would be nice if we could have a validation and fail on installation whenever the health_check is not present since the Collector Pods would fail to become ready anyways.

Filed https://github.com/open-telemetry/opentelemetry-helm-charts/pull/1070 for this.


Blazor - VS tooling fails to reflect a parameter type change

This issue has been moved from a ticket on Developer Community.

[severity:It's more difficult to complete my work]
Steps to reproduce:

Create a Blazor WASM app

Open Counter.razor and add:
[Parameter] public bool Foo { get; set; }

Use the Counter component recursively, i.e. in the same file, add:

Change the Foo type to int:
[Parameter] public int Foo { get; set; }

Change the Foo value to 10:

Build works, but the tooling keeps reporting an error, an Error List entry:
Severity	Code	Description	Project	File	Line	Suppression State
Error	CS1503	Argument 1: cannot convert from 'int' to 'bool'

Original Comments
Feedback Bot on 1/18/2021, 00:08 AM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Original Solutions
(no solutions)

@ryanbrandenburg Should we repurpose this issue or open a new issue to reflect your concerns above?


[jvm-packages] #2843 Add "round" and "objective" as model parameters

This is a simple patch that would address the problem in https://github.com/dmlc/xgboost/issues/2843. A new trait BoostingAlgorithmParams is created and holds other boosting-level (or ensemble-level) params (different from "booster" params) that should also be available in the model. XGBoostEstimator and XGBoostModel then mix in this trait so that the parameters are owned by both.
Obviously, there may be other parameters that should be transferred to the model, so we can discuss that here as well. If there is some design history that I've missed about why these parameters weren't copied originally, please let me know.

cc @xiaozhouwang

Codecov Report

Merging #2850 into master will increase coverage by <.01%.
The diff coverage is 93.33%.

@@             Coverage Diff             @@
##             master   #2850      +/-   ##
===========================================
+ Coverage     43.09%   43.1%   +<.01%
  Complexity      200     200
===========================================
  Files           151     152       +1
  Lines         11519   11522       +3
  Branches       1167    1167
===========================================
+ Hits           4964    4966       +2
- Misses         6225    6226       +1
  Partials        330     330

Impacted Files
Coverage Δ
Complexity Δ

...a/ml/dmlc/xgboost4j/scala/spark/XGBoostModel.scala
78.52% <100%> (ø)
24 <0> (ø)
:arrow_down:

...oost4j/scala/spark/params/LearningTaskParams.scala
91.3% <100%> (-1.8%)
0 <0> (ø)

.../dmlc/xgboost4j/scala/spark/XGBoostEstimator.scala
79.31% <100%> (ø)
20 <0> (ø)
:arrow_down:

...c/xgboost4j/scala/spark/params/GeneralParams.scala
94.73% <100%> (-0.51%)
0 <0> (ø)

...j/scala/spark/params/BoostingAlgorithmParams.scala
90.9% <90.9%> (ø)
0 <0> (?)

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 46f2b82...40ed2b6. Read the comment docs.

Initially, I thought it would be better to just add LearningTaskParams to the model as well, but it doesn't work because the parameter numClasses conflicts with the class member val numClasses for XGBoostClassificationModel. So, now BoostingParams and LearningTaskParams seem to cover common ground. We could probably rethink the organization of the params traits to make it clearer, but perhaps in another PR.

Hey @sethah do you plan to continue working on this PR or should we merge it as-is?

Are there any work-arounds at the moment? Can I dump the model and look at that array to tell the number of rounds?

Closing as inactive for more than six months


Add support for fingering and import it from MusicXML

This PR adds support for importing MusicXML fingering information and displaying it.
From the MusicXML spec it is not clear what is the expected valid content for the <fingering> element and what to do when a note has many <fingering>elements. Also, I do not have tests scores other than those created by myself. Thus, support is currently restricted to ‘expected’ and ‘logical’ combinations. Apart from numbers 1 to 5, also the fingering symbols included in SMuFL are supported (digits 0, 6 to 9, and some characters). Score 50060-fingering.xml.txt is an example of currently supported fingerings:

Other changes

Bravura.otf font file updated to latest version (1.392). Previous Bravura version (1.18) included with Lomse did not have glyphs for fingering.
Fixed bug: when a glyph did not exist in the font the score was displayed as a blank page. Now the score is rendered but the missing glyph is not displayed.
Class name ImoAttr renamed as AttrObj, as it is not an Imo but an auxiliary class
Destructor of AttrObj now deletes the list of attributes. ImoObj no longer does it.
Added regression test score 50060-fingering.xml

IMPORTANT

It is necessary to install the updated Bravura font. Otherwise, fingering will not be displayed. Apart from the Bravura.otf file included with Lomse, there is a .deb installer here.

If that would be of help, I have recently seen this score which has quite a lot of fingerings. However there doesn't seem to be anything unusual there: <fingering> tags contain just numbers as their content and sometimes placement as their attributes. I can search for more examples though if needed.

Thank you. I have downloaded it and tested and it is rendered fine. This PR deals with all normal cases for piano and my doubts are about other use cases.
The issue with <fingering> is that MusicXML documentation is not good and, thus, it is uncertain what to expect. I have open an issue ( https://github.com/w3c/musicxml/issues/437#issuecomment-985780017) and will wait for confirmation before merging this PR.

It seems that the clarifications from MusicXML developers will take some time.  Thus, I'm going to merge this.


Small understandability improvement in Pytorch basics

Hi!
First of all, really nice resource for learning pytorch and neural nets!
I am following your tutorial for preparing a short hands-on tutorial
During this process, I have identified a very small understandability issue here https://github.com/yunjey/pytorch-tutorial/blob/master/tutorials/00 - PyTorch Basics/main.py#L74
If understand correctly, your intention is to show how the loss goes down after the first opt step, but you do not make a new forward pass with the new weights, thus the loss is the same as previously. Making linear(x) either in the call or more explicitly reassigning pred = linear(x) would help to show how the loss is reduced. As I said, it is a minor issue but thought it might help!
Thank you!

Thanks, you're right. I fixed the code.


DLL files are not located in the correct directory

SlicerOpenVR depends on vtkRenderingOpenVR-8.1.dll and openvr_api.dll, but these are not copied to .<BUILD-DIR>\inner-build\lib\Slicer-4.9\qt-loadable-modules\Release\ by default.
Temporary workaround: Manually copy the following files into <BUILD-DIR>\inner-build\lib\Slicer-4.9\qt-loadable-modules\Release\

<BUILD-DIR>\bin\Release\vtkRenderingOpenVR-8.1.dll
<BUILD-DIR>\OpenVR\bin\win64\openvr_api.dll (on Windows, macOS will be different)

Do you still have a problem after specifying the additional launcher settings:
Copied from the README:
./Slicer.exe  --launcher-additional-settings C:\path\to\SlicerOpenVR-build\inner-build\AdditionalLauncherSettings.ini --additional-module-paths C:\path\to\SlicerOpenVR-build\inner-build\

This issue is duplicate of #2

Closing. Fixed in https://github.com/KitwareMedical/SlicerVirtualReality/pull/23


Configuration expansion

Config file validation with gopkg.in/go-playground/validator.v9
Expand config to include options to set major/minor labels
Expand config to include pre-release and full-release strategy types
Use logrus for logging
Package the github client in a releaser which takes care of release logic based on configuration

Support release strategy types in .ship-it

related to #19


Discuss and share general ADaM conventions (outside of Ophth assessments) + spec sharing

Background Information
Indicator of eye selected for study - What are we using in ADSL to denote this (if ADSL?)
Indicator of eye within Occurrence datasets - Eg. in ADAE/ADMH etc. to denote Study or Fellow Eye - What var do we use?
Definition of Done
No response

In our studies, we currently use the below,
ADSL.STUDYEYE - This is used to indicate LEFT/RIGHT/BILATERAL as the study selected eye
ADAE.AFEYE - This is used to decode AELAT (normally "LEFT", "RIGHT") to indicate either "STUDY EYE" or "FELLOW EYE"

Similarly for ADEX we have ADEX.AFEYE ('Study Eye' or 'Fellow Eye') coming from EXLAT ('LEFT' or 'RIGHT')

We also have this as above for ADPR (PRLAT used in the derivation for AFEYE in ADPR). Furthermore if we are producing ADMH we might want to consider targeted ophtha medical history terms with MHLAT.

In our study (PDS),
ADSL.STUDYEYE is used to indicate the selected study eye. The info is from SDTM.SC mapped from the eCRF Form: Study Eye Selection.
AFEYE is used in ADAE, ADEX, ADCM, ADPR, ADMH to indicated the affected eye based on ADSL.STUDYEYE, xxLOC and xxLAT


cant mate

my bot cannot mate KQ vs K
it also cant mate KR vs K
also KBN vs K
https://lichess.org/gs3MdtVgCwsw
https://lichess.org/Iu6OOPrHUQwm
https://lichess.org/WloZ4btBCN3M

no just the normal hyperchessbot

Yes it perhaps playing the increment is the way, but how come when it's like opening-middlegame my bot moves extremely fast? And then it slows down

For the "bot slows down" problems, there's an investigation going on here:
https://github.com/hyperchessbot/hyperbot/issues/8
Meanwhile if you want to check your latency to Heroku's US and EU servers, just visit this link, which will show you both upload speed and latency, and then you can use those values to adjust your Move Overhead settings:
https://cloudharmony.com/speedtest-for-heroku


DOC: Is it possible to check if a PDF is a valid PDF/A-1 or PDF/A-2?

Can I check with pdfminer.six if there is active content within the PDF?

Hi,
Very late reply.
The thing is: pdfminer.six is a package for extracting text from a PDF. It is not aimed at validating the content of the PDF. So, no, you cannot use pdfminer.six to check if PDF is valid PDF/A-1 or PDF/A-2. The best pdfminer.six can do is extract the version from the header. See Section 3.4.1 from the PDF reference.


Vote revealer doesn't work?

doesn't work for me, how bout you guys

it works, the output is in console

it should be on a tab. i dont check console when im playing game

Now Vote Revealer outputs to local chat


Issue 170 tag checks refactor

Breaking change

The current unused_tag now checks for tags defined in tags section but not used in any operation.
The new undefined_tag checks for tags used in operations but not defined in tags section (previous unused_tag behaviour)

Discussed in #170

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


HLS manifest parsing error

Hi,
(Player version: 3.2.4)
I created my video platform and testing video player with our video transcoding solution for HLS streaming. It works at Microsoft Edge and Chrome 57.0.2987.110, but it does not work in Firefox 51.0.1 and Chrome 56.0.2924.87, some computer with Chrome 57.0.2987.110 can't work too.
The error message is:
hlsError Object { type: "networkError", details: "manifestParsingError", fatal: true, url: "…", reason: "no EXTM3U delimiter" }
Video source URL: http://v2.dao365.video/1060322000004/1060322000004_playlist.m3u8
How to resolve it? or newer version can resolve it?
Thank you.

I'd suggest to try the master branch and see if it solves it. If not, I'll ask this on the HLS.js project. They will give you a more in-depth answer. Keep me posted

I updated to v4.0.2, but issue is still exists.

Yeah post this on https://github.com/video-dev/hls.js and see what they say. Keep me posted, please

Closing this issue since it's not related to plugin.


feat: yurthub automatically recognize nftables or iptables (#1135)

What type of PR is this?
/kind feature
What this PR does / why we need it:
Since CentOS8, nftables is used instead of iptables by default.
Which issue(s) this PR fixes:

Fixes #1135
Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

/lgtm


Terminal not reading updated environment variables

Windows Terminal version
1.11.2921.0
Windows build number
10.0.22000.348
Other Software
Powershell 7.2.0
NodeJS 16.13.0
Steps to reproduce
https://user-images.githubusercontent.com/694964/143573699-23c42e1e-20c0-416a-af61-5129e092ecda.mp4
Expected Behavior
After installing NodeJS and opening a new Terminal instance, all the env variables should be updated.
The only way I managed to get this working if a restart of windows
Actual Behavior
No updates are being pulled through. It's like WT is keeping the processes running and not updating when I create a new instance.

Looks like when I quite Terminal it still leaves child processes running. If I manually quit these processes and reopen then I get refreshed ENV

Related to (or dupe of) #1125

Perfect @rkeithhill looks to be the issue!!


Creation CODE_OF_CONDUCT.md

for issue #117

Thanks @PILOTEZEBS for this PR 👍 , I will merge it.
@Sanix-Darker , please what do you think about adding CODE_OF_CONDUCT at the org level in osscameroon's .github repo like Google is doing here ?
In order to improve this in the future, we might use these links:

https://github.com/EthicalSource/contributor_covenant/blob/release/README.md#registering-your-community-as-an-adopter

https://opensource.microsoft.com/codeofconduct/

https://opensource.google/documentation/reference/releasing/template/CODE_OF_CONDUCT

https://github.com/googleapis/google-cloud-go/blob/main/CODE_OF_CONDUCT.md


CMake Infrastructure relies on default GCC build bits

C++ compiler version: GCC 7.2
Hazelcast Cpp client version: Master GitHub Cline
Hazelcast server version: N/A
Number of the clients: N/A
Cluster size, i.e. the number of Hazelcast cluster members:
OS version (Windows/Linux/OSX): Linux
Please attach relevant logs and files for client and server side.
Expected behaviour
The build of the 64 bit client is explicit called as part of the cmake infrastructure
Actual behaviour
the cmake infrastructure sets only only the -m32 option if it is building the 32 bits and relies on the gcc default behaviour for the 64 and doesn't perform any check at the end of build on the output archive / shared object to ensure it is a 64 bits build (even if in the name there is the 64)
Steps to reproduce the behaviour
Build with 64 bit option, the gcc is not invoked with the -m64

Is your environment a 32-bit built machine? Because the default for the option if nothing provided is the same as your environment.
But in any case, we can force it to use -m64 for 64-bit as you suggested. I will send a PR for that.
Thanks for the contribution.

@alexvanzu Can you please review the fix PR https://github.com/hazelcast/hazelcast-cpp-client/pull/568 ?


Adding Horizontal Scrolling Issue #23

This should add horizontal scrolling while retaining support for
vertical scrolling and should even allow diagonal scrolling if that ever
occurs..

Thanks a lot.


Adding nodes to static inventory

Hi,
Is there any suggested way of adding nodes to cluster using ansible playbook?
Thanks,
Mustafa

Hello @mustafayalniz
I did not understand your question well
if you need just to add new hosts to your cluster you can add it as u like
:
`[hdp-master]
master01 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="~/.ssh/id_rsa" rack=/default-rack
master02 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="~/.ssh/id_rsa" rack=/default-rack
[hdp-slave]
slave01 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="~/.ssh/id_rsa" rack=/default-rack
slave02 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="~/.ssh/id_rsa" rack=/default-rack
slave03 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="~/.ssh/id_rsa" rack=/default-rack

Hello @mustafayalniz
I did not understand your question well
if you need just to add new hosts to your cluster you can add it as u like
:
`[hdp-master]
master01 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="/.ssh/id_rsa" rack=/default-rack
master02 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="/.ssh/id_rsa" rack=/default-rack
[hdp-slave]
slave01 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="/.ssh/id_rsa" rack=/default-rack
slave02 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="/.ssh/id_rsa" rack=/default-rack
slave03 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="~/.ssh/id_rsa" rack=/default-rack`

Hello @mustafayalniz
I did not understand your question well
but if u mean just to add new hosts to your cluster you can add it like this :
[hdp-master]
master01 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="/.ssh/id_rsa" rack=/default-rack
master02 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="/.ssh/id_rsa" rack=/default-rack

[hdp-slave]
slave01 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="/.ssh/id_rsa" rack=/default-rack
slave02 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="/.ssh/id_rsa" rack=/default-rack
slave03 ansible_host=<IP_ADDRESS> ansible_user=root ansible_ssh_private_key_file="~/.ssh/id_rsa" rack=/default-rack


moving all the logic into the service

Hi
What I want to do is to simplify the code of the directive and put all the logic into the directive.
Advantages are:

easier testing (for the directive, you just have to mock $breadcrumb)
optimization (as the step are not destroyed and recreated several time during the rendering process)

Some work to do:

manage the unregistration of the watcher
update unit test

I have worked on top of #23 so as soon as you merge it I will rebase my branch with your master and submit a pull request.
My code: c9d8ae48646ff9a84db0e9fdfb1fe7d63c075d62

Still waiting for the PR :wink:
The project has moved a lot since nearly one year. And the issue is maybe unnecessary now.
I closed the issue. Feel free to reopen and comment the actual master if you have time.

Hi
Sorry for that, I started working on it but I parked it for a while and now my code is completely out-focus.
Carry on the good work, this project is awesome! ;)


Make _CountingAttr empty metadata unique

Issue #278

No coverage for non-default metadata?  Hmm.  Locally metadata is mostly None at the point of the partially covered if metadata is None: but many times it is not None so I'm not sure I understand this correctly.  Guidance would be appreciated.
Note that this is my first Hypothesis test and while my change to the bare_attrs makes sense to me it does seem fishy that I would need to modify that.  If there's another way to get independent instances of _CounterAttr or if we want to leave existing as is and just do what I did only for the new test, let me know.
Also, I am not sure if this belongs in any docs or changelog.  It seems a bit behind the scenes but not completely.

@Tinche this is yours

Sure, I'll take this when I'm feeling a little better.

Sure no rush, this is not a blocker.

@Tinche No urgency for me. I've got my simple workaround in place.  I hope you get better soon.

Rebase please and I will review.

Updated, but all the caveats from https://github.com/python-attrs/attrs/pull/280#issuecomment-340559686 still apply.  I'd love to understand the coverage issue.

@Tinche switched to bare_attrs = st.builds(attr.ib, default=st.none())

I'm OK with this PR as it stand except I'd like to get to the bottom of the coverage issue. @hynek any ideas?

If you don't know I'll see what I can find. Probably not for a couple days though. Thanks for keeping up on this.

So this is interesting.
If I do the famous XXX test:
    if metadata is None:
        XXX
        metadata = {}

it fails already in hypothesis.  If I invent an else, it fails in our test suite:
    if metadata is None:
        metadata = {}
    else:
        XXX

Therefore, if I add this test:
def test_meta():
    y = attr.ib(metadata={})

we get 100% test coverage.
IOW we don’t appear to have a test that sets metadata to something which seems like a glaring omission.

Hypothesis will generate attributes with arbitrary metadata in some tests. We probably never assert the metadata is the thing we set it to, though.

One of the first things I did was to print metadata and run the tests. It mostly printed None but many times printed a thing.  I can't swear I printed the repr(), but I normally do. I'm away from my computer for a day or I'd try again.  I also recall seeing 100% coverage reported locally.
@hynek, did you get less than 100% coverage when running locally?

Yes I had less than 100% until I added the test I mentioned which lifted it to 100%.

I added some prints and confirmed that both sides of the if are being hit.  If we look down at a run without disabling capture we see that under py36 runtests: commands[0] | coverage run --parallel -m pytest we do in fact only ever see metadata is None getting hit.
It sort of looks like coverage is not being measured during the full test run but only on that commands[0] line.  Is there anything related to this that was intentional?  I still have to learn a bit about coverage/tox/pytest to understand how these systems work.
I hope you don't mind me digging into this a bit more.  The way I read all this is that the tests would cover metadata is None both ways but something about how we are running it, or just a coverage bug, is keeping it from being measured.

I added both a 'real' test that sure seems like it should achieve coverage (beyond all the other indications we should have had full coverage already) and also a 'force coverage' test that actually manages to achieve full reported coverage.
I have taken several passes at this without managing to identify the actual issue.  Perhaps it relates in some way to https://github.com/HypothesisWorks/hypothesis-python/issues/997?  Though I tried the various mentioned workarounds there including https://github.com/HypothesisWorks/hypothesis-python/pull/1031 without any effect.  The only relationship I see is that hypothesis tests don't seem to consistently have coverage reported appropriately.  Are you concerned enough to open a new ticket about this coverage funny business?
This gist shows the coverage loss when the coverage forcing test is removed.
@Tinche, was there anything else you had wanted changed?  I added the news fragment and the coverage report doesn't complain anymore.

@hynek please take a last look and do the honors. :)

Thanks and welcome to software hell. ;)

@hynek, yeah, so it goes.  I made a sample showing that code called from strategies does not get coverage recorded.  From a discussion in #hypothesis, apparently this is expected behavior.  It changed at release 3.29.0 in September.  Actually, the first commit or two after 3.28.3 (https://github.com/HypothesisWorks/hypothesis-python/commit/6e7a478f4068ec6d49935b7e94673c24fa6e5ab0 https://github.com/HypothesisWorks/hypothesis-python/commit/d75ac34df9cf12a654847de1968a006d8adfa947).  The recommendation was to not rely on strategies for coverage.  One approach would be to use the strategy to provide the attrib() parameters and then do the actual attrib() call inside the test function.  Maybe via a decorator instead?
In case you can't tell, I just hate sticking stuff in to cover up systems that aren't working as expected (well, at least as I expected :]).  Should I open a ticket to track this?  Or just drop it...

Apparently it may just be a performance thing and could be open to discussion.  If you don't want to just drop it.  Using @example was also brought up but the guess was that it may not be appropriate for the attrs case.

I actually welcome that feature!  I was always a bit…nervous about relying on hypothesis for coverage because it’s kind of a matter of luck that it hits them all.
I’ll just rewrite the test myself, don’t worry about it.

This only seems to partially address any concerns about inconsistent coverage from using hypothesis.  The test body that runs would be just as inconsistent about coverage as the construction in the strategies, I would think.
As opposed to a little change like that, I was thinking more that a large portion of the test suite may be based on the expectation that strategies provided coverage and might need to be reconsidered (even though we do have 100% coverage presently).  I figured it was the developers responsibility to pick strategies such that coverage would be achieved.  In this case being sure to explicitly use both simple_attrs_with_metadata and simple_attrs_without_metadata.
I went ahead and made a small example adjustment to try out the idea of having strategies only generate parameters and the test itself generate the attr.ib().
https://github.com/altendky/attrs/commit/da4512be0618724bb76e1a4876095a06e78306fa
If there is desire to simply not use hypothesis for coverage then it seems like there should perhaps be complete isolation with no coverage for hypothesis tests and separate tests which are the sole contributors to coverage.   :)
Generally speaking, I would like to streamline our hypothesis use (the test suite could be really faster) so I’m open to improvements (although they’ll have to pass @Tinche’s discerning eye :)).
So I would suggest to open a new issue and sum up your ideas & findings from here, thanks.


Fix apiserver and apiextensions-apiserver versions

This basically reverts the parts of https://github.com/kubernetes-incubator/external-storage/pull/373/files that broke snapshot. sorry everybody

/area snapshot

/lgtm


[WIP][Avro] Use "extensions/avro" instead of avro from"core" in Java SDK modules

DON'T MERGE!!!
#24748

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run Java PreCommit


Update text for recirc and resubmit

Thanks, Andy, I have addressed all the comments.

@hanw Sorry, but I had some updates to the cloning section, at least, in my now-merged PR for how to associate metadata with packets, which is why this PR now has conflicts with the latest master.  Do you want me to take a look at merging them?

Thanks, Andy!

@cc10512 I've approved this.  Not sure if you want to take a pass through it before it is merged in?  I expect there will be further edits in these sections even after this is merged, to make everything consistent.


Are 0.0 and -0.0 equal or not?

https://wren.io/try/?code=G4QwTgBAHgvADAKFJAnjAtI5EAWMDeUAXAIwC+CAyigM4AuApgLYB0ADmAJYB2dAFLBgoAlFVqNWHHvxwBtFAF1hQA
There seems to be two types of equality (because the bit representation of -0 and 0 differ). I am not sure whether this is documented anywhere.

That issue should be value representation dependant. Union tagged values
should not be affected.

As far as I'm aware, Wren always treats 0 and -0 as being equal in value even though their underlying floating-point bit representations differ.
However, in the docs for the Object.same method it says:

For value types, this returns true if the objects have equivalent state. In other words, numbers, strings, booleans, and ranges compare by value.

In the interests of clarity, I suggest we add the following sentence to that paragraph:
"Note that the numbers 0 and -0 are treated as being equal in value even though their bit representations differ."

Does this depend at all on the  compile options?

I don't think so though @mhermier would know better than me.
The position seems to be governed by the following lines 1407-1410 in the implementation of Object.same in  wren_core.c:
// These are defined just so that 0 and -0 are equal, which is specified by
// IEEE 754 even though they have different bit representations.
PRIMITIVE(vm->numClass, "==(_)", num_eqeq);
PRIMITIVE(vm->numClass, "!=(_)", num_bangeq);

So internally they remain distinct which often shows up when you're trying to format numbers for display purposes - negative zero is a nuisance, frankly in that particular scenario.

The problem highly lies in https://github.com/wren-lang/wren/blob/accfa598b3cbc54fdfb33cb568055ed6994a4966/src/vm/wren_value.c#L430 and the notion of equality. One would expect that equality implies same hashing, and this is usually the case, but it is not an absolute truth in particular with ieee754 double. Some values are considered equal, but in their representation they can be fundamentally different, and some numbers are not equals despite being the same exact bits.
As @PureFox48 mentioned https://github.com/wren-lang/wren/blob/accfa598b3cbc54fdfb33cb568055ed6994a4966/src/vm/wren_value.h#L803 partially solve the problem, but the normal iee754 equality is applied when WREN_NAN_TAGGING is not defined (I would fix that).
Considering how ieee754 implementation support is important for performance, I would normalize the indexes in wren if this is really an issue. Properly fixing equality and fighting against ieee754 would be a huge performance loss.

I think the best way will be to have two types of equality.
In Javascript  Object.is(-0,0)==false and Object.is(NaN,NaN) == true
but -0==0 and NaN!=NaN

@Srinivasa314 if previous message were not clear enough, wren already has 2 types of quality: ==(_) and Object.same(_,_).

I've just run this code with the results shown:
System.print(0 == -0)            // true
System.print(Object.same(0, -0)) // false

So I think if we are to document this, wording should be added to the Object's ==(other) and !=(other) operators rather than to Object.same. I'd suggest now:
"Note however that these operators are overridden in the Num class to ensure 0 and -0 are treated as being equal in value even though they have different bit representations. Object.same(0, -0) still returns false because they are different objects."

As you'll see above I've added a pull request for the additional wording so this doesn't get forgotten.

A similar situation exists for NaN.
https://wren.io/try/?code=G4QwTgBADgdiMF4ByBXAtgOjjAUKSM2CAtKptjgMoCeAzgC4CmmUYAljPQBSzwCUVOkxbtOXQv0ENmGVh24B5AEYArRgGN6GWiDSMe2ADS8YfATWkj5XZWs3bd+k4YmmBQA

We looked into the NaN quagmire in some depth in #818.
As a result a Num.nan property was added in v0.4.0 (we already had a Num.isNan property) which is described in the docs as follows:

One value representing a NaN.

Provides a default NaN number suitable for the vm internal values.

@mhermier will correct me if I'm wrong but I think I'm right in saying  that Object.same will only be true if the NaNs being compared happen to have the same underlying bit representation (there are several different values used).
However,  the == operator will always return false even if the NaNs have the same underlying bit representation and conversely the != operator will always return true. This is what one would expect as  it's standard IEEE 754 behavior.
I don't really think any further clarification is required in the docs as everyone knows NaNs are peculiar but, if anyone disagrees, I could add something to the PR.

The result of Object.same will depends on WREN_NAN_TAGGING. When enabled
bit comparison is performed, otherwise ieee754 equality is performed.
Everything else is true.


Green square root symbol instead of tick on successful compilation

Which @angular/* package(s) are the source of the bug?
compiler-cli
Is this a regression?
No
Description
On successful compilation of any Angular Project, we see a green square root symbol instead of green tick mark whereas the 'Browser application bundle generation complete' message on the CLI shows a green tick.
Refer below screenshot.

Please provide a link to a minimal reproduction of the bug
https://user-images.githubusercontent.com/55897940/176140371-34d37dac-f560-431f-9dfb-0eb98626cf82.png
Please provide the exception or error you saw
No response
Please provide the environment you discovered this bug in (run ng version)
Angular CLI: 14.0.3
Node: 16.14.2
Package Manager: npm 8.5.0
OS: win32 x64

Angular: 14.0.3
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1400.3
@angular-devkit/build-angular   14.0.3
@angular-devkit/core            14.0.3
@angular-devkit/schematics      14.0.3
@schematics/angular             14.0.3
rxjs                            7.5.5
typescript                      4.7.4

Anything else?
No response

Same root cause as #21282


explicitly display mysqli error

Minor change to show mysqli errno and error explicitly. Without this, mysqli errors do not get shown in some debuggers when preparing sql statements, for example whoops.
Here is an example with whoops before

and after the change.

I think some components already use this style, for example zend-http/src/Client/Adapter/Socket.php line 278.

@mwillbanks I'm having some trouble creating a mock connection to a database. I've pushed up my attempt in the last commit. Sorry, it's a bit messy. I tried following the Pdo test setup as an example. Could you give me some suggestions on how to create an appropriate mock or stub for the db connection?

This repository has been moved to laminas/laminas-db. If you feel that this patch is still relevant, please re-open against that repository, and reference this issue. To re-open, we suggest the following workflow:

Squash all commits in your branch (git rebase -i origin/{branch})
Make a note of all changed files (`git diff --name-only origin/{branch}...HEAD
Run the laminas/laminas-migration tool on the code.
Clone laminas/laminas-db to another directory.
Copy the files from the second bullet point to the clone of laminas/laminas-db.
In your clone of laminas/laminas-db, commit the files, push to your fork, and open the new PR.
We will be providing tooling via laminas/laminas-migration soon to help  automate the process.


copy problem...

Required information

Distribution: ubuntu
Distribution version: 18.04
The output of "lxc info" or if that fails:

Kernel version: 4.15.0-33-generic
LXC version: 3.4
LXD version: 3.4
Storage backend in use: default

Issue description
lxc copy test galaxy2:test

from local to server (debian snap)
errors out:
Error: Failed container creation:
 - https://<IP_ADDRESS>:8443: Error transferring container data: Unable to connect to: <IP_ADDRESS>:8443
 - https://[fd42:c137:74da:69e::1]:8443: Error transferring container data: Unable to connect to: [fd42:c137:74da:69e::1]:8443
 - https://<IP_ADDRESS>:8443: Error transferring container data: Unable to connect to: <IP_ADDRESS>:8443
 - https://<IP_ADDRESS>:8443: Error transferring container data: Unable to connect to: <IP_ADDRESS>:8443
 - https://<IP_ADDRESS>:8443: Error transferring container data: Unable to connect to: <IP_ADDRESS>:8443
 - https://<IP_ADDRESS>:8443: Error transferring container data: Unable to connect to: <IP_ADDRESS>:8443

lxc exec galaxy2:XXX bash

works so I guess remote is set right.
is this because my ip changes (dhcp?)
The goal was to develop the container on my computer/laptop and then transfer it to the server.
Steps to reproduce
Information to attach

[ ] Any relevant kernel output (dmesg)
[ ] Container log (lxc info NAME --show-log)
[ ] Container configuration (lxc config show NAME --expanded)
[ ] Main daemon log (at /var/log/lxd/lxd.log or /var/snap/lxd/common/lxd/logs/lxd.log)
[ ] Output of the client with --debug
[ ] Output of the daemon with --debug (alternatively output of lxc monitor while reproducing the issue)

Most likely you don't have a direct network path (no NAT) between the target server and the source server.
You can use --mode=push to reverse the direction of the connections or use --mode=relay which will have your command line client relay data between the two servers.


Maintain fixed distance from dock/menu bar when they move or resize

One minor annoyance with the way the docked behavior works right now is that it doesn’t know when what it’s docked to changes position or size. This is especially noticable when docking to the bottom of the screen, as the dock can change size slightly when set to full width.
One simple workaround is to set the dock to its tallest configuration and then invoke touch bar simulator, but that’s kind of a pain because it means I have to periodically drag out the three recent apps in the dock.
It would be nice if touch bar simulator could move the touch bar window when the dock resizes. Bonus points: let me set the distance from the top/bottom that it docks so I can have it sit slightly above the dock or slightly below the menu bar.

@issuehunt has funded $80.00 to this issue.

Submit pull request via IssueHunt to receive this reward.
Want to contribute? Chip in to this issue via IssueHunt.
Checkout the IssueHunt Issue Explorer to see more funded issues.
Need help from developers? Add your repository on IssueHunt to raise funds.


Put copyright notice

Fixes #222

Yea. We'd have to unify the handling on generated stuff.

I'm going to first get this PR merged since it touches almost every single source.

Can we add the copyright to Scala 2.10 sources too? @eed3si9n

Yes we should. Maybe it's a bug in sbt-header if it's not putting it automatically.


Hotspot Beacon Rate

For each hotspot, bucketed over time, tell me how many beacons this Hotspot was a challengee.
This should unblock the app team from launch.
Eventually we'll follow this up with whether the Beacon had witnesses and valid witnesses, and the full monty: challenge pass/fail rate.

I must be missing something. Isn't this exactly what https://github.com/helium/blockchain-http/pull/182 does?

looks like it.

Re-open if you meant this to be something else @cokes518
Duplicates #172


filePicker.alternateFileNameMatching doesn't seem to work

I have fuzzy file name matching enabled in my user settings:

However, it doesn't appear to work as expected - here I have typed "ls", you can see a number of files in the list:

Now I type a t ("lst") - only "localstorage.js" is matched:

I expected that all of the files in the previous list would have still matched as they have got "t" in them after the previous match.

This screenshot from the release notes suggests that it should work as I would have expected:

@gwynjudd this feature is currently limited to file matches only. what you see is the editor history which is  containing other editors too. We might expand this feature to other areas, but for now it is limited.

@bpasero I don't really understand what you mean about the "editor history" as opposed to "file matches". Surely the things in my screenshots are files?

@gwynjudd the editor history is a list of editors you opened in the past, persisted between sessions. If you just Ctrl+P you will see this list even without searching. Once you start searching results from the editor history are merged with results from a traditional file search. Currently the alternate scoring and matching is only enabled for the file search. If a result from editor history matches, it will not be repeated from the file search.
Since the editor history is persisted and does not require disk access, you can very quickly find files you worked on in the past and dont need to wait for the slower disk search to complete.

So, anyway, you should get proper results from the slower disk search eventually. Improving performance of the file search is high on our plan.

@bpasero oh thanks for the reply. If you are interested in feedback, it seems like the search history seems to be quite slow to populate compared to the editor history. Also I think it's probably a bit confusing that you have to do a search first (something I pretty much never do) before fuzzy file name matching would work.

@gwynjudd if the file search was as fast as the editor history, would it make any difference?

@bpasero yes that would be better, but it still seems weird that you have to do a search before fuzzy matching happens


Updated the FAQ according to #339

as Android devices are now exporting more then 100 entries since end of August.

@MarlisFriedl

see also text suggestion in / update also corona-warn-app/cwa-faq#337 accordingly

The link https://github.com/corona-warn-app/cwa-faq/issues/337 doesn't work for me (404 error). Maybe it's a private repository?

Regarding the proposed text change:
"The log limit of 100 entries on Android devices has been recently removed by Google with a configuration change at the end of August 2020."
I'm not convinced that the limit was brought about by a configuration change, however I am unable to prove otherwise! Given that we don't really know,  I would remove the text "with a configuration change" making the text instead:
"The log limit of 100 entries on Android devices has been recently removed by Google at the end of August 2020."
If Google reveals at some time how they made the change, the FAQ entry could be updated accordingly.

@MikeMcC399 Hi Mike, yes you're right. We use it to prepare updates that we see coming. All changes are then done only publicly in cwa-website.


It's trivial to update to 2024.1 EAP

Doesn't seem to be that trivial. We need to do the usual version upgrades in multiple files, and then add @error_prone_annotations//jar dependency to some libraries. I tested it on Linux, MacOS, and Windows 11 and it worked. However, the pipelines are still failing so I'll have a look today.

Hi @ahmedyarub, Can you update the issue description with clear and complete details. Thanks!

Added.

Ready for review! My work heavily depends on work from other devs.

Why did you open a PR to merge @tpasternak WIP changes instead of waiting for him to open one?

Oh sorry that was not my intention. I think that my PR has changes other than his. I'd rather wait for him to merge the his PRs and then come call to this.


Visualize what line of code the editor is running

So this is just an idea, but when I am running lots of code with 'run current selection' it would be cool if the  lines in the IPython consol were a different color after they were run.

What is func2-funcN were all greyed out while func1 was running, then func2 gets color when its running, etc, etc. That way, we know what lines have already run and where our code is in the process!
Just an idea, it beats a bunch of print functions/waiting and hoping.

I think it would slow down the code significantly. I had the idea to have a plug-in where you can push a button and it would show you where the code is. Updating continuously would take too much time in my opinion.

https://github.com/spyder-ide/spyder/pull/10461

I had the idea to have a plug-in where you can push a button and it would show you where the code is.

I think thats a wonderful idea! That would very be a quality of life feature that I would use regularly, and would fit my need perfectly!
@impact27


Sm/channel-promote-bugs-2

What does this PR do?

fixes places where arrayWithDeprecation can be undefined.  Once we move to tsconfig-strict we'll get warnings about these

I was having issue with the call to PluginCommand.  I have a thread open in slack about why it's necessary.  Code works as is (I ran locally from inside sf's repo and it did the expected changes to the s3 buckets).  Other code is calling yarn and "the npm package known as oclif" is a devDep of the CLIs so...it works?

some dependency updates and linter fixes

if we decide to adopt this long-term, we can delete PluginCommand and its tests.
What issues does this PR fix or reference?

live reviewed with Pete, I'm also ignoring that failing windows UT (timeout, passed on other node version)


Windows-style path separator in include dirs cause parsing failure

In some cases CMake will not automatically replace '' with '/' in incude directories, for example, when an include directory is added by the INTERFACE_INCLUDE_DIRECTORIES property. When there are ''s in include directories, cotire will fail to parse the string by treating '' as an escaping character.
My solution is replacing '' with '/' before parsing:
    if (CMAKE_${_language}_IMPLICIT_INCLUDE_DIRECTORIES)
        list (REMOVE_ITEM _includeDirs ${CMAKE_${_language}_IMPLICIT_INCLUDE_DIRECTORIES})
    endif()
+   if (WIN32)
+       string (REPLACE "\\" "/" _includeDirs "${_includeDirs}")
+   endif()
    if (COTIRE_DEBUG AND _includeDirs)
        message (STATUS "Target ${_target} include dirs: ${_includeDirs}")
    endif()

Fixed in 1.7.9.


Investigate withdraw_gas panic method issue

          I had to roll it back bcs it resulted in the error

                message=f"A unexpected type of error occurred in binding {binding_name}: {str(ex)}"
            ) from ex
E           protostar.cairo.cairo_exceptions.CairoBindingException: A unexpected type of error occurred in binding collect_tests: Failed calculating gas usage, it is likely a call for `get_gas` is missing.

There is probably some weird thing hardcoded in the compiler 🤔
Originally posted by @MaksymilianDemitraszek in https://github.com/software-mansion/protostar/pull/1727#discussion_r1162815036

@Mak