Fix headers for clang 6 build

Fixes these issues during the build:
------- Build details --------
  Using clang (/usr/bin/clang++) version '6.0.0' (string), 6 (major), 0 (minor), 0 (patch)
  Using bundled libc++ standard C++ library.
  Using lld linker
  Using llvm-ar : /usr/bin/llvm-ar
  Using fast way to relink  circularly dependent libraries (no FixDeps).
  ------------------------------
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonConsole/Private/PyFbxFactory.cpp(1): error: Expected PyFbxFactory.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonConsole/Private/PythonConsoleModule.cpp(1): error: Expected PythonConsoleModule.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonConsole/Private/PythonScriptFactory.cpp(1): error: Expected PythonScriptFactory.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonConsole/Private/SPythonConsole.cpp(1): error: Expected SPythonConsole.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonConsole/Private/SPythonLog.cpp(1): error: Expected SPythonLog.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/DirectoryScanner.cpp(1): error: Expected DirectoryScanner.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/PYRichTextSyntaxHighlighterTextLayoutMarshaller.cpp(1): error: Expected PYRichTextSyntaxHighlighterTextLayoutMarshaller.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/PythonEditorCustomization.cpp(1): error: Expected PythonEditorCustomization.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/PythonEditorStyle.cpp(1): error: Expected PythonEditorStyle.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/PythonProject.cpp(1): error: Expected PythonProject.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/PythonProjectEditor.cpp(1): error: Expected PythonProjectEditor.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/PythonProjectEditorCommands.cpp(1): error: Expected PythonProjectEditorCommands.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/PythonProjectEditorToolbar.cpp(1): error: Expected PythonProjectEditorToolbar.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/PythonProjectItem.cpp(1): error: Expected PythonProjectItem.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/PythonSyntaxTokenizer.cpp(1): error: Expected PythonSyntaxTokenizer.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/SProjectViewItem.cpp(1): error: Expected SProjectViewItem.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/SPythonEditableText.cpp(1): error: Expected SPythonEditableText.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/SPythonEditor.cpp(1): error: Expected SPythonEditor.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/SPythonProjectEditor.cpp(1): error: Expected SPythonProjectEditor.h to be first header included.
  /home/user/temp/HostProject/Plugins/UnrealEnginePython/Source/PythonEditor/Private/WhiteSpaceTextRun.cpp(1): error: Expected WhiteSpaceTextRun.h to be first header included.
  ERROR: Build canceled.

Just a note this still fails with:
  ------- Build details --------
  Using clang (/usr/bin/clang++) version '6.0.0' (string), 6 (major), 0 (minor), 0 (patch)
  Using bundled libc++ standard C++ library.
  Using lld linker
  Using llvm-ar : /usr/bin/llvm-ar
  Using fast way to relink  circularly dependent libraries (no FixDeps).
  ------------------------------
  Performing 190 actions (8 in parallel)
  [1/190] Compile UEPyAudio.cpp
  [2/190] Compile UEPyCapture.cpp
  [3/190] Compile UEPyController.cpp
  [4/190] Compile UEPyDataTable.cpp
  [5/190] Compile UEPyExporter.cpp
  [6/190] Compile UEPyHUD.cpp
  [7/190] Compile UEPyInput.cpp
  [8/190] Compile UEPyLandscape.cpp
  [9/190] Compile UEPyMaterial.cpp
  [10/190] Compile UEPyMovements.cpp
  [11/190] Compile UEPyNavigation.cpp
  [12/190] Compile UEPyObject.cpp
  [13/190] Compile UEPyPackage.cpp
  [14/190] Compile UEPyPawn.cpp
  [15/190] Compile UEPyPhysics.cpp
  [16/190] Compile UEPyPlayer.cpp
  [17/190] Compile UEPySequencer.cpp
  [18/190] Compile UEPySkeletal.cpp
  [19/190] Compile UEPySpline.cpp
  [20/190] Compile UEPyAttaching.cpp
  [21/190] Compile UEPyStaticMesh.cpp
  [22/190] Compile UEPyAnimSequence.cpp
  [23/190] Compile UEPyFSlateApplication.cpp
  [24/190] Compile UEPySPythonEditorViewport.cpp
  [26/190] Compile UEPySPythonShelf.cpp
  [25/190] Compile UEPySPythonListView.cpp
  [27/190] Compile UEPySPythonTreeView.cpp
  [28/190] Compile UEPySPythonWidget.cpp
  [29/190] Compile UEPySRotatorInputBox.cpp
  [30/190] Compile UEPySScrollBox.cpp
  [31/190] Compile UEPySSlider.cpp
  [32/190] Compile UEPySSpacer.cpp
  [33/190] Compile UEPySSplitter.cpp
  [34/190] Compile UEPySTableViewBase.cpp
  [35/190] Compile UEPySTextBlock.cpp
  [36/190] Compile UEPySTreeView.cpp
  [37/190] Compile UEPySVectorInputBox.cpp
  [38/190] Compile UEPySVerticalBox.cpp
  [39/190] Compile UEPySViewport.cpp
  [40/190] Compile UEPySWidget.cpp
  [41/190] Compile UEPySWindow.cpp
  [42/190] Compile UEPySlate.cpp
  [43/190] Compile UEPyActor.cpp
  [44/190] Compile UEPySPythonComboBox.cpp
  [45/190] Compile UEPyTexture.cpp
  [46/190] Compile UEPyTransform.cpp
  [47/190] Compile UEPyFSoftSkinVertex.cpp
  [48/190] Compile UEPyFStringAssetReference.cpp
  [49/190] Compile UEPyFTransform.cpp
  [50/190] Compile UEPyFVector.cpp
  [51/190] Compile UEPyFViewportClient.cpp
  [52/190] Compile PyActor.gen.cpp
  [53/190] Compile PyCharacter.gen.cpp
  [54/190] Compile PyCommandlet.gen.cpp
  [55/190] Compile PyHUD.gen.cpp
  [56/190] Compile PyNativeWidgetHost.gen.cpp
  [57/190] Compile PyPawn.gen.cpp
  [58/190] Compile PyUserWidget.gen.cpp
  [59/190] Compile PythonBlueprintFunctionLibrary.gen.cpp
  [60/190] Compile PythonClass.gen.cpp
  [61/190] Compile PythonComponent.gen.cpp
  [62/190] Compile PythonDelegate.gen.cpp
  [63/190] Compile PythonFunction.gen.cpp
  [64/190] Compile PythonScript.gen.cpp
  [65/190] Compile UnrealEnginePython.init.gen.cpp
  [66/190] Compile UEPyFSocket.cpp
  [67/190] Compile UEPyTraceAndSweep.cpp
  [68/190] Compile UEPyFSlowTask.cpp
  [69/190] Compile UEPyFRawMesh.cpp
  [70/190] Compile UEPyUserDefinedStruct.cpp
  [71/190] Compile UEPyViewport.cpp
  [72/190] Compile UEPyWidget.cpp
  [73/190] Compile UEPyWidgetComponent.cpp
  [74/190] Compile UEPyWorld.cpp
  [75/190] Compile UEPyIVoiceCapture.cpp
  [76/190] Compile UEPyESlateEnums.cpp
  [77/190] Compile UEPyFARFilter.cpp
  [78/190] Compile UEPyFAssetData.cpp
  [79/190] Compile UEPyFColor.cpp
  [80/190] Compile UEPyFEditorViewportClient.cpp
  [81/190] Compile UEPyFHitResult.cpp
  [82/190] Compile UEPyFLinearColor.cpp
  [83/190] Compile UEPyFMorphTargetDelta.cpp
  [84/190] Compile UEPyFObjectThumbnail.cpp
  [85/190] Compile UEPyFPythonOutputDevice.cpp
  [86/190] Compile UEPyFQuat.cpp
  [87/190] Compile UEPyFRandomStream.cpp
  [88/190] Compile UEPyFRawAnimSequenceTrack.cpp
  [89/190] Compile UEPyFRotator.cpp
  [90/190] Compile UEPySProgressBar.cpp
  [91/190] Compile UEPySPythonMultiColumnTableRow.cpp
  [92/190] Compile UEPySOverlay.cpp
  [93/190] Compile UEPyUClassesImporter.cpp
  [94/190] Compile UEPyUScriptStruct.cpp
  [95/190] Compile UEPyUStructsImporter.cpp
  [96/190] Compile UEPyVisualLogger.cpp
  [97/190] Compile UnrealEnginePython.cpp
  [98/190] Compile UEPyEdGraph.cpp
  [99/190] Compile UEPyEdGraphPin.cpp
  [100/190] Compile UEPyICollectionManager.cpp
  [101/190] Compile UEPyIConsoleManager.cpp
  [102/190] Compile UEPyFbxIOSettings.cpp
  [103/190] Compile UEPyFbxImporter.cpp
  [104/190] Compile UEPyFbxManager.cpp
  [105/190] Compile UEPyFbxMesh.cpp
  [106/190] Compile UEPyFbxNode.cpp
  [107/190] Compile UEPyFbxObject.cpp
  [108/190] Compile UEPyFbxPose.cpp
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxIOSettings.cpp:1:
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxIOSettings.h:6:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk.h:98:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxloadingstrategy.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxplugin.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxobject.h:21:
  ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h:1188:70: error: binding dereferenced null pointer to reference has undefined behavior [-Werror,-Wnull-dereference]
                  return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);
                                                                                ^~~~~~~~~~~~~~~~~~~
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxImporter.cpp:1:
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxImporter.h:6:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk.h:98:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxloadingstrategy.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxplugin.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxobject.h:21:
  ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h:1188:70: error: binding dereferenced null pointer to reference has undefined behavior [-Werror,-Wnull-dereference]
                  return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);
                                                                                ^~~~~~~~~~~~~~~~~~~
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxManager.cpp:1:
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxManager.h:6:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk.h:98:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxloadingstrategy.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxplugin.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxobject.h:21:
  ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h:1188:70: error: binding dereferenced null pointer to reference has undefined behavior [-Werror,-Wnull-dereference]
                  return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);
                                                                                ^~~~~~~~~~~~~~~~~~~
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxMesh.cpp:2:
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxMesh.h:7:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk.h:98:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxloadingstrategy.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxplugin.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxobject.h:21:
  ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h:1188:70: error: binding dereferenced null pointer to reference has undefined behavior [-Werror,-Wnull-dereference]
                  return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);
                                                                                ^~~~~~~~~~~~~~~~~~~
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxNode.cpp:1:
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxNode.h:6:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk.h:98:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxloadingstrategy.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxplugin.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxobject.h:21:
  ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h:1188:70: error: binding dereferenced null pointer to reference has undefined behavior [-Werror,-Wnull-dereference]
                  return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);
                                                                                ^~~~~~~~~~~~~~~~~~~
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxObject.cpp:2:
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxObject.h:6:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk.h:98:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxloadingstrategy.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxplugin.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxobject.h:21:
  ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h:1188:70: error: binding dereferenced null pointer to reference has undefined behavior [-Werror,-Wnull-dereference]
                  return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);
                                                                                ^~~~~~~~~~~~~~~~~~~
  [109/190] Compile UEPyFbxProperty.cpp
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxPose.cpp:1:
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxPose.h:6:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk.h:98:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxloadingstrategy.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxplugin.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxobject.h:21:
  ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h:1188:70: error: binding dereferenced null pointer to reference has undefined behavior [-Werror,-Wnull-dereference]
                  return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);
                                                                                ^~~~~~~~~~~~~~~~~~~
  1 error generated.
  [110/190] Compile UEPySPanel.cpp
  1 error generated.
  [111/190] Compile UEPyIHttpBase.cpp
  1 error generated.
  [112/190] Compile UEPyTimer.cpp
  1 error generated.
  [113/190] Compile UEPyIHttpRequest.cpp
  1 error generated.
  [114/190] Compile UEPyTicker.cpp
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxProperty.cpp:1:
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxProperty.h:6:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk.h:98:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxloadingstrategy.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxplugin.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxobject.h:21:
  ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h:1188:70: error: binding dereferenced null pointer to reference has undefined behavior [-Werror,-Wnull-dereference]
                  return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);
                                                                                ^~~~~~~~~~~~~~~~~~~
  1 error generated.
  [115/190] Compile UEPyModule.cpp
  1 error generated.
  [116/190] Compile PyActor.cpp
  [117/190] Compile PyCharacter.cpp
  [118/190] Compile PyCommandlet.cpp
  1 error generated.
  [119/190] Compile PyHUD.cpp
  [120/190] Compile PyNativeWidgetHost.cpp
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/UEPyModule.cpp:45:
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbx.h:7:
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxManager.h:6:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk.h:98:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxloadingstrategy.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxplugin.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxobject.h:21:
  ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h:1188:70: error: binding dereferenced null pointer to reference has undefined behavior [-Werror,-Wnull-dereference]
                  return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);
                                                                                ^~~~~~~~~~~~~~~~~~~
  [121/190] Compile PyPawn.cpp
  [122/190] Compile PyUserWidget.cpp
  [123/190] Compile PythonBlueprintFunctionLibrary.cpp
  [124/190] Compile PythonComponent.cpp
  1 error generated.
  [125/190] Compile PythonDelegate.cpp
  [126/190] Compile PythonFunction.cpp
  [127/190] Compile PythonScript.cpp
  [128/190] Compile PythonSmartDelegate.cpp
  [129/190] Compile UEPyAssetUserData.cpp
  [130/190] Compile UEPyCallable.cpp
  [131/190] Compile UEPyEditor.cpp
  [132/190] Compile UEPyEngine.cpp
  [133/190] Compile UEPyEnumsImporter.cpp
  [134/190] Compile UEPyIPlugin.cpp
  [135/190] Compile UEPySubclassing.cpp
  [136/190] Compile UEPyIHttpResponse.cpp
  [137/190] Compile UEPyFbxScene.cpp
  [138/190] Compile UEPyFCharacterEvent.cpp
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxScene.cpp:1:
  In file included from /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Source/UnrealEnginePython/Private/Fbx/UEPyFbxScene.h:6:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk.h:98:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxloadingstrategy.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxplugin.h:20:
  In file included from ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxobject.h:21:
  ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h:1188:70: error: binding dereferenced null pointer to reference has undefined behavior [-Werror,-Wnull-dereference]
                  return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);
                                                                                ^~~~~~~~~~~~~~~~~~~
  [139/190] Compile UEPySDirectoryPicker.cpp
  [140/190] Compile UEPySDockTab.cpp
  [141/190] Compile UEPyFMaterialEditorUtilities.cpp
  [142/190] Compile UEPySEditableTextBox.cpp
  [143/190] Compile UEPySEditorViewport.cpp
  1 error generated.
  [144/190] Compile UEPySFilePathPicker.cpp
  [145/190] Compile UEPySGraphEditor.cpp
  [146/190] Compile UEPySGraphPanel.cpp
  [147/190] Compile UEPySGridPanel.cpp
  [148/190] Compile UEPySHeaderRow.cpp
  [149/190] Compile UEPySHorizontalBox.cpp
  [150/190] Compile UEPySImage.cpp
  [151/190] Compile UEPySLeafWidget.cpp
  [152/190] Compile UEPySLevelViewport.cpp
  [153/190] Compile UEPySListView.cpp
  [154/190] Compile UEPySMultiLineEditableText.cpp
  [155/190] Compile UEPySNodePanel.cpp
  [156/190] Compile UEPySNumericEntryBox.cpp
  [157/190] Compile UEPySObjectPropertyEntryBox.cpp
  [158/190] Compile UEPySCompoundWidget.cpp
  [159/190] Compile UEPySColorBlock.cpp
  [160/190] Compile UEPySDropTarget.cpp
  [161/190] Compile UEPySCanvas.cpp
  [162/190] Compile UEPyFGeometry.cpp
  [163/190] Compile UEPyFInputEvent.cpp
  [164/190] Compile UEPyFKeyEvent.cpp
  [165/190] Compile UEPyFMenuBuilder.cpp
  [166/190] Compile UEPyFModifierKeysState.cpp
  [167/190] Compile UEPySCheckBox.cpp
  [168/190] Compile UEPyFPointerEvent.cpp
  [169/190] Compile UEPyFSlateIcon.cpp
  [170/190] Compile UEPyFSlateStyleSet.cpp
  [171/190] Compile UEPyFPaintContext.cpp
  [172/190] Compile UEPyFTabSpawnerEntry.cpp
  [173/190] Compile UEPyFTabManager.cpp
  [174/190] Compile UEPySBoxPanel.cpp
  [175/190] Compile UEPySBox.cpp
  [176/190] Compile UEPySBorder.cpp
  [177/190] Compile UEPySButton.cpp
  [178/190] Compile UEPyIStructureDetailsView.cpp
  [179/190] Compile UEPyIDetailsView.cpp
  [180/190] Compile UEPyFToolBarBuilder.cpp
  [181/190] Compile UEPySAssetDropTarget.cpp
  [182/190] Compile Module.PythonEditor.gen.cpp
  [183/190] Compile Module.PythonAutomation.cpp
  [184/190] Compile Module.PythonConsole.cpp
  [185/190] Compile Module.PythonConsole.gen.cpp
  [186/190] Compile Module.PythonEditor.cpp
  ERROR: UBT ERROR: Failed to produce item: /home/stastny/temp/HostProject/Plugins/UnrealEnginePython/Binaries/Linux/libUE4Editor-UnrealEnginePython.so
  Total build time: 274.81 seconds (Local executor: 0.00 seconds)
