VS2019 Support

Add support for VS2019
Current Known issues:
SCons will use VS2019 but will misidentify the version as 14.1.
Until VS2019 support is listed in CHANGES.txt it's not a supported version.
Please add any other issue found with VS 2019 here.
Work is in progress.

I've looked at the code, and I think there are several issues:
In the first place, the Visual Studio numbering seems  to be wrong. Note that Visual Studio (VS) and Visual C++ (VC) numbering is out of sync starting with VS2017.

year
VS
VC

2015
14.0
14.0

2017
15.0-15.9
14.1

2019
16.0-?
14.2

Therefore, I'd suggest to update the visual studio code (vs.py) to use the actual version numbers. This means that for 2017, a change is required from 14.1 to 15.0. 2019 should be refered to as 16.0
In the second place, vswhere is used incorrectly. It looks like the -version command line parameter requires a version range instead of a single version. For VS 2017, this ought to be [15.0,16.0]. For VS2019, this should be [16.0,17.0]. Therefore, I'd like to suggest the following changes to from tool.MSCommon.vc

Remove VC 14.1 from _VCVER_TO_PRODUCT_DIR

Ad a new dictionary _VCVER_TO_VSWHERE_VERSION_RANGE, like this:

_VCVER_TO_VSWHERE_VERSION_RANGE = {
"14.1": "[15.0,16.0]",
"14.2": "[16.0,17.0]",
}

    In find_vc_pdir, directly fallback to find_vc_pdir_vswhere if msvc_version is not in _VCVER_TO_PRODUCT_DIR but in _VCVER_TO_VSWHERE_VERSION_RANGE.
* Change the vswhere command to properly set the `-version` command line parameter according to what's in _VCVER_TO_VSWHERE_VERSION_RANGE

If you would like any assistance with this, let me know.

I do not think it matters, but the vswhwere version range should be an open-ended interval rather than a closed-end interval as above (i.e., a close parenthesis rather than close square bracket):
_VCVER_TO_VSWHERE_VERSION_RANGE = {
    "14.1": "[15.0,16.0)",
    "14.2": "[16.0,17.0)",
}

The following minimal changes below were hacked into a python 2.7 installation on 32-bit windows and appear to be working as expected.  Quick tests appear to work.  The changes have not been tested on 64-bit windows yet.
As I made the following changes before reading the post above. the dictionary mapping the msvc version to vswhere version is not the same as above.
Added the following definition for msvs 2019 to vs.py:
    # Visual Studio 2019
    VisualStudio('14.2',
                 vc_version='14.2',
                 sdk_version='10.0A',
                 hkeys=[],
                 common_tools_var='VS160COMNTOOLS',
                 executable_path=r'Common7\IDE\devenv.com',
                 batch_file_path=r'VC\Auxiliary\Build\vsvars32.bat',
                 supported_arch=['x86', 'amd64', "arm"],
                 ),

Added/extended the following declarations for msvc 2019 to vc.py:
_VCVER = ["14.2", "14.1", "14.0", "14.0Exp", "12.0", "12.0Exp", "11.0", "11.0Exp", "10.0", "10.0Exp", "9.0", "9.0Exp","8.0", "8.0Exp","7.1", "7.0", "6.0"]

_VCVER_TO_VSWHERE_VER = {
    '14.2' : '[16.0, 17.0)',
    '14.1' : '[15.0, 16.0)',
}

_VCVER_TO_PRODUCT_DIR = {
    '14.2' : [
        (SCons.Util.HKEY_LOCAL_MACHINE, r'')],
    '14.1' : [
        (SCons.Util.HKEY_LOCAL_MACHINE, r'')], # Visual Studio 2017 doesn't set this registry key anymore

Added a lookup from the msvc version to vswhere version and then use the vswhere version variable in the query in find_vc_pdir_vswhere in vc.py:
    try:
        vswhere_version = _VCVER_TO_VSWHERE_VER[msvc_version]
    except KeyError:
        debug("Unknown version of MSVC: %s" % msvc_version)
        raise UnsupportedVersion("Unknown version %s" % msvc_version)

    # For bug 3333 - support default location of vswhere for both 64 and 32 bit windows
    # installs.
    for pf in ['Program Files (x86)', 'Program Files']:
        vswhere_path = os.path.join(
            'C:\\',
            pf,
            'Microsoft Visual Studio',
            'Installer',
            'vswhere.exe'
        )
        if os.path.exists(vswhere_path):
            # If we found vswhere, then use it.
            break

    vswhere_cmd = [vswhere_path, '-products', '*', '-version', vswhere_version, '-property', 'installationPath']

Note: the MSVC_VERSION documentation in Tool/msvc.xml would need to be updated as well.

Keep going, guys!  It helps to have people who actually use Windows contribute to fixing the Windows issues :)

Mats and Bill,
The attached zip file contains a minimal patch to provide MSVS 2019 support for windows.
Comments:

A docstring comment was modified to include raising an exception.  This was changed similar to a comment in the same file.  I'm not sure what the documentation conventions are so it should either be reviewed or removed,
The exception raised was copied and pasted.  I did not test actually raising the exception.  However, I don't believe an invalid msvc version should get this far unless there is a source configuration error.
The changes have not been fully tested on x64 platforms.
The batch file included (stk_msvc.bat) is a "pure" windows batch file that configures the msvc toolsets from the windows command line.  The logic mirrors that of scons.  This has proved somewhat beneficial to check that the environment is configured correctly outside of scons.  I have used the batch file for most all major versions of MSVC since 6.0 (1998) on x86 and recent versions (2013+) on x64.

Joe
scons-master-msvs2019-patch.zip

Joe,
Any chance you can submit a pull request?
We'd be glad to help you through the process if you're unfamiliar.
-Bill
On Fri, May 24, 2019 at 8:39 AM jcbrill<EMAIL_ADDRESS>wrote:

Mats and Bill,
The attached zip file contains a minimal patch to provide MSVS 2019
support for windows.
Comments:

A docstring comment was modified to include raising an exception.
This was changed similar to a comment in the same file. I'm not sure what
the documentation conventions are so it should either be reviewed or
removed,
The exception raised was copied and pasted. I did not test actually
raising the exception. However, I don't believe an invalid msvc version
should get this far unless there is a source configuration error.
The changes have not been fully tested on x64 platforms.
The batch file included (stk_msvc.bat) is a "pure" windows batch
file that configures the msvc toolsets from the windows command line. The
logic mirrors that of scons. This has proved somewhat beneficial to check
that the environment is configured correctly outside of scons. I have used
the batch file for most all major versions of MSVC since 6.0 (1998) on x86
and recent versions (2013+) on x64.

Joe
scons-master-msvs2019-patch.zip
https://github.com/SCons/scons/files/3217360/scons-master-msvs2019-patch.zip
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/SCons/scons/issues/3346?email_source=notifications&email_token=AAAUCNGQC3VKTZ276IYNXUTPW74YJA5CNFSM4HFAP2H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWFSLGY#issuecomment-495658395,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAUCNA6OMMPVZRWFQRLD3LPW74YJANCNFSM4HFAP2HQ
.

Bill,
I would appreciate it if you could walk me through the process like I'm five years old.
I am not a git user.  I created a GitHub account for the sole reason of reporting an earlier scons windows x86 anomaly.  Any and all help is appreciated.
Any pointers on using MS Outlook to reply to the user mailing list correctly would also be useful.  I can't seem to get Outlook to reply to the appropriate message at the appropriate nesting of a thread in the user mailing list.
Joe

Joe,
Any chance you can submit a pull request?
We'd be glad to help you through the process if you're unfamiliar.
-Bill

* A docstring comment was modified to include raising an exception.  This was changed similar to a comment in the same file.  I'm not sure what the documentation conventions are so it should either be reviewed or removed,

I think we want to keep the same docstring style within a single docstring, so instead of the more human-readable Google/NumPy style you've used, write it (lined up with the earlier markup) in the ReST style as:
     :raises: UnsupportedVersion blah blah

Revised patch with ReST style docstring for raising UnsupportedVersion exception consistent with other specifications for the same function (dropped inherits from VisualCException text):
:raises UnsupportedVersion: if the version is not known by this file.
I removed the batch file in the previous attachment from the zip archive as well.  It is unrelated to the patch to add support for VS 2019.
scons-master-msvs2019-patch2.zip

Take a read through:
https://github.com/SCons/scons/wiki/GitWorkflows
That should (we hope) help you do your first pull request.
If something doesn't work/isn't clear. please send email to the dev mailing
list.
Can you send an initial email to users or dev mailing list? or is it only
replying to an email which is causing you issues?
On Sat, May 25, 2019 at 5:34 AM jcbrill<EMAIL_ADDRESS>wrote:

Bill,
I would appreciate it if you could walk me through the process like I'm
five years old.
I am not a git user. I created a GitHub account for the sole reason of
reporting an earlier scons windows x86 anomaly. Any and all help is
appreciated.
Any pointers on using MS Outlook to reply to the user mailing list
correctly would also be useful. I can't seem to get Outlook to reply to the
appropriate message at the appropriate nesting of a thread in the user
mailing list.
Joe
Joe,
Any chance you can submit a pull request?
We'd be glad to help you through the process if you're unfamiliar.
-Bill
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/SCons/scons/issues/3346?email_source=notifications&email_token=AAAUCNF7RZMYSWXK3KXQZCTPXEP35A5CNFSM4HFAP2H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWHP6SY#issuecomment-495910731,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAUCNE4F3B5IJ3QPOMFPTDPXEP35ANCNFSM4HFAP2HQ
.

I got stuck in this mess looking at something else, and the above looks good to me, with some experiments, I get the same sorts of results.
While we've got some people paying attention, what is the purpose of the "SDK version"?  right now, there's the table SupportedVSList (to which an addition for vc14.2 as appears in vs2019 is proposed above) which seems to map vs version to sdk version, but then that's used to plug in to a registry query that doesn't find anything... the only SDKs I have in the registry location it looks in are 8.0 and 8.1, but I have a lot more things in the SDK directory.
HKEY_FMT = r'Software\Microsoft\Microsoft SDKs\Windows\v%s\InstallationFolder'

There are a ton of things called SDK by Microsoft, these seem to be the dot-net bits.  Is there something that needs fixing here?  What is this SDK search actually for in the SCons context?

@mwichmann  - It's the platform SDK (think OS level stuff)

I can't answer what SCons is doing with the SDK version.
The SDK version can be passed as a command-line argument (winsdk_version) to vcvarsall.bat.  AFAIK, SCons does not support this.

winsdk_version
Optionally specifies the version of the Windows SDK to use. By default, the latest installed Windows SDK is used. To specify the Windows SDK version, you can use a full Windows 10 SDK number such as 10.0.10240.0, or specify 8.1 to use the Windows 8.1 SDK.

