TypeScript: Kiota.Builder.KiotaBuilder[0]: error generating the client: the current dom node already contains a child with name

Hello!
I'm trying to generate a TypeScript API client for the following OpenApi specification:
https://vdc-download.vmware.com/vmwb-repository/dcr-public/57e38985-f93c-4dba-baaf-cc7a8f77664e/ad079dcd-ef86-4be5-8e82-5dee43c79e74/vi_json_openapi_specification_v8_0_2_0.zip
I have installed "kiota" and followed the instructions.
./kiota --version
1.12.0+1735a2ff916ebec661974d9560f1dd00d3dc349b

And this is the problem that I'm hitting:
crit: Kiota.Builder.KiotaBuilder[0]
      error generating the client: the current dom node already contains a child with name HostScsiTopologyInterface and of type CodeClass

Note: I can successfully generate API clients for Java/Python.
Sorry if the topic is already covered by another issue.

Hi @NikolayLS
Thanks for using kiota and for reaching out.
Can you generate again, passing --ll information and upload the full kiota log here please?

@baywet Thanks for the prompt response!
Here is the full kiota log:
./kiota generate -l typescript -d vi_json_openapi_specification_v8_0_2_0.yaml -c ApiClient -o ./client --ll information
info: Kiota.Builder.KiotaBu./kiota generate -l typescript -d vi_json_openapi_specification_v8_0_2_0.yaml -c ApiClient -o ./client --ll information
info: Kiota.Builder.KiotaBuilder[0]
      loaded description from local source
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/paths/~1SessionManager~1{moId}~1AcquireCloneTicket/post/responses/200/content/application~1json/schema - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ChangeNFSUserPasswordRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ChangePasswordRequestType/properties/oldPassword - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ChangePasswordRequestType/properties/newPassword - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/CloneSessionRequestType/properties/cloneTicket - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ConfigureDatastorePrincipalRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/JoinDomainRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/LoginRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/QueryConnectionInfoRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/SetNFSUserRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/UploadClientCertRequestType/properties/privateKey - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostServiceTicket/properties/sessionId - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/PasswordField/properties/value - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ServiceLocatorNamePassword/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ServiceLocatorSAMLCredential/properties/token - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/SessionManagerGenericServiceTicket/properties/id - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/VirtualMachineMksTicket/properties/ticket - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/VirtualMachineTicket/properties/ticket - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/CryptoKeyPlain/properties/keyData - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/KmipServerSpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostActiveDirectorySpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostConnectSpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostConnectSpec/properties/vimAccountPassword - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostInternetScsiHbaAuthenticationProperties/properties/chapSecret - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostInternetScsiHbaAuthenticationProperties/properties/mutualChapSecret - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostIpmiInfo/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostAccountSpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostNasVolumeSpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostPatchManagerPatchManagerOperationSpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostSecuritySpec/properties/adminPassword - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/VAppPropertyInfo/properties/defaultValue - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/VAppPropertyInfo/properties/value - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/CustomizationPassword/properties/value - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/NamePasswordAuthentication/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/SAMLTokenAuthentication/properties/token - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/TicketedSessionAuthentication/properties/ticket - The format password is not supported by Kiota for the type string and the string type will be used.
crit: Kiota.Builder.KiotaBuilder[0]
      error generating the client: the current dom node already contains a child with name HostScsiTopologyInterface and of type CodeClassilder[0]
      loaded description from local source
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/paths/~1SessionManager~1{moId}~1AcquireCloneTicket/post/responses/200/content/application~1json/schema - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ChangeNFSUserPasswordRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ChangePasswordRequestType/properties/oldPassword - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ChangePasswordRequestType/properties/newPassword - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/CloneSessionRequestType/properties/cloneTicket - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ConfigureDatastorePrincipalRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/JoinDomainRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/LoginRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/QueryConnectionInfoRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/SetNFSUserRequestType/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/UploadClientCertRequestType/properties/privateKey - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostServiceTicket/properties/sessionId - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/PasswordField/properties/value - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ServiceLocatorNamePassword/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/ServiceLocatorSAMLCredential/properties/token - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/SessionManagerGenericServiceTicket/properties/id - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/VirtualMachineMksTicket/properties/ticket - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/VirtualMachineTicket/properties/ticket - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/CryptoKeyPlain/properties/keyData - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/KmipServerSpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostActiveDirectorySpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostConnectSpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostConnectSpec/properties/vimAccountPassword - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostInternetScsiHbaAuthenticationProperties/properties/chapSecret - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostInternetScsiHbaAuthenticationProperties/properties/mutualChapSecret - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostIpmiInfo/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostAccountSpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostNasVolumeSpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostPatchManagerPatchManagerOperationSpec/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/HostSecuritySpec/properties/adminPassword - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/VAppPropertyInfo/properties/defaultValue - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/VAppPropertyInfo/properties/value - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/CustomizationPassword/properties/value - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/NamePasswordAuthentication/properties/password - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/SAMLTokenAuthentication/properties/token - The format password is not supported by Kiota for the type string and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/TicketedSessionAuthentication/properties/ticket - The format password is not supported by Kiota for the type string and the string type will be used.
crit: Kiota.Builder.KiotaBuilder[0]
      error generating the client: the current dom node already contains a child with name HostScsiTopologyInterface and of type CodeClass

The issue here is caused byt the openApi description contains the type HostScsiTopology and HostScsiTopologyInterface. When the refiner is creating the interface for HostScsiTopology by appending the Interface suffix, there is a collision in the names between interface to be created and the existing model HostScsiTopologyInterface.
Solution here is to have the refiner check the new interface name exists in the namespace and try to disambiguate further before trying to add it in the refiner.
https://github.com/microsoft/kiota/blob/bf97766490d22f314fdab919a7bda7f5d1da05a8/src/Kiota.Builder/Refiners/TypeScriptRefiner.cs#L955


fix avoid generate config doc automatically

Proposed changes
Issue Number: close #xxx
Problem summary
After #19246, when compilng FE, it will automatically generate Config and Session Variables doc and overwrite the origin one.
Need to avoid it because it is not ready to use yet
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall


Change Stepper's currentStep according to StepState

As the screenshot shown below, the first 2 of the steps are StepState.complete and others are StepState.indexed.
Is it possible to change the currentStep to 3rd step since it is not completed when the widget builds? I couldn't do a setState when the list is building
My attempt:
List<Step> _steps(List<Guide> guides) {
    List<Step> _steps = <Step>[];
    Step _incompleteGuide;

    guides.forEach((Guide guide) {
      Step _step = Step(
        title: Text(guide.title),
        subtitle: Text(guide.subtitle),
        content: Column(
          crossAxisAlignment: CrossAxisAlignment.stretch,
          children: <Widget>[
            StepButton(guide.type),
          ],
        ),
        isActive: true,
        state: guide.isCompleted ? StepState.complete : StepState.indexed,
      );
      _steps.add(_step);
      if (_incompleteGuide == null) {
        if (guide.isCompleted == false) {
          _incompleteGuide = _step;
        }
      }
    });
    setState(() {
      _currentStep = _steps.indexOf(_incompleteGuide);
    });
    return _steps;
  }

If I understood your problem, you should set the _currentStep in the initState method!

@GaspardMerten yea, I've added initState but it gets error saying that I can't setState when I'm building the widget

@ezraaaa  no need to use setState in the initState !

@GaspardMerten uhhmm maybe take a look at my code
import 'package:codecumbers/blocs/guidance_bloc.dart';
import 'package:codecumbers/common/widgets/loader.dart';
import 'package:codecumbers/models/guide.dart';
import 'package:codecumbers/providers/bloc_provider.dart';
import 'package:codecumbers/screen/home/widgets/step_button.dart';
import 'package:flutter/material.dart';

class Guidance extends StatefulWidget {
  @override
  _GuidanceState createState() => _GuidanceState();
}

class _GuidanceState extends State<Guidance> {
  GuidanceBloc _guidanceBloc;
  int _currentStep;

  @override
  void initState() {
    _currentStep = 0;
    super.initState();
  }

  @override
  void didChangeDependencies() {
    _guidanceBloc = BlocProvider.of<GuidanceBloc>(context);
    super.didChangeDependencies();
  }

  List<Step> _steps(List<Guide> guides) {
    List<Step> _steps = <Step>[];
    Step _incompleteGuide;

    guides.forEach((Guide guide) {
      Step _step = Step(
        title: Text(guide.title),
        subtitle: Text(guide.subtitle),
        content: Column(
          crossAxisAlignment: CrossAxisAlignment.stretch,
          children: <Widget>[
            StepButton(guide.type),
          ],
        ),
        isActive: true,
        state: guide.isCompleted ? StepState.complete : StepState.indexed,
      );
      _steps.add(_step);
      if (_incompleteGuide == null) {
        if (guide.isCompleted == false) {
          _incompleteGuide = _step;
        }
      }
    });
    setState(() {
      _currentStep = _steps.indexOf(_incompleteGuide);
    });
    return _steps;
  }