Took 275.174322s to run mono, ExitCode=5

Looking into it, this is not this plugins issue but more of an engine not supporting clang 6 yet officially(Although it builds and compiles ok).

Hi, the error is present in clang-3.9 too. I am investigating if i can bypass it

I found a way to bypass it but it requires modification of the fbxproperty.h which is not really desirable from the plugin standpoint.
Just for the posterity this works:(line 1188 in Engine/Source/ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h)
                return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(eFbxEnum), pValue, pForceSet, pFlags);
//              return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);

Hello, I experimented the same error with the FBX module when compiling with clang-3.9 on the new Ubuntu-18.04 (clang-3.8 is no more available on that distribution). The fix you propose @aknarts works pretty well. So modifying line 1188 in Engine/Source/ThirdParty/FBX/2018.1.1/include/fbxsdk/core/fbxproperty.h is sufficient:
return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(eFbxEnum), pValue, pForceSet, pFlags);
// return StaticInit(pObject, pName, FbxGetDataTypeFromEnum(FbxTypeOf(*((FbxReference*)0))), pValue, pForceSet, pFlags);

Thank you!


Argument parsing issue with temporal env set --codec-endpoint

What are you really trying to do?
Set a codec server endpoint as documented in https://docs.temporal.io/dataconversion#cli
Describe the bug
Run temporal env set --codec-endpoint "http://localhost:8081"
Result:
Error: invalid number of args, expected 2: property and value
Minimal Reproduction
Trying to follow the other example on that page also doesn't work:
temporal --codec-endpoint "http://localhost:8081" --namespace "default" workflow show --workflow-id "codecserver_workflowID"  --output "table"
Incorrect Usage: flag provided but not defined: -codec-endpoint
So it seems like something is wrong with how the --codec-endpoint flag is parsed.
Environment/Versions
temporal version 0.10.7 (server 1.22.2) (ui 2.21.3) (x86 Mac)

You're not using the command correctly, the syntax is:
temporal env set $your_env.codec-endpoint "http://localhost:8081"

The help string for this command has an example so I don't think there's anything to do here. I'm closing this issue.
Please re-open if you're not satisfied with this response.

Using the steps that @axfelix provided above, I can reproduce both problems on temporal version 0.10.7, running on an Apple Silicon (M2) Mac.

I posted my comment without seeing Roey's message, which reopened the issue. That was not my intent (although I admit that I don't understand Roey's comment, because running temporal workflow show --help shows a usage message that includes a --codec-endpoint option, just as Alex had specified in his command.
Is the problem that this option is not supported and therefore the usage message should not display it?

That's because urfave (the cli argument parsing library we're currently using) doesn't support positional arguments at the top level.
You have to issue the command as:
temporalworkflow show --workflow-id "codecserver_workflowID"  --output "table"  --codec-endpoint "http://localhost:8081" --namespace "default"

There's a PR that's rewriting the entire CLI to use cobra and remove this restriction.


At the end of the sliced video via split-video there is a frame of the next video

Description:
At the end of the sliced video via split-video there is a frame of the next video. I cut the anime into moments and on some videos it worked poorly, as a result, either 1-2 frames from the last moment are shown at the beginning, or the next one appears at the end for 1 frame
Command:
scenedetect -i input/input.mp4 split-video -o output -hq -p fast
Output:
BUG_REPORT.txt
Environment:
[PySceneDetect] PySceneDetect 0.6.4
System Info
OS           Windows-10-10.0.19045-SP0
Python       3.9.13
Packages
av           10.0.0
click        8.1.7
cv2          4.10.0
moviepy      Not Installed
numpy        1.26.4
platformdirs 4.2.2
scenedetect  0.6.4
tqdm         4.66.4
Tools
ffmpeg       6.0-full_build-www.gyan.dev
mkvmerge     Not Installed
Media/Files:
https://github.com/user-attachments/assets/cf4dac57-632f-44a6-8893-d0ad1bf64cde
https://github.com/user-attachments/assets/379f5981-7e44-41a7-a277-583907542869
https://github.com/user-attachments/assets/c79a5b5a-1ade-4cee-8a43-66624aa839b9
https://github.com/user-attachments/assets/6ac030fc-a95d-4cde-a68e-03fd14209f8b
https://github.com/user-attachments/assets/ca551609-7a9e-46a4-a54d-6de1921a8ff8
https://github.com/user-attachments/assets/2bc46619-b1db-4917-a9f5-8e0c1c3ad124