If you are on a 64-bit version of Windows, check the following key as well:
HKEY_FMT = r'Software\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v%s\InstallationFolder'
On a windows 10, 64-bit box, the key in your post had the following SDK keys: v7.1A, v8.0A, v8.1A.
The Wow6432Node key above contained the following SDK keys: v7.1A, v8.0, v8.0A, v8.1, v8.1A, v10.0.
ProgramFiles(x86)\Microsoft SDKs\Windows contains sub-folders: v7.0, v7.1A, v8.0, v8.0A, v8.1, v8.1A, v10.0A.
ProgramFiles(x86)\Windows Kits contains sub-folders: 8.0, 8.1, 10, NETFXSDK
Confusing enough?

Of course it is confusing enough :)   Yeah, I see the check in Wow6432Node, that's not in the initialized bits buts is added as part of a different spot. Missed that.  Yeah, I see the same list as you there (excepting the 7.x ones, presumably versions I don't have installed).

sigh... must have hit the wrong key, wasn't done yet.  The Wow6432Node check doesn't seem to apply to the sdks - the class has a method get_sdk_dir that does not do that, as can be seen in the debug log if you turn it on. It is applied in find_vc_pdir.
With debugging turned on, the find_sdk_dir check seems to only find the aforementioned 8.x ones for my setup

In recent versions of MSVS, there is a batch file winsdk.bat in the sub-folder Common7\Tools\vsdevcmd\core\winsdk.bat.
I am not familiar with this batch file.
When an SDK version is not specified, the batch file appears to search the registry in the following order of key prefixes:

HKLM\SOFTWARE\Wow6432Node
HKCU\SOFTWARE\Wow6432Node
HKLM\SOFTWARE
HKCU\SOFTWARE

For 2019, the actual registry queries are segmented by SDK version 10 and 8.1.
For 10:
for /F "tokens=1,2*" %%i in ('reg query "%1\Microsoft\Microsoft SDKs\Windows\v10.0" /v "InstallationFolder"') DO (
    if "%%i"=="InstallationFolder" (
        SET WindowsSdkDir=%%~k
    )
)

For 8.1:
if "%WindowsSdkDir%"=="" for /F "tokens=1,2*" %%i in ('reg query "%1\Microsoft\Microsoft SDKs\Windows\v8.1" /v "InstallationFolder"') DO (
    if "%%i"=="InstallationFolder" (
        SET WindowsSdkDir=%%k
    )
)

Note:  This may only apply to recent versions of MSVS.
My guess is that omission of "HKLM\SOFTWARE\Wow6432Node" in the SCons SDK search is an error of omission.
It appears that the "HKLM\SOFTWARE\Wow6432Node" keys should be queried before before the ""HKLM\SOFTWARE" keys in SCons.
Note:  The MS batch file also queries the Current User keys after the Local Machine keys.

Thanks for all the info! I had actually patched in a check to try the Wow6432Node entry first just as you suggest; it worked but didn't work - because it then takes the path obtained from the registry and uses it to look for a file named SetEnv.cmd, which does not appear to be used any longer, I can only find one of those on the system and it's not in a mainline sdk. Probably that means newer installations need to be following more of the stuff you dug up.
DEBUG:SCons.Tool.MSCommon.common:MSCommon/sdk.py: trying to find SDK 10.0
DEBUG:SCons.Tool.MSCommon.common:find_sdk_dir(): checking registry:Software\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v10.0\InstallationFolder
DEBUG:SCons.Tool.MSCommon.common:find_sdk_dir(): Trying SDK Dir: C:\Program Files (x86)\Windows Kits\10\
DEBUG:SCons.Tool.MSCommon.common:find_sdk_dir(): sanity check C:\Program Files (x86)\Windows Kits\10\bin\SetEnv.Cmd not found

My guess is that omission of "HKLM\SOFTWARE\Wow6432Node" in the SCons SDK search is an error of omission.

Yes, in the sense that it was written too long ago and didn't know it needed to.  This is why I was fishing for if anyone knew what the sdk information was actually used for.  Without tracing the whole thing all the way through it looks like it's only an existence check.

My guess is that SCons may have supported versions of the msvc compiler that were distributed with the windows SDKs (i.e., command-line tools without devenv gui) that were available separate from the visual studio releases.
I believe that there were SDK msvc versions for 2005 (SDK update for vista), 2008 (sdk 7.0), and 2010 (sdk 7.1),
I don't believe that there were SDK msvc versions for 2012 (SDK 8.0) or 2013 (SDK 8.1) but I could be wrong.
On my 32-bit windows 7 box, setenv.bat exists for the v7.0 and v7.1 (but curiously not v7.1A) SDK installations which would be consistent with the SDK compiler releases.

See also https://github.com/SCons/scons/pull/3391