  @override
  Widget build(BuildContext context) {
    return StreamBuilder(
        stream: _guidanceBloc.outGuides,
        builder: (BuildContext context, AsyncSnapshot<List<Guide>> snapshot) {
          if (snapshot.connectionState == ConnectionState.waiting) {
            return Center(
              child: Loader(
                circular: true,
              ),
            );
          } else {
            return Stepper(
              steps: _steps(snapshot.data),
              currentStep: _currentStep,
              physics: ClampingScrollPhysics(),
              onStepTapped: (step) {
                setState(() {
                  _currentStep = step;
                });
              },
              controlsBuilder: (BuildContext context,
                      {VoidCallback onStepContinue,
                      VoidCallback onStepCancel}) =>
                  Container(),
            );
          }
        });
  }
}

the error was
flutter: _StreamBuilderBaseState<List<Guide>, AsyncSnapshot<List<Guide>>>#af19b):
flutter: setState() or markNeedsBuild() called during build.
flutter: This Guidance widget cannot be marked as needing to build because the framework is already in the
flutter: process of building widgets.  A widget can be marked as needing to be built during the build phase
flutter: only if one of its ancestors is currently building. This exception is allowed because the framework
flutter: builds parent widgets before children, which means a dirty descendant will always be built.
flutter: Otherwise, the framework might not visit this widget during this build phase.
flutter: The widget on which setState() or markNeedsBuild() was called was:
flutter:   Guidance
flutter: The widget which was currently being built when the offending call was made was:
flutter:   StreamBuilder<List<Guide>>

Just remove the setState from your function! And remove the initstate part that I told you about.
You don't need to call setState, just change the variable without setState

@GaspardMerten okay, it works but another problem surface, onStepTapped don't switch to the steps that is tapped

You should not use setState with bloc logic!
What you should do is push a new state on the stream to refresh the view!
But you should ask that on Stack Overflow, Flutter issues are for issue within the framework!

Thank you @GaspardMerten for help!
@ezraaaa in case when another problem occurs as you mentioned in the comment above, it's recommended to close the existing issue and to open the new one, with a reference to the previous one if needed.
Anyway, this is a question better suited for StackOverflow. Closing, as this is not an issue report. See https://flutter.dev/community for support options. And hope you solved your problem!


C# support

[x] .NET Standard wrapper
[x] Functional tests
[x] Unit tests
[X] CI Automation
[X] NuGet Packaging
[X] SDK Packaging

C# support
Target .NET Frameworks

.NET Framework (desktop apps)
.NET Core (Windows and Linux)

Target UI Framewoks

WPF
WinForms

@Brent-A I have some thoughts for the C# wrapper:
I've noticed the body tracking SDK uses some structures of the Kinect4A DK, in particular it uses k4a_result_t, k4a_calibration_t, k4a_wait_result_t, k4a_capture_t , and might use others too...
I don't know if it's possible, but it could be interesting if the new Body tracker could be used offline, even without a device plugged, for which it could be interesting to use the body tracker without dragging the whole Microsoft.Azure.Kinect.Sensor....  so I was thinking if it could be possible to split the project into two assemblies.... something that would only containt the core, exchangeable types (so it could be used separately) and another one for the actual API.
About accessing IntPtr* .... its something we do use in our current implementation of Kinect2 for performance reasons, if such an API is considered, it could be nice if the exposed API uses ReadOnlySpan instead of IntPtr*

The bulk of the C# support is in develop now and we are mostly working on cleanup, bugs, and documentation. Closing this issue out in favor of individual issues for the remaining work.

By Chance is this SDK for the V2 Kinect Sensor!?

This SDK only supports the Azure Kinect DK. It does not support the Kinect for Windows v2.

When can I expect the C# wrapper for Body Tracking SDK?

~tumbleweed~

@MsDerekMa  Any updates on C# wrapper for Body Tracking ?

Guys check it below link,it may be useful
https://ivatilca.wordpress.com/2019/08/22/first-azure-kinect-app-c-api-vs-c-k4a-nuget-package/  - Explain both how to use C API and C# API

@dhgokul as noted in #689, we don't have the the C# wrapper for Body Tracking planned. We are tracking the request on the feedback site, https://feedback.azure.com/forums/920053-azure-kinect-dk/suggestions/38661742-bodytracking-c-wrapper, to help us understand interest levels.


Running BlackParrot through OpenFPGA

Hi!
So here is a single core BP Verilog file generated by bsg_sv2v. I'm trying to run it through the flow, but I'm getting strange Yosys errors. Any ideas on were the problem might be?
The error is: input buffer overflow, can't enlarge buffer because scanner uses REJECT ERROR: Fail Yosys for benchmark bp.
bp_top.v.txt

bp_be_calculator_top.v.txt


Steam Container Runtime Support

The recent linux steamvr beta uses a new version of the steam runtime (sniper) based on containers, which prevents alvr from loading (*in the case of a install in system directories, /home is still visible by default), this should fix that.
Resources:

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md#layout-of-the-container-runtime
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md#detecting-the-container-environment

Everything should work now, though I haven't done any testing on AppImages.

What is the state on this? Can we include this in the next release?

Nope, it appears after another update of SteamVR not to only not work with flatpak but also native

rip, I'll look into it

Huh, it still works for me
Well, i'm getting a "Failed to connect to headset display" error (didn't test if that prevents it from streaming), but the driver loads, at least
(Could be a vulkan layer issue)

Possibly, would you at least be willing to workout the flatpak side

Where in the logs where I need to check to see if everything is loading correctly?

It's pretty apparent in steamvr whether or not the driver loads, but idk if the vulkan layer loading is logged anywhere

yea I get a 108 so I assume that what you get when the driver doesn't load