Can you share the original clip?  Does the issue happen with all videos or only a few?

Can you share the original clip? Does the issue happen with all videos or only a few?

yes, sure
https://drive.google.com/file/d/1a2el3LT2A_EOhzCWws3jvk2hLmOeEMFG/view?usp=sharing

Thanks for sharing, I was able to repro the issue.  This typically occurs when a frame fails to decode, which shifts the frame numbers off by one.  In the future this should be fixed by #168 but that will require some significant API changes which is why this still happens occasionally.  I'll see if there are any workarounds I can suggest in the meantime.

@whatforiam can you try using the PyAV backend?
scenedetect -i input/input.mp4 -b pyav split-video -o output -hq -p fast

scenedetect -i input/input.mp4 -b pyav split-video -o output -hq -p fast

Thank you so much. This command solved the problem!
But I have another question. Is there any way to improve the detect of places where need to cut? As I understand it, the program is designed primarily for real videos, but are there any settings for a better detect for such 2d animations that I gave as an example? It's just that it either cuts too often, or vice versa in one moment 2 different angles. I just wanted it to separate into a separate file every time I changed the angle

Of course, I wrote a script for bat to combine these files when dragging into one, but considering how many such videos I have, and how much I have to do this (>5000 series), I would like to make the work easier
here is my code for combining videos when dragging, if it is useful, I wrote it myself (but the sound disappears a little at the joints of the video, I did not come up with how to solve this, so I wanted to at least reduce the number when it is necessary to combine)
chcp 65001
for %%i in (%*) do (
    if /i not "%%~xi"==".exe" (
        echo file '%%~i' >> txt.txt
    )
)
ffmpeg -f concat -safe 0 -i "txt.txt" -c copy output.mp4
for %%i in (%*) do (del /s /q "%%~i")
ren output.mp4 "%~n1.mp4"
del txt.txt

You might want to try another kind of detector for this kind of input e.g. detect-hist.  You might also have some luck with detect-hash.  These were added recently so any feedback you have on those is welcome.

the frame rate is different depending on the backend used

Could this be due to precision differences between the different libraries? It looks like moviepy and pyav are the same while OpenCV is different. I wonder if a solution for this specific framerate (23.976 comes from 3:2 pulldown), would be to check to see if the detected framerate is very, very close to 23.976, and if so, then simply define it as such, overriding what the library automatically detects? Not sure what that would break though.

You can change the weight placed on the luma channel for detect-content/detect-adaptive and tweak other parameters. For example try adding this to your command:
detect-adaptive -w 0.5 1.0 0.0 0.0 -c 27 -t 5

Yes, thank you very much for your help. I came to the conclusion that it is either better without any additional settings at all

scenedetect -i input/input.mp4 -b pyav split-video -o output -hq -p fast

or with these.
scenedetect -i "input/input.mp4" -b pyav detect-adaptive -w 0.1 0.1 1.0 0.0 -c 34 -t 4 split-video -o "output"

Should I close the repo or do you still need any information?

the frame rate is different depending on the backend used

Could this be due to precision differences between the different libraries? It looks like moviepy and pyav are the same while OpenCV is different. I wonder if a solution for this specific framerate (23.976 comes from 3:2 pulldown), would be to check to see if the detected framerate is very, very close to 23.976, and if so, then simply define it as such, overriding what the library automatically detects? Not sure what that would break though.

@wjs018 I looked into this just now, but it looks like both ffmpeg and OpenCV are using double for these calculations.  Initially I thought it was the same thing, 32-bit float issues.  Your theory though is still plausible, could be some intermediate calculations or differences in what options the libs were compiled with.
Hard-coding a value for cases like this is a reasonable one, and would probably not break too many things.  The most important thing is that we get the timecode calculations aligned with what ffmpeg expects for split-video functionality, as all the other output commands work on the VideoStream directly so there will never be visual off-by-one issues like this.  I'll do some digging into how ffmpeg translates these timestamps back into timecodes or how it uses start seek and -t.
It's a bit worrying that OpenCV doesn't seem to work even when I use CAP_PROP_POS_MSEC since I thought that would fix this, but it didn't.  Makes me wonder if we should consider switching the default backend to PyAV until we can sort that out.  Thoughts?

@whatforiam sure, please do.  You might also want to try the new detect-hist command with a very high threshold, e.g. detect-hist -t 0.5. Lastly, note that downscaling might be rendering some details out, so you might want to lower downscale factor so the processing happens at higher resolution.  That will come with performance cost however.
Thanks for the report and sharing the params you are using, I'll close the issue once I've done some further investigation into OpenCV/FFmpeg differences here.