@mwichmann and @rhuijben
There is an omission with both my patch above [https://github.com/SCons/scons/issues/3346#issuecomment-495931740] and https://github.com/SCons/scons/pull/3391:  the test suite has not been updated for MSVS 2019 [14.2].
Unfortunately, I am not familiar with the SCons test harness nor with msvs workspaces.  I moved to SCons from msvc 6.0 and haven't used a msvc/msvs workspace since.
A quick search yields at least the following:

test\MSVS\MSVC_UWP_APP.py [would need to be updated]
test\MSVS\vs-14.2-exec.py [would need to be added]
test\MSVS\vs-14.2-files.py [would need to be added]
test\MSVS\vs-14.2-scc-files.py [would need to be added]
test\MSVS\vs-14.1-scc-legacy-files.py [would need to be added]
testing\framework\TestSConsMSVS.py [would need to be updated]

There certainly could be other places that need to be updated to wire in a new version of MSVS.
One of the reasons that I have not been proactive about the patch above is that I am somewhat reluctant to add 14.2 to msvc.xml as an officially supported version without [someone] updating the test suite.

Is anyone else testing MSVS 2019 getting msvc linker warning LNK4204 when re-building a debug configuration with pdb files using the latest update to 14.21.27702?
I have interleaved 32-bit and 64-bit target dll and exe builds on a 64-bit host in both release and debug configurations.  There are inter-dependencies between the libraries and executables.  Immediately running scons a second time following a clean initial build invokes the msvc link command again for some of the build targets [this could be an user-created dependency problem] without compiling any of the source files (i.e., the object files have not changed).  Up until the latest 2019 update, there have been no warnings when re-linking.
Example MSVC 2019 [14.21.27702] linker warnings:

cmore_work.obj : warning LNK4204: '??????' is missing debugging information for referencing module; linking object as if no debug info

test.obj  : warning LNK4204: '??????' is missing debugging information for referencing module; linking object as if no debug info

cmore_dllmain.obj : warning LNK4204: '' is missing debugging information for referencing module; linking object as if no debug info

The "?" characters are unprintable characters.
I updated to 14.21 before doing any testing so I can't be sure if the behavior was the same in 14.20 on a 64-bit host.
There are no such warnings with exactly the same build and re-build sequence using MSVC 2017 (14.16.27031) or any earlier versions.
For the initial build, the only differences between the captured stdout+stderr for 2017 and 2019 is the msvc version number when the tools are executed.  For the rebuild, other than the version numbers, the only differences are that the 2019 log contains the linker warnings.  The build sequence is the same as well as all flags and switches.
It is entirely possible the problem lies on my end.  It is curious that the warnings are not elicited any with earlier versions of msvc.

Is anyone else testing MSVS 2019 getting msvc linker warning LNK4204 when re-building a debug configuration with pdb files using the latest update to 14.21.27702?
I have interleaved 32-bit and 64-bit target dll and exe builds on a 64-bit host in both release and debug configurations.  There are inter-dependencies between the libraries and executables.  Immediately running scons a second time following a clean initial build invokes the msvc link command again for some of the build targets [this could be an user-created dependency problem] without compiling any of the source files (i.e., the object files have not changed).  Up until the latest 2019 update, there have been no warnings when re-linking.
Example MSVC 2019 [14.21.27702] linker warnings:

cmore_work.obj : warning LNK4204: '??????' is missing debugging information for referencing module; linking object as if no debug info

test.obj  : warning LNK4204: '??????' is missing debugging information for referencing module; linking object as if no debug info

cmore_dllmain.obj : warning LNK4204: '' is missing debugging information for referencing module; linking object as if no debug info

The "?" characters are unprintable characters.
I updated to 14.21 before doing any testing so I can't be sure if the behavior was the same in 14.20 on a 64-bit host.
There are no such warnings with exactly the same build and re-build sequence using MSVC 2017 (14.16.27031) or any earlier versions.
For the initial build, the only differences between the captured stdout+stderr for 2017 and 2019 is the msvc version number when the tools are executed.  For the rebuild, other than the version numbers, the only differences are that the 2019 log contains the linker warnings.  The build sequence is the same as well as all flags and switches.
It is entirely possible the problem lies on my end.  It is curious that the warnings are not elicited any with earlier versions of msvc.

Is anyone else testing MSVS 2019 getting msvc linker warning LNK4204 when re-building a debug configuration with pdb files using the latest update to 14.21.27702?
I have interleaved 32-bit and 64-bit target dll and exe builds on a 64-bit host in both release and debug configurations. There are inter-dependencies between the libraries and executables. Immediately running scons a second time following a clean initial build invokes the msvc link command again for some of the build targets [this could be an user-created dependency problem] without compiling any of the source files (i.e., the object files have not changed). Up until the latest 2019 update, there have been no warnings when re-linking.
Example MSVC 2019 [14.21.27702] linker warnings:

cmore_work.obj : warning LNK4204: '??????' is missing debugging information for referencing module; linking object as if no debug info

test.obj  : warning LNK4204: '??????' is missing debugging information for referencing module; linking object as if no debug info

cmore_dllmain.obj : warning LNK4204: '' is missing debugging information for referencing module; linking object as if no debug info

The "?" characters are unprintable characters.
I updated to 14.21 before doing any testing so I can't be sure if the behavior was the same in 14.20 on a 64-bit host.
There are no such warnings with exactly the same build and re-build sequence using MSVC 2017 (14.16.27031) or any earlier versions.
For the initial build, the only differences between the captured stdout+stderr for 2017 and 2019 is the msvc version number when the tools are executed. For the rebuild, other than the version numbers, the only differences are that the 2019 log contains the linker warnings. The build sequence is the same as well as all flags and switches.
It is entirely possible the problem lies on my end. It is curious that the warnings are not elicited any with earlier versions of msvc.

So are you building 32 bit and 64 bit binaries into the same location based on some command line flag?

So are you building 32 bit and 64 bit binaries into the same location based on some command line flag?

Each build target (dll, exe) has it's own build sub-folder based on: target architecture (32 or 64), compiler (msvc or mingw-w64), crt runtime (60, 80, 90, 100, 110, 120, or 140/ucrt), and configuration (release or debug).
For example

lib-cbase

__build

32mgw60d
32mgw60r
32vc140d
32vc140r
32mgw60d
32mgw60r
64vc140d
64vc140r

The example above is a typical testing build: 32/64 bit MSVC 2015/2017/2019 and 32/64-bit mingw-w64 [gcc 8.1].
Due to legacy software compatibility, each library is compiled with for msvc runtime compatibility with 60, 80, 90, 100, 120, and 140/ucrt for both 32-bit and 64-bit.
The 140 builds use whichever MSVC version is installed (MSVS 2019, MSVS 2017, MSVS 2015) or, if none are installed, Mingw-W64 with custom specs file and libraries to link to the required compatible crt.
Currently, I'm using mingw-w64 gcc 8.1 for runtime compatibility with 60, 80, 90, 100, and 110 and MSVC for runtime compatibility with 120 and 140/ucrt.  Although this can be changed easily in the build script.
The home-brew script is crt-centric rather than compiler-centric.
For both msvc and mingw compiled dlls, import libraries are re-generated for both msvc and mingw with a common, shorter name using post-actions and gendef.exe, lib.exe, and dlltool.exe.

So are you building 32 bit and 64 bit binaries into the same location based on some command line flag?

Each build target (dll, exe) has it's own build sub-folder based on: target architecture (32 or 64), compiler (msvc or mingw-w64), crt runtime (60, 80, 90, 100, 110, 120, or 140/ucrt), and configuration (release or debug).
For example

lib-cbase

__build

32mgw60d
32mgw60r
32vc140d
32vc140r
32mgw60d
32mgw60r
64vc140d
64vc140r

The example above is a typical testing build: 32/64 bit MSVC 2015/2017/2019 and 32/64-bit mingw-w64 [gcc 8.1].
Due to legacy software compatibility, each library is compiled with for msvc runtime compatibility with 60, 80, 90, 100, 120, and 140/ucrt for both 32-bit and 64-bit.
The 140 builds use whichever MSVC version is installed (MSVS 2019, MSVS 2017, MSVS 2015) or, if none are installed, Mingw-W64 with custom specs file and libraries to link to the required compatible crt.
Currently, I'm using mingw-w64 gcc 8.1 for runtime compatibility with 60, 80, 90, 100, and 110 and MSVC for runtime compatibility with 120 and 140/ucrt. Although this can be changed easily in the build script.
The home-brew script is crt-centric rather than compiler-centric.
For both msvc and mingw compiled dlls, import libraries are re-generated for both msvc and mingw with a common, shorter name using post-actions and gendef.exe, lib.exe, and dlltool.exe.

This discussion should probably be moved to the users mailing list since it's not really about VS2019 support.

So some of the work is now merged vis #3408: the description (correct or not) of VS 2019 added to the list of versions, and the work to send a more correct version arg to vswhere through an additional mapping table. The authors of these bits have been credited.
It would be great to resync and see what is still needed to finish up support for VS2019.  The generation of correct project files appears to be one of those items.

Any updates here from people who actually use this stuff? Is it "done" in scons 3.1.1?

I have been using scons 3.1.1 [32-bit windows 7 with Python 3.7.4] and compiling with VS2019 (14.21) targeting both 32-bit and 64-bit intel architecures without issue.
I have not used scons 3.1.1 nearly as much on 64-bit windows 10 with Python 3.7.4, but have not experienced any issues to date.
Appears done to me.  Nice work.
P.S.:  The LNK4024 warnings in VS2019 mentioned above were my own fault and due to custom pdb file names not being unique across multiple msvc compiler combinations (or at least changing the pdb file names eliminated the warning).

Closing based on @jcbrill 's comment above.


[terra-form-select] Announce OptGroup labels to improve screen reader accessibility

closes #2663
Deployment Example: https://terra-core-deployed-pr-2796.herokuapp.com/components/terra-form-select/form-select/select
Found under Ability to add Option Groups (applies to all)

@lokesh-0813 saw your comment on the translation JIRA. We don't worry about finnish translations since it's not officially supported (see https://github.com/cerner/terra-core/blob/master/packages/terra-dropdown-button/translations/fi-FI.json) for an example of what we typically do.

@ryanthemanuel  Translations Added here 7defe48c45eaa2e6265e7dfea86ffe9496c3afea
Typo fixed here 9c75500046b25e53bb41fc7c6419936021756488.
I noticed that recent translations for Finnish have been ignored in terra-form-select. Except AR and FI everything else is updated.

Before merging I’d recommend confirming with the translations team that these translations can be combined in this format.
From the JIRA is appears the requested translations were specifically for the word “Group”
But the sentence translations structure is:
Group ${groupName}, ${optionDisplay}
or
Group ${groupName}, ${optionDisplay} Selected.
Not all languages share the same left to right sentence construction. The end result looks like this:

Group Shade of blue, Blue
Group Shade of blue, Blue Selected.

Picture for reference:

@StephenEsser
Translations looks good for majority of the languages.
JIRA LINK

Thank you for verifying the translations @lokesh-0813


Development

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

:exclamation: No coverage uploaded for pull request base (main@550491a). Click here to learn what that means.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #71   +/-   ##
=======================================
  Coverage        ?   85.00%
=======================================
  Files           ?        6
  Lines           ?      260
  Branches        ?        0
=======================================
  Hits            ?      221
  Misses          ?       39
  Partials        ?        0

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


Improved transactions

Rebased CheckoutHandler and make it possible to add arbitrary expenses

@machiato32 Please check the emails.

Made some changes:

fixed missing assigning of the title variable of the Transactions mailable
added paid_at to the fillable array in the Transaction model
better readability in emails: hungarian language, no - sign at the transactions, receiver and payer not stated if same
removed unnecessary translations from students council checkout.app.blade
added more explanations for better understanding to the checkout page


volumeSnapshot should not be created on below scale version (<IP_ADDRESS>)

Describe the bug
volumeSnapshot should not be created on below scale version (<IP_ADDRESS>)
To Reproduce
Steps to reproduce the behavior:
volumeSnapshot should not be created on below scale version (<IP_ADDRESS>)
Expected behavior
volumeSnapshot creation should fail with proper error if created below scale version (<IP_ADDRESS>)

The code changes were done only in driver (not operator). So for testing sharing just the driver image at quay.io/madhuthorat/ibm-spectrum-scale-csi-driver-dev:driver_issue364.

Also for testing, one option for testing logic for version check is to run the portion of the patch which does version check at: https://play.golang.org/p/auCWHE0ARkg
Change the values here and test.

@Jainbrt Can we close this ?


Location inconsistency in AKS quickstart doc

The output of a command which specified westus2 gives back westeurope according to the docs. Seems incorrect.

@vincentheet : Thanks for your contribution to the Azure documentation! The author, @neilpeterson, has been notified to review your proposed change.

@vincentheet thanks for catching this.
#sign-off


CanonicalizeOSSA: Destructure canonicalization and conslidate borrow scope support for destructure

Canonicalize struct_extract to destructure and handle destructure in conslidate borrow scope. The later is still disabled. This is an incremental development step.

@swift-ci test

@swift-ci benchmark

@swift-ci test source compatibility

Performance: -O

Regression
OLD
NEW
DELTA
RATIO

Breadcrumbs.MutatedUTF16ToIdx.Mixed
299
1241
+315.0%
0.24x

Breadcrumbs.MutatedIdxToUTF16.Mixed
309
1247
+303.6%
0.25x

StringFromLongWholeSubstring
4
5
+25.0%
0.80x

NSStringConversion.UTF8
959
1076
+12.2%
0.89x (?)

UTF8Decode_InitFromBytes_ascii
296
327
+10.5%
0.91x (?)

AngryPhonebook
476
525
+10.3%
0.91x

SubstringFromLongString
10
11
+10.0%
0.91x (?)

NSStringConversion.LongUTF8
507
548
+8.1%
0.93x (?)

Improvement
OLD
NEW
DELTA
RATIO

ObjectiveCBridgeFromNSArrayAnyObject
21300
19600
-8.0%
1.09x (?)

DictionaryKeysContainsCocoa
28
26
-7.1%
1.08x (?)

ArrayAppendUTF16Substring
28116
30636
+9.0%
0.92x (?)

ArrayAppendLatin1Substring
28728
31212
+8.6%
0.92x (?)

ArrayAppendAsciiSubstring
28116
30492
+8.5%
0.92x (?)

ProtocolDispatch
371
400
+7.8%
0.93x (?)

Improvement
OLD
NEW
DELTA
RATIO

Set.isStrictSubset.Int.Empty
88
82
-6.8%
1.07x (?)

Set.isSubset.Empty.Int
168
157
-6.5%
1.07x (?)

Improvement
OLD
NEW
DELTA
RATIO

String.replaceSubrange.Substring.Small
87
81
-6.9%
1.07x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

Build failed
Swift Test Linux Platform
Git Sha - 1fe88cd0b7308ac390bb91fb9f9b421e28fb3e25

Build failed
Swift Test OS X Platform
Git Sha - 1fe88cd0b7308ac390bb91fb9f9b421e28fb3e25

Making this a pure NFC PR.
I originally implemented this to fix a massive StringBreadCrumbs benchmark regression. However, for that to work, borrow scope canonicalization also needs to be enabled.  Now, special struct_extra logic has been added to optimize StringBreadCrumbs, which the canonicalization here interferes with.
Putting this all under a flag until that has been sorted out.

@swift-ci test

Build failed
Swift Test OS X Platform
Git Sha - 9ba55492f227f1c66087f917a437d76b14c73a8d

@swift-ci test

@swift-ci benchmark

Performance: -O

Regression
OLD
NEW
DELTA
RATIO

String.data.LargeUnicode
105
113
+7.6%
0.93x (?)

Improvement
OLD
NEW
DELTA
RATIO

DictionaryKeysContainsCocoa
32
28
-12.5%
1.14x (?)

FlattenListFlatMap
4525
4065
-10.2%
1.11x (?)

Code size: -O
Performance: -Osize

Regression
OLD
NEW
DELTA
RATIO

DataAppendDataSmallToSmall
4080
4980
+22.1%
0.82x (?)

UTF8Decode_InitFromBytes_ascii_as_ascii
450
535
+18.9%
0.84x (?)

ObjectiveCBridgeFromNSArrayAnyObjectForced
4700
5480
+16.6%
0.86x (?)

ObjectiveCBridgeFromNSStringForced
2545
2895
+13.8%
0.88x (?)

StringToDataLargeUnicode
3750
4150
+10.7%
0.90x (?)

UTF8Decode_InitFromData_ascii_as_ascii
744
812
+9.1%
0.92x (?)

Code size: -Osize
Performance: -Onone

Regression
OLD
NEW
DELTA
RATIO

DataAppendDataSmallToSmall
5120
5520
+7.8%
0.93x (?)

Improvement
OLD
NEW
DELTA
RATIO

StringWordBuilderReservingCapacity
2940
2650
-9.9%
1.11x (?)

StringWordBuilder
2980
2690
-9.7%
1.11x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB


[Feat. req.] Support for iframe selection when debugging

When debugging with Chrome Dev Tools, it is possible to target a specific <iframe>, as shown here:

It would be useful to have a prop in launch.json that specifies the target iframe.
Context about my feature request is found in this StackOverflow topic.
Thank you!

We have been actively working on improving multi-target debugging for the chrome debug extension. Closing this but stay tuned!
https://github.com/microsoft/vscode-chrome-debug-core/issues/529


D415: pyrealsense2 is giving out stale frames or repeated frames

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
D415

Firmware Version
<IP_ADDRESS>

Operating System & Version
Linux (Ubuntu 16)

Kernel Version (Linux Only)
4.15.0-88-generic

Platform
PC

SDK Version
2.32.1

Language
python

Segment
Robot

Issue Description
Hello realsense community
I'm facing an issue where a D415 realsense camera is giving out stale frames (frames with an old timestamp).
The following code captures the frames in 5 seconds and prints the summary on the terminal:
pipeline = rs.pipeline()
config = rs.config()
config.enable_stream(rs.stream.color, 1280, 720, rs.format.rgb8, 30)
config.enable_stream(rs.stream.depth, 1280, 720, rs.format.z16, 30)
pipeline.start(config)
start_time = time.time()
num_frames_captured, num_stale_frames = 0, 0
color_ts, depth_ts = None, None
while (time.time() - start_time) < 5:
    frames = pipeline.wait_for_frames()
    color_frame, depth_frame = frames.get_color_frame(), frames.get_depth_frame()
    if color_ts == color_frame.timestamp or depth_ts == depth_frame.timestamp:
        num_stale_frames += 1
    num_frames_captured += 1
    color_ts, depth_ts = color_frame.timestamp, depth_frame.timestamp

print('Summary:\n# Total frames: {}'.format(num_frames_captured))
print('# Stale frames: {}'.format(num_stale_frames))

Output:
Summary:
# Total frames: 115
# Stale frames: 51

Any help is appreciated.

Hi @redM0nk
There could be two possible reasons for this:

The RGB camera by default is controlled by auto-exposure algorithm and can decide to reduce its FPS (when the environment is sufficiently dark). You can enforce the FPS you requested by setting RS2_OPTION_AUTO_EXPOSURE_PRIORITY to 0 on the second sensor.

p = pipe.start(cfg)
p.get_device().query_sensors()[1].set_option(rs.option.auto_exposure_priority, 0.0)

If RGB FPS is fixed, pipeline will provide stale frames in case of frame drops. This can sometimes happen due to high CPU load, but should not be widespread

@redM0nk Any other questions about this with the reply from dorodnic? Looking forward to your update. Thanks!

@dorodnic Thank you for the reponse.
I tried the above mentioned solution and it is giving me some error:
RuntimeError: object doesn't support option #30
The current camera configuration is as follows:
Resolution: 1280x720
Fps: 30
RGB Exposure: 32ms
Depth Exposure: auto

Upgrading the camera to the latest firmware <IP_ADDRESS> and installing pyrealsense2 using the source code definitely helps.
At present, I'm noticing another issue with timestamp delta (system timestamp - frame timestamp) of 40-70 ms.
Any help with the issue is appreciated.

@redM0nk The error "RuntimeError: object doesn't support option #30" is due to the sensor you queried is not RGB sensor. Please add the query for RGB sensor.
And please create another one to track the timestamp issue, logs will be appreciated. Thanks!

@redM0nk Any other question about this? Looking forward to your update. Thanks!

thanks. i was able to set the RS2_OPTION_AUTO_EXPOSURE_PRIORITY option on the RGB sensor.
as of now I'm not noticing any more issues with stale frames.
summary:

move to the latest firmware,
compile realsense library from source code,
use appropriate settings (mentioned above)


How to use Purestake algorand api as AlgodClient

Hi, I want to use Purestake Algorand API as my node in the Algorand blockchain and not set one up by myself.
To be able to connect to Purestake API, I need the ALGOD V3.0.1 TESTNET address :

https://testnet-algorand.api.purestake.io/ps2

and a private API key that is prepared in the Purestake panel.
I tried the following code from quickstart  with Purestake like  :
algod = new AlgodClient(             address: "testnet-algorand.api.purestake.io/ps2",             token: "my private API key"         );
and CheckAlgodStatus prints out :

Connected to algod!

but when I use CheckBalance() function to check my wallet on the Algorand test net, it always returns

My account has 0 algos

and it seems not working properly cause I have algos in my TestNet wallet address that I'm using in CheckBalance().
Have you tried to test this plugin with Purestake API? am I missing something?
Regards.

I haven't tried purestake myself, I see now that they have specific headers.
There are 2 issues here:

The request should be failing if it isn't authenticating to purestake correctly.
Setting additional request headers isn't supported, and it should be.

The token given in the AlgodClient constructor is used with the X-Algo-API-Token header key, while purestake is using x-api-token (and no X-Algo-API-Token) to authenticate its apis.

I should have a fix in soon @emaadgh :) and thanks for reporting these issues!
Currently updating the integration tests so I can change the AlgodClient, IndexerClient, and KmdClient settings from environment vars or inside the editor. This should let me easily test the clients against different nodes.

@emaadgh I went ahead and updated the docs too on how to customize the http headers. For purestake, you're going to wanna do something like
algod = new AlgodClient(
   "https://testnet-algorand.api.purestake.io/ps2/v2/status",
   ("x-api-key", "my-super-secret-api-key")
);

@emaadgh I went ahead and updated the docs too on how to customize the http headers. For purestake, you're going to wanna do something like
algod = new AlgodClient(
   "https://testnet-algorand.api.purestake.io/ps2/v2/status",
   ("x-api-key", "my-super-secret-api-key")
);

Thanks, Jason,
I've tested the new version with this custom header but I'm getting

Missing Authentication Token

from response of await algod.GetHealth(); .
I like to mention that the curl command is working with a schema like this in Command-Line with the same token :

curl -X GET "https://testnet-algorand.api.purestake.io/ps2/v2/status" -H "x-api-key:secret-token"

Hi @emaadgh ,
Sorry I had a typo in my URL. You want to use the root of the algod service:
https://testnet-algorand.api.purestake.io/ps2/v2


Clarify "classifiers"/"filters" wording

Per conversation on python-list (1, 2), the "Filter projects" section on the left-hand side of the page is not clearly related to the "list of classifiers", and

"Classifiers" is what the relevant package metadata is called, but it's not exactly what the average user would refer to that data as.

What can we do to both serve people who don't know what classifiers are and people who know that term and are specifically thinking in terms of classifiers?

#3410 adds an FAQ entry about adding a new classifier. As we get more consistent about talking about filters and classifiers, I'd like us to update this wording or add another FAQ to clarify where the "Trove"/"classifier" wording and master list originated.

Maybe introducing https://github.com/nepsilon/search-query-parser and letting users to type search queries like "Framework:Django" in the search bar will help promoting classifiers.

We could do something like this:
Filter by classifier :information_source:
Hovering your mouse over the icon could then launch a tooltip that describes what a classifier is.
@brainwane could you provide some appropriate text for this?

Gregory Ewing brought up "Categories" which seems, to me, a very sensible name for what we're talking about.
Here's text for the tooltip:

Each project's maintainers give PyPI a list of "trove classifiers" to use to categorize each release, describing who it's for, what systems it can run on, and how mature it is.

(Background, in case anyone wants to add an FAQ item: the original list of trove classifiers was drawn from Freshmeat and SourceForge lists.)
@drunkwcodes that's an interesting idea! I'm going to open a separate ticket for that. Thanks for bringing it up.


currency update fails

Hi.
When executing
/index.php?_url=/api/admin/currency/update_rates
they all go to zero exchange rate and when looking into the code at
/bb-modules/Currency/Service.php
it seems to be this bit
http://query.yahooapis.com/v1/public/yql?q=select rate%2Cname from csv where url%3D'http%3A%2F%2Fdownload.finance.yahoo.com%2Fd%2Fquotes%3Fs%3D".$from_Currency.$to_Currency."%253DX%26f%3Dl1n' and columns%3D'rate%2Cname'&format=json
which if tested in a browser throws this error
"Invalid URL http://download.finance.yahoo.com/d/quotes?s=".$from_Currency.$to_Currency."%3DX&f=l1n: Illegal character in query at index 45: http://download.finance.yahoo.com/d/quotes?s=".$from_Currency.$to_Currency."%3DX&f=l1n"
BoxBilling doc says
http://docs.boxbilling.com/en/latest/reference/currency.html?highlight=currency update
"Currency rates are taken form google.com" (but it is stamped with 2012, so either 2012 is wrong, or the info on the doc page).
Either way, what is the fix?

I'm wondering if you're still facing the issue. I faced the same issue today. So, I have changed few lines under the _getRate function in the /bb-modules/Currency/Service.php page. I have used the API
from https://free.currencyconverterapi.com.
Replace the whole  _getRate function with this
protected function _getRate($from, $to)
    {
        $from_Currency = urlencode($from);
        $to_Currency   = urlencode($to);
        $url = "http://free.currencyconverterapi.com/api/v5/convert?q=".$from_Currency."_".$to_Currency."&compact=y";
        $ch = curl_init();
        curl_setopt ($ch, CURLOPT_URL, $url);
        curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
        curl_setopt($ch,  CURLOPT_USERAGENT , "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)");
        curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, 10);
        $json = curl_exec($ch);
        $array = json_decode($json, true);
        return (float)$array[$from_Currency."_".$to_Currency]['val'];
    }