After testing: On a source dir build & run (from /home ) everything works fine, broken when installed as a system package, seems like it has to be the vulkan layer/vrcompositor-wrapper (also there might be an issue with pipewire, but that's for later)

Steamvr 2.0 got out of beta into stable branch.
If you do not update client though (i can't seem to get one yet), then it works even without this pr.


Update Plugin/Widget to use new dynamic page loading feature

From Figma:

We're writing to encourage you to update these plugins and/or widgets on Figma Community: Automotive Design for Compose
Why? We’re in the process of rolling out dynamic page loading, which will shorten load times by up to 25%. By updating your plugin or widget to support dynamic page loading using new APIs, you’ll prevent users from encountering a 1–30 second delay the first time they use a plugin/widget in a newly-opened file.
You can update now. If you’ve got questions or want to chat with other creators about updating your plugin/widget, come join the Friends of Figma Discord.

This is now actually blocking the release of the widget for v0.25.0

That said, I don't think we have any actual code changes to the Widget so I don't think this needs to block release.


Do you have API?

Can I get the data I want by writing a script rather than operating on the website?

We don't have a stable API. You can however inspect the requests your browser makes and recreate them. Authentication is easiest done with basic auth. Be aware that these endpoints can change without notice.


Create a tx_id() std library function

The transaction ID is simply at address zero: https://github.com/FuelLabs/fuel-specs/blob/0d56640183c3fc1eee055ab380f796565955a973/specs/vm/main.md#vm-initialization

@mohammadfawaz It seems like a tx_id() function would just be a wrapper around the preexisting start_stack_ptr() function?

John wrote the on Discord IIRC and looked something like:
asm() {
    zero: b256
}

That's it 😄


Read token from file or string

You should be able to pass a file to --token-file that is read for the token value.

This has been added in v0.2.0-rc3

Verified:
ubuntu@k3s-node2:~$ sudo ./k3s agent --server https://<IP_ADDRESS>:6443 --token-file token.txt
INFO[2019-03-08T06:28:29.341790729Z] Starting k3s agent v0.2.0-rc6 (2771ae1)
INFO[2019-03-08T06:28:29.455829097Z] Logging containerd to /var/lib/rancher/k3s/agent/containerd/containerd.log
...

root@k3s-node1:~# /home/ubuntu/k3s kubectl get nodes
NAME        STATUS   ROLES    AGE    VERSION
k3s-node1   Ready    <none>   111m   v1.13.4-k3s.1
k3s-node2   Ready    <none>   9s     v1.13.4-k3s.1


CMakeLists.txt is missing OPENGL_INCLUDE_DIR.

Describe the bug
I went to build VisIt on Fedora 27 and it doesn't have any OpenGL installed on it. I used mesagl to provide OpenGL. When it went to compile one of the files in avt/VisWindow/Colleagues it failed because it included GL/gl.h, which it couldn't find. My assumption is that every system we have ever built VisIt on had some minimal OpenGL and had GL/gl.h in the system include files. This one did not. Adding OPENGL_INCLUDE_DIR to the include directories.
Impact

[X] Medium - User productivity partially degraded

Likelihood

[X] Medium - neither low nor high likelihood

Desktop

OS and version: Fedora 27
VisIt Version: 3.0.1

Adding OPENGL_INCLUDE_DIR to the bottom of the INCLUDE_DIRECTORIES in avt/VisWindow/CMakeLists.txt, just below VTK_INCLUDE_DIRS fixed the problem. Anyone see a problem with that?

Where is the opengl include dependency coming from for VisWindow?
Kathleen
On Thu, 2019-08-29 at 13:07 -0700, Eric Brugger wrote:

Adding OPENGL_INCLUDE_DIR to the bottom of the INCLUDE_DIRECTORIES in
avt/VisWindow/CMakeLists.txt, just below VTK_INCLUDE_DIRS fixed the
problem. Anyone see a problem with that?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Sorry just wondering why we haven't encountered this before, and trying to prevent dependency creep. If it is truly just a system thing and the dependency has always been there, I think your solution is fine.

Hi Kathleen,
It's coming from VisWinRenderingWithoutWindow.C. Here is the error message:
[ 16%] Building CXX object avt/VisWindow/CMakeFiles/avtviswindow_ser.dir/Colleagues/VisWinRenderingWithoutWindow.C.o
In file included from /home/visit/visit3.0.1/src/avt/VisWindow/Colleagues/VisWinRenderingWithoutWindow.C:54:0:
/home/visit/third-party/vtk/8.1.0/linux-x86_64_gcc-7.3/include/vtk-8.1/vtkOpenGL.h:27:11: fatal error: GL/gl.h: No such file or directory
include <GL/gl.h> // Include OpenGL API.
       ^~~~~~~~~

compilation terminated.
make[2]: *** [avt/VisWindow/CMakeFiles/avtviswindow_ser.dir/build.make:407: avt/VisWindow/CMakeFiles/avtviswindow_ser.dir/Colleagues/VisWinRenderingWithoutWindow.C.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1792: avt/VisWindow/CMakeFiles/avtviswindow_ser.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

Thanks.


Inside ScrollView Doesn't work

Expected behavior
Scroll entire page along with Tab
Actual behavior
Giving ScrollView Doesn't render TabAnimated inside Tab Content
Code sample, screenshots
What have you tried

Hey, I just released a new alpha 2.0.0-alpha.0 of the library. It's rewritten using react-native-gesture-handler and react-native-reanimated addresses a many platform specific bugs and performance problems. The documentation is updated as well.
Please try the new version and see if it addresses your issue. If not, please open a new issue following the issue template.


Enhance ColChooserModel config and expose it via GridModel

This PR addresses https://github.com/xh/hoist-react/issues/2084.

Desktop ColChooserModel supports new config options: commitOnChange, showRestoreDefaults, width, and height, to specify ColChooser implementations in popover and dialog.
ColChooserModel config can be specified via GridModel config: colChooserModel. It also accepts true or false to show or hide default components -- upgraders must replace enableColChooser with this new flag.

Toolbox PR: https://github.com/xh/toolbox/pull/427

Added new 'restoreDefaults' action to default StoreContextMenu, since 'commitOnSave' will remove the 'Reset' button. (Also makes this action more clearly aligned with all grid defaults (not just columns)).

Hoist P/R Checklist
Pull request authors: Review and check off the below. Items that do not apply can also be
checked off to indicate they have been considered. If unclear if a step is relevant, please leave
unchecked and note in comments.

[x] Caught up with develop branch as of last change.
[x] Added CHANGELOG entry, or determined not required.
[x] Reviewed for breaking changes, added breaking-change label + CHANGELOG if so.
[x] Updated doc comments / prop-types, or determined not required.
[x] Reviewed and tested on Mobile, or determined not required.
[x] Created Toolbox branch / PR, or determined not required.

If your change is still a WIP, please use the "Create draft pull request" option in the split
button below to indicate it is not ready yet for a final review.

Pull request reviewers: when merging this P/R, please consider using a squash commit to
collapse multiple intermediate commits into a single commit representing the overall feature
change. This helps keep the commit log clean and easy to scan across releases. PRs containing a
single commit should be rebased when possible.

Petra and I discussed and I had a few ideas for your input when you have a chance, @lbwexler -

There's an issue currently where the dev has no way to configure/set options on the ColChooserModel, at least when it's launched from the default context menu. This PR has a workaround to add a new mode prop to the button, which will then set the mode on the model when the button is rendered, but Petra and I discussed how that's a bit unexpected.

I'm thinking it might be worth supporting an optional GridModel.colChooserModel config, which could be a model instance (rare) or a config/partial config for one. This would allow us to configure any aspect of the chooser API at the model level.
We could still support enableColChooser: true|false for convenience and backwards compat. But a dev could leave enableColChooser unspecified - passing any object to colChooserModel would enable the chooser.

I found the mode concept to be a bit tricky, as modes often are, especially since we are looking at only two cases at the moment (and I couldn't think of any others).

I'm favoring commitOnChange as a boolean - Petra mentioned she had that, so I wanted to discuss before we changed anything to avoid flipping around. To me it's a little bit weird in the context of the col chooser, but not really - and once you think about it, it really seems to fit.
I would then also favor an explicit option such as showRestoreDefaults so apps could set this independently of the commitOnChange/mode. Petra explained the inconsistency with allowing restore of defaults while in batch/save mode, but I think on balance it ends up being more confusing to sometimes see the button and sometimes not - so I would default this to true. (Although I understand that for our new client app project we have other technical reasons for always disabling - hence supporting the flag.)
I would also suggest labelling the button "Restore Defaults" to match (almost) the context menu option. We could take the step of prompting the user if commitOnChange:false (or always) to make it clear that all grid customizations will be immediately reset.

Happy to discuss more - it's a busy day so I agreed with Petra I would write up this comment for discussion when we have a few minutes the three of us.

I agree entirely with your second major item, regarding a single 'commitOnChange'  and the "showRestoreDefaults" flag.

I like the first suggestion as well.  Its analogous to the selection model.  Its also better for it to behave the same way whether it comes up via context menu or button, unlike what we have now!

could deprecate enableColumnChooserModel, and ask upgraders to just set colChooserModel: true instead for the default behavior

Discussed with Petra. - She is doing a bit more testing, and also one more change to make the reset alert easily configuable with a new model property


SubDAG docs and examples

Adds an example and concept documentation for SubDAGs, addressing #1061.

I'd put more emphasis on the idea of repeating patterns using subdags. Maybe the bullet I wrote about it should be a paragraph at the top.
Oh and maybe a screenshot of the "zoom into subdag" button would help understanding how you get there, though it isn't necessary.

@mistercrunch - good points. Thanks. I will add them now, as well as a pretty picture of the zoom in functionality.

@mistercrunch - updated with your suggestions. The tests were a little flakey last night, so hopefully it goes green this time.

@r39132 - updated with both of your suggestions.

@nicktrav Add a few minor comments. Once fixed, ping me on gitter and I will merge it.


feat(bimap): change update method names and reverse parameters for up…

…dateKeyAt method
the update methods were confusing, longer names should clarify this. also changed the order for updateKeyAtValue so that the key is always first
BREAKING CHANGE: changed updateKeyAt to updateKeyAtValue, and updateValueAt to updateValueAtKey, and reversed parameter order for updateKeyAtValue to always have key first
Fixes #101

Codecov Report
Base: 93.49% // Head: 93.49% // No change to project coverage :thumbsup:

Coverage data is based on head (24a6af1) compared to base (f4cd636).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #106   +/-   ##
=======================================
  Coverage   93.49%   93.49%
=======================================
  Files         216      216
  Lines       14047    14047
  Branches     2844     2844
=======================================
  Hits        13133    13133
  Misses        828      828
  Partials       86       86

Impacted Files
Coverage Δ

packages/bimap/src/main/interface.ts
100.00% <ø> (ø)

...kages/bimap/src/custom/implementation/immutable.ts
92.97% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


e2e test for mm-4.9.3

fixed e2e and integration tests

@dennis00010011b please resolve conflict in package-lock.json


Move HVVM to another linux distributive for Travis

First attempt failed with:
$ curl -s -o archive.tar.bz2 $archive_url && tar xjf archive.tar.bz2 --directory /
bzip2: (stdin) is not a bzip2 file.
tar: Child returned status 2
tar: Error is not recoverable: exiting now

Merged. Thank you!


Hermetic Oracle GDS downloads

At the moment, the bindist map of artifacts → hashes can't cover Oracle GraalVM components, because these are served from Oracle's Global Download Service (GDS) which doesn't have predictable artifact URLs.
These are our options:

Talk to their API. We could re-use some of GraalVM's code for this, but the integration would be brittle and probably break when gu is deprecated, which is coming up.

Register all hashes manually. This is a pretty lame outcome, so let's avoid it.

Move components to predictable URLs on our own infra. This is banned by license and still requires maintainer intervention.

Provide a user-facing repository input for artifacts of this nature. We could take an approach similar to how rules_kotlin handles custom kotlinc distributions. This is probably what we should do.

Got some advice from the GraalVM team on this topic:


Add login to companies#show table

Ah!
On Fri, Jul 7, 2017 at 4:03 PM garyfoster<EMAIL_ADDRESS>wrote:

@garyfoster commented on this pull request.
In app/views/companies/show.html.haml
https://github.com/radicalbear/radbear_multi_tenant/pull/48#discussion_r126233725
:

@@ -22,6 +23,7 @@
%td= member.user.email
%td= member.member_status
%td= member.user.status

           %td= format_datetime(member.user.last_sign_in_at)

I think you're looking for current_sign_in_at which is the last one.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/radicalbear/radbear_multi_tenant/pull/48#pullrequestreview-48705024,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG0HklhTDFzt4Xc-V9kb-3qFAeuUXYV2ks5sLo8igaJpZM4OQ-tC
.


Describe, bail and each don't work as written in the doc

🐛 Bug Report
Describe doesn't start a test suite, bail doesn't stop the tests after a fail, each doesn't format names correctly, and jest output is so verbose that it overflows my terminal.
To Reproduce

git clone https://github.com/Sharcoux/GoldMines.git
npm i
npm run test
Try to read the results of the tests

Expected behavior
describe
According to the documentation:

describe(name, fn) creates a block that groups together several related tests in one "test suite".

This should start 2 tests suite:
    describe('test 1',() => {
      test('one space, one mine', () => {
        expect(findBestSpot(1, 1, 1, 1, [{"x":0,"y":0}])).toEqual({"coordinates":{"x":0,"y":0},"goldMines":1});
      });
    });

    describe('test 2',() => {
      test('one space, no mine', () => {
        expect(findBestSpot(1, 1, 1, 1, [])).toEqual({"coordinates":{"x":0,"y":0},"goldMines":0});
      });
    });

Actual result:
=> Test Suites: 1 failed, 1 total
bail
According to the documentation:

The bail config option can be used here to have Jest stop running tests after the first failure.

Running: npx jest -b
Actual result:
=> Tests:       23 failed, 10 passed, 33 total
How could 23 tests fail if jest did stop at first failure?
each
According to the documentation:

Generate unique test titles by positionally injecting parameters with printf formatting:

So this test's name should be 'name', but instead, it's name is '1'...
const A = [[1, 2, 3, "name"]];
test.each(A)('%s', (a,b,c) => expect(a+b).toBe(c));

Actual result:
 PASS  ./index.test.js
  ✓ 1 (5ms)

By the way, "%4$s" doesn't work either....
Link to repl or repo (highly encouraged)
A small repo with a single test file that perfectly illustrate the issue
Run npx envinfo --preset jest
Paste the results here:
  System:
    OS: macOS High Sierra 10.13.6
    CPU: (4) x64 Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz
  Binaries:
    Node: 8.9.2 - ~/.nvm/versions/node/v8.9.2/bin/node
    Yarn: 1.12.1 - ~/.yarn/bin/yarn
    npm: 6.3.0 - ~/.nvm/versions/node/v8.9.2/bin/npm
  npmPackages:
    jest: ^23.6.0 => 23.6.0

A "test suite" in jest's terminology means a test file, not a describe. So the docs are imprecise there, should definitely be improved. In the future we wanna improve that situation, see https://github.com/facebook/jest/issues/6616#issuecomment-403899521.
bail also just stops at the file level, it doesn't abort running more tests within the same file. That could potentially change, I guess. Not sure it adds value, though. Perhaps 🙂
Regarding each... I not sure what's going on there, @mattphillips could you chime in?
Regarding verbosity - we know jest is pretty verbose, and it's probably gonna stay that way. There's a couple of things you can do

use https://github.com/rickhanlonii/jest-silent-reporter which will only print errors, and only do that once
use the watch mode. When using bail it's mostly so you can focus on a few failure, right? You can use both file filtering and test name filtering in watch mode (I recommend to use https://github.com/jest-community/jest-watch-typeahead so you can see what's gonna run before starting the test run). We also have a "failures only" mode which will only rerun test files that had failures in the previous runs. Those combined should make it pretty easy to focus on a single failure at a time without being overwhelmed by lots of output

Thanks for your reply.

A "test suite" in jest's terminology means a test file, not a describe

I'm not sure about the relevance of the describe function in this case... But ok. The doc should really be corrected, though, because it is very confusing.

bail also just stops at the file level, it doesn't abort running more tests within the same file.

Shouldn't this be reflected into the doc?

Regarding verbosity

In my use case, I provide students with a project that have already the tests written for them. In this case, if they run npm run test they will be flooded by test failures and they will only be able to read the last tests, whereas the tests are written with progressive difficulty. So the one they are interested in are probably the first ones.
Fortunately, I finally could work around this by hacking my way through each.

Sorry guys, but I slept on this, and it really bugs me.
When you decide to use an option to stop the tests after the first failure, in what kind of context would it be the expected behavior that it keeps failing all the tests in the current file?
Moreover, you are telling me that with jest, if I want to create 20 tests and I want the tests to stop at the first failure, my only choice is to create 20 test files?!

Hey @Sharcoux sorry for the confusion - I think we would be interested in making bail work at a test-level but I think the way it works today is accurate to the documentation (though it could be clearer)
Do you want to submit a feature proposal to update bail to stop at the first failing test instead of the first failing test suite/test file?

You might find me narrow-minded, but I don't think that

The bail config option can be used here to have Jest stop running tests after the first failure.

that I can read there, would normally be interpreted by:

If the bail config option is set, Jest will stop the tests if at least one test failed in the current file.

Actually, I think that most people would understand: Jest will stop running tests after the first failure 😜
I'll check if I'm able to provide a PR about this if you are willing to change the way bail is working.

@cpojer what do you think about --bail stopping at the first test instead of the first test file?
@Sharcoux if the docs aren't clear about this then I'm happy to merge a clarification 👌

I'm fine with that. I can see advantages of both but showing just one error may be less confusing for people.

Yeah I agree
@Sharcoux if you want to take a stab go ahead!

Pull Request to resolve issue in documentation regarding the describe() method: https://github.com/facebook/jest/pull/7452

Just got bitten by this as well. I'd say that the current description of bail is even more misleading:

Alias: -b. Exit the test suite immediately upon n number of failing test suite. Defaults to 1.

Bail currently keeps running the remaining tests in a file even when the first one fails i.e. it does not appear to "exit the suite immediately".
Or does it mean that it should exit jest immediately after a single test suite fails? Either way the language and grammar are rather confusing.

Bail doesn't exit the test suite and is meaningless. This is a bug.
Bail should stop testing immediately upon n number of failing and n defaults to 1.
Please make sure everyone understands, because you won't understand that this is a bug until you understand this statement: It does not stop immediately upon n (where n=1 as default) fails.
Given you understand this, it is a bug and not a "feature"

@SimenB , what, still no assignee? How many people or likes would it take to finally do anything about this bug? There are two ways: update the docs, reveal the sour truth about "the great misleading of bail", or, to change its behavior to match the docs. The latter is preferable. Who do I need to CC in order to incite the action?

@dartandrevinsky Please cc yourself and send a PR with a fix. It's an open source project and you're very welcome to help fixing issues you have with it :)

With all due respect (and do mean respect), Michal, the 'collaborator' badge that you and several other people sport here, suggests you are more capable to address this issue (with no need of assuming the offensive). I apologize if I sounded rude, sorry - I wanted to draw attention to this issue.
Apparently it is an issue - it was reported a year ago - there was an argument, yet the OP's reasons seem to outweigh the responses.  There is no working bail, no way to abruptly stop the tests - if it's the part of the bigger design, maybe it should be shared? Or fixed accordingly?

Sorry guys, but I slept on this, and it really bugs me.
When you decide to use an option to stop the tests after the first failure, in what kind of context would it be the expected behavior that it keeps failing all the tests in the current file?
Moreover, you are telling me that with jest, if I want to create 20 tests and I want the tests to stop at the first failure, my only choice is to create 20 test files?!

I still wonder if I have to write different test files for bail to work?
I am using describe.each for using the same test for different implementations of a class.
But still bail option doesn't work after a failure so i have to wait until every one of them finalizes.
Do i need to duplicate same test test to make it work parallel and work with the bail option?
What is the purpose if .each then?
Do you have any plans to

group together several related tests in one "test suite".

using something like describe

Sorry guys, but I slept on this, and it really bugs me.
When you decide to use an option to stop the tests after the first failure, in what kind of context would it be the expected behavior that it keeps failing all the tests in the current file?
Moreover, you are telling me that with jest, if I want to create 20 tests and I want the tests to stop at the first failure, my only choice is to create 20 test files?!

I still wonder if I have to write different test files for bail to work?
I am using describe.each for using the same test for different implementations of a class.
But still bail option doesn't work after a failure so i have to wait until every one of them finalizes.
Do i need to duplicate same test test to make it work parallel and work with the bail option?
What is the purpose if .each then?
Do you have any plans to

group together several related tests in one "test suite".

using something like describe

Opened 2 years ago and still no progress..Well, I have a similar question. How can I force the "describe" test to be counted as a suite? I don't care now if you have a bug or misunderstanding in ocumentation, I just want to tell the Jest what to consider as a test suite, cause now I have 1 test file and several "describe" tests inside and I want each of this "describe" tests to be considered as a Suite, not the file entirely. I need this to see the success/fail rate through the "describe" tests.

Opened 2 years ago and still no progress..Well, I have a similar question. How can I force the "describe" test to be counted as a suite? I don't care now if you have a bug or misunderstanding in ocumentation, I just want to tell the Jest what to consider as a test suite, cause now I have 1 test file and several "describe" tests inside and I want each of this "describe" tests to be considered as a Suite, not the file entirely. I need this to see the success/fail rate through the "describe" tests.

That is the thing, you can't.
In the end I had to separate the describe blocks into different files.

Opened 2 years ago and still no progress..Well, I have a similar question. How can I force the "describe" test to be counted as a suite? I don't care now if you have a bug or misunderstanding in ocumentation, I just want to tell the Jest what to consider as a test suite, cause now I have 1 test file and several "describe" tests inside and I want each of this "describe" tests to be considered as a Suite, not the file entirely. I need this to see the success/fail rate through the "describe" tests.

That is the thing, you can't.
In the end I had to separate the describe blocks into different files.

That's sad( I can't seperate my describe block because they are generated inside one file(((

I'm trying to adopt Jest for a project I'm working on and I got here because it appears "bail" still doesn't halt after a test fails. Is this just a super low priority or what? To me this is a big shortcoming for a test runner to have. I'm surprised this hasn't been fixed. Was there any progress towards a fix or a design to implement this? I'd be happy to help work on a PR if anyone else has an idea where to start.

Every other test system I've used means I can add --bail and then the output of the failed test is the most recent thing in scroll.
Not jest.
Please, please, please, fix this?

To run our large E2E solution that needs to run in order, we needed to have this feature.
As a workaround for that, we decided to split tests into different tests files.
Then use the testSequencer to play tests in order.
We replaced:
beforeAll by globalSetup
afterAll by globalTearDown
Hope this will helps folks coming here.

Not stale. Waiting for fix.

Still waiting for a fix


repeating announcement video

When I load the player, when I skip the ad and make a new request it always returns the same ad to me.

Hello @lzhudson
I think this is likely an issue with you ad-tag setup in Ad Manager. Are you able to see loading the ad-tag in the Video Suite Inspector result in different ads? If the ads are the same there, I would recommend reaching out to your Ad Manager agent to help resolve the issue.

Hello @Kiro705
I tested the tag here though, now it is returning me error 1009.
Follow the test link: https://www.mtorrespack.com.br/video-ads/

@Kiro705 Now he is repeating the same mistake. Always display the same ad even changing the tag and making the request.

Hello @lzhudson ,
Thank you for sharing the test page. I think the issue for you is with the ad tag and not the implementation. I tired using IMA's sample skippable pre-roll, then on the SKIPPED event, I called the following code to switch the ad to a IMA's sample post-roll and that played successfully at the end of the video.
player.ima.changeAdTag(postRollAdTag);
player.ima.requestAds();

I think the current issue is the 1009 error which will have to be solved on the ad manager side.
In addition, the IMA team does not recommend requesting new ads for the same content video on the SKIPPED event. This can be seen as spammy behavior if multiple ad requests are made in quick succession.


Web front-end progress/ code

I saw your comment on reddit saying that the web front-end is in the works. Can you tell us how's the progress? If there are some codes, can you push the incomplete code to GitHub in a different branch (so anyone can help)? If not, I can try to port other UI e.g. poolui?

The web-frontend is not yet ready to be checked in for public consumption. Giving porting poolui a shot would be actually great idea since it's quite popular and would ease the transition for operators who have already experience with that frontend.

Is there any update on the web-frontend?
The frontend on https://poolmining.org/ looks nice it this the one that will be used for this pool software?

I am working on it. Check https://github.com/calvintam236/miningcore-ui/issues/2 for updates.

@oliverw if you add the header globally, all of the API methods can be called externally. you said don't open API to internet, so how you want us to use it?
to protect some API methods, add basic auth/IP whitelist?

@calvintam236 I added the headers so your web-frontend may call the API even if hosted on a totally different domain/host than the pool server. This is the only recommended use-case for the Pool's API interface. If you really need to expose the API from your web-frontend it should be done by just proxying a subset through your web-layer. poolmining.org does something like that for the Monero Pool: https://poolmining.org/api/cryptonote-pool/xmr/stats

In case it is helpful to someone, I've done the following with nginx which allows me to secure the api with it's own hostname using SSL. Example shows I was adding the CORS header to work around the issue. Any number of other auth methods could be applied using this same approach so that @oliverw is not wasting his time recreating the wheel. :-)
server {
        listen 80;
        server_name api.example.com;

        location / {
            rewrite ^(.*)$  https://$host/$1 permanent;
        }
    }

    server {
        listen 443 ssl http2;
        server_name api.example.com;

        ssl_certificate /path/to/cert.pem;
        ssl_certificate_key /path/to/key.pem;
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout  10m;
        ssl_ciphers HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers on;

        location / {
            proxy_pass http://localhost:4000/api/;
            add_header Access-Control-Allow-Origin *;
        }
}

@oliverw API auth reference: http://blog.restcase.com/restful-api-authentication-basics/
i would suggest to use same username/password on the server to simplify user control.
alternatively, split public access and security critical APIs on two ports, which we only need to open the public port?

Solid frontend, thanks

I have made myself a simple frontend for my site
http://eth.coinstomine.eu
http://xmr.coinstomine.eu
https://github.com/minernl/miningcore/tree/MiningCore.Web/src/MiningCore.Web
Needs some improvements but it runs nice for now

@minernl can you please write some steps how to get it working?
I have downloaded the folder MiningCore.Web, moved it to /var/www folder, running apach2 server, but webpage is not getting info from the pool, even it looks not so nice like yours, there is no collors etc..
Running ubuntu 16.04
I would really approciate some steps, to get it fully working, dependencies and so on..
Thanks a lot

Is anyone "officially" working on front-end development?
I've started a GoFundMe to speed along development for anyone interested. I've seen a lot of people asking for a front-end, let's get it done!
https://www.gofundme.com/miningcore-frontend-ui-development
I'm currently working with a front-end dev to make a simple front-end for my own personal needs, but I'd love to build on top of that and get a stunning, feature-rich web front-end banged out to the caliber that it can be added to the MiningCore repo for everyone to use.

Closing as this is not really an issue with the project itself.

my new webUI is at
https://github.com/minernl/Miningcore.WebUI


What sqllite engine version is supported?

I tried to use this statement
"INSERT INTO words values (?, ?)
on conflict(word) do update set
instances = instances + ?"
This works fine on sqlite 2.29, and should work since 2.24. However, I get this error
/var/lib/gems/2.3.0/gems/sqlite3-1.4.1/lib/sqlite3/database.rb:147:in `initialize': near "on": syntax error (SQLite3::SQLException)
Is this not supported?
using gem  sqlite3 1.4.1 and I have sqlite 2.29 installed at /usr/local/bin/sqlite3

Hi, @Ronserruya
By default sqlite3 compiles with 3.22.0
 irb -rsqlite3
>> SQLite3::SQLITE_VERSION
=> "3.22.0"
>> SQLite3::VERSION
=> "1.4.1"

To get newer version you need to pass additional include parameters when compiling native extension

Thanks, but I still get the error
irb(main):001:0> SQLite3::SQLITE_VERSION
=> "3.29.0"
irb(main):002:0> db = SQLite3::Database.new "test.db"
=> #<SQLite3::Database:0x000000025cb000 @tracefunc=nil, @authorizer=nil, @encoding=nil, @busy_handler=nil, @collations={}, @functions={}, @results_as_hash=nil, @type_translation=nil, @type_translator=#<Proc:0x000000025eb3a0@/var/lib/gems/2.3.0/gems/sqlite3-1.4.1/lib/sqlite3/database.rb:722 (lambda)>, @readonly=false>
irb(main):003:0> db.execute("insert into words values ('ron', 2) on conflict(word) do update set instances = instances + 1")
SQLite3::SQLException: near "on": syntax error
	from /var/lib/gems/2.3.0/gems/sqlite3-1.4.1/lib/sqlite3/database.rb:147:in `initialize'
	from /var/lib/gems/2.3.0/gems/sqlite3-1.4.1/lib/sqlite3/database.rb:147:in `new'
	from /var/lib/gems/2.3.0/gems/sqlite3-1.4.1/lib/sqlite3/database.rb:147:in `prepare'
	from /var/lib/gems/2.3.0/gems/sqlite3-1.4.1/lib/sqlite3/database.rb:193:in `execute'
	from (irb):3
	from /usr/bin/irb:11:in `<main>'
irb(main):004:0>

Apologies to hijack - but I have a similar issue.
I have rspec tests which pass locally, but they fail on the CI build.  Since we are using the same ruby version and the same sqlite3 gem version, I was at a loss as to what the issue could be.
I noticed when adding the following code to my tests:
sql_version= ActiveRecord::Base.connection.execute("select sqlite_version();")
      puts "SQL version is " + sql_version.first.to_s

The sql version on my local machine was: {"sqlite_version()"=>"3.29.0", 0=>"3.29.0"}
But on the CI server the same code reveals:  {"sqlite_version()"=>"3.7.17", 0=>"3.7.17"}
Could this be the cause if my failing specs?
SQLite3::SQLException: near "WITH": syntax error: ;WITH included_items as (
My next step is to try an replicate this locally, but how can I force the sqlite3 gem to use an older version of sqlite3?


Making panel on top of all windows except fullscreen

Resubmitted from baskerville/bspwm#484.
I'm currently using the following code inside my panel, which is the same as found in bspwm/examples/panel/panel.
panel_bar < "$PANEL_FIFO" | lemonbar -n "$PANEL_WM_NAME" -g x$PANEL_HEIGHT -f "$PANEL_FONT_FAMILY" -F "$(bar_color_fg COLOR_BAR)" -B "$(bar_color_bg COLOR_BAR)" | while read line; do
	eval "$line"
done

wid=$(xdo id -a "$PANEL_WM_NAME")
tries_left=20
while [ -z "$wid" -a "$tries_left" -gt 0 ] ; do
	sleep 0.05
	wid=$(xdo id -a "$PANEL_WM_NAME")
	tries_left=$((tries_left - 1))
done
[ -n "$wid" ] && xdo above -t "$(xdo id -N Bspwm -n root | sort | head -n 1)" "$wid"

However, I'm finding that other applications, when fullscreened, remain underneath the panel:

I have found a workaround that lowers the panel once, to just below a fullscreen screen:
if [ -n "$wid" ]; then
	xdo above -t "$(xdo id -N Bspwm -n root | sort | head -n 1)" "$wid"
	xdo lower "$wid"
fi

However, this issue does not work when using multiple monitors; on the second monitor, the rule is not applied:

Could this be a bug in xdo, or is it more likely me doing something wrong?

Sorry, I should have been more explicit: this can't be an xdo bug.


Fix lang server tests failures due to new transaction implementation

Following tests are disabled, as they fail due to the new transaction implementation syntax changes. These are disabled in the org.ballerinalang.langserver.completion.definitions.FunctionDefinitionCompletionTest class
{"completionWithinWorkersInResource.json", "function"},
{"completionBeforeIfElse.json", "function"},
{"completionWithinIf.json", "function"},
{"completionWithinElse.json", "function"},
{"completionWithinElseIf.json", "function"},
{"completionBeforeWhile.json", "function"},
{"completionWithinWhile.json", "function"},
{"completionWithinTransaction.json", "function"},
{"completionWithinTransactionOnRetry.json", "function"},
{"completionWithinTransactionAborted.json", "function"},
{"completionWithinTransactionCommited.json", "function"},

Changes have been incorporated in the master branch, hence closing the issue.


views: addition of weak ETags check

Adds support for checking weak ETags. (closes #39)

Coverage decreased (-0.5%) to 99.512% when pulling eb1b7bca457b7e3b2eeb291b7cc6bc89eeb3ea6e on slint:weak_etags into 6f08ee8949745ca90dfc6637e09a3ac1e76c63c3 on inveniosoftware:master.


mbpfan: include buffer overflow patch

Motivation for this change
mbpfan crashes due to a buffer overflow now that the new hardening measures are in place.
This change includes an upstream patch to fix it (vs disabling fortify).
Things done

[ ] Tested using sandboxing
(nix.useChroot on NixOS,
or option build-use-chroot in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Works for me, thanks.


Hugepages support doesn't appear to work correctly

On OpenShift 4.6 I'm hitting an issue when hugepages is enabled (due to 3rd party SDN requirements) where I see "Bus" errors like:

and the postgres pod fails to start. When I apply the fix outlined here:
https://github.com/bitnami/charts/issues/7901
namely to set huge_pages = off in postgresql.conf.example using configmap applied to the Deployment then the pod starts.

I'm unsure if the issue is with OCP not correctly reporting hugepages as my understanding is that the huge_pages = try default should fallback correctly.
However it would be nice to have a way to pass a custom file to the postgres pod in a similar manner as with the config.yaml for Quay itself.

As we already have a JIRA card and a BZ for this very same issue I am closing it here.


chore(Tactic/GeneraliseProofs): reduce Inhabited to Nonempty

This seems to work, but I am not sure if this change is fully fine, or there are side effects I don't know about.

Found by the linter in #10235.

Nonempty is a strictly weaker assumption than Inhabited (i.e. there is instNonemptyOfInhabited), so I think this generalisation is desired and should have no side effects.
maintainer merge

bors merge

There are no side effects to this change, so it's fine. I think it's also sort of a useless change since this is all meta code, and partial as well, so we're not improving the reasoning capabilities.
The linter should be sure to not flag partial functions, I think. Maybe even it should avoid anything that looks like it could be a meta definition.


Add project files

Fixes #113.

@hugovk thanks!

Pull Request Test Coverage Report for Build 803

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

Totals

Change from base Build 801:
0.02%

Covered Lines:
3914

Relevant Lines:
4811

💛  - Coveralls

Pull Request Test Coverage Report for Build 803

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

Totals

Change from base Build 801:
0.02%

Covered Lines:
3914

Relevant Lines:
4811

💛  - Coveralls


Bugfix: the base criterion converter can interpret lists of values for IN

What this PR changes/adds
The BaseCriterionConverter now tries to interpret the right-hand value of an IN expression as list, and throws an exception otherwise.
Why it does that
To ensure consistent behaviour with CosmosDB- and SQL implementations.
Checklist

[x] added appropriate tests?
[x] performed checkstyle check locally?
[x] added/updated copyright headers?
[x] documented public classes/methods?
[x] added/updated relevant documentation?
[ ] added relevant details to the changelog? (skip with label no-changelog)
[x] formatted title correctly? (take a look at the CONTRIBUTING and styleguide for details)

Codecov Report

Merging #1284 (bed8f0a) into main (508b591) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1284   +/-   ##
=======================================
  Coverage   67.35%   67.36%
=======================================
  Files         715      715
  Lines       15735    15743    +8
  Branches     1043     1044    +1
=======================================
+ Hits        10599    10605    +6
- Misses       4652     4654    +2
  Partials      484      484

Impacted Files
Coverage Δ

...r/spi/query/BaseCriterionToPredicateConverter.java
100.00% <100.00%> (ø)

...e/dataspaceconnector/catalog/cache/LoaderImpl.java
23.07% <0.00%> (-4.20%)
:arrow_down:

...tor/catalog/store/InMemoryFederatedCacheStore.java
100.00% <0.00%> (ø)

.../catalog/cache/FederatedCatalogCacheExtension.java
80.32% <0.00%> (ø)

...nector/catalog/cache/loader/LoaderManagerImpl.java
89.65% <0.00%> (+0.18%)
:arrow_up:

Continue to review full report at Codecov.

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


RPI3 compile errors on MMAL_CLOCK_UPDATE_THRESHOLD_T

When compiling using openFrameworks v0.9.3 or v0.9.6 we keep getting this error: /opt/vc/include/interface/mmal/mmal_parameters_clock.h:61:4: error: unknown type name ‘MMAL_CLOCK_UPDATE_THRESHOLD_T’
(Full error: http://pastebin.com/hhTdNuAf).
We followed the "guides" in readme but we keep getting this error when compiling Footfall in myApps/Footfall.

The issue seems to be in the ofxCvPiCam addon.
Discussion and solution here: https://github.com/orgicus/ofxCvPiCam/issues/3
(basically: remove ~/openframeworks/addons/ofxCvPiCam/libs)


bump k8s to 0.27.4 and golang to 1.20

This PR resolved the conflicts of https://github.com/open-cluster-management-io/managed-serviceaccount/pull/66, and fixed the unit tests based on https://github.com/kubernetes-sigs/controller-runtime/pull/2259
@clyang82, please help review

cc @elgnay  @qiujian16

/approve

/lgtm

/lgtm


Implement mapping of Protobuf maps

Only maps of primitive types are supported.  It's currently impossible to map maps of complex types that require Dozer mapping.

@jbq - can you fix:
proto/src/main/java/org/dozer/propertydescriptor/ProtoFieldPropertyDescriptor.java:31: error: Wrong order for 'java.lang.reflect.InvocationTargetException' import.
Happy to merge once thats done.

@garethahealy fixed, enjoy maps support.


add command to replace double quoted instances of className

Hi there, thanks for this excellent extension.
I find myself pasting lots of HTML from the web (including TailwindUI, HeadlessUI, etc.) where React className is specified as a double quoted string. I want a VSCode command that replaces those strings with their tw wrapped content. This PR adds that function.

@sastan hey there 👋 do you think this has a chance of being merged? i'd love to get back to running the distributed copy of the extension (running in dev mode is a pain)

Thank you. Sorry for the delay. The new version is published as v0.2.0.


Task: Update readme with new emoji's that have been added.

Some emoji's were fixed and some were added. Update the readme with the ones that were added from #44

@VagishVela it looks like the readme was updated as part of that PR already https://github.com/Neo11/ChitChat/pull/44/files -- Am I missing something?

@donofriov Whoops my bad.


Filtered workspaces sometimes show on wrong display

Steps to replicate currently unknown.

Closing as I suspect the refactor sorted this


tools: Add filelife tools to track the lifecycle of a file

Usage:
  $ sudo ./filelife.bt
  Attaching 6 probes...
  Tracing the lifespan of short-lived files, Hit Ctrl-C to end
  TIME     PID      COMM             AGE(us)        FILE
  20:01:26 109927   rm               507814         a.txt
  20:01:28 109934   rm               507448         a.txt
  ^C

Test command line:
  $ touch a.txt && sleep 0.5 && rm a.txt
  ...

From 2019: https://github.com/brendangregg/bpf-perf-tools-book/blob/master/originals/Ch08_FileSystems/filelife.bt
A) This version is a bit different: Kernel changes?
I did not put it (and dozens of other examples I created) in the bpftrace repo since the plan was maintain bcc libbpf/CO-RE/BTF tools as the eBPF-observability-toolkit, and not duplicate maintenance effort by shipping similar versions in bpftrace, leaving bpftrace with a smaller set as examples. I know, I know, it's such a short thing, how hard could maintenance be? see (A). :-)
I think an argument could be made that bpftrace/CO-RE/BTF/no-libllvm with 100 text tools will be a smaller install than the equivalent libbpf/CO-RE/BTF versions, with the added advantage of being customizable on the fly. In which case, we're doing it wrong by pouring effort into libbpf, and we should abandon the libbpf versions and back bpftrace. I'm interested to hear what the Facebook folk think. We should have this argument once bpftrace is buildable without llvm, and you can drop a small static bpftrace binary on an Android phone and it just works.

Thanks, Gregg, actually, i start two PR in bcc to fix filelife with CO-RE way, https://github.com/iovisor/bcc/pull/4339, https://github.com/iovisor/bcc/pull/4340.

So the conclustion is that we close this?

I'd like to merge this PR, which is a good change https://github.com/brendangregg/bpf-perf-tools-book/blob/master/originals/Ch08_FileSystems/filelife.bt, but it's up to you and Gregg to merge or not. :)

Thanks @brendangregg @viktormalik , I just close this PR. Just like Gregg said

I did not put it (and dozens of other examples I created) in the bpftrace repo since the plan was maintain bcc libbpf/CO-RE/BTF tools as the eBPF-observability-toolkit.

Thanks again.


NIFI-13146 ConsumeSlack rate limit error mitigation

Summary
NIFI-13146
ConsumeSlack processor got stuck in initialization phase and reported rate limit error continuously when it was running in a Slack workplace with thousands of channels.
As a mitigation for the problem I added a logic which checks if "Channels" property contains only IDs. In case no channel name is specified, another Slack API call (conversations.info) is used to fetch the channel names for the channel IDs and no need to fetch the whole conversation list.
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[x] Apache NiFi Jira issue created

Pull Request Tracking

[x] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[x] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[x] Pull Request based on current revision of the main branch
[x] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[ ] Build completed using mvn clean install -P contrib-check

[x ] JDK 21

UI Contributions

[ ] NiFi is modernizing its UI. Any contributions that update the current UI also need to be implemented in the new UI.

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

@markap14 If you have free cycles, can you please check this PR? You created the original implementation, do you think this modification makes sense? Thanks.

Thanks @krisztina-zsihovszki the changes seems reasonable. Contrib-check looks good, and I was able to verify behavior using both ID's and channel names. +1 will merge.


Update README

The README doesn't include Send Transactions as a completed feature.  This is incorrect, IIUC Send Transactions has been implemented.

I see that Send transaction is included in the README now so closing this issue


Expression paged list Unit Test

Thanks to @antmdvs
Some scenarios need to add:
given totalCount > pageSize when page = 0 then should return pageSize elements
given totalCount > pageSize when page = 1 then should return results for page 1
other boundary conditions
a. totalCount = 0
a. page < 0
b. last page
c. page > # pages

From https://github.com/ardalis/RegExLib.com/pull/25#discussion_r448112694


[feature] is it possible to add autoPingTime work with idleTimeout?

Is it possible to add autoPingTime work with idleTimeout in WebSocketBehavior config ?
like this:
/** Maximum amount of seconds that may pass without sending or getting a message. Connection is closed if this timeout passes. Resolution (granularity) for timeouts are typically 4 seconds, rounded to closest.
     * Disable by leaving 0.
     */
idleTimeout: 250,
/** auto send ping to remote client interval time (seconds)
     * the response pong will auto refresh idleTimeout, make sure remote client is alive
     * Disable by leaving 0.
     */
autoPingTime: 120,

This can make sure remote client is alive especially in mobile network.
Right now i'm recording all websocket, loop sending ping and handle pong at nodejs APP layer. If this feature can be add to uWebSockets core layer, maybe the performance will be better and APP layer will be easier.

Why are you not having the Client send the ping message? You want the server to do as little work as possible

@hst-m
1, It's a big topic about APP background alive on Android and iOS. At some scenario, only the server sending ping can keep the APP socket alive.
2, if the client are not write by us, other partner's websocket client may not send ping.
3, html websocket client not provide send ping method directly.
https://developer.mozilla.org/docs/Web/API/WebSocket

Docs for idleTimeout  says it works like this: "Maximum amount of seconds that may pass without sending or getting a message" so sending any message/ping resets the idleTimeout even if you don't receive a response, so what you are trying to do won't work (I just tested this with ping)

I tried this on my Android Chrome, the client continues to send ping messages when in different tab, or when in different app, the only time it stops is when you lock the phone. Even if there are other cases like iOS (don't have on me to try) when it stops sending ping, seems ok to just re-open connection when app resumes
tell them to send ping message if they want to keep connection open, otherwise they can just re-open connection when it closes
I just posted in other issue https://github.com/uNetworking/uWebSockets.js/issues/394 to just send empty message from client, the server doesn't even need to respond to it (better performance?)

@hst-m did you mean the pong will not reset idleTimeout ?

You can send a Ping from the server and it will reset the idleTimeout, it does not need to receive a Pong back to reset idleTimeout

oh, sending will also reset the idleTimeout. I used to treat it only refresh when receive any data.
So if the client not respond pong, the idleTimeout will still be refreshed? Then i can't use idleTimeout to check whether client is alive.
Maybe i need aliveTimeout with autoPingTime, stand for client alive, client -> server data make socket connection alive.
So I should keep my server APP layer sending ping and handle pong, not depend on idleTimeout.

You can still keep idleTimeout, I see that if you send a Ping and there is no response the server closes the connection in 20 seconds with 1006 Abnormal Closure where as idleTimeout violation closes the connection with 1006 Abnormal Closure WebSocket timed out from inactivity after the timeout time. So just keep that in mind, its 20 seconds and a different close message if you send a Ping with no response

You can still keep idleTimeout, I see that if you send a Ping and there is no response the server closes the connection in 20 seconds with 1006 Abnormal Closure where as idleTimeout violation closes the connection with 1006 Abnormal Closure WebSocket timed out from inactivity after the timeout time. So just keep that in mind, its 20 seconds and a different close message if you send a Ping with no response

It looks good when no response close.
So what the bad side about adding autoPingTime ? It can be disabled by default 0. But in my case, APP layer no need do anything to trace ping and pong. The idleTimeout + autoPingTime can make sure the client is  really alive no matter what network scenario. I guess lots of user need this feature.

The idleTimeout + autoPingTime can make sure the client is really alive no matter what network scenario.

idleTimeout already does this. You can't send on a broken connection. The kernel has a retransmission timeout that will cause the app to see the connection as broken unless it gets a TCP ack for the send in time. The default of this timeout is maybe a little off, but not that much.
Timeout is definitely not something you should do in scripted business logic. This is and should be part of the library. It can be tweaked, sure, but it works as is.

@roytan883 No, people should be sending ping from the client so the client is doing the work. Then you don't need to be "tracing" Ping and Pong on the server like you said. See issue for example sending Ping from client https://github.com/uNetworking/uWebSockets.js/issues/394

@roytan883 No, people should be sending "ping" keep-alive from the client with idleTimeout on the server. Then you don't need to be "tracing" Ping and Pong on the server like you said. See issue for example sending "ping" keep-alive from client #394

Ok, I see the problem why you insist on client sending ping. I can explain more about problem 1.
In China, all Android device can not use Google GMS, So we must develop our own push service. The big problem is about APP alive. It stand for two side: app process alive, app socket alive.
About app socket alive, we have different android phone and different android system version, test on China three big mobile companies: China Mobile, China Telecom  and China Unicom. The real test result is different, use different mobile company's phone card, the tcp socket alive time is different, and in some case, need both side ping pong to keep socket alive( for example: on some phone card if 6 minutes no data from server to client, although the connect looks good, no callback for socket close or error, but when client use it sending data, the socket return error immediately). As i said, mobile tcp socket is not stable as normal tcp socket, there are many edge case and different scenario which related to phone, phone system, network router, network carrier company.

Have you looked into this for Push notifications, and you are sure this does not work for you? https://developers.google.com/web/fundamentals/push-notifications

idleTimeout already does this. You can't send on a broken connection. The kernel has a retransmission timeout that will cause the app to see the connection as broken unless it gets a TCP ack for the send in time. The default of this timeout is maybe a little off, but not that much.
Timeout is definitely not something you should do in scripted business logic. This is and should be part of the library. It can be tweaked, sure, but it works as is.

@alexhultman  If idleTimeout is 10 minutes, no sending data to client and not receive any data from client, how can we make sure the client is really alive? especially for mobile device client.
As i understand, the kernel SO_KEEPALIVE default  is disabled, and tcp_keepalive_time is 7200 seconds (2 hours).

Have you looked into Web Push Notifications, and you are sure this does not work for you? https://developers.google.com/web/fundamentals/push-notifications

As i said, in China. Most of Google service is forbidden, both politics and technical. It is LAW we must follow.  Even the link you provide can't not open in China.

I have no idea what is going on China but if you need to send some Pings from the server to the client go ahead and do it, but don't expect to add an autoping feature that no one else needs

I have no idea what is going on in China but if you need to send some Pings from the server to the client go ahead and do it, but don't expect to add an autoping feature that no one else needs

Its not about in China or not. Technically, its about tcp socket NAT on mobile base station. Each mobile base station keep NAT hole time for tcp socket is different on different mobile company. some is 6 minutes, some is 28 minutes. So each APP must do heartbeat to keep socket alive. There are some example: WhatsApp 4m45s, Line 7m.

If you want to use native feature, just do ws.subscribe('all') in the open handler and then do app.publish('all','ping') to send a ping message to every client. This should be faster than looping through websockets in JS

If you want to use native feature, just do ws.subscribe('all') in the open handler and then do app.publish('all','ping') to send a ping message to every client. This should be faster than looping through websockets in JS. The close event should trigger if there is problem with connection

Its a good idea, i think it will have better performance than my current solution.
Also, there is a topic about Carrier Grade NAT Timeout. At France mobile network, how to config its XMPP server to send keepalive(ping). Its NAT time is like China mobile company, around 5 minutes. That's why I take example for 4~5 minutes autoPing. His solution is change kernel tcp_keepalive_time, my suggestion is add this feature autoPingTime in uWebSockets core.
https://blog.wirelessmoves.com/2020/09/carrier-grade-nat-timeouts-and-how-to-configure-your-xmpp-server.html

If idleTimeout is 10 minutes, no sending data to client and not receive any data from client, how can we make sure the client is really alive? especially for mobile device client.

You can't. That's why you send pings. Even if you have 10 minutes idleTimeout (which is really high) you still have to make sure to send pings every, say 1 minute. Either you do this from the client side (which you do not seem to want) or you do this from the server (which is more demanding for the server).
Most users, I would guess, have idleTimeout of about 1 minute and send pings from clients with maybe 30 second interval. That works over whatever Chinese or Russian phone or sputnik. It doesn't matter if you live in China or not, you still play by TCP rules.
I don't have any immediate plan to change any of this, but I might tweak things and (maybe) add this autoPingInterval, but not because it is needed, but rather because in some cases the client (application) protocol is so stupidly designed that it cannot handle client-side pings.

As i understand, the kernel SO_KEEPALIVE default is disabled, and tcp_keepalive_time is 7200 seconds (2 hours).

If you are using Nginx as reverse proxy, you can try to configure TCP

so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]
this parameter configures the “TCP keepalive” behavior for the listening socket. If this parameter is omitted then the operating system’s settings will be in effect for the socket. If it is set to the value “on”, the SO_KEEPALIVE option is turned on for the socket. If it is set to the value “off”, the SO_KEEPALIVE option is turned off for the socket. Some operating systems support setting of TCP keepalive parameters on a per-socket basis using the TCP_KEEPIDLE, TCP_KEEPINTVL, and TCP_KEEPCNT socket options. On such systems (currently, Linux 2.4+, NetBSD 5+, and FreeBSD 9.0-STABLE), they can be configured using the keepidle, keepintvl, and keepcnt parameters. One or two parameters may be omitted, in which case the system default setting for the corresponding socket option will be in effect. For example,
so_keepalive=30m::10
will set the idle timeout (TCP_KEEPIDLE) to 30 minutes, leave the probe interval (TCP_KEEPINTVL) at its system default, and set the probes count (TCP_KEEPCNT) to 10 probes.

http://nginx.org/en/docs/stream/ngx_stream_core_module.html#tcp_nodelay

@alexhultman
At beginning we do send ping from client to server.
But after more real test and more search, we find at mobile network, only client->server ping can't not cover all case. That's why i'm talking about server->client ping. Different mobile company, 3G, 4G, 5G, NAT timeout, tcp socket is not stable as we expect.
Thanks for consider adding autoPingInterval to uWebSockets core.

If you want to use native feature, just do ws.subscribe('all') in the open handler and then do app.publish('all','ping') to send a ping message to every client. This should be faster than looping through websockets in JS. The close event should trigger if there is problem with connection after 20 seconds (or sooner if the client officially closes the connection)

Smart. That's a quite simple solution really. Just do a setInterval in JS and make it publish to some topic that all clients are subscribed to.

The only problem is it sounds like he is not controlling the client code so it will show up on the client as a websocket message where a real Ping is not a websocket message, but is up to him. Maybe better performance for server to not receive bunch of Pong messages but I don't know

Another case client->server not work is Android APP background scenario. Android APP have some kind of sleep rule when at background, light sleep and deep sleep. When light sleep, APP can wake up itself and send ping to server. But in deep sleep, the APP process can not even wake up itself process. At this time, if a server->client ping is received from cell mobile down layer, system will wake up the APP process handle it.

Another case client->server not work is Android APP background scenario. Android APP have some kind of sleep rule when at background, light sleep and deep sleep. When light sleep, APP can wake up itself and send ping to server. But in deep sleep, the APP process can not even wake up itself process. At this time, if a server->client ping is received from cell mobile down layer, system will wake up the APP process handle it.

This makes sense (I don't know for sure, but I can buy it), but do you really want a WebSocket to be kept alive during deep sleep? Isn't it better to just reconnect? So to not hog resources on the server?

If you want to use native feature, just do ws.subscribe('all') in the open handler and then do app.publish('all','ping') to send a ping message to every client. This should be faster than looping through websockets in JS. The close event should trigger if there is problem with connection after 20 seconds (or sooner if the client officially closes the connection)

Smart. That's a quite simple solution really. Just do a setInterval in JS and make it publish to some topic that all clients are subscribed to.

@hst-m @alexhultman  will it cause big network traffic flow? If 100K client connect to server, it send all ping at one time.
Right now, my solution is JS loop all ws, and send 1000 ping then await 500ms, then continue.
sendAutoPing = async () => {
    let sendCount = 0
    let clientInfos = _.values(this.clientMap)
    for (let index = 0; index < clientInfos.length; index++) {
      const clientInfo = clientInfos[index];
      if (_.isNil(clientInfo) || _.isNil(clientInfo.p)) {
        continue
      }
      sendCount++
      if (sendCount === 1000) {
        //send ping smooth
        await Bluebird.delay(500)
        sendCount = 0
      }
      _.each(clientInfo.p, (platformInfo, platform) => {
        if (platformInfo && platformInfo.ws) {
          let ws = platformInfo.ws
          if (!ws._isKicked) {
            ws.ping()
          }
        }
      })
    }
  }

On the other hand, if you can be woken from deep sleep from a network interrupt then surely you can register a timer to be woken up when to send the client side ping. I know for a fact that you can register timer interrupts to basically any processor ever created.

On the other hand, if you can be woken from deep sleep from a network interrupt then surely you can register a timer to be woken up when to send the client side ping. I know for a fact that you can register timer interrupts to basically any processor ever created.

Yes, in our APP we do have timer send client->server ping. But also we need server->client ping.
Network interrupt not work as timer. The Android system will disable all timer for APP in deep sleep. But the socket data event is from some kind of mobile cell down layer module service, it can always wake up APP.

WebSocket to be kept alive during deep sleep?

@alexhultman
As i said, in China, we can't use GCM(Google Cloud Messaging) or FCM(Firebase Cloud Messaging), both technical and LAW. we must develop our own push service. Implement a push service, need long-alive socket connection.

@hst-m @alexhultman
Actually, i used to create a smart keep alive solution.
Server normally do not send any ping. it trace all received data(pong, message) to refresh internal updateTime. If the updateTime is old than autoPingInterval, server will send ping to client, if still no response, than treat client is disconnected, call close.

It looks like your function is only useful for determining on the server side that the connection client is closed, your function detects this before the TCP timeout or idleTimeout, this is the only benefit of your function.

It looks like your function is only useful for determining on the server side that the connection client is closed, your function detects this before the TCP timeout or idleTimeout, this is the only benefit of your function.

@uasan Yes, at beginning i thought the idleTimeout is only refreshed by receiving data. Then @hst-m clear it for me that also effect on sending data.
But the purpose is to make sure all client is alive. not-alive clients should be delete (@hst-m  said it will auto close when no pong after 20s). Keep not-alive clients do not make sense.

@uasan Yes, at beginning i thought the idleTimeout is only refreshed by receiving data. Then @hst-m clear it for me that also effect on sending data.

TCP cannot send data without also receiving data (within a reasonable time). <--- impoartant
So idleTimeout works "as if" it measured only received data. I might change this back so that idleTimeout only resets on data receive, but that is only a minor tweak - in practice it already does this.

We have two technical arguments in favor of the add autoPingInterval setting.

Rapid detection of dead connections
Ping to client who cannot send pings on their own

I can definitely make sense to add this support, and maybe tweak the rule about resetting idleTimeout on sends. However like said none of this is currently "broken". We are talking about subtle improvements.

On the other hand, if you can be woken from deep sleep from a network interrupt then surely you can register a timer to be woken up when to send the client side ping. I know for a fact that you can register timer interrupts to basically any processor ever created.

Let me give the browser perspective on this:
Modern browsers, regardless of device type, started "throttling" background tabs (since a year?). Safari's throttling is the most aggressive one, it throttles CPU clocks to an absolute minimum. One exception to throttling is a network interrupt. Once the tab receives a network interrupt, Safari allows the tab's thread to run at full speed for a couple milliseconds.

Thanks for adding more info. What do you think about autoPing: true/false?
Only going by idleTimeout, being entirely automatic.

autoPing option probably a good idea, I noticed when only having idleTimeout: phone sleeps and triggers the idleTimeout close connection, but this close event gets sent to client which wakes the client back up and it re-opens the connection, goes back to sleep, triggers idleTimeout again so loop of open/close events which is no good. Ended up increasing idleTimeout to 2:30 minutes to prevent this on phone, or can just send some server autoPings at interval and the connection will close if it doesn't go through

OFF TOP
@hst-m Did constant pinging prevent throttling in modern safari? 2 years ago when I tried this, it doesn't. In IOS safari I used to use:
<meta id=backgroundRefresh http-equiv="refresh" content=-1>
<script>
setInterval(() => document.getElementById('backgroundRefresh').content = 5, 1000)
</script>

JavaScript constantly updating time to reload page, and when safari throttles JS, it wakes up in 5 seconds.

(this support is implemented in v19, "binaries" branch has it but it is not released yet)