Something that could be looked into is also how these timecodes are exported with list-scenes. I once noticed that the results for split-video and using the values from the split file with ffmpeg separately are different for videos that have framerates like 24000/1001. This seems to be due to the rounding error introduced in scene_manager.py by formatting values with %.3f. This can round up, causing ffmpeg to include an additional frame from the next scene IIRC (or the other way around, I'm not quite sure anymore and would need to find some sample).

Something that could be looked into is also how these timecodes are exported with list-scenes. I once noticed that the results for split-video and using the values from the split file with ffmpeg separately are different for videos that have framerates like 24000/1001. This seems to be due to the rounding error introduced in scene_manager.py by formatting values with %.3f. This can round up, causing ffmpeg to include an additional frame from the next scene IIRC (or the other way around, I'm not quite sure anymore and would need to find some sample).

I noticed that after I was advised to add pyav, most of my frames became normal, but sometimes not one frame is added to the end, but a whole second, I do not know how to fix it

Something that could be looked into is also how these timecodes are exported with list-scenes. I once noticed that the results for split-video and using the values from the split file with ffmpeg separately are different for videos that have framerates like 24000/1001. This seems to be due to the rounding error introduced in scene_manager.py by formatting values with %.3f. This can round up, causing ffmpeg to include an additional frame from the next scene IIRC (or the other way around, I'm not quite sure anymore and would need to find some sample).

@IncredibleLaser thanks for bringing that up, I wasn't aware that was an issue. Filed #464 to track this issue.

I noticed that after I was advised to add pyav, most of my frames became normal, but sometimes not one frame is added to the end, but a whole second, I do not know how to fix it

@whatforiam could you provide a logfile to help debug the issue and also provide the version of PyAV you are using (run scenedetect version)? You can generate a debug log by adding -v debug -l BUG_REPORT.txt to the beginning of your command.

[PySceneDetect] PySceneDetect 0.6.4
System Info
OS           Windows-10-10.0.19045-SP0
Python       3.9.13
Packages
av           10.0.0
click        8.1.7
cv2          4.10.0
moviepy      Not Installed
numpy        1.26.4
platformdirs 4.2.2
scenedetect  0.6.4
tqdm         4.66.4
Tools
ffmpeg       6.0-full_build-www.gyan.dev
mkvmerge     v45.0.0 ('Heaven in Pennies') 64-bit
BUG_REPORT.txt


CSCFAIRMETA-24: Additional accessibility fixes

This pull request resolves accessibility issues:

[x] https://jira.eduuni.fi/browse/CSCFAIRMETA-37  - most of the changes is related to to this issue, all color contrast errors should be fixed (see issue comments for details)
[x] https://jira.eduuni.fi/browse/CSCFAIRMETA-38 - see issue description for details (Qvain light add dataset page)
[ ] https://jira.eduuni.fi/browse/CSCFAIRMETA-25 - no changes needed
[ ] https://jira.eduuni.fi/browse/CSCFAIRMETA-27 - no changes needed
[ ] https://jira.eduuni.fi/browse/CSCFAIRMETA-28 - no changes needed, Axe errors would need (lots of) refactoring
[x] https://jira.eduuni.fi/browse/CSCFAIRMETA-29 - see issue description for details
[ ] https://jira.eduuni.fi/browse/CSCFAIRMETA-166 - TODO: check is this fixed

Used to test color contrast:
https://addons.mozilla.org/en-US/firefox/addon/wcag-contrast-checker/

https://jira.eduuni.fi/browse/CSCFAIRMETA-166 -  Deleted / deprecated banner link text

Can't find anymore any datasets causing the banner to be visible. This needs to be tested properly

https://jira.eduuni.fi/browse/CSCFAIRMETA-166 - Deleted / deprecated banner link text

Can't find anymore any datasets causing the banner to be visible. This needs to be tested properly
There's a bug that prevents the banner from showing up, this will fix it: https://github.com/CSCfi/etsin-finder/pull/519

https://jira.eduuni.fi/browse/CSCFAIRMETA-166
Still needs to be checked with the case:

If there is an older version of the dataset (and it's the only existing version)

Other case:

A new version of this dataset is available. You can open the new version via this link.

Tested and ok


Implementation of drag and drop handler

hey guys can someone help me with drag and drop handler in blui cause it doesn't work in ue4

You probably want to expose https://github.com/chromiumembedded/cef/blob/fa5268fa2d87701acb39947bd80970de10ddbddd/include/cef_browser.h#L787 and related methods, adding them into e.g. https://github.com/getnamo/BLUI/blob/master/Source/Blu/Private/RenderHandler.cpp


STORM-689. SimpleACLAuthorizer should provide a way to restrict who can submit topologies.

@revans2 can you please take a look at this.

@revans2  pinging for a review. Thanks.

+1. I think most users would much rather define a nimbus.groups m e can probably file a separate jira for that.

Sorry it took so long for the review.  It looks good, and I agree having groups of allowed users would be a good step.

@Parth-Brahmbhatt @revans2 Thanks for the review. I updated the PR to include nimbus.groups as well and added doc under SECURITY.md. Please take a look.

+1.

+1

+1


Revert water pistol to real pistol

Reflecting recent changes to the X web client. SVG is pulled from https://abs.twimg.com/responsive-web/client-web/1f52b.cec753aa.svg, with extra scale parameter so that it is 36x36 like the other emoji. No other changes.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Is this repo abandoned or something?

I'm not sure. Could be. Strange and unfortunate choice.


st2chatops env/secrets management

Hey there !
Currently the injection of secret in st2chatops is done through an env variable mapping.
The env is iterated over as follow: https://github.com/StackStorm/stackstorm-ha/blob/85c21ed9e925b6fabcbcdef6eae3e5ee04cd8b34/templates/secrets_st2chatops.yaml#L18-L21
This seems to be a bit counter intuitive. From the end user point of view, the env is never referenced as being secret, but every K\V is stored as a secret in k8s.
In addition to this, if we wanted to inject custom env variables that don't have anything secret (eg: proxy settings or equivalent) they will forcefully be stored as secret.
I ran into this issue when trying to allow injection of arbitrary env variables into the deployments.
One solution would be using secrets.st2 for the variables that should be stored as secret, and a classic st2chatops.env or more generally (st2chatops|st2actionrunner|st2api|...).env variable to store the "standard" environment.
This can be loosely linked to #14

I think this is a good idea.  I'd recommend doing st2chatops.env for standard env variables and something like st2chatops.secrets (or st2chatops.envSecrets or similar) for secrets like:
st2chatops:
  secrets:
    HUBOT_ADAPTER: slack
    HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE
  env:
    FOO: bar

I did something comparable, you can checkout the associated PR :).

In addition to this, if we wanted to inject custom env variables that don't have anything secret (eg: proxy settings or equivalent) they will forcefully be stored as secret.

I don't think there is a harm in forcefully storing ENV variables as secrets.
Eg. you don't know if ENV variable from the Helm perspective contains secret data or not and if you're passing sensitive data via specific ENV.
With the beforementioned proposal there is a chance of conflicts and misuse like this:
st2chatops:
  secrets:
    # really non-secret
    HUBOT_ADAPTER: slack
    HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE
  env:
    # conflict
    HUBOT_ADAPTER: non-slack
    # conflict
    HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE1
    # really secret
    ANOTHER_SECRET: value
    FOO: bar

And so any custom ENV variables to override would be more straightforward to define like that:
st2chatops:
  env:
    HUBOT_ADAPTER: slack
    HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE
    FOO: bar

I think it's a good idea to explore the official Helm charts and research examples about how majority approach it.
BTW is there a practical downside by having a chance to store a non-secret data as secret?  I just assume it's better comparing to storing secret data as non-secret, but there could be more I'm missing.

BTW is there a practical downside by having a chance to store a non-secret data as secret?

Size limits.  Secrets max size is 1mb

To be noted when using env and envFrom in the same spec: values defined by an Env with a duplicate key will  take precedence.
Also, inside env, the last value defined will be used when there is a duplicate.


For example, 'dart test --chain-stack-traces'.
00:31 +1 -1: instruction-sizes basic-parsing

00:37 +2 -1: instruction-sizes program-info-from-sizes

00:44 +3 -1: instruction-sizes histograms

00:49 +4 -1: instruction-sizes histograms-filter

00:56 +5 -1: instruction-sizes diff

01:05 +6 -1: instruction-sizes diff-collapsed

01:14 +7 -1: v8-profile program-info-from-profile

01:18 +8 -1: v8-profile instruction ownership is preserved

01:28 +9 -1: v8-profile histograms

01:34 +10 -1: v8-profile diff

01:42 +11 -1: v8-profile diff-collapsed

01:51 +12 -1: v8-profile treemap

01:55 +13 -1: v8-profile dominators

01:59 +14 -1: Some tests failed.

stderr:
Unhandled exception:
Dummy exception to set exit code.

--- Re-run this test:
python3 tools/test.py -n unittest-asserts-release-mac pkg/vm_snapshot_analysis/test/instruction_sizes_test

looks to be dup of https://github.com/dart-lang/sdk/issues/46551


Feature/notification settings

Added support for notification settings API. See issue #123

@sindrepm could you please check out https://github.com/xanzy/go-gitlab/tree/f-notification-settings and maybe also check if it works as expected for you as well?
It's a feature branch based on yours.
If you have any question about why I did certains things, please find me here https://gitter.im/xanzy/go-gitlab.

Merged and refactored in #130
Thanks for your groundwork and help!


MAC and Linux Support

[Enter feedback here]

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

ID: 034ffda3-6ef7-13f4-6341-82ac3c11f455
Version Independent ID: 5527ef3f-6361-b037-d9c3-3d520cf2ef2c
Content: Threat & Vulnerability Management supported operating systems and platforms - Windows security
Content Source: windows/security/threat-protection/microsoft-defender-atp/tvm-supported-os.md
Product: w10
Technology: windows
GitHub Login: @levinec
Microsoft Alias: ellevin

Microsoft Defender ATP for Linux is now generally available!
https://techcommunity.microsoft.com/t5/microsoft-defender-atp/microsoft-defender-atp-for-linux-is-now-generally-available/ba-p/1482344
Deploy Microsoft Defender ATP for Mac in just a few clicks
https://techcommunity.microsoft.com/t5/microsoft-defender-atp/deploy-microsoft-defender-atp-for-mac-in-just-a-few-clicks/ba-p/1341619

@e0i . Assign user to check PR #7133

Hi @RAJU2529  and @v-rapate, thanks for your feedback. However, not all Microsoft Defender ATP capabilities have the same supported operating systems/platforms (including threat and vulnerability management). That's why we have one page for Microsoft Defender ATP requirements: https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/minimum-requirements, and a different one for threat and vulnerability management: https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/tvm-supported-os. Currently, Mac and Linux are not supported for threat and vulnerability management. Hope that clears that up!


Mainnet (old)

### Tasks
- [ ] https://github.com/zeta-chain/zeta-node/issues/361
- [ ] https://github.com/zeta-chain/zeta-node/issues/344
- [ ] https://github.com/zeta-chain/zeta-node/issues/684
- [ ] https://github.com/zeta-chain/zeta-node/issues/645
- [ ] https://github.com/zeta-chain/zeta-node/issues/642
- [ ] https://github.com/zeta-chain/zeta-node/issues/641
- [ ] https://github.com/zeta-chain/zeta-node/issues/162
- [ ] https://github.com/zeta-chain/zeta-node/issues/675
- [ ] https://github.com/zeta-chain/zeta-node/issues/726
- [ ] https://github.com/zeta-chain/zeta-node/issues/734
- [ ] https://github.com/zeta-chain/zeta-node/issues/757
- [ ] https://github.com/zeta-chain/zeta-node/issues/768
- [ ] https://github.com/zeta-chain/zeta-node/issues/770
- [ ] https://github.com/zeta-chain/node/issues/920
- [ ] https://github.com/zeta-chain/node/issues/840
- [ ] https://github.com/zeta-chain/zeta-node/issues/769

Closing as it seems no longer relevant


Remove localData copy from the database driver, to free up some memor…

…y, it is only used on first receiver registration

Nice work! We are getting close to memory footprint target.
There is one bug? we need to fix/figure out before checking in this change, otherwise the latency may have a notable regression.

Every handle.store(entity) will create a new Backing Store which in turn calls DatabaseDriver:registerReceiver() that will always call getDatabaseData() with this change.
From the code,
suspend fun store(id: String) = storeMutex.withLock {
        stores.getOrPut(id) {
            setupStore(id)
        }
    }
Different entity reference id would spin up a new Store even if it's with the same handle.
This is also why I observed growing StoreRecord at class BackingStore and never got freed (http://b/154865157)

Nice work! We are getting close to memory footprint target.
There is one bug? we need to fix/figure out before checking in this change, otherwise the latency may have a notable regression.

Every handle.store(entity) will create a new Backing Store which in turn calls DatabaseDriver:registerReceiver() that will always call getDatabaseData() with this change.
From the code,
suspend fun store(id: String) = storeMutex.withLock { stores.getOrPut(id) { setupStore(id) } }
Different entity reference id would spin up a new Store even if it's with the same handle.
This is also why I observed growing StoreRecord at class BackingStore and never got freed (http://b/154865157)

Yes we need a new store for each entity/ref being stored. BackingStore takes care of that. This is by design and this change does not affect it.
There may be some latency increase: with this change registerReceiver always goes to the database. So it may be slower on first creation, but I think it is unavoidable if we want to get rid of this in-memory copy.

What does the "first creation" mean? Currently the every handle.store() acts like the first creation to me.
Say
handleA.store(SomeEntity())
handleA.store(SomeEntity())
The two store() calls on the handleA trigger two DatabaseDriver:registerReceiver().
Is this expected?
Say
val entity = SomeEntity()
handleA.store(entity)
entity.xxx = yyy // manipulation of fields, not sure if it's allowed
handleA.store(entity)
How many DatabaseDriver:registerReceiver() are expected?

Also wondering is it possible to just change/update the object reference in DatabaseDriver to refer to that one in BackingStore? Prefer to finding a win-win.

I mean first creation of each entity.
For example:
val entity1 = SomeEntity()
handleA.store(entity1)
val entity2 = SomeOtherEntityOfTheSameType()
handleA.store(entity2)
in this case we expect two backing stores, each one with a separate driver instance, ie two setupStore() and two registerReceiver() calls. The two registerReceiver calls are on two different driver objects, not on the same driver (each database driver only handles one backing storageKey, each entity has a separate backing storage key).
entity.xxx = yyy // manipulation of fields
this I think at the moment should talk to the existing driver (ie there is an existing store in stores in backingstore), so no registerReceiver call in this case.
Again, none of this is changed by this pr. Do you have any specific concerns with this pr?

Nope, the PR is good to get in :-)
I just need to keep eyes on every improvement, regression as well as tradeoff in behind.

Nope, the PR is good to get in :-)
I just need to keep eyes on every improvement, regression as well as tradeoff in behind.

Yes you are right. Let me know if you find this introduces a latency regression. I think it won't as registerReceiver would be called on a new driver (ie null local model) in most of the cases.


"Refreshing Files" step of sync takes a really long time

Some engineers here at Stripe are seeing IntelliJ spend many minutes performing "Refreshing files." This often happens after every Bazel IntelliJ sync.

When we pause IntelliJ in the debugger, we see that it's stuck indexing the execution root for the Bazel workspace:

(This behavior appears to have been changed – or maybe introduced – in #1703, though I'm not sure how (or why).)
On my laptop, this means it's refreshing (or reindexing?) hundreds of thousands of files:
% find /private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander | wc -l
  134063
% find -L /private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander | wc -l
  151299

Most of the CPU is spent just traversing the files:

If I set a logging-only breakpoint in com.intellij.openapi.vfs.VirtualFileVisitor.visitFileEx I see it visiting runfiles for hundreds of tests:
file:///private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander/external/com_stripe_uppsala/bazel-uppsala/bazel-out/darwin-fastbuild/bin/src/test/java/com/stripe/XXX/test_XXX.runfiles/com_stripe_uppsala/external/third_party_jvm/3rdparty/jvm/org/apache/commons/commons_lang3.jar
file:///private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander/external/com_stripe_uppsala/bazel-uppsala/bazel-out/darwin-fastbuild/bin/src/test/java/com/stripe/XXX/test_XXX.runfiles/com_stripe_uppsala/external/third_party_jvm/3rdparty/jvm/org/apache/commons/commons_math3.jar
file:///private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander/external/com_stripe_uppsala/bazel-uppsala/bazel-out/darwin-fastbuild/bin/src/test/java/com/stripe/XXX/test_XXX.runfiles/com_stripe_uppsala/external/third_party_jvm/3rdparty/jvm/org/apache/commons/commons_compress.jar
file:///private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander/external/com_stripe_uppsala/bazel-uppsala/bazel-out/darwin-fastbuild/bin/src/test/java/com/stripe/XXX/test_XXX.runfiles/com_stripe_uppsala/external/third_party_jvm/3rdparty/jvm/org/apache/logging
file:///private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander/external/com_stripe_uppsala/bazel-uppsala/bazel-out/darwin-fastbuild/bin/src/test/java/com/stripe/XXX/test_XXX.runfiles/com_stripe_uppsala/external/third_party_jvm/3rdparty/jvm/org/apache/logging/log4j
file:///private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander/external/com_stripe_uppsala/bazel-uppsala/bazel-out/darwin-fastbuild/bin/src/test/java/com/stripe/XXX/test_XXX.runfiles/com_stripe_uppsala/external/third_party_jvm/3rdparty/jvm/org/apache/logging/log4j/log4j_api.jar
file:///private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander/external/com_stripe_uppsala/bazel-uppsala/bazel-out/darwin-fastbuild/bin/src/test/java/com/stripe/XXX/test_XXX.runfiles/com_stripe_uppsala/external/third_party_jvm/3rdparty/jvm/org/apache/logging/log4j/log4j_core.jar
file:///private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander/external/com_stripe_uppsala/bazel-uppsala/bazel-out/darwin-fastbuild/bin/src/test/java/com/stripe/XXX/test_XXX.runfiles/com_stripe_uppsala/external/third_party_jvm/3rdparty/jvm/org/apache/logging/log4j/log4j_slf4j_impl.jar
file:///private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander/external/com_stripe_uppsala/bazel-uppsala/bazel-out/darwin-fastbuild/bin/src/test/java/com/stripe/XXX/test_XXX.runfiles/com_stripe_uppsala/external/third_party_jvm/3rdparty/jvm/org/xerial
file:///private/var/tmp/_bazel/479f88e6c4756e5120907a9f85b5f7d8/execroot/com_stripe_zoolander/external/com_stripe_uppsala/bazel-uppsala/bazel-out/darwin-fastbuild/bin/src/test/java/com/stripe/XXX/test_XXX.runfiles/com_stripe_uppsala/external/third_party_jvm/3rdparty/jvm/org/xerial/snappy

Some questions I have:

Why is IntelliJ VFS even aware of the execroot itself? It seems that it would be much more efficient for the VFS roots to be individual jars and source paths.

Are the bazel-<workspacename>, bazel-out symlinks relevant? We usually use directories: . in our .bazelproject which may inadvertently be causing this problem

If so, should we just generate the .bazelproject file to have directories: contain a list of all subdirectories except bazel-*?

Why do the Python and Go plugins need to refresh the execution root, but other plugins don't? Is this a bug that could be fixed? We write a good bit of Python here and would rather not disable that Bazel IntelliJ language extension.
Could we work around this by using excludes somehow? The IntelliJ docs are not clear about whether this helps:

The IntelliJ plugin developer docs suggest we cannot just add those to some kind of ignore/exclude list:

The VFS itself does not honor ignored files listed in Settings/Preferences | Editor | File Types and folders to ignore and excluded folders listed in Project Structure | Modules | Sources | Excluded. If the application code accesses them, the VFS will load and return their contents. In most cases, the ignored files and excluded folders must be skipped from processing by higher-level code.

However the IntelliJ product docs say otherwise:

Marking dynamically generated files as excluded can speed up the indexing and overall IDE performance. For example, it's recommended that you exclude compilation output folders. Excluded files remain a part of a project, but are ignored by code completion, navigation, indexing, and inspections.

We recently added our Python code to Bazel in our monorepo (which was previously just managed Java & Scala via Bazel).
Intellij now freezes when it starts refreshing files and eventually crashes due to out of memory errors. Every time this happened, I bumped the memory up by 1GB to see if that would fix it. I'm up to 6GB now and it just takes longer to crash.
To corroborate this bug report, I ran dtruss on Intellij and confirmed that when the IDE locks up it is scanning all the files in the execroot. These directories are all excluded via Intellij.
# ij.bazelproject
directories:
  .
  -bazel-bin
  -bazel-dataworks
  -bazel-genfiles
  -bazel-out
  -bazel-testlogs

targets:
  //...:all

java_language_level: 8

additional_languages:
  scala

Since adding a hermetic Python install to Bazel, the scanning is now nearly impossible to deal with.
My "workaround" is to run a bazel clean every morning and every time I switch modules. Then I "partially sync" the folder I am working on, and while it still scans the files it completes after a few minutes when just indexing a single module.

Hello @keithl-stripe & @dfinninger,  Could you please confirm if you are still seeing the above performance issue even with the latest intellij and bazel plugin releases. Thanks!

I believe I'm up to date on minor versions (probably a few patches behind), and I'm still seeing the issue. However I'm on PTO this week so I won't be able to test for a little bit.
I'll upgrade next week and try it out again.

@sgowroji I've updated to the latest versions I could get in the Jetbrains Toolbox app.
IDEA Version: IntelliJ IDEA 2022.2.3 (Ultimate Edition), Build #IU-222.4345.14, built on October 4, 2022
Bazel Plugin version: 2<IP_ADDRESS>.1-api-version-222
And while indexing I still see it looking through my excluded Bazel directories:
❯ sudo dtruss -p 21559 | grep _bazel_dfinninger | grep getattrlist
getattrlist("/private/var/tmp/_bazel_dfinninger/e0de62c3aa2a01df70346b0386e30cf1/execroot/REDACTED/bazel-out/darwin-fastbuild/bin/REDACTED/src\0", 0x7FF8093C41E4, 0x70000DEECEF0)               = 0 0
getattrlist("/private/var/tmp/_bazel_dfinninger/e0de62c3aa2a01df70346b0386e30cf1/execroot/REDACTED/bazel-out/darwin-fastbuild/bin/REDACTED/src/main\0", 0x7FF8093C41E4, 0x70000DEECEF0)          = 0 0
getattrlist("/private/var/tmp/_bazel_dfinninger/e0de62c3aa2a01df70346b0386e30cf1/execroot/REDACTED/bazel-out/darwin-fastbuild/bin/REDACTED/src/main/python\0", 0x7FF8093C41E4, 0x70000DEECEF0)           = 0 0
getattrlist("/private/var/tmp/_bazel_dfinninger/e0de62c3aa2a01df70346b0386e30cf1/execroot/REDACTED/bazel-out/darwin-fastbuild/bin/REDACTED/src/main/python/print.runfiles\0", 0x7FF8093C41E4, 0x70000DEECEF0)            = 0 0

... etc ...

@bazelbuild/triage - I'm having trouble understanding why this issue was autoclosed. What's the underlying thinking here?
The users responded promptly to every request for more data or more information, all was given, and the issue was added to Bazel backlog.

@mai93 since that alias linked in the comment above apparently did not resolve to a team.

And @sgowroji

What's the customer obsessed reason to have the bot do this when all action is pending on Bazel team?

This could be fixed now with IntelliJ 2024.1 and after #6094 is merged.
There is more context in IDEA-333933.
@tpasternak can you please confirm?

I am facing the same issue with IntelliJ 2024.1
my bazel sync is stuck in refreshing files and is taking more than 3 hours to complete a small sync

hey @piyush-golani
3 hours is indeed enormous size. It looks like you are working on a really large codebase. Could you try to reduce the scope by manipulating targets/directories sections in the projectview file? Also, we still don't support non-default convenience symlink locations


Remove unnecessary Box

related https://github.com/sqlparser-rs/sqlparser-rs/pull/556

Previously, Query variant in enum Statement seemed to be used recursively, but this is not the case now.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

8 of 8 (100.0%)  changed or added relevant lines in 4 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.01%) to 97.892%

Files with Coverage Reduction
New Missed Lines
%

core/src/executor/aggregate/mod.rs
4
92.2%

Totals

Change from base Build<PHONE_NUMBER>:
-0.01%

Covered Lines:
29354

Relevant Lines:
29986

💛  - Coveralls


PLR2004: Accept 0.0 and 1.0 as common magic values

Summary
Accept 0.0 and 1.0 as common magic values. This is in line with the pylint behaviour, and I think makes sense conceptually.
Test Plan
Test cases were added to crates/ruff_linter/resources/test/fixtures/pylint/magic_value_comparison.py

I think this is a good change and arguably a "bug" (or at least an oversight) given that we already allow 0 and 1. Wdyt @zanieb (with respect to gating this in preview vs. not)?


Option --user-summary crashes

Hotsos version:
jo@t14s:~$ hotsos --version
652

Error:
jo@t14s:~$ sudo hotsos --user-summary
[sudo] password for jo:

Traceback (most recent call last):
  File "/snap/hotsos/652/bin/hotsos", line 8, in <module>
    sys.exit(main())
  File "/snap/hotsos/652/lib/python3.8/site-packages/hotsos/cli.py", line 326, in main
    cli(prog_name='hotsos')
  File "/snap/hotsos/652/lib/python3.8/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/snap/hotsos/652/lib/python3.8/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/snap/hotsos/652/lib/python3.8/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/snap/hotsos/652/lib/python3.8/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/snap/hotsos/652/lib/python3.8/site-packages/hotsos/cli.py", line 297, in cli
    with open(data_root) as fd:
TypeError: expected str, bytes or os.PathLike object, not NoneType

thanks for the bug, that option should have been deprecated and removed ages ago so im gonna go ahead and do that now.


chore(publish): streamline dendron config availablity

The aim of this PR is to TODO
[[dendron://private/task.2022.10.04.nextjs-template-dendronyml-validation]]
this branch is build on top of https://github.com/dendronhq/dendron/pull/3618
Pull Request Checklist
If you are a community contributor, copy and paste the PR template from Dendron Community PR Checklist and add it to the body of the pull request.
If you are a team member, copy and paste the template from Dendron Extended PR Checklist.
To copy the template, click on the Raw button on the gist to copy the plaintext version of the template to this PR.

I'll wrap up #3618 asap so it doesn't block this! 🙏🏼

@kevinslin I played with an idea in this commit 3c1090e (#3649). Its about using es6 modules instead of classes for namespacing purposes. I saw a couple of times the pattern of using classes and maybe we are having a "leakage" here where we started using them for defining module API surfaces. Do we want to address this pattern and add an explicit intend into the dev docs.

@kevinslin I played with an idea in this commit 3c1090e (#3649). Its about using es6 modules instead of classes for namespacing purposes. I saw a couple of times the pattern of using classes and maybe we are having a "leakage" here where we started using them for defining module API surfaces. Do we want to address this pattern and add an explicit intend into the dev docs.

it looks like that commit is no longer available

@kevinslin I played with an idea in this commit 3c1090e (#3649). Its about using es6 modules instead of classes for namespacing purposes. I saw a couple of times the pattern of using classes and maybe we are having a "leakage" here where we started using them for defining module API surfaces. Do we want to address this pattern and add an explicit intend into the dev docs.

it looks like that commit is no longer available

This is the commit: 364b646 (#3649)


Permission denied - TASK [Ensure internet-monitoring environment is running.]

Playbook fails at the following task :
TASK [Ensure internet-monitoring environment is running.] ********************************************************************
fatal: [<IP_ADDRESS>]: FAILED! => {"changed": false, "msg": "Error connecting: Error while fetching server API version: ('Connection aborted.', PermissionError(13, 'Permission denied'))"}

I tried to give all permissions to the folder with sudo chmod -R a+rwx ~/internet-monitoring/, but unfortunately this did not work.

Solved by rm -rf ~/internet-monitoring (as advised here)

(closed by mistake)

Please see https://github.com/geerlingguy/internet-pi/issues/22 — this indicates you may need to log out and log back in (or reboot).

Thanks ! I also had to add my username and root user to "docker" group", before rebooting the machine to get it to work


Make automatic submodule updates more frequent

Every 6 hours. We can always ignore them if they're not needed, but given that we have people in various timezones, it's better to get good coverage. Also the weekend ones can just be ignored, but if someone is around and cares to update it will already be prepped for them.

Feel free to click merge


Add golang runtime

Issue Ref: #169
Description:
Add Golang as a supported runtime. Review docs for developing a new runtime.
TODOs:

[X] Ready to review
[X] Automated Tests
[X] Docs

General comment. Perhaps we need to think also on the user feedback when function fails to compile.
Right now if I give incorrect go code, pod deployment gets stuck in Init:Error, with no clear error message on what happened. A descriptive termination message would be good.

Agree, let me check if we can provide an easier way of debugging.

Overall LGTM.


2.16.2 offers update to 2.17.0 which is known to crash

My Setup

Operating System: macOS 10.13.6
App Version: 2.16.2
Installation type: dmg (Since 2.16.0 from Mac App Store is known to crash and never launch.)

[X] I have tested with the latest version
[X] I can simulate the issue easily

Description
After Installing 2.16.2 from dmg I'm immediately presented a notification to update to 2.17.0.
Version 2.17.0 is known to crash immediately upon launch on macOS. This is the reason for 2.16.2 in the first place and why 2.17.0 is not offered on the website for download. (at least not for macOS)
2.16.2 must not display an update notification for a withdrawn release (on said platform).
Current Behavior
An update notification is presented. If you actually do the update, your application will not launch anymore.

Expected Behavior
A withdrawn release should never be offered as an update!

How does one roll back to 2.16.2 after running this update? It seems it has now corrupted my 2.16.2 as well. Reinstalled 2.16.2 and now it is unresponsive and seems broken.
macOS 10.15.1

How does one roll back to 2.16.2 after running this update? It seems it has now corrupted my 2.16.2 as well. Reinstalled 2.16.2 and now it is unresponsive and seems broken.
macOS 10.15.1

mine was doing the same thing, so i used an "uninstaller app" then reinstalled 2.15.5 because 2.16.2 doesn't like darkmode in Catalina.

Please test if the latest release did solve this. If not please reopen the issue or create a new one and tell us. I will be closing this one for now.
Thank you!


Error: undefined method downcase' for nil:NilClass in brew desc`

Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to Homebrew again.

[x] are reporting a bug others will be able to reproduce and not asking a question. If you're not sure or want to ask a question do so on our Discourse: https://discourse.brew.sh
[x] ran a brew command and reproduced the problem with multiple formulae? If it's a problem with a single, official formula (not cask) please file this issue at Homebrew/homebrew-core: https://github.com/Homebrew/homebrew-core/issues/new/choose. If it's a brew cask problem please file this issue at https://github.com/Homebrew/homebrew-cask/issues/new/choose. If it's a tap (e.g. Homebrew/homebrew-php) problem please file this issue at the tap.
[x] ran brew update and can still reproduce the problem?
[x] ran brew doctor, fixed all issues and can still reproduce the problem?
[x] ran brew config and brew doctor and included their output with your issue?

busytown ~ » brew config                                                                      1 ↵
HOMEBREW_VERSION: 1.7.0
ORIGIN: https://github.com/Homebrew/brew
HEAD: 7e8fb9a0f8ab5e841763ec6c7fefa72a8462b594
Last commit: 6 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 47d170afb91a448297dc44331736b3827d0cd8c1
Core tap last commit: 3 hours ago
HOMEBREW_PREFIX: /usr/local
CPU: quad-core 64-bit kabylake
Homebrew Ruby: 2.3.7 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.7/bin/ruby
Clang: 9.1 build 902
Git: 2.15.2 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.54.0 => /usr/bin/curl
Java: 1.6.0_65-b14-468
macOS: 10.13.6-x86_64
CLT: <IP_ADDRESS>.1.1528165917
Xcode: 9.4.1
XQuartz: 2.7.11 => /opt/X11

busytown ~ »  brew doctor
Your system is ready to brew.

To help us debug your issue please explain:

What you were trying to do (and why)

run brew desc -s to search for several packages (cutter, z3)

What happened (include command output)

busytown ~ » brew desc -s z3                                                                  1 ↵
Error: undefined method `downcase' for nil:NilClass
Please report this bug:
  https://docs.brew.sh/Troubleshooting
/usr/local/Homebrew/Library/Homebrew/searchable.rb:14:in `simplify_string'
/usr/local/Homebrew/Library/Homebrew/searchable.rb:28:in `block (2 levels) in search_string'
/usr/local/Homebrew/Library/Homebrew/searchable.rb:28:in `any?'
/usr/local/Homebrew/Library/Homebrew/searchable.rb:28:in `block in search_string'
/usr/local/Homebrew/Library/Homebrew/searchable.rb:26:in `select'
/usr/local/Homebrew/Library/Homebrew/searchable.rb:26:in `search_string'
/usr/local/Homebrew/Library/Homebrew/searchable.rb:7:in `search'
/usr/local/Homebrew/Library/Homebrew/descriptions.rb:112:in `search'
/usr/local/Homebrew/Library/Homebrew/cmd/desc.rb:36:in `desc'
/usr/local/Homebrew/Library/Homebrew/brew.rb:100:in `<main>'

What you expected to happen

the output of the search with all items matching the description or title of my query

Step-by-step reproduction instructions (by running brew commands)

brew desc -s z3

updated description after fixing brew prune issue still exists


Advisory for Browser Zoom Related Issues

Some browsers have issues detecting exact font and image sizes when zoomed
in or out.  Prior workarounds have failed and we don't want to use regular
expressions, which have many defeciencies.
For the short term we will add a note to the affected challenges that the
browser zoom must be at 100%.

Closes #6397
Closes #6242
Closes #6395
Tested Locally

Looks good to me, but it would since I helped him work on it. Leaving it open for a third set of eyes.

:+1:

Browser Zoom Related Issues persist in my case, I'm using Google Chrome on a Linux Mint platform; setting zoom to 100% still does not allow me to procedd further with my task

@cladddd If you're still having issues please open another issue and detail your browser, etc.  You can also post your code.


Kong v0.10.0rc1 start with cassandra,  raised error

I try to run https://github.com/Mashape/docker-kong/blob/0.10.0rc1/Dockerfile with Cassandra(v2.2.8)
Here is a error.log from kong
2017/01/08 04:26:59 [warn] 76#0: [lua] globalpatches.lua:228: randomseed(): math.randomseed() must be called in init_worker context
stack traceback:
/usr/local/openresty/lualib/resty/dns/resolver.lua:951: in main chunk
[C]: in function 'require'
/usr/local/share/lua/5.1/kong/core/globalpatches.lua:358: in function </usr/local/share/lua/5.1/kong/core/globalpatches.lua:3>
/usr/local/share/lua/5.1/kong.lua:27: in main chunk
[C]: in function 'require'
init_by_lua:3: in main chunk
2017/01/08 04:26:59 [error] 88#0: init_worker_by_lua error: /usr/local/openresty/lualib/resty/lock.lua:153: API disabled in the context of init_worker_by_lua*
stack traceback:
[C]: in function 'sleep'
/usr/local/openresty/lualib/resty/lock.lua:153: in function 'lock'
/usr/local/share/lua/5.1/resty/cassandra/cluster.lua:625: in function 'get_or_prepare'
/usr/local/share/lua/5.1/resty/cassandra/cluster.lua:833: in function 'execute'
/usr/local/share/lua/5.1/cassandra/init.lua:411: in function '(for generator)'
/usr/local/share/lua/5.1/kong/dao/db/cassandra.lua:339: in function 'find_all'
/usr/local/share/lua/5.1/kong/dao/dao.lua:178: in function 'find_all'
/usr/local/share/lua/5.1/kong/core/handler.lua:32: in function 'build_router'
/usr/local/share/lua/5.1/kong/core/handler.lua:61: in function 'before'
/usr/local/share/lua/5.1/kong.lua:186: in function 'init_worker'
init_worker_by_lua:2: in main chunk
2017/01/08 04:27:08 [error] 89#0: *6 [lua] events.lua:88: errlog(): worker-events: dropping event; waiting for event data timed ou
t, id: 2, context: ngx.timer
2017/01/08 04:27:15 [warn] 88#0: *4 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition key
, context: ngx.timer
2017/01/08 04:27:15 [warn] 88#0: *19 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition ke
y, context: ngx.timer
2017/01/08 04:27:15 [warn] 88#0: *11 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition ke
y, context: ngx.timer
2017/01/08 04:27:16 [warn] 88#0: *30 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition ke
y, context: ngx.timer
2017/01/08 04:27:19 [warn] 88#0: *39 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition ke
y, context: ngx.timer
2017/01/08 04:27:22 [warn] 88#0: *47 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition ke
y, context: ngx.timer
2017/01/08 04:27:25 [warn] 88#0: *55 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition ke
y, context: ngx.timer
2017/01/08 04:27:28 [warn] 88#0: *63 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition ke
y, context: ngx.timer
2017/01/08 04:27:31 [warn] 88#0: *73 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition ke
y, context: ngx.timer
2017/01/08 04:27:34 [warn] 88#0: *81 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition ke
y, context: ngx.timer
2017/01/08 04:27:37 [warn] 88#0: *89 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition ke
y, context: ngx.timer

Kong version (0.10.0rc1)
Kong default configuration

kong git:(next) curl -i -X POST
--url http://localhost:8001/apis/
--data 'name=test'
--data 'upstream_url=http://test:8081/apis/'
--data 'request_host=test.com'
HTTP/1.1 400 Bad Request
Date: Sun, 08 Jan 2017 04:27:18 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Access-Control-Allow-Origin: *
Server: kong/0.10.0rc1

The first one (randomseed) is just a warning. The second is a bug that has been fixed in a commit I just pushed. The last ones are also warnings.
Thx for the report 👍

fixed in the next rc, closing this

Hi,
I'm getting the same error on kong 0.10.1 and cassandra 3.0.9 installed on centos 7.3.1611:
2017/03/30 09:16:38 [error] 4238#0: *8 [lua] events.lua:88: errlog(): worker-events: dropping event; waiting for event data timed out, id: 3, context: ngx.timer
2017/03/30 09:16:38 [error] 4236#0: *4 [lua] events.lua:88: errlog(): worker-events: dropping event; waiting for event data timed out, id: 2, context: ngx.timer
2017/03/30 09:16:38 [error] 4236#0: *4 [lua] events.lua:88: errlog(): worker-events: dropping event; waiting for event data timed out, id: 3, context: ngx.timer
2017/03/30 09:16:38 [error] 4236#0: *4 [lua] events.lua:88: errlog(): worker-events: dropping event; waiting for event data timed out, id: 4, context: ngx.timer
2017/03/30 09:16:38 [error] 4238#0: *8 [lua] events.lua:88: errlog(): worker-events: dropping event; waiting for event data timed out, id: 4, context: ngx.timer
2017/03/30 09:16:39 [error] 4237#0: *15 [lua] events.lua:88: errlog(): worker-events: dropping event; waiting for event data timed out, id: 4, context: ngx.timer
2017/03/30 09:16:39 [warn] 4236#0: *5 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition key, context: ngx.timer
2017/03/30 09:16:40 [warn] 4236#0: *22 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition key, context: ngx.timer
2017/03/30 09:16:45 [warn] 4237#0: *38 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition key, context: ngx.timer
2017/03/30 09:16:46 [warn] 4237#0: *57 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition key, context: ngx.timer
2017/03/30 09:16:49 [warn] 4237#0: *73 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition key, context: ngx.timer
2017/03/30 09:16:52 [warn] 4237#0: *89 [lua] cluster.lua:745: execute(): [lua-cassandra] Aggregation query used without partition key, context: ngx.timer
I installed the kong and cassandra on the fresh VM:
$ java -version
openjdk version "1.8.0_121" // OK
$ cd  /etc/yum.repos.d/
$ sudo vi datastax.repo
[datastax]
name = DataStax Repo for Apache Cassandra
baseurl = http://rpm.datastax.com/community
enabled = 1
gpgcheck = 0
$ sudo yum install dsc30
$ sudo yum install cassandra30-tools
$ sudo chkconfig cassandra on
$ sudo service cassandra start
$ sudo yum install epel-release
$ sudo wget https://bintray.com/mashape/kong-rpm-el7-0.10.x/rpm -O bintray-mashape-kong-rpm-el7-0.10.x.repo
$ sudo yum install kong-0.10.1
$ sudo cp /etc/kong/kong.conf.default /etc/kong/kong.conf
$ sudo vi /etc/kong/kong.conf
database = cassandra
$ kong start


Remove deprecated features in 0.45 in quantumcircuit

Summary
Remove features deprecated in 0.45 in qiskit/circuit/quantumcircuit.py
Details and comments
The list of featured removed are:

header
extension_lib
i
fredkin
cnot
toffoli
mct
diagonal
iso
hmailtonian
uc
ucrx
urcy
urcz
squ
snapshot

I also removed spy,py in qiskit/extensions/quantum_initializer, as its __init__ is deprecated and to use a single-qubit unitary, you can use qiskit.circuit.library.UnitaryGate instead.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.008%) to 89.496%

Totals

Change from base Build<PHONE_NUMBER>:
0.008%

Covered Lines:
59472

Relevant Lines:
66452

💛  - Coveralls


Draggable & Minimizable Modals

Describe the feature
I'm not sure if this is possible but one of our members requested the following:

when doing a name or vehicle search, can there be an ability to minimise the windows instead of having to close them each time. So when doing a name search, you then have to close that window and then do a vehicle search. You sometimes forget the name and have to ask for ID again then close the vehicle search window and do a new name search. Could there be an ability to have the two open at the same time, and minimise one or the other instead of having to close one or the other on each occasion.
If you forget to close one of the windows and try to open another one, i.e i have a name search window open and go to open another, a message comes up informing there is already a window open.

Something like the attached additional content gif I believe is what the ask is. This would be for the following modals:

Name Search
Registration Search
Creating warrants/warnings/arrest reports and fines.

Additional Context

Duplicate of #1167


WatchTree leaks etcd.EtcdError if key doesn't exist with etcd backend.

Desired behavior is for WatchTree to return store.ErrKeyNotFound so that client code doesn't need special-casing to handle different backends.

+1 we should handle this case gracefully so that the client can test the error code and take the appropriate actions.

Closed by #27 (WatchTree still needs a refactor though, see #28)


Update release-please-action

Not an easy task: https://github.com/google-github-actions/release-please-action?tab=readme-ov-file#upgrading-from-v3-to-v4

The main issue with v4 is that a bunch of configuration that we could pass to the action has now to be set in a json file in the project being released. Whatever solution we come up with should not make this configuration file mandatory.

I was trying to automatically create a config file before running release-please in https://github.com/zakodium/workflows/commits/release-please-v4/.
But it didn't work and I found out that the file has to live on the base branch, it is not read from the local file system (that's probably because release-please does everything using the GH API, it doesn't need a checkout): https://github.com/googleapis/release-please/blob/main/docs/manifest-releaser.md#configfile
So there is no way to have a default/global config file.
The only solution I see is to remove our custom config. It currently has two fields:

bump-minor-pre-major. I think this one is not a problem. We usually shouldn't keep 0.x version numbers for a long time. If it's necessary, we can add a config file directly in the project.
changelog-sections. This is a bit more annoying because it was added so that docs: PRs trigger a release. But we can (and have historically) live without it.

@stropitek wdyt?

I guess for bump-minor-pre-major we will notice the major bump in the release PR and add the config file if needed before releasing so that we don't get a major bump.
For changelog-sections it's indeed more annoying.
We should probably add the config file to our cheminfo-generator if we are still maintaining that.

This will not help for the hundreds of repos that are already out there

I can live with it


Chai v5 support

The current peerDependencies version range forbids installing chai-as-promised with chai v5:
"peerDependencies": {
    "chai": ">= 2.1.2 < 5"
  }

Release notes: https://github.com/chaijs/chai/releases/tag/v5.0.0

I have the problem too. @domenic -> if you have no bandwidth to maintain, let's talk

Also note that chai.use() doesn't currently work without a code change: https://github.com/chaijs/chai/issues/1569

node version - v16.19.1
npm version - 8.19.3
when updated the package dependencies for chai to 5.0.0 its not longer working.
npm WARN While resolving<EMAIL_ADDRESS>npm WARN Found<EMAIL_ADDRESS>npm WARN node_modules/chai
npm WARN   dev<EMAIL_ADDRESS>from the root project
npm WARN   1 more (chai-as-promised)
npm WARN
npm WARN Could not resolve dependency:
npm WARN peer chai@">= 2.1.2 < 5" from<EMAIL_ADDRESS>npm WARN node_modules/chai-as-promised
npm WARN   dev<EMAIL_ADDRESS>from the root project

Chai 5 is DEFINITLY not useable currently

See also: https://github.com/chaijs/chai/issues/1570

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/chai
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer chai@">= 2.1.2 < 5" from<EMAIL_ADDRESS>npm ERR! node_modules/chai-as-promised
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
npm ERR! For a full report see:
npm ERR! /home/khteh/.npm/_logs/2024-01-06T09_00_12_017Z-eresolve-report.txt

Hope you noticed that the last commit at this repository is 6 years ago.
I would not expect a fast fix...

Is there any alternative to this library?

Is there any alternative to this library?

https://github.com/chaijs/chai/issues/1570

I got desperate enough to fork and fix, https://github.com/rvagg/chai-as-promised, @rvagg/chai-as-promised is ESM, bundles the @types/chai-as-promised types, and works with chai@5. Can upstream some of those commits here if Domenic decides this isn't a dead project.

I got desperate enough to fork and fix, https://github.com/rvagg/chai-as-promised, @rvagg/chai-as-promised is ESM, bundles the @types/chai-as-promised types, and works with chai@5. Can upstream some of those commits here if Domenic decides this isn't a dead project.

Just in time

As long as there are no breaking changes somewhere, you can simply add chai to package.json's overrides section e.g.:
...
  "overrides": {
    "chai": "^5.0.0"
  },
...

This approach is giving us often a bit time for either finding a maintained replacement or forking + maintaining on our own or for entirely cleaning up an unmaintained dependency. More freedom temporarily ...

https://github.com/ramanarupa/chai-promised

FYI 7.1.2 resolves the peer dependency issue
8.0.0 is on the way and will be esm-only like chai itself
closing since the 7.1.2 release should solve this issue for now.


missing VAR declaration in function

I was getting a "key is undefined" error. You need to add the VAR declaration in your for loop in the checkCompletion function (line 203).
for(var key in marks)

Thanks! Should be fixed.


Annotate all scikit-image functions with types

In order to automatically generate a GUI and to know what to do with the return types of each function, we need the functions to be properly annotated. Is an output array an image or a set of coordinates?

Use Python 3.5 type annotations
Augment these annotations with new type definitions, eg Coordinates, Image, NumPyCoordinates...

We can then use these annotations to display each type appropriately.
Initially, we can try to do some processing of our current annotations from NumPy style docstrings.

Yeah, I was thinking about this in addition to general parameter typing with GUI elements – for example labeling discrete data types for use with dropdowns, small-range bounded continuous data types for use with sliders, large-range and unbounded continuous data types with input fields, angles with a directional vector, etc.
One thing that may present a problem is API changes. Should we assume specific/minimum versions for the interfaces we will be working with?

@jni
Ok, now that I've actually read up on typing annotations (just found out about them lol!) and I'm going to have to disagree with you here. Python 3.5-style typing is useful, yes, but I don't think that it necessarily has any advantages over using decorators for our use case, so it doesn't really warrant a Python 3.5+ dependency.
Furthermore, the "typing" that we want is less of actual typing and more of instructions for how we want to build our GUI structures. Additionally, from my brief skimming of the documentation, it doesn't look like we can add arguments to these types (and I hope not for the sake of bloat), which means that we won't be able to set bounds for continuous data types and label the meaning of "None", among other useful utilities.
TLDR; I propose that we use decorators in conjunction with classes to represent our GUI for access to additional structure parameters.

Hi @kne42!
Several points:
The first one is that Napari will be either Py3.5+ or Py3.6+ anyway, so we get type annotations for free.  We are not taking any additional dependencies for this. (This is true of skimage master also, btw.) As an aside, no new Python projects should use an earlier version of Python imho.
Now, if we assume we can use typing, what can we do?
The goal is to crawl the scikit-image API, populate the Napari menus with functions that make sense, and use the appropriate display functions for each conceptual "type". A constraint is that whatever solution we pick should not create a tight coupling between Napari and any libraries it uses (be it skimage, NumPy, TensorFlow...).
I agree with you that we probably don't want to create a "type" for "float in [0.01, 100]" or whatever, (though I think this is totally possible to do) (and actually maybe it is the right thing to do), but we can create type definitions for different conceptual "arrays", and I think that these would actually be useful in scikit-image to generate documentation anyway.
As to parameter ranges, I think that we shouldn't worry too much about sliders etc for now and use a text box. If the user inputs an "incorrect" value, hopefully we raise a useful error message that will point them to the right place in the skimage documentation.
What do you think? This is all a bit vague without a clear implementation, so it might be best to attempt something and see how it looks. (I also believe there was a discussion in the NumPy mailing list about typing for NumPy, that might be informative.) I don't have time to mock this up right now but will later this week.

On 4. Jun 2018, at 22:43, Juan Nunez-Iglesias<EMAIL_ADDRESS>wrote:
Hi @kne42 https://github.com/kne42!
Several points:
The first one is that Napari will be either Py3.5+ or Py3.6+ anyway, so we get type annotations for free. We are not taking any additional dependencies for this. (This is true of skimage master also, btw.) As an aside, no new Python projects should use an earlier version of Python imho.

Definitely.

Now, if we assume we can use typing, what can we do?
The goal is to crawl the scikit-image API, populate the Napari menus with functions that make sense, and use the appropriate display functions for each conceptual "type". A constraint is that whatever solution we pick should not create a tight coupling between Napari and any libraries it uses (be it skimage, NumPy, TensorFlow...).

I agree.

I agree with you that we probably don't want to create a "type" for "float in [0.01, 100]" or whatever, (though I think this is totally possible to do) (and actually maybe it is the right thing to do), but we can create type definitions for different conceptual "arrays", and I think that these would actually be useful in scikit-image to generate documentation anyway.

I also think that defining a functional ‘contractt with value ranges is a very good thing going forward.
this will be essential to be able to have sliders, good for documentation.
I come from the java world, and i am of course biased towards strong typing.

As to parameter ranges, I think that we shouldn't worry too much about sliders etc for now and use a text box. If the user inputs an "incorrect" value, hopefully we raise a useful error message that will point them to the right place in the skimage documentation.

We can start simple,
but even with a text box,
it would be great if we can
tell the user what kind of values
to expect… That would have a great impact
on ergonomics. I have seen too many tools with
complicated GUIs and tons of parameters, and
you never know which kind of values are ‘correct’
which also makes it difficult to understand the meaning
of these paramneters,,,,
Any chance we can have also some sort of annotation
of the function that describes what it does? so we can
also populate that in the menus and gui popups… ?

What do you think? This is all a bit vague without a clear implementation, so it might be best to attempt something and see how it looks. (I also believe there was a discussion in the NumPy mailing list about typing for NumPy, that might be informative.) I don't have time to mock this up right now but will later this week.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/Napari/napari/issues/1#issuecomment-394588579, or mute the thread https://github.com/notifications/unsubscribe-auth/AByMkljIGXQS6g04VNCnzysEVeKCzd_mks5t5hp9gaJpZM4UYKRs.

@royerloic I haven't looked at it yet, but we should be able to use the numpy doc parsing tools to get a lot of this information out. We can have a short description displayed that parallels the first line of text in the docstring and have an expanded explanation for the rest of it, as well as conversion of the Notes section to an info button/tooltip, etc.

Any chance we can have also some sort of annotation
of the function that describes what it does? so we can
also populate that in the menus and gui popups… ?

Yes. All skimage and SciPy ecosystem functions follow the NumPy docstring convention that annotates all arguments and return values. We can automatically parse these and include them as (?) buttons or hover tooltips. Actually this is another awesome advantage of this ecosystem, we are going to get great docs for almost free.
By the way, @royerloic, you can turn these on in the preferences for PyCharm (search for "docstring"), and you will be given a nice template every time you start a new docstring.

I also think that defining a functional ‘contractt with value ranges is a very good thing going forward.
this will be essential to be able to have sliders, good for documentation.

Sliders are harder to implement. A very large proportion of parameters are unbounded but only really make sense in some typical range. This range, though, is often data dependent, and anyway should not be restricted in case someone comes up with a pipeline where atypical argument values make sense. One solution might be to have sliders for some parameters, that can be reverted to text boxes by clicking on an "Advanced" interface button (with "Simplified" being the default).

I come from the java world, and i am of course biased towards strong typing.

Then you are entering Python at exactly the right moment. =)

Let's move discussion of docstring parsing to #6 :)

@kne42 an exciting notebook! How close do you think it is to working? Can't wait to see the output on skimage.filters.gaussian.__doc__, for example. =)
Come to think of it, a NumPy docstring -> Py3.5 type annotations conversion library would be tremendously impactful. A ton of projects could make use of it.

@jni I expect to finish a rudimentary version of this by the end of
tomorrow, or Friday at latest.
Custom type definitions have been covered for the most part, with the
exception of arrays (I think I’ll implement a similar syntax to Cython
memoryviews). I’ll open a PR to track these implementations soon and you
can let me know what you think about the conventions used.
On Wed, Jun 6, 2018 at 6:19 PM Juan Nunez-Iglesias<EMAIL_ADDRESS>wrote:

@kne42 https://github.com/kne42 an exciting notebook! How close do you
think it is to working? Can't wait to see the output on
skimage.filters.gaussian.doc, for example. =)
Come to think of it, a NumPy docstring -> Py3.5 type annotations
conversion library would be tremendously impactful. A ton of projects
could make use of it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Napari/napari/issues/1#issuecomment-395232143, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Ab0F02JBN_NtwEqnqMPlN542NB9yFIUtks5t6FVjgaJpZM4UYKRs
.

@jni Actually upon second thought, perhaps some hacky implementation might be better considering that bracket notation is already in use by types.
We would make a Shape class that overrides the <= operator to modify whatever type is on the right. The type on the right must implement Iterable, naturally.
Here's some example syntax:
Shape[:, :] <= Array[Integer]      # 2D int Array
Shape[...] <= Array[Float]         # nD float Array
Shape[:, :, ...] <= Array[Object]  # 2+D Object Array
Shape[3] <= Array[Float]           # flat Array of length 3
Shape[..., 5] <= Array[Integer]    # nD int Array with last axis of size 5

and the option to have SizeVars, similar to TypeVars:
M = SizeVar('M')
N = SizeVar('N')

def foo(coords: Shape[M, ..., N] <= Array[Number],
        center: Union[Scalar, Shape[M] <= Iterable[Number]]
        ) -> Shape[M, N] <= Array[Float]

Actually, to implement the above I think I'll need a lot longer than two days 😅

@kne42 I'm on board with this but I still think it's important to do a minimal proof of concept first, and expand that proof of concept to something more thorough (including shape info) later.
Also note that some of this info could be part of Image: Image2D, ImageMultichannel, etc.

@kne42 in case you haven't seen these already, here's some links that could be useful:
https://github.com/numpy/numpy/issues/7370#issuecomment-345844120
https://github.com/numpy/numpy/issues/7370#issuecomment-349494653
https://github.com/numpy/numpy_stubs

@jni How do you think we should go about typing {'reflect', 'constant', 'nearest', 'mirror', 'wrap'}?

@kne42 in languages like Haskell this would be an Enum type. Python actually has some facility for this:
https://docs.python.org/3/library/enum.html
https://www.python.org/dev/peps/pep-0484/ (search for Enum)
it would be nice to get the relevant libraries to use Enum here but I don't think that's realistic, so perhaps using a Union again would be useful.
Thinking about it in terms of Napari, the goal would be to have a drop-down for this type of annotation, so whatever you do, you should be able to get the possible values from the type annotation.

@jni Thank you for this! The typing library is actually compatible with class types in general so hopefully this will work. The reason we've been having so many issues with NumPy arrays is due to a lot of their functions (and subsequent derived SciPy functions) accepting array_like instead of explicit arrays. Also the conflict between array indexing and subtyping using the same syntax is an issue preventing us from necessarily using the ndarray class directly.

Some interesting type discussions on the NumPy mailing list. Specifically, the new XND project has created an "ndtypes" library that includes pattern matching for dtypes and shapes:
https://mail.python.org/pipermail/numpy-discussion/2018-June/078261.html
Not necessary promoting any action here, just making a note for future reference. =)


Error: nativeNC failed

I have tried that sample code take from wiki :
var request = require('sync-request');
var res = request('GET', 'http://example.com');
console.log(res.getBody());

result:
events.js:137
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at _errnoException (util.js:1003:13)
    at TCP.onread (net.js:623:25)
/Users/stamagnini/Workspace/uniservFrontend/acceptanceTests/node_modules/sync-rpc/lib/index.js:121
      throw new Error(
      ^

Error: nativeNC failed:

    at sendMessage ([..]/node_modules/sync-rpc/lib/index.js:121:13)
    at createClient ([..]/node_modules/sync-rpc/lib/index.js:152:27)
    at Object.<anonymous> ([..]/node_modules/sync-request/lib/index.js:16:14)
    at Module._compile (module.js:660:30)
    at Object.Module._extensions..js (module.js:671:10)
    at Module.load (module.js:573:32)
    at tryModuleLoad (module.js:513:12)
    at Function.Module._load (module.js:505:3)
    at Module.require (module.js:604:17)
    at require (internal/module.js:11:18)

my node version is v9.5.0 , OS: macosx 10.11.6

If you clear any package-lock.json/yarn.lock files and re-install you can see if the latest sync-rpc release (1.3.1) makes a difference. I can't reproduce the issue myself, so there's a limit to what I can do.

Ok, with sync-rpc 1.3.1 work! Thx.

I'm using<EMAIL_ADDRESS>that references<EMAIL_ADDRESS>and I have experienced this same "Error: nativeNC failed" error twice in the last month. Any ideas ?

I remain unable to reproduce the issue across multiple operating systems and devices, so I'll need much more detail if I'm to be of any assistance.

I'm consistently getting this error using sync-mysql, would a reproducible example or 3 help here?