upgrade to lodash 4.x

i changed the code a little bit to use the new require schema of lodash.

no problem at all, good job!


Possible bug: Always uses Side::Bid when booting out the lowest order

Again, not totally sure if intentional behaviour or bug but this one seems more suspicious.
When removing the lowest order from the orderbook the code always uses side: Side::Bid whereas it should probably use side: side. It looks like serum v3 uses different sides depending which kind of order is being booted, bids here and asks here.
Then in the consume events code for dex v4, the settling behaviour is different depending on whether it's from the bid or ask side.
So it certainly seems like a miscategorized side in an event could be an issue.
https://github.com/Bonfida/agnostic-orderbook/blob/71242678400eb942af555d19affa4c2d8554c805/program/src/orderbook.rs#L278-L285

Thanks for the catch! This is indeed a bug. Closing this issue with PR #32.

So I did the maths on this and at least for v4 this could have been exploited pretty badly.
The attack vector is:

Put in an order with a very high price, e.g. $100 for 1 base token
The highest order is removed
It gets processed as a bid
This is essentially the same as getting filled. In v4 it would mean the user gets price * quantity worth of quote tokens returned to them, so $100 in this example. While the true price is much lower.


caffe-server: error while loading shared libraries: libcaffe.so.1.0.0: cannot open shared object file: No such file or directory

Hi,
when starting up the GRE I got the following error:
caffe-server: error while loading shared libraries: libcaffe.so.1.0.0: cannot open shared object file: No such file or directory
Environment:

Amazon EC3 p2.xlarge instance, booted with the DIGITS 6 Ubuntu 16.04 image (downloaded today).
gpu-rest-engine master branch, HEAD of today.
built the docker image with caffe using the instructions from README.md

When I start up the container:
ubuntu@ip-xxx-xx-xx-xxx:~/dev/gpu-rest-engine$ nvidia-docker run -it --net=host --rm inference_server  /bin/bash
root@ip-xxx-xx-xx-xxx:/opt/caffenet# caffe-server
caffe-server: error while loading shared libraries: libcaffe.so.1.0.0: cannot open shared object file: No such file or directory
This seems to fix the problem:
root@ip-xxx-xx-xx-xxx:/opt/caffenet# ldconfig
root@ip-xxx-xx-xx-xxx:/opt/caffenet# caffe-server
panic: runtime error: index out of range
goroutine 1 [running]:
main.main()
/go/src/caffe-server/main.go:43 +0x45e
My first guess was this commit, but purely based on the log message:
634441D - Execute ldconfig after "make install", not in a separate layer
When I roll back my GRE working copy to commit f4294f7, cleanup and rebuild from scratch, I get a perfectly working image.
regards,
Lieven

What's your version of docker?

Ah no, I see, you're right. There is an issue with ldconfig, but it didn't show up for me because I was using nvidia-docker 2.0.
Can you confirm you are using nvidia-docker 1.0?

Hi, yeah I'm using v1 of nvidia-docker:
$ apt search nvidia-docker
nvidia-docker/now 1.0.1-1 amd64 [installed,local]
NVIDIA Docker container tools

Fixed, thanks for the bug report!


Use the same kind of strings for radio values

It aims to fix issue #12386.

/botio test

/botio-linux preview

Thanks!


 Javascript console prints:
{"message":"(psycopg2.errors.ForeignKeyViolation) update or delete on table "flow" violates foreign key constraint "message_flow_id_fkey" on table "message"\nDETAIL:  Key (id)=(33e0480a-77b8-4636-b08f-ab4f40eb1284) is still referenced from table "message".\n\n[SQL: DELETE FROM flow WHERE flow.id = %(id_1)s::UUID]\n[parameters: {'id_1': '33e0480a-77b8-4636-b08f-ab4f40eb1284'}]\n(Background on this error at: https://sqlalche.me/e/20/gkpj)"}
Expected behavior
Option 1) Cascading delete: deleting a flow deletes all related rows on all related history tables (ideal)
Option 2) Notify to user to manually delete all related content first.
Who can help?
No response
Operating System
Ubuntu 22.04
Langflow Version
1.0.14
Python Version
3.10
Screenshot
No response
Flow File
No response

@hakan-77
Could you try on version 1.0.15 and check if persists?


[Bug]Suggestion - Mongo DB - The response n:1 on insert, n:1 on count , n:1Modified on Update can be renamed with Document inserted successfully, Document updated successfully and Document modified successfully

Description
Release Environment - Mongo DB - It is observed that the response message for insert, count , modified are displayed as n:1 , n:n and n:1 modified
Expected Result:
The response can be renamed with Document name Inserted successfully, Document count is 3, Document is modified successfully or any appropriate messages
Actual Result:
For the insert , Count and modified the response message is displayed as n:1, n:n and n:

1 modified
Steps to reproduce the behaviour:

Launch appsmith app in the release environment
2.Expand DB and click on create new DataSource
3.Choose DB as Mongo Plugin
4.Choose option as with uri and pass the following uri -<EMAIL_ADDRESS>5.Click on Create new Query
6.Choose the type as Form input
choose the command as 'Insert a document'
Enter collection name in the insert query enter the following query
{
"documents": [
{ "_id": 1, "user": "Appsmith", status: "Active" }
]
}
observe the response message for insert document
Similarly, try for count and Update secnario

Important Details
Version: [14.1 (166<IP_ADDRESS>.3)]
OS: [MacOS Big sur 11.3]
Browser [Safari]

This is a breaking change for all the existing apps who are relying on the response to be of the aforementioned type. Should this be taken up?


Enforce certain CSS properties to use CSS variables (stylelint-declaration-strict-value)

Added stylelint-declaration-strict-value plugin to enforce the following properties to use variables:

any property with "color";
font-family and font-weight;
z-index;

Closes #11

Good job 👍
Normally the commit message is in the present tense.
Another note, before the merge we squash all commits.
Besides that, all good 👍


(re)added 2022-05-04-preview to Azure.DataCollaboration [Do not Merge this PR Please]

ARM API Information (Control Plane)
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

We cannot use the OpenAPI experience, because our product exists only in Azure:dev-datacollaboration-Microsoft.DataCollaboration-2020-05-04-preview branch, so the tool to not identify our product to allow its usage.

Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
- New API version will be deployed behind a private feature flag to our PROD regions (WUS, EUS2, WEU) ASAP (June 2022) depending only on ARM this review.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
- New API swagger documentation will be made available for private feature user only ASAP (June 2022) depending only on ARM this review.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[x] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[x] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

"Workspace": {

This is a Tracked Resource. Modeling is not done right. Tags need to be top level property

Refers to: specification/datacollaboration/resource-manager/Microsoft.DataCollaboration/preview/2022-05-04-preview/DataCollaboration.json:11561 in ca400e0. [](commit_id = ca400e0e8ccde2946a79da798ce31b8b3a58cd23, deletion_comment = False)

Approving the changes.


feat: link check

add feature to check broken internal link. (ignore general URL)
this is required for tactic-cheatsheet, lean-book.

You can use this:
lycheeverse/lychee-action https://github.com/lycheeverse/lychee-action
mdgen does not need to support link-check.


Using a digital sensor

Using a DS18B20 sensor, which gives me a direct reading of the temperature in Celsius (float)
So "Input" is not an analog pin, but a variable that stores the temperature.
I don't know C++ well enough to understand how the code operates ; looking for clues.

Sorry I didn't reply sooner. I don't have an example that gets temperature without using the analog pin, but soon I'll be getting some new hardware and will be able to do testing on a similar setup and update the examples.

Just look on PID_basic example just store/assign your temperatue value in Input variable


TODO found environment.py (2)

TODO Found in src/core/environment.py
Line 120   # TODO this bit is dropped otherwise on a timeout...
Line 143  # TODO: decide what to do here.

Closing as duplicate of the "umbrella" code quality issue https://github.com/general-ai-challenge/Round1/issues/16


[PLUGIN REQUEST] strapi-provider-email-sendinblue

Name
strapi-provider-email-sendinblue
Link
https://github.com/lith/strapi-provider-email-sendinblue
Status
Ready
Author
@Lith

Closing this issue since it's in ready status! Thanks for your contribution 🚀


add wasd and hjkl move to ahokusa

wasd to hjkl de ugokeru youni natta kamo

Codecov Report

Merging #119 into master will not change coverage.
The diff coverage is 0%.

@@          Coverage Diff           @@
##           master    #119   +/-   ##
======================================
  Coverage    44.6%   44.6%
======================================
  Files          39      39
  Lines        3849    3849
  Branches      776     776
======================================
  Hits         1717    1717
  Misses       1684    1684
  Partials      448     448

Impacted Files
Coverage Δ

ahokusa/index.js
59.64% <0%> (ø)
:arrow_up:

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 e0c8a0e...6f9f565. Read the comment docs.


Changed the JSON "tpe" field to "$type" and fixed the tests.

A re-targeted pull request for #113/#131 (Fixes #64) originally requested by @Ahnfelt

Looks safe and worthwhile, +1

The original commit targeted to 0.9.x has gone out of date, so I rebased to it to the current head.
#113 says:

Yep, we'd like this to be part of our upcoming 0.9.0 release :)

So once Travis passes, I'm merging this in.


Could we get an option to set a default zoom level in settings?

It'd be helpful to have the option to set a default zoom level for displaying the player content- as things stand, it's almost unusable at resolutions below 1920x1080, and even then- it's got so much whitespace and large text/graphics that it's a bit of a chore to use.
I've always set it at 90% or 75% in Chrome- it's a bit jarring to be jolted back to a forced standard zoom level with this player. Appreciate that the underlying design's Google's fault, but the zoom function's always been a way of working around the issue- it'd be nice to have the option to set it by default in the app's settings!

Ctrl + and Ctrl - shortcuts will be implemented soon #196


ndimage.map_coordinates performs incorrectly with several order values

The results given by map_coordinates are unexpected when testing the example given in the function description.
In particular, the order=None and order=1 are giving incorrect results. In the example below I compare the cpu and gpu versions of the function and show this. (cupy left, scipy right)
import cupy as cp
from cupyx.scipy.ndimage import map_coordinates as cupy_map_coordinates
from scipy.ndimage import map_coordinates as scipy_map_coordinates

arr = cp.arange(12.).reshape((4, 3))
points = cp.array([[0.5, 2], [0.5, 1]])

print(f"order={None} ->",
      cupy_map_coordinates(arr, points),
      scipy_map_coordinates(arr.get(), points.get())) # scipy defaults to order=3, but cupy gives only zeros
for order in [0, 1]:
    print(f"order={order} ->",
          cupy_map_coordinates(arr, points, order=order),
          scipy_map_coordinates(arr.get(), points.get(), order=order))

# order=None -> [0. 0.] [1.3625 7.    ]
# order=0 -> [0. 7.] [4. 7.]
# order=1 -> [2. 7.] [2. 7.]

OS                           : Windows-10-10.0.18362-SP0
CuPy Version                 : 8.3.0
NumPy Version                : 1.19.4
SciPy Version                : 1.5.3
Cython Build Version         : 0.29.21
CUDA Root                    : C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.1
CUDA Build Version           : 11010
CUDA Driver Version          : 11020
CUDA Runtime Version         : 11010
cuBLAS Version               : 11201
cuFFT Version                : 10300
cuRAND Version               : 10202
cuSOLVER Version             : (11, 0, 0)
cuSPARSE Version             : 11200
NVRTC Version                : (11, 1)
Thrust Version               : 100910
CUB Build Version            : 100910
cuDNN Build Version          : None
cuDNN Version                : None
NCCL Build Version           : None
NCCL Runtime Version         : None
cuTENSOR Version             : None
Device 0 Name                : GeForce GTX 1080 Ti
Device 0 Compute Capability  : 61

The None case seems to be fixed in v9.
order=None -> [1.3625 7.    ] [1.3625 7.    ]
order=0 -> [0. 7.] [4. 7.]
order=1 -> [2. 7.] [2. 7.]

Maybe @grlee77 can help with this :)

The None case seems to be fixed in v9.
order=None -> [1.3625 7.    ] [1.3625 7.    ]
order=0 -> [0. 7.] [4. 7.]
order=1 -> [2. 7.] [2. 7.]

Maybe @grlee77 can help with this :)

Yes, order=3 is implemented for CuPy 9.0 and in general various SciPy 1.6 bugfixes/enhancements have been incorporated in that branch that are not in CuPy 8.x.
There does indeed seem to be a difference in rounding when the coordinate is exactly 0.5, though. I will take a look at why. If I use
points = cp.array([[0.49999, 2], [0.49999, 1]])

or
points = cp.array([[0.50001, 2], [0.50001, 1]])

then I get agreement between CuPy and SciPy for all cases on CuPy 9.0.0b1, so I think any behavior difference lies in the direction of rounding at half integer coordinates.

Yes, order=3 is implemented for CuPy 9.0 and in general various SciPy 1.6 bugfixes/enhancements have been incorporated in that branch that are not in CuPy 8.x.
There does indeed seem to be a difference in rounding when the coordinate is exactly 0.5, though. I will take a look at why. If I use
points = cp.array([[0.49999, 2], [0.49999, 1]])

or
points = cp.array([[0.50001, 2], [0.50001, 1]])

then I get agreement between CuPy and SciPy for all cases on CuPy 9.0.0b1, so I think any behavior difference lies in the direction of rounding at half integer coordinates.

Nice catch! @grlee77, just a quick thank you to you and the others who work on this - for me, now that map_coordinates and histogram2d* are implemented in CuPy, there is a whole lot image correction that is possible to consider doing for us physicists :) (that would have taken an awful lot longer before).

I installed cupy v9 today and realised it was there :)

Nice catch! @grlee77, just a quick thank you to you and the others who work on this - for me, now that map_coordinates and histogram2d* are implemented in CuPy, there is a whole lot image correction that is possible to consider doing for us physicists :) (that would have taken an awful lot longer before).

I installed cupy v9 today and realised it was there :)

Nice catch! @grlee77, just a quick thank you to you and the others who work on this - for me, now that map_coordinates and histogram2d* are implemented in CuPy, there is a whole lot image correction that is possible to consider doing for us physicists :) (that would have taken an awful lot longer before).

Thanks, it is nice to hear how others are using the library! The CuPy team has been great on reviewing and merging these community-driven ndimage PRs. NVIDIA's RAPIDS team should also get credit for sponsoring effort toward ndimage improvements.
The half integer rounding issue seems specific to order=0 and should be fixed by: #4552.

Nice catch! @grlee77, just a quick thank you to you and the others who work on this - for me, now that map_coordinates and histogram2d* are implemented in CuPy, there is a whole lot image correction that is possible to consider doing for us physicists :) (that would have taken an awful lot longer before).

Thanks, it is nice to hear how others are using the library! The CuPy team has been great on reviewing and merging these community-driven ndimage PRs. NVIDIA's RAPIDS team should also get credit for sponsoring effort toward ndimage improvements.
The half integer rounding issue seems specific to order=0 and should be fixed by: #4552.


ARTEMIS-3289 Reduce journal appender executor Thread wakeup cost

https://issues.apache.org/jira/browse/ARTEMIS-3289
https://issues.apache.org/jira/browse/ARTEMIS-3290

@TomasHofman I see that you've worked on https://issues.apache.org/jira/browse/ARTEMIS-3037.
My changes for https://issues.apache.org/jira/browse/ARTEMIS-3290  are merging the append attempt with the checkKnowRecordID while happening on the appender thread.
But I see that the appender methods are not handling Thread interruption while awaiting to enter the read lock(!!!) that seems like a bug of the original implementation too, agree?

@clebertsuconic @gtully
I'm not totally sold about the current semantic while checking for record ID presence: if sync == false (as ReplicationEndpoint) it seems that JournalBase is going to use DummyCallback.getInstance() as callback, meaning that it won't expect to block ever, but the existing semantic that check for record presence will make the caller thread to block until the record presence is verified, is it correct?
I would expect instead that if sync == false the caller thread won't get any error back, if not for something that can be verified on the same thread eg the new lock-free knownRecordID check.

I need to run some benchmark using replication to see how much it worths both changes :+1:

I've run some benchmarks vs this version getting these results on the replica:
main total broker CPU usage = ~1000 samples.
430 samples on (5) I/O threads + 570 samples on replication endpoint thread
155 samples/ 570 samples on replication endpoint thread are spent to awake the I/O threads.
this PR total broker CPU usage = ~664 samples
171 samples on a single I/O thread + 492 samples on replication endpoint thread
91 samples/570 samples on replication endpoint thread are spent to awake the single I/O thread.
TLDR: The improvement in term of CPU usage is ~30% (!!!!)
Throughput is slightly improved for the single producer/single consumer case, but not dramatically.
The improved CPU usage instead means having more room to handle I/O, but I don't have a big enough machine to test this case.

@clebertsuconic I haven't been able to run scale tests with more then 32 clients because I was hitting the issue reported here https://github.com/apache/activemq-artemis/pull/3558#issuecomment-841664877 with both this PR and main too, so I suppose it worth to address it

@clebertsuconic @michaelandrepearce @gtully
One important note related the default thread pool(s) configuration of the broker.
Just to have some fun, I've played a bit with the thread configuration in order to reduce the number of context switched of master and this is the improvement I got:
**************
RUN 1	EndToEnd Throughput: 51031 ops/sec
**************
EndToEnd SERVICE-TIME Latencies distribution in MICROSECONDS
mean                346.02
min                  92.67
50.00%              321.54
90.00%              444.42
99.00%              626.69
99.90%             4014.08
99.99%            14942.21
max               22020.10
count              1600000

Same test as https://github.com/apache/activemq-artemis/pull/3572#issuecomment-841677475, where I was getting 37770 ops/sec
I've just reduced the acceptor thread pool size to be 1/2 of the available cores (instead of 3X), while leaving the rest to the thread-pool-max-size (instead of having it to be 30).
eg on a 16 cores machines -> 8 threads for Netty + 8 threads for Artemis generic thread pool.
Given that core protocol perform very few operations on the Netty threads I've decided to split the CPU capacity in 2.
The boost is A LOT, hence I think we should re-think the default parameters we set for the broker wdyt?
I'm going to file a new issue if you agree

By using the improved broker configuration on https://github.com/apache/activemq-artemis/pull/3572#issuecomment-841788187, I've been able to run some tests with 32 producers/consumers and this PR is indeed delivering a huge speedup under heavy load
main:
**************
RUN 1	EndToEnd Throughput: 51037 ops/sec
**************
EndToEnd SERVICE-TIME Latencies distribution in MICROSECONDS
mean               2740.07
min                 102.91
50.00%              565.25
90.00%             6258.69
99.00%            48496.64
99.90%            82837.50
99.99%            95944.70
max               96993.28
count              3200000

this PR:
**************
RUN 1	EndToEnd Throughput: 60405 ops/sec
**************
EndToEnd SERVICE-TIME Latencies distribution in MICROSECONDS
mean                611.91
min                  95.23
50.00%              471.04
90.00%              700.42
99.00%             4358.14
99.90%            10158.08
99.99%            18350.08
max               29097.98
count              3200000

I see that the very last version that's using a ThreadPoolExecutor + an ordered executor isn't getting the same performance of the ExclusiveExecutor I've built https://github.com/apache/activemq-artemis/pull/3572#issuecomment-841792315, hence I'm going to revert to the original abstraction
**************
RUN 1	EndToEnd Throughput: 54793 ops/sec
**************
EndToEnd SERVICE-TIME Latencies distribution in MICROSECONDS
mean              20899.53
min                  92.67
50.00%              561.15
90.00%            84410.37
99.00%           211812.35
99.90%           333447.17
99.99%           385875.97
max              404750.34
count              3200000

Going to try some more tests to be sure of this

I've reverted the executor change, re-applying the original ExclusiveExecutor code and removing the usage of JCTools qs, getting back just some of the original performance of https://github.com/apache/activemq-artemis/pull/3572#issuecomment-841792315 but still with ugly 90 percentiles: still investigating what's going on

I see that I'm not getting anymore the improvement of the first version of this PR (removing the correct thread pool sizing):
**************
RUN 2	EndToEnd Throughput: 33550 ops/sec
**************
EndToEnd SERVICE-TIME Latencies distribution in MICROSECONDS
mean                728.90
min                 135.17
50.00%              565.25
90.00%              819.20
99.00%             5210.11
99.90%            10420.22
99.99%            23855.10
max               24510.46
count               160000

Found the reason of the regression: the changes for https://issues.apache.org/jira/browse/ARTEMIS-3290 are impacting differently from the original runs and I'm getting again some sync check for known record ID that slow down replica append update records.
Probably worth re-thinking https://issues.apache.org/jira/browse/ARTEMIS-3290 to save the sync call to happen as a whole.

I've cleanup machines and performed some tests (again) with the previous version of this PR vs last commit, without getting any evident regressions. I need to cleanup the exclusive executor impl putting it into a separate package (+ some tests) and we're ready to go: in the best case this PR is delivering a nice speedup in both throughput and latencies but the most noticeable benefit come from CPU usage, 30% less under mild load for backup.

This is the last comparison of main vs this PR with 32 producers.
main:
**************
RUN 1	EndToEnd Throughput: 52667 ops/sec
**************
EndToEnd SERVICE-TIME Latencies distribution in MICROSECONDS
mean                638.65
min                 104.45
50.00%              573.44
90.00%              884.74
99.00%             2015.23
99.90%             7045.12
99.99%            11141.12
max               21233.66
count              3200000

this PR
**************
RUN 1	EndToEnd Throughput: 57492 ops/sec
**************
EndToEnd SERVICE-TIME Latencies distribution in MICROSECONDS
mean                725.65
min                  94.72
50.00%              501.76
90.00%             1286.14
99.00%             4685.82
99.90%            10616.83
99.99%            17563.65
max               25690.11
count              3200000

Despite what looks to be a better latency profile for main the reality is that the new version is capable of pushing a bit more throughput with a better CPU usage overall, that could be used elsewhere (more load or GC).

Closing this to be reopened in the future


Use correct quotes for file extensions and settings examples

https://www.typescriptlang.org/docs/handbook/compiler-options.html

the problem

Great! Thanks


Add documentation for contributors

We use Docz extensively in our dev team (and in my personal projects too). I am extremely grateful for this amazing tool and would love to give back/contribute.
However (apart from the distinction between the docz and docz-core folder) there is not a lot of supporting documentation explaining the underlying architecture and conventions. I also don't see the addition of additional contributor documentation mentioned in the project roadmap (http://feedback.docz.site/roadmap).
I'm happy to help create this documentation if someone in the team or someone with experience contributing is able to give me a basic overview of the architecture.

hey! as a new contributor i'd love this too. not actually sure who apart from Pedro we can ask. I'd love for him to sketch out some outlines.

Hi folks, sorry the too late response I was very busy with the v1.
Now that I have the v1 released, I'll try to improve our contribution guide in order to be more easy to understand and help me in the project.
Btw, we really need core developers to help and maintain Docz 🙏


[ MB-15948 ] Customer contact fields optional for destination service items

Jira ticket
Summary
These changes modify the relationship between the service items and the customer contacts to be a many to many relationship. Each customer contact is attached to the destination service items upon creation, and subsequent edits to the customer contacts will be associated with each service item.
There needed to be modifications to some of our fetches that included Customer Contacts in the EagerPreload fields. This had to do with a conflict in how Pop queries for the field in EagerPreload vs how Pop queries for the field when storing the relationships on a Many to Many table. Customer Contacts was moved out of these EagerPreloaded fields into its own subsequent loads. This is less efficient, so we are only doing these loads for destination SIT service items.
Please give extra scrutiny to the migration file, there is a sql query that will create the many to many relationship entries on the join table and then deletes any orphaned records.
Changes
I am going to go through the changes that I made here in an order that I think might make it easier to digest:
Migration
There is a new  migration and the manifest has the requisite update.
The migration creates the  many to many table and creates the new associations of the existing service items and customer contacts
Model Changes

Addition of the many to many table service_items_customer_contacts
Change from has_many to many_to_many for the service items and customer contacts

MTO Service Item Services changes
The functional changes of how we create and update the customer contacts and associate them with the service items.

mto_service_item_validator.go - make the customer contact fields optional and set the new customer contacts
mto_service_item_creator.go - create the customer contacts first and then attach them to the service item
mto_service_item_updater.go - attach the related service items to the customer contacts and either create or update the customer contacts

Switches from EagerPreload to an ad hoc Load
Because of a difference in how Pop builds the column name when fetching many to many relationships with EagerPreload and what Pop expects when it saves these relationships we had to switch a couple of queries to using Load for CustomerContacts.

ghcapi/mto_service_items.go
move_task_order_fetcher.go

Primeapi

model to payload - fix for a small related bug
payload to model - update to validation to make CC fields optional

Prime Simulator UI

Making the customer contact fields optional

Prime Swagger Def

Modification of the documentation of the Destination SIT service items to reflect that the customer contact fields are now optional.
There are also the generated file changes that come with this change

Tests and test data generation

There were a few changes to the test data generation to reflect the changes to the relationship between the customer contacts and service items

Verification Steps for the Author
These are to be checked by the author.

[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] Have the Jira acceptance criteria been met for this change?

Verification Steps for Reviewers
These are to be checked by a reviewer.
Setup to Run the Code

Instructions for starting storybook
Instructions for starting the MilMove application
Instructions for running tests

How to test

Create a DDFSIT service item using Postman to send a request to the createMTOServiceItem endpoint, provide both first and second customer contact fields.

Here is a sample request body

{
 "modelType": "MTOServiceItemDestSIT",
 "moveTaskOrderID": "<move id>",
 "mtoShipmentID": "<shipment id>",
 "reServiceCode": "DDFSIT",
 "sitEntryDate": "2023-04-23",
 "firstAvailableDeliveryDate1": "2023-06-21",
 "timeMilitary1": "1530Z",
 "firstAvailableDeliveryDate2": "2023-07-31",
 "timeMilitary2": "1300Z",
 "sitDepartureDate":"2022-08-18"
}

You should see a response returned of three service items with the first and second customer contact fields attached
You should also be able to verify in you local DB that only two customer contacts were created and 6 service_item_customer_contact relationship records were created
Here is a sample video of the process using Postman: https://dp3.atlassian.net/wiki/spaces/~62dff422bc2c449f3d9403fd/pages/2145452059/Videos+for+testing+MB-15948#Creating-2-customer-contacts-when-creating-destination-SIT-service-items

Create a DDFSIT service item using Postman to send a request to the createMTOServiceItem endpoint, provide only the first customer contact fields.

Here is a sample request body

{
 "modelType": "MTOServiceItemDestSIT",
 "moveTaskOrderID": "<move id>",
 "mtoShipmentID": "<shipment id>",
 "reServiceCode": "DDFSIT",
 "sitEntryDate": "2023-04-23",
 "firstAvailableDeliveryDate1": "2023-06-21",
 "timeMilitary1": "1530Z",
 "sitDepartureDate":"2022-08-18"
}

You should see a response returned of three service items with the first customer contact fields attached
You should also be able to verify in you local DB that only one customer contact was created and 3 service_item_customer_contact relationship records were created

Now update the DDDSIT service item using postman to send a request to the updateMTOServiceItem endpoint, provide bot the first and second customer contact fields

Here is a sample request body

{
 "modelType": "UpdateMTOServiceItemSIT",
 "sitEntryDate": "2023-12-24",
 "firstAvailableDeliveryDate1": "2023-12-21",
 "timeMilitary1": "1530Z",
 "firstAvailableDeliveryDate2": "2023-12-31",
 "timeMilitary2": "1300Z",
 "reServiceCode": "DDDSIT"
}

You will also need the etag and the id of the DDDSIT service item.
You should see a response returned of the DDD service item with the first and second customer contact fields attached
If you refetch the move with the getMoveTaskOrder endpoint, you will see that the first and second customer contact fields are attached to all three destination SIT service items
You should also be able to verify in you local DB that a second customer contact was created and 3 more service_item_customer_contact relationship records were created
Here is a sample video of the process using Postman: https://dp3.atlassian.net/wiki/spaces/~62dff422bc2c449f3d9403fd/pages/2145452059/Videos+for+testing+MB-15948#Creating-and-updating-customer-contacts-when-updating-destination-SIT-service-items

Frontend

[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, Edge).
[ ] There are no new console errors in the browser devtools.
[ ] There are no new console errors in the test output.
[ ] If this PR adds a new component to Storybook, it ensures the component is fully responsive, OR if it is intentionally not, a wrapping div using the officeApp class or custom min-width styling is used to hide any states the would not be visible to the user.

Backend

[ ] Code follows the guidelines for Logging.
[ ] The requirements listed in Querying the Database Safely have been satisfied.

Database
Any new migrations/schema changes:

[ ] Follows our guidelines for Zero-Downtime Deploys.
[ ] Have been communicated to #g-database.
[ ] Secure migrations have been tested following the instructions in our docs.

Screenshots

Warnings

:warning:
Please add the JIRA issue key to the PR title (e.g. MB-123)

  Generated by :no_entry_sign: dangerJS against be85e3d9b17bfc66e3672537ff64076ece6c48a8

@mmayo-truss I had written some placeholder tests that would be relevant after Namibia's PR were merged. Since those changes have been merged do you mind uncommenting this line. It looks like the comment setting up the reason in the service item has already been uncommented.


[WICKET-6999] Update bundle plugin to support slf4j [1.7,3)

[x] Initial PR for review
[x] Add a Karaf feature file to help with installs (and future itests)
[x] Add bundle headers to wicket-websocket, etc
[x] Fix OsgiClashingPackagesTest.collectProjectPackages() unit test
[x] Finalize Require-Capability header yes|no, version various on branches?
[x] Uncomment _noee = true to disable Require-Capability header

At issue is the bundle plugin runs different at various maven phases. When combined with the enforcer plugin to restrict config to an execution, the bundle plugin definition will get chatty and redundant.
Thoughts?

Commit f2edd61 fixes bundle plugin execution phase+goal to generate correct MANIFEST and allow for enforcer plugin to be maintained.

wicket-request:
Export-Package =
	org.apache.wicket.request;version=10.0.0,
	org.apache.wicket.request.flow;version=10.0.0,
	org.apache.wicket.request.handler;version=10.0.0,
	org.apache.wicket.request.handler.logger;version=10.0.0,
	org.apache.wicket.request.http;version=10.0.0,
	org.apache.wicket.request.http.flow;version=10.0.0,
	org.apache.wicket.request.http.handler;version=10.0.0,
	org.apache.wicket.request.mapper;version=10.0.0,
	org.apache.wicket.request.mapper.info;version=10.0.0,
	org.apache.wicket.request.mapper.parameter;version=10.0.0,
	org.apache.wicket.request.parameter;version=10.0.0
Import-Package =
	org.slf4j;version="[1.7,3)",
	jakarta.servlet.http;version="[5.0,6)",
	org.apache.commons.collections4;version="[4.4,5)",
	org.apache.wicket.util;version="[10.0,11)",
	org.apache.wicket.util.encoding;version="[10.0,11)",
	org.apache.wicket.util.io;version="[10.0,11)",
	org.apache.wicket.util.lang;version="[10.0,11)",
	org.apache.wicket.util.string;version="[10.0,11)",
	org.apache.wicket.util.time;version="[10.0,11)"

NOTE: Generate export packages list for wicket-core
% find . -name "*.java" -exec grep "^package" {} \; | cut -f2 -d" " | sort -u

I've removed the DynamicImport-Package: * rule. I think that should only be needed by the application wars to support modular pages and allow Wicket to instantiate those classes from the war's classpath.

I've removed the DynamicImport-Package: * rule. I think that should only be needed by the application wars to support modular pages and allow Wicket to instantiate those classes from the war's classpath.

I think it would be better not to remove DynamicImport-Package: *, because of deserialization problems in OSGi env (Wicket need to know all classes serialized inside components from other bundles). It can be achieve in different way, but I think it requires more changes in the framework.

@dstoch the actual application bundle would need to do that as they require. Further backing evidence is the Wicket 8.x bundles do not have 'DynamicImport-Package: *' specified.

@dstoch the actual application bundle would need to do that as they require. Further backing evidence is the Wicket 8.x bundles do not have 'DynamicImport-Package: *' specified.

MANIFESTs are broken since Wicket 8.x, so it is not a good evidence ;).

MANIFESTs are broken since Wicket 8.x, so it is not a good evidence ;).

What is broken? We've been running unmodified bundles on Wicket 8.x for years.

I described a problem in this issue description in JIRA. Eg. without exporting org.apache.wicket.markup.html.internal package is not possible to use Wicket in OSGi. Do you really use it in OSGi without problems? I wonder how is this possible, maybe you don't use the code which requires abstractions from this packages?

I described a problem in this issue description in JIRA. Eg. without exporting org.apache.wicket.markup.html.internal package is not possible to use Wicket in OSGi. Do you really use it in OSGi without problems? I wonder how is this possible, maybe you don't use the code which requires abstractions from this packages?

Correct. We do not extend anything from that package. If you see in the above, the new OSGi wiring includes exporting that package from wicket-core.

I described a problem in this issue description in JIRA. Eg. without exporting org.apache.wicket.markup.html.internal package is not possible to use Wicket in OSGi. Do you really use it in OSGi without problems? I wonder how is this possible, maybe you don't use the code which requires abstractions from this packages?

Keep in mind-- if you need to extend packages that have not been exported you can create a fragment bundle to attach your extension classes. Generally, things like 'internal' are not exported since they are not part of a proper API or SPI.

Generally, things like 'internal' are not exported since they are not part of a proper API or SPI.

In OSGi world it is indeed. But as I wrote in description in Wicket they are part of API (maybe these packages should not have "internal" word in name).

Agreed, Wicket's API+SPI definition and encapsulation could be better. The API+SPI should be separated into its own jar and only include interfaces and POJO classes. I created https://issues.apache.org/jira/browse/WICKET-6855 to open discussion on this, but I didn't articulate the use case in a meaningful way.

Let me get a couple more done. For sure we should have the web socket bundles in good shape

New feature to ease installs on Apache Karaf
karaf@root()> repo-add mvn:org.apache.wicket/wicket/10.0.0-M1-SNAPSHOT/xml/features
Adding feature url mvn:org.apache.wicket/wicket/10.0.0-M1-SNAPSHOT/xml/features
karaf@root()> feature:list | grep -i wicket
wicket-core                       │ 10.0.0.M1-SNAPSHOT │          │ Uninstalled │ org.apache.wicket.wicket-10.0.0-M1-SNAPSHOT │
karaf@root()> feature:info wicket-core
Feature wicket-core 10.0.0.M1-SNAPSHOT
Feature has no configuration
Feature has no configuration files
Feature has no dependencies.
Feature contains followed bundles:
  mvn:com.github.openjson/openjson/1.0.12
  mvn:commons-io/commons-io/2.11.0
  mvn:commons-fileupload/commons-fileupload/2.0-SNAPSHOT
  mvn:org.apache.commons/commons-collections4/4.4
  mvn:org.danekja/jdk-serializable-functional/1.9.0
  mvn:org.apache.wicket/wicket-util/10.0.0-M1-SNAPSHOT
  mvn:org.apache.wicket/wicket-request/10.0.0-M1-SNAPSHOT
  mvn:org.apache.wicket/wicket-core/10.0.0-M1-SNAPSHOT
  mvn:org.apache.wicket/wicket-auth-roles/10.0.0-M1-SNAPSHOT
  mvn:org.apache.wicket/wicket-devutils/10.0.0-M1-SNAPSHOT
  mvn:org.apache.wicket/wicket-extensions/10.0.0-M1-SNAPSHOT
  mvn:org.apache.wicket/wicket-jmx/10.0.0-M1-SNAPSHOT
Feature has no conditionals.

Updated user guide w/ Apache Karaf feature info


Update GH actions script

Description
This PR updates the GH actions script to use v3 instead of v2 for the checkout action.
Changes include

[ ] Bugfix (non-breaking change that solves an issue)
[ ] Hotfix (change that solves an urgent issue, and requires immediate attention)
[x] New feature (non-breaking change that adds functionality)
[ ] Breaking change (change that is not backwards-compatible and/or changes current functionality)

Checklist

[x] I have assigned this PR to myself
[x] I have added at least 1 reviewer
[x] I have added the relevant labels
[ ] I have updated the official documentation
[ ] I have added sufficient documentation in code

Testing

[x] I have tested this code with the official test suite
[ ] I have tested this code manually

@ZeljkoBenovic
Is notify-deployer still relevant?


v1.2.4 breaks my webpack build

Upgraded to v1.2.4 and webpack build failed:
Module not found: Error: Can't resolve 'font-awesome-icon-chars' in ...
If I run the command npm install --save-dev<EMAIL_ADDRESS>the webpack build succeeds.

Could you give me full error or the sample project to reproduce it?

It seems that dist directory is missing on NPM registry. 😱
I just look on unpkg.
I will fix it ASAP. Thank you for reporting.

@mainstreetmark I've republished with 1.2.5. Please try it and tell me.

It appears that 1.2.5 resolve this issue. Now, closed.

Yeah, sorry.  I'm at 1.2.5 now and it works.  Thanks.


Change Synapse Gateway to API Gateway

Update the name of Synapse Gateway to API Gateway.

@samgnaniah Dont we have to change mkdocs yaml too to change the page name appearing on the side menu?

@samgnaniah Dont we have to change mkdocs yaml too to change the page name appearing on the side menu?

Fixed with 41463bd


[Event Request] codeunit 90 "Purch.-Post" - OnBeforeGetPurchLines

In codeunit 90 "Purch.-Post" please add the following event:
    procedure GetPurchLines(var PurchHeader: Record "Purchase Header"; var PurchLine: Record "Purchase Line"; QtyType: Option General,Invoicing,Shipping)
    begin
        FillTempLines(PurchHeader, TempPurchLineGlobal);
        // New event
        OnBeforeGetPurchLines(PurchHeader, PurchLine, QtyType, TempPurchLineGlobal);
        // New event
        if QtyType = QtyType::Invoicing then
            CreatePrepmtLines(PurchHeader, false);
        SumPurchLines2(PurchHeader, PurchLine, TempPurchLineGlobal, QtyType, true);
    end;

    [IntegrationEvent(false, false)]
    local procedure OnBeforeGetPurchLines(var PurchHeader: Record "Purchase Header"; var PurchLine: Record "Purchase Line"; QtyType: Option; var TempPurchLineGlobal: Record "Purchase Line" temporary)
    begin
    end;

Thank you

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


[build] update gevent

The current version has a severe CVE warning.
This updates gevent to the latest released version.

Sorry, I think we need one more sync before merging given merge of dependency pinning


Upload file stream to S3 by web api

The Question
I have the ASP.NET MVC API project and want to design the upload file stream web API, which stores to S3 bucket. I have tried the code is correct and can work in the console app project, but when I copy my code to the API project, it will keep waiting for the response messages for a long time.
public void uploadS3(long DrugsID,string sCategory, FileStream fs, out bool Result, out string Exe_Msg)
{
    try
    {
        var fileTransferUtility = new TransferUtility(s3Client);
        FileInfo fi = new FileInfo(fs.Name);
        keyName = fi.Name;

        if (fs.Length > 0)
        {
	   fileTransferUtility.UploadAsync(fs, bucketName, fi.Name);
        }

        Result = true;
        Exe_Msg = string.Empty;
    }
    catch (AmazonS3Exception AWSe)
    {
        Result = false;
        Exe_Msg = AWSe.Message.ToString();
    }
    catch (FileNotFoundException IOe)
    {
        Result = false;
        Exe_Msg = IOe.Message.ToString();
    }
    catch (Exception e)
    {
        Result = false;
        Exe_Msg = e.InnerException.ToString();
    }
}

Environment

SDK Version: AWSSDK.S3
Package Version:
OS Info: Windows 10
Build Environment Visual Studio 2017
Targeted .NET Platform:  ASP.Net framework 4.7

This is a :question: general question

we have an asp.net mvc application hosted in aws. Updated awssdk.s3 nuget to latest and it stopped working. (no exception)
Tried both sync (Upload) and async (UploadAsync) methods.
It works for awssdk.s3 version <IP_ADDRESS>, awssdk.core version <IP_ADDRESS>

we have an asp.net mvc application hosted in aws. Updated awssdk.s3 nuget to latest and it stopped working. (no exception)
Tried both sync (Upload) and async (UploadAsync) methods.
It works for awssdk.s3 version <IP_ADDRESS>, awssdk.core version <IP_ADDRESS>

Today, I have installed these in my project, but it doesn't work. I try another method that is the low-level API method of the AWS S3, which can work. I don't understand the low-level API and the high-level API where the difference is?

This sounds like another issue that was happening in ASP.NET web applications where the async calls were hanging.  I released a fix for this today as of versions:
AWSSDK.Core <IP_ADDRESS>
AWSSDK.S3 <IP_ADDRESS>
Can you give these versions a try and let us know if it corrected this issue? This should fix the UploadAsync calls from hanging.

This sounds like another issue that was happening in ASP.NET web applications where the async calls were hanging. I released a fix for this today as of versions:
AWSSDK.Core <IP_ADDRESS>
AWSSDK.S3 <IP_ADDRESS>
Can you give these versions a try and let us know if it corrected this issue? This should fix the UploadAsync calls from hanging.

OK. I will try to create the new ASP.NET Web API project to test for this issue. Now, I installed the AWS SDK version list in my web API project, which is below.
  <package id="AWSSDK.Core" version="<IP_ADDRESS>" targetFramework="net47" />
  <package id="AWSSDK.S3" version="<IP_ADDRESS>" targetFramework="net47" />

I hope it can help you to find the solution method.

Closing this issue as the fix released should correct the problem and I have not heard back. Please reopen if the issue persists after upgrading to the latest versions.


Updates ctrl+enter checks for TextInput

Related Issue
Fixes #4575
Description
This ensures that the keyboard shortcut of Ctrl+Enter works when an inlineAction is assigned to a Text.Input.
Notes
In my own project, I had to use e.ctrlKey && e.charCode === 13 && this.inlineAction as my condition. This PR contains the fix for this, but I'm unsure whether it is OK because apparently charCode is deprecated and code should be used, but that doesn't appear in my types as an available option 🤷♂
How Verified
I have been writing my own control to display in adaptive code and it works there, so figured I'd bring across the change to here too.
Microsoft Reviewers: Open in CodeFlow

Closing this PR as the fix is now in this other PR: https://github.com/microsoft/AdaptiveCards/pull/4840