Relay API client throws non-error objects

When using RelayClient or sending transactions with DefenderRelaySigner, errors are thrown as non-error objects.
For example, if your account does not have enough MATIC and you try to send a transaction with RelayerClient.sendTransaction(), an object with the following structure will be thrown:
{
  "response": {
    "status": 400,
    "statusText": "Bad Request",
    "data": {
      "message": "Insufficient funds: 0.0194178065148 MATIC required but 0.0 MATIC are available."
    }
  },
  "message": "Request failed with status code 400",
  "request": {
    "path": "/txs",
    "method": "POST"
  }
}

The thrown object does not extend the standard Error class.
First, this makes debugging and monitoring sometimes confusing. For example Sentry will display those errors as Non-Error exception captured with keys: message, request, response.
When uncaught in AWS Lambda, it will be logged in CloudWatch like this:
{
  "errorType": "object",
  "errorMessage": "[object Object]",
  "trace": []
}

Also, we need to be able to automate the recovery of failures such as HTTP 402s (quota exceeded) or some HTTP 400s (insufficient founds) but the SDK makes it difficult to create our own errors.
The problem comes from the Axios response interceptor you use:
  instance.interceptors.response.use(
    (response) => response.data,
    (error) =>
      Promise.reject({
        response: pick(error.response, 'status', 'statusText', 'data'),
        message: error.message,
        request: pick(error.request, 'path', 'method'),
      }),
  );

https://github.com/OpenZeppelin/defender-client/blob/master/packages/base/src/api/api.ts#L15-L23
The minimum would be to turn the object your throw { response: pick(error.response, 'status', 'statusText', 'data'), message: error.message, request: pick(error.request, 'path', 'method') } into an instance of Error.
Ideally, the SDK should throw errors implementing or extending a common Error class (e.g.RelayApiResponseError) and export it so we can extend it to create our custom errors, and the API error response codes should be documented.

Hi @cbm-egoubely , thanks for reaching out!
It does seem that we are not returning a standardized Error and we would like to change that.
We will be updating the version with a fix for this soon.

It as been addressed here and will soon be available in the package https://github.com/OpenZeppelin/defender-client/commit/a6029410ebaf347d0ba5e71d06e39d4761fd514d


merge package from arlac77/npm-package-template

.travis.yml

chore(travis): remove node versions 10.12
chore(travis): add node versions 10.13

Codecov Report

Merging #373 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #373   +/-   ##
=======================================
  Coverage   83.33%   83.33%
=======================================
  Files           1        1
  Lines           6        6
=======================================
  Hits            5        5
  Misses          1        1

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 4ab8a2a...978c844. Read the comment docs.

Coverage remained the same at 83.333% when pulling 978c844e19d63b324c55c4ebce89b0adf772b7bc on template-sync-1 into 4ab8a2ae8867c398f5111b80e126e379b70605d2 on master.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


NoMethodError in Spree::Admin::RefundsController#create undefined method `credit' for #ActiveMerchant::Billing::KomojuGateway:0x007fca9bd61bc8

When trying to refund a payment in the admin backend to following error is raised:
NoMethodError in Spree::Admin::RefundsController#create undefined method `credit' for #ActiveMerchant::Billing::KomojuGateway:0x007fca9bd61bc8

We've just released 0.0.7, this should be fixed now.

Thank you so much guys! Will update now :)


Track airtime used per day

TTN has a 30 second fair access policy. The nodes should be able to keep track of their daily airtime usage to ensure they don't violate it.
It would be nice if we implement this in the arduino-library, as an example for people how to track this.
The node can also make decisions (e.g. spreading factor) based on remaining airtime.

Afaik, the uno does not have a clock nor static memory which means the only way to do this would be to track that time since the last boot, and reset in when > 1day.
Since most of the devices that will use this library are used for workshops / home dev / geek stuff, they will probably be rebooted very often... meaning that the time tracking won't work. Am I wrong ?

It's about making users aware of the airtime usage, and giving them an example of how to track it. Look at it as education. That you lose track on the Uno after a reboot is not so much a concern.

Ho sorry, I thought you wanted to implement a local airtime controller


lightgbm.basic.LightGBMError: Bug in GPU histogram! split 11937: 12, smaller_leaf: 10245, larger_leaf: 1704

version: 2.3.2
[LightGBM] [Fatal] Bug in GPU histogram! split 11937: 12, smaller_leaf: 10245, larger_leaf: 1704

Traceback (most recent call last):
  File "lgb_prefit_4ff5fa97-86b3-420c-aa87-5f01abcc18c3.py", line 10, in <module>
    model.fit(X, y, sample_weight=sample_weight, init_score=init_score, eval_set=eval_set, eval_names=valid_X_features, eval_sample_weight=eval_sample_weight, eval_init_score=init_score, eval_metric=eval_metric, early_stopping_rounds=early_stopping_rounds, feature_name=X_features, verbose=verbose_fit)
  File "/home/jon/.pyenv/versions/3.6.7/lib/python3.6/site-packages/lightgbm_gpu/sklearn.py", line 818, in fit
    callbacks=callbacks, init_model=init_model)
  File "/home/jon/.pyenv/versions/3.6.7/lib/python3.6/site-packages/lightgbm_gpu/sklearn.py", line 610, in fit
    callbacks=callbacks, init_model=init_model)
  File "/home/jon/.pyenv/versions/3.6.7/lib/python3.6/site-packages/lightgbm_gpu/engine.py", line 250, in train
    booster.update(fobj=fobj)
  File "/home/jon/.pyenv/versions/3.6.7/lib/python3.6/site-packages/lightgbm_gpu/basic.py", line 2106, in update
    ctypes.byref(is_finished)))
  File "/home/jon/.pyenv/versions/3.6.7/lib/python3.6/site-packages/lightgbm_gpu/basic.py", line 46, in _safe_call
    raise LightGBMError(decode_string(_LIB.LGBM_GetLastError()))
lightgbm.basic.LightGBMError: Bug in GPU histogram! split 11937: 12, smaller_leaf: 10245, larger_leaf: 1704

script and pickle file:
lgbm_histbug.zip
@sh1ng need help seeing if this is fixed in even later master.

I think the latest master branch will not produce this error anymore, as cnt is removed in histogram.

On master
[LightGBM] [Fatal] Check failed: best_split_info.right_count > 0 at /root/repo/LightGBM/src/treelearner/serial_tree_learner.cpp, line 706 .

Traceback (most recent call last):
  File "lgbm_histbug.py", line 8, in <module>
    model.fit(X, y, sample_weight=sample_weight, init_score=init_score, eval_set=eval_set, eval_names=valid_X_features, eval_sample_weight=eval_sample_weight, eval_init_score=init_score, eval_metric=eval_metric, early_stopping_rounds=early_stopping_rounds, feature_name=X_features, verbose=verbose_fit)
  File "/home/sh1ng/dev/.venv/lib/python3.6/site-packages/lightgbm_gpu/sklearn.py", line 829, in fit
    callbacks=callbacks, init_model=init_model)
  File "/home/sh1ng/dev/.venv/lib/python3.6/site-packages/lightgbm_gpu/sklearn.py", line 614, in fit
    callbacks=callbacks, init_model=init_model)
  File "/home/sh1ng/dev/.venv/lib/python3.6/site-packages/lightgbm_gpu/engine.py", line 250, in train
    booster.update(fobj=fobj)
  File "/home/sh1ng/dev/.venv/lib/python3.6/site-packages/lightgbm_gpu/basic.py", line 2145, in update
    ctypes.byref(is_finished)))
  File "/home/sh1ng/dev/.venv/lib/python3.6/site-packages/lightgbm_gpu/basic.py", line 46, in _safe_call
    raise LightGBMError(decode_string(_LIB.LGBM_GetLastError()))
lightgbm.basic.LightGBMError: Check failed: best_split_info.right_count > 0 at /root/repo/LightGBM/src/treelearner/serial_tree_learner.cpp, line 706 .

it is still a GPU bug.
ping @huanzhang12

@guFalcon @huanzhang12 FYI, we are tracking a major accuracy issue with latest lightgbm compared to before.  This is just a heads-up, perhaps it's related to this issue.  But we'll post a separate issue once we have moment to generate MRE.

Thanks @pseudotensor , could the accuracy issue reproduce in CPU?

BTW, maybe this is related: https://github.com/microsoft/LightGBM/pull/2811

https://github.com/microsoft/LightGBM/issues/2813 yes, it's CPU run.  Same setup with GPU hits this GPU histogram bug issue so can't be run.

I think this may be fixed by #2811 too.

So in the latest master branch, the CPU version is okay, while the GPU version failed?

@guolinke  correct
stack trace of the error
/home/sh1ng/dev/.venv/lib/python3.6/site-packages/lightgbm_gpu/basic.py:893: UserWarning: categorical_feature keyword has been found in `params` and will be ignored.
Please use categorical_feature argument of the Dataset constructor to pass this parameter.
  .format(key))
[LightGBM] [Info] This is the GPU trainer!!
[LightGBM] [Info] Total Bins 22008
[LightGBM] [Info] Number of data points in the train set: 1348045, number of used features: 150
[LightGBM] [Info] Using GPU Device: GeForce MX150, Vendor: NVIDIA Corporation
[LightGBM] [Info] Compiling OpenCL Kernel with 256 bins...
[LightGBM] [Info] GPU programs have been built
[LightGBM] [Info] Size of histogram bin entry: 8
[LightGBM] [Info] 138 dense feature groups (179.98 MB) transferred to GPU in 0.273129 secs. 1 sparse feature groups
[LightGBM] [Info] Start training from score -11.811581
[LightGBM] [Info] Start training from score -7.921803
[LightGBM] [Info] Start training from score -0.432866
[LightGBM] [Info] Start training from score -1.142893
[LightGBM] [Info] Start training from score -3.439298
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Fatal] Check failed: best_split_info.left_count > 0 at /root/repo/LightGBM/src/treelearner/serial_tree_learner.cpp, line 702 .

Traceback (most recent call last):
  File "lgb_accuracyissue.py", line 14, in <module>
    eval_init_score=init_score, eval_metric=eval_metric, early_stopping_rounds=early_stopping_rounds, feature_name=X_features, verbose=verbose_fit)
  File "/home/sh1ng/dev/.venv/lib/python3.6/site-packages/lightgbm_gpu/sklearn.py", line 829, in fit
    callbacks=callbacks, init_model=init_model)
  File "/home/sh1ng/dev/.venv/lib/python3.6/site-packages/lightgbm_gpu/sklearn.py", line 614, in fit
    callbacks=callbacks, init_model=init_model)
  File "/home/sh1ng/dev/.venv/lib/python3.6/site-packages/lightgbm_gpu/engine.py", line 250, in train
    booster.update(fobj=fobj)
  File "/home/sh1ng/dev/.venv/lib/python3.6/site-packages/lightgbm_gpu/basic.py", line 2145, in update
    ctypes.byref(is_finished)))
  File "/home/sh1ng/dev/.venv/lib/python3.6/site-packages/lightgbm_gpu/basic.py", line 46, in _safe_call
    raise LightGBMError(decode_string(_LIB.LGBM_GetLastError()))
lightgbm.basic.LightGBMError: Check failed: best_split_info.left_count > 0 at /root/repo/LightGBM/src/treelearner/serial_tree_learner.cpp, line 702 .

Just letting you know that I'm unable to reproduce the issue with dataset originally provided, but it's easily reproducible with data from https://github.com/microsoft/LightGBM/issues/2813

@guolinke I'm trying to track down an issue where after upgrading to latest master branch in mmlspark I am seeing a similar error - any recommendations for code/commits I should look into to investigate what might be the root cause:
[LightGBM] [Warning] Set TCP_NODELAY failed
[LightGBM] [Info] Trying to bind port 12422...
[LightGBM] [Info] Binding port 12422 succeeded
[LightGBM] [Warning] Set TCP_NODELAY failed
[LightGBM] [Warning] Connecting to rank 1 failed, waiting for 200 milliseconds
[LightGBM] [Warning] Set TCP_NODELAY failed
[LightGBM] [Info] Trying to bind port 12426...
[LightGBM] [Info] Binding port 12426 succeeded
[LightGBM] [Info] Listening...
[LightGBM] [Info] Listening...
[LightGBM] [Warning] Set TCP_NODELAY failed
[LightGBM] [Warning] Set TCP_NODELAY failed
[LightGBM] [Info] Connected to rank 1
[LightGBM] [Warning] Set TCP_NODELAY failed
[LightGBM] [Info] Local rank: 0, total number of machines: 2
[LightGBM] [Info] Connected to rank 0
[LightGBM] [Info] Local rank: 1, total number of machines: 2
[LightGBM] [Warning] metric is set=, metric= will be ignored. Current value: metric=
[LightGBM] [Warning] metric is set=, metric= will be ignored. Current value: metric=
[LightGBM] [Warning] Starting from the 2.1.2 version, default value for the "boost_from_average" parameter in "binary" objective is true.
This may cause significantly different results comparing to the previous versions of LightGBM.
Try to set boost_from_average=false, if your old models produce bad results
[LightGBM] [Warning] Starting from the 2.1.2 version, default value for the "boost_from_average" parameter in "binary" objective is true.
This may cause significantly different results comparing to the previous versions of LightGBM.
Try to set boost_from_average=false, if your old models produce bad results
[LightGBM] [Info] Number of positive: 610, number of negative: 762
[LightGBM] [Info] Number of positive: 610, number of negative: 762
[LightGBM] [Warning] Auto-choosing col-wise multi-threading, the overhead of testing was 0.000514 seconds.
You can set force_col_wise=true to remove the overhead.
[LightGBM] [Info] Total Bins 916
[LightGBM] [Warning] Auto-choosing col-wise multi-threading, the overhead of testing was 0.000664 seconds.
You can set force_col_wise=true to remove the overhead.
[LightGBM] [Info] Total Bins 916
[LightGBM] [Info] Number of data points in the train set: 686, number of used features: 4
[LightGBM] [Info] Number of data points in the train set: 686, number of used features: 4
[LightGBM] [Info] [binary:BoostFromScore]: pavg=0.438776 -> initscore=-0.246133
[LightGBM] [Info] [binary:BoostFromScore]: pavg=0.450437 -> initscore=-0.198904
[LightGBM] [Info] Start training from score -0.222518
[LightGBM] [Info] Start training from score -0.222518
[LightGBM] [Info] Finished linking network in 0.003935 seconds
[LightGBM] [Fatal] Check failed: best_split_info.left_count > 0 at /home/ilya/LightGBM/src/treelearner/serial_tree_learner.cpp, line 709 .
20/02/29 00:35:01 WARN LightGBMClassifier: LightGBM reached early termination on one worker, stopping training on worker. This message should rarely occur

Could it run by only one node?

@guolinke amazing insight!  I tried 1 node instead of 2 and almost all of my tests passed (except 1 test due to the number of nodes which is expected)

Here is the output from the same test as above (except it was successful):
[LightGBM] [Warning] metric is set=, metric= will be ignored. Current value: metric=
[LightGBM] [Warning] Auto-choosing col-wise multi-threading, the overhead of testing was 0.000942 seconds.
You can set force_col_wise=true to remove the overhead.
[LightGBM] [Info] Total Bins 327
[LightGBM] [Info] Number of data points in the train set: 106, number of used features: 9
[LightGBM] [Info] Start training from score -1.572397
[LightGBM] [Info] Start training from score -1.618917
[LightGBM] [Info] Start training from score -2.024382
[LightGBM] [Info] Start training from score -1.955389
[LightGBM] [Info] Start training from score -1.890850
[LightGBM] [Info] Start training from score -1.773067
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] metric is set=, metric= will be ignored. Current value: metric=
[LightGBM] [Warning] Auto-choosing col-wise multi-threading, the overhead of testing was 0.002017 seconds.
You can set force_col_wise=true to remove the overhead.
[LightGBM] [Info] Total Bins 327
[LightGBM] [Info] Number of data points in the train set: 106, number of used features: 9
[LightGBM] [Info] Start training from score -1.572397
[LightGBM] [Info] Start training from score -1.618917
[LightGBM] [Info] Start training from score -2.024382
[LightGBM] [Info] Start training from score -1.955389
[LightGBM] [Info] Start training from score -1.890850
[LightGBM] [Info] Start training from score -1.773067
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] metric is set=, metric= will be ignored. Current value: metric=
[LightGBM] [Warning] Auto-choosing col-wise multi-threading, the overhead of testing was 0.000835 seconds.
You can set force_col_wise=true to remove the overhead.
[LightGBM] [Info] Total Bins 327
[LightGBM] [Info] Number of data points in the train set: 106, number of used features: 9
[LightGBM] [Info] Start training from score -1.572397
[LightGBM] [Info] Start training from score -1.618917
[LightGBM] [Info] Start training from score -2.024382
[LightGBM] [Info] Start training from score -1.955389
[LightGBM] [Info] Start training from score -1.890850
[LightGBM] [Info] Start training from score -1.773067
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] metric is set=, metric= will be ignored. Current value: metric=
[LightGBM] [Warning] Auto-choosing col-wise multi-threading, the overhead of testing was 0.001298 seconds.
You can set force_col_wise=true to remove the overhead.
[LightGBM] [Info] Total Bins 327
[LightGBM] [Info] Number of data points in the train set: 106, number of used features: 9
[LightGBM] [Info] Using GOSS
[LightGBM] [Info] Start training from score -1.572397
[LightGBM] [Info] Start training from score -1.618917
[LightGBM] [Info] Start training from score -2.024382
[LightGBM] [Info] Start training from score -1.955389
[LightGBM] [Info] Start training from score -1.890850
[LightGBM] [Info] Start training from score -1.773067
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf
[LightGBM] [Warning] No further splits with positive gain, best gain: -inf

Note this is from this commit on 2/21 (both failing and successful runs):
"Better documentation for Contributing (#2781)"
I'm currently trying to work back to older versions/commits of lightgbm to see which commit is causing the tests to fail, but it is a slow process to build and update the jar and rerun the tests (I'm currently skipping small batches of commits at a time but I might do a binary search to make this optimal since it looks like the issue goes back before 2/21).

@imatiach-msft you can try the commit (509c2e50c25eded99fc0997afe25ebee1b33285d) and its parent (https://github.com/microsoft/LightGBM/commit/bc7bc4a158d47bd9a12b89de21176e1e67a6e961)

@guolinke you're right, it looks like the issue is with commit (509c2e5).
I validated that including that commit causes the error, and removing it fixes the issue.

@imatiach-msft could you share the data (and config) to me for the debugging?

@guolinke  I'm running the mmlspark scala tests, maybe I can try to create an example that you can easily run?
You can find the lightgbm classifier tests here:
https://github.com/Azure/mmlspark/blob/master/src/test/scala/com/microsoft/ml/spark/lightgbm/split1/VerifyLightGBMClassifier.scala
The first test that failed was below, but I tried several others and they failed as well:
https://github.com/Azure/mmlspark/blob/master/src/test/scala/com/microsoft/ml/spark/lightgbm/split1/VerifyLightGBMClassifier.scala#L169
The compressed file with most datasets used in mmlspark can be found here:
https://mmlspark.blob.core.windows.net/installers/datasets-2020-01-20.tgz

@shiyu1994 con you help to investigate this too?
you can start from @imatiach-msft 's test.

Still happens in version 3.0
lightgbm.basic.LightGBMError: Check failed: (best_split_info.left_count) > (0) at /root/repo/LightGBM/src/treelearner/serial_tree_learner.cpp, line 630

https://github.com/h2oai/h2o4gpu/blob/master/tests/python/open_data/gbm/test_lightgbm.py#L265-L284

@shiyu1994 con you help to investigate this too?
you can start from @imatiach-msft 's test.

Ok.

@shiyu1994 @guolinke FYI my issue was resolved when I upgraded after my fix https://github.com/microsoft/LightGBM/pull/3110 , but it sounds like others are still encountering issues similar to what I had

I have this issue with CPU learner, not GPU. Got it after upgrading from 2.3.1 to 3.0.0, makes every test with a tiny testing dataset fail for exactly the same reason:
lightgbm.basic.LightGBMError: Check failed: (best_split_info.left_count) > (0) at /__w/1/s/python-package/compile/src/treelearner/serial_tree_learner.cpp, line 630 .

@diditforlulz273 could you try the latest master branch?
if the problem still exists, you can create a new issue and would be better if you can provide a reproducible example.

@guolinke Have just built it from the latest master branch, still fails. I'll try to separate a minimum reproducible example and create an issue then.

+1, this bug makes lightgbm GPU useless. still happens to me on latest master

Hi,
I'm using the GPU setting and have the same issue. I tried "deterministic = True" but it did not solve the problem. I saw that the LightGBM v3.2.0 may fix this defect. I have a few question as follows:

In the v3.2.0 release thread, I noticed that this bug #2793 is not in bold. Does this mean that it may not be fixed until a later release?
Does a fix exists for it in a non-release (build from source) option? If so, can you please guide me to it?
Assuming that a fix may be part of v3.2.0 release, is this release about to happen? I noticed that v3.1.1 was released 3 months ago.

I apologize if my questions are a bit out of bound.
Best regards

It's puzzling and unfortunate that a known issue of this severity is left open for over 1.5 years. The error affects every other attempt to train on GPUs when using the latest 'stable' bits in Business Division (Dynamics). I can help with a business case from inside Microsoft, to push this if necessary. My alias: dakowalc. Thanks

Thank you @nightflight-dk , actually we had re-writing the LightGBM GPU version, and previous OpenCL and CUDA versions will be deprecated.  refer to PR https://github.com/microsoft/LightGBM/pull/4528

Since there hasn't been any activity for a year, I would like to bring this topic up again.
Got the version 3.3.3, python.  Training on GPU, on Windows.
The issue is bugging me for the past 2 days.. The data set is 500k, with 1500 features. There seems to be some correlation with min_gain_to_split parameter. When the value is 1 I have not yet seen any errors, however on value 0 (default) it seems to crash quite often. Take this comment with caution since I have not ran enough tests yet..
crashed when

{'learning_rate': 0.43467624523546383, 'max_depth': 8, 'num_leaves': 201, 'feature_fraction': 0.9, 'bagging_fraction': 0.7000000000000001, 'bagging_freq': 8}

{'learning_rate': 0.021403440298427053, 'max_depth': 2, 'num_leaves': 176, 'lambda_l1': 3.8066251775052895, 'lambda_l2': 1.08526150100961e-08, 'feature_fraction': 0.6, 'bagging_fraction': 0.9, 'bagging_freq': 6}

{'learning_rate': 0.3493368922746614, 'max_depth': 6, 'num_leaves': 109, 'lambda_l1': 4.506588272812341e-05, 'lambda_l2': 2.5452579091348995e-07, 'feature_fraction': 0.7000000000000001, 'bagging_fraction': 1.0, 'bagging_freq': 6, 'min_gain_to_split': 0}

{'learning_rate': 0.17840010040986135, 'max_depth': 12, 'num_leaves': 251, 'lambda_l1': 0.004509589012189404, 'lambda_l2': 3.882151732343819e-08, 'feature_fraction': 0.30000000000000004, 'bagging_fraction': 1.0, 'bagging_freq': 8, 'min_gain_to_split': 0}

the code is:
    params = {
        'device_type': "gpu",
        'objective': 'multiclass',  #
        'metric': 'multi_logloss',  #
        "boosting_type": "gbdt",
        "num_class": 3,
        'random_state': 123,
        'verbosity': -1,  # hides "No further splits with positive gain, best gain: -inf" warnings
        "learning_rate": trial.suggest_float("learning_rate", 0.01, 0.9, log=True),  # 0.1
        'max_depth': trial.suggest_int('max_depth', 2, 12),
        'num_leaves': trial.suggest_int('num_leaves', 2, 256),  # def 31
        'lambda_l1': trial.suggest_float('lambda_l1', 1e-8, 10.0, log=True),  # 0
        'lambda_l2': trial.suggest_float('lambda_l2', 1e-8, 10.0, log=True),  # 0
        'feature_fraction': trial.suggest_float('feature_fraction', 0.1, 1.0, step=0.1),  # 1
        'bagging_fraction': trial.suggest_float('bagging_fraction', 0.1, 1.0, step=0.1),  # 1
        'bagging_freq': trial.suggest_int('bagging_freq', 0, 10),  # 0
        'min_gain_to_split': trial.suggest_int('min_gain_to_split', 0, 5),
    }

with a few changes here and there
exception is:
[LightGBM] [Fatal] Check failed: (best_split_info.left_count) > (0) at D:\a\1\s\python-package\compile\src\treelearner\serial_tree_learner.cpp, line 653 .

[W 2022-11-07 09:49:32,774] Trial 49 failed because of the following error: LightGBMError('Check failed: (best_split_info.left_count) > (0) at D:\\a\\1\\s\\python-package\\compile\\src\\treelearner\\serial_tree_learner.cpp, line 653 .\n')
Traceback (most recent call last):
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\optuna\study\_optimize.py", line 196, in _run_trial
    value_or_values = func(trial)
  File "D:\dev\Pycharm2022\LearningCNN\test9_realData4_optuna.py", line 174, in objective
    model = lgb.train(
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\lightgbm\engine.py", line 292, in train
    booster.update(fobj=fobj)
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\lightgbm\basic.py", line 3021, in update
    _safe_call(_LIB.LGBM_BoosterUpdateOneIter(
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\lightgbm\basic.py", line 125, in _safe_call
    raise LightGBMError(_LIB.LGBM_GetLastError().decode('utf-8'))
lightgbm.basic.LightGBMError: Check failed: (best_split_info.left_count) > (0) at D:\a\1\s\python-package\compile\src\treelearner\serial_tree_learner.cpp, line 653 .

Traceback (most recent call last):
  File "D:\dev\Pycharm2022\LearningCNN\test9_realData4_optuna.py", line 237, in <module>
    study.optimize(objective, n_trials=_NUMBER_OF_TRIALS)
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\optuna\study\study.py", line 419, in optimize
    _optimize(
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\optuna\study\_optimize.py", line 66, in _optimize
    _optimize_sequential(
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\optuna\study\_optimize.py", line 160, in _optimize_sequential
    frozen_trial = _run_trial(study, func, catch)
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\optuna\study\_optimize.py", line 234, in _run_trial
    raise func_err
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\optuna\study\_optimize.py", line 196, in _run_trial
    value_or_values = func(trial)
  File "D:\dev\Pycharm2022\LearningCNN\test9_realData4_optuna.py", line 174, in objective
    model = lgb.train(
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\lightgbm\engine.py", line 292, in train
    booster.update(fobj=fobj)
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\lightgbm\basic.py", line 3021, in update
    _safe_call(_LIB.LGBM_BoosterUpdateOneIter(
  File "D:\dev\Py_Global_vEnv_2022\lib\site-packages\lightgbm\basic.py", line 125, in _safe_call
    raise LightGBMError(_LIB.LGBM_GetLastError().decode('utf-8'))
lightgbm.basic.LightGBMError: Check failed: (best_split_info.left_count) > (0) at D:\a\1\s\python-package\compile\src\treelearner\serial_tree_learner.cpp, line 653 .

Process finished with exit code 1

I am using optuna for optimization so the set of parameters is always different.
Tried using different split ratio (0.19/0.20/0.21) - does not seem to fix anything
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.19, random_state=42, shuffle=True)

as well as tried experimenting with the amount of data (600_000/600_001/200_001). Nothing seems to help fix the issue.. Can this fix be expected in the next major release? I see that the topic is still active..

I build the docker image with this dockerfile. And I encounter this issue, too.
LightGBMError: Check failed: (best_split_info.left_count) > (0) at /usr/local/src/lightgbm/LightGBM/src/treelearner/serial_tree_learner.cpp, line 653 .


Render the post tiles and content as per the new format

The post list tiles and blogs should be rendered according to the format mentioned in #94. Changes need to be made in Article, ArticleView and Writer

Closing as migrated to https://github.com/muellners/second.exchange


blendMode crashes when selected to generate response

This happens because the property being passed to be execute is  blendMode, but the correct property name is mode

Ok, I will look into that. I think there are few more properties like that. I think that for the clipped layer is another one.

Will be fixed in 1.2.0


Add optimizer, seed, discriminator getter/setter methods to QuantumGenerator class

Summary
Added a new method, set_optimizer, to the QuantumGenerator class, which allows for changing the optimizer used while training the generator without needing to create a new QuantumGenerator object.
Details and comments
This PR addresses #1454

Hi @woodsp-ibm ,
Thanks for letting me know!
I can add the type hints to this PR if you'd like.

Hi @woodsp-ibm ,
Thanks for letting me know!
I can add the type hints to this PR if you'd like.

I can add the type hints to this PR if you'd like.

Sure, that would be great, thx!

I can add the type hints to this PR if you'd like.

Sure, that would be great, thx!

Hi @woodsp-ibm ,
I noticed that in qgan.py, the default value for the seed property is 7, so I did the same for QuantumGenerator.seed: I hope that's okay?

Hi @woodsp-ibm ,
I noticed that in qgan.py, the default value for the seed property is 7, so I did the same for QuantumGenerator.seed: I hope that's okay?

I noticed that in qgan.py, the default value for the seed property is 7, so I did the same for QuantumGenerator.seed: I hope that's okay?

I also need to direct this at @Zoufalc too. In qgan the seed coming in goes to a instance var _random_seed which later is set to the seed setter such that aqua_globals is now seeded to this. In my mind the behavior, by default should be random, so to me a better default for qgan would be None (i.e. an Optional int). Though I guess whatever value is set here will override the common global generator so if you seeded the common global generator then None would drop back to a random seed.
In you case it seems that seed default is just set on the member instance and by default, unlike qgan.py that then goes on to pass it to the setter, its not done here. Internally, like qgan, it is using the common global generator anyway - aside from in qgan where it also gets passed to the discriminator which when PyTorch has its own seed as I recall.
This mix of what looks like an independent seeded object yet overrides the common global generator seems problematic in my mind. Using the common global generator has the advantage of a single seed to control the randomness throughout the algorithms so that the user does not have to set a whole bunch of seeds in various places. I understood when this was done that some independence of seeding was wanted. Maybe it really ought to have its own random generator in this case and not use the common global one at all.

I noticed that in qgan.py, the default value for the seed property is 7, so I did the same for QuantumGenerator.seed: I hope that's okay?

I also need to direct this at @Zoufalc too. In qgan the seed coming in goes to a instance var _random_seed which later is set to the seed setter such that aqua_globals is now seeded to this. In my mind the behavior, by default should be random, so to me a better default for qgan would be None (i.e. an Optional int). Though I guess whatever value is set here will override the common global generator so if you seeded the common global generator then None would drop back to a random seed.
In you case it seems that seed default is just set on the member instance and by default, unlike qgan.py that then goes on to pass it to the setter, its not done here. Internally, like qgan, it is using the common global generator anyway - aside from in qgan where it also gets passed to the discriminator which when PyTorch has its own seed as I recall.
This mix of what looks like an independent seeded object yet overrides the common global generator seems problematic in my mind. Using the common global generator has the advantage of a single seed to control the randomness throughout the algorithms so that the user does not have to set a whole bunch of seeds in various places. I understood when this was done that some independence of seeding was wanted. Maybe it really ought to have its own random generator in this case and not use the common global one at all.

This mix of what looks like an independent seeded object yet overrides the common global generator seems problematic in my mind.

Good catch!
Looks like I tripped up a little on this one.
I think the idea from what I've seen (plus what you just wrote) would be that there are a couple different cases here:

No seed is provided at all, anywhere: use RNGs without setting their seeds
A seed is provided to the QGAN object: Use the same seed throughout all three files (qgan, generator, discriminator)
A seed is provided to the QuantumGenerator object or the discriminator:  We continue using an RNG without a set seed for the QGAN, but set the seed for the RNG used in the generator or discriminator.

In case we experience cases which are a mixture of these (for example, if we pass a seed to the QGAN, and then we set the seed for the generator) we simply overwrite the seed properties of the objects in question. In the case of the example, we would have the same seed for the QGAN and the discriminator, but a different one for the generator, since we overwrote the generator's seed property.

I understood when this was done that some independence of seeding was wanted.

If we really want linked yet independent seeding behavior, using separate RNGs like you mentioned is probably the easiest option.
I think it also sort of comes down to a question of whether we want to use the aqua_globals properties to control RNG for the QGAN and its components or not - in my opinion a nice middle ground would be:

Check, in each class, whether the aqua_globals.random_seed property is set: if it is, then use the aqua_globals.random method to get RNGs and use them
If it is set, but the class also has a seed property set: revert to the rules I mentioned earlier.

That's a (super long) summary of what I thought - please let me know if this works, or if you (or @Zoufalc) think any (or all!) of it can be done better.

This mix of what looks like an independent seeded object yet overrides the common global generator seems problematic in my mind.

Good catch!
Looks like I tripped up a little on this one.
I think the idea from what I've seen (plus what you just wrote) would be that there are a couple different cases here:

No seed is provided at all, anywhere: use RNGs without setting their seeds
A seed is provided to the QGAN object: Use the same seed throughout all three files (qgan, generator, discriminator)
A seed is provided to the QuantumGenerator object or the discriminator:  We continue using an RNG without a set seed for the QGAN, but set the seed for the RNG used in the generator or discriminator.

In case we experience cases which are a mixture of these (for example, if we pass a seed to the QGAN, and then we set the seed for the generator) we simply overwrite the seed properties of the objects in question. In the case of the example, we would have the same seed for the QGAN and the discriminator, but a different one for the generator, since we overwrote the generator's seed property.

I understood when this was done that some independence of seeding was wanted.

If we really want linked yet independent seeding behavior, using separate RNGs like you mentioned is probably the easiest option.
I think it also sort of comes down to a question of whether we want to use the aqua_globals properties to control RNG for the QGAN and its components or not - in my opinion a nice middle ground would be:

Check, in each class, whether the aqua_globals.random_seed property is set: if it is, then use the aqua_globals.random method to get RNGs and use them
If it is set, but the class also has a seed property set: revert to the rules I mentioned earlier.

That's a (super long) summary of what I thought - please let me know if this works, or if you (or @Zoufalc) think any (or all!) of it can be done better.

Hi @woodsp-ibm and @Zoufalc ,
Please let me know if what I wrote above sounds okay, or if you feel something could be done better, so that I can implement it.
Thanks!

Hi @woodsp-ibm and @Zoufalc ,
Please let me know if what I wrote above sounds okay, or if you feel something could be done better, so that I can implement it.
Thanks!

Hi @SashwatAnagolum,
Thanks for explaining your thoughts on this. I am fine with whatever seeding behavior you and @woodsp-ibm prefer.

Hi @SashwatAnagolum,
Thanks for explaining your thoughts on this. I am fine with whatever seeding behavior you and @woodsp-ibm prefer.

@Zoufalc As far as I can see, while QGAN takes a seed (which seems to be 7 which defaults the random generator to always be the same!) its not used by the algorithm itself, just passed onto the discriminator. Since the discriminator is the one seeded, and the user either creates it or can access it via QGAN, maybe the seed should just be on the discriminator and removed from QGAN.
The PyTorch based discriminator, since thats a different subsystem, needs to have the seed setter. As to the NumPy based one I guess this is a choice. It could work by default off the global generator but have a seed capability that if set would then use its own generator, if it is seen as reasonable to allow something that is independent. As @SashwatAnagolum suggested this mix is a middle ground of convenience via a common global seed that is simple to setup for predictability in tests and experiments, but is flexible for more advance use as it can be independently seeded if this is deemed suitable.
As this code will be migrated to a Machine Learning repo and we need to keep backwards compatibility I am wondering if the changes related to the seed should just be done on the code after it has migrated since anything done here needs to be kept backwards compatible, whereas on the migrated code such breaking changes are less of a concern in that regard.

Both suggestions sound good to me.
Of course, it is important to keep both user-friendliness as well flexibility for advanced experiments.
And you are right since the migration should happen in the near future it might make sense to wait for it.

@woodsp-ibm and @Zoufalc ,
Would it make sense to work on it now, and make a PR, in case you think we can merge it before the migration?
Even if we end up using the code only after the move to a new repo is made, the work will be done already.
Let me know if this sounds okay to you.

@SashwatAnagolum Thanks for being so keen to take a shot at things. But I feel we need to wait for the new repository which should be setup very soon. For the code here in Aqua we need to ensure current function continues to work, via deprecation as necessary, when we go over to new function/behavior. As such this constrains what we can do to some degree. Under the new repository there will be more freedom to change with a migration guide to help people move to the newer codebase.


VUE_DEV_SERVER_URL in nightwatch plugin leads nowhere

Version
3.0.0-beta.10
Reproduction link
https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/cli-plugin-e2e-nightwatch/generator/template/tests/e2e/specs/test.js
Steps to reproduce
Run npm run test:e2e and watch nightwatch be unable to find anything—then die.
Error: Command failed: /~projectpath/node_modules/nightwatch/bin/nightwatch --config<EMAIL_ADDRESS>--env chrome
    at makeError (/~projectpath/node_modules/execa/index.js:172:9)
    at Promise.all.then.arr (/~projectpath/node_modules/execa/index.js:277:16)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:182:7)

If you run npm run test:e2e -- --url=http://localhost:8080—if you have a server up and running—the tests pass just fine.
What is expected?
I expect the #app element to be to visible.
What is actually happening?
Nightwatch can't find the #app element because it never loads the page.
When Chrome fires up, the URL in the bar says: data:,. After that, it attempts to go to localhost:8081, but just dies and fails the tests. Again, passing the --url option on the command line gets the tests to pass.

Cannot reproduce on a fresh beta.10 install. Please provide an actual reproduction repository.

My apologies—it was due to a vue.config.js tweak. I had forgotten that e2e tests spin up in production mode. The development server part made me think I wasn't in production mode. The production mode has a different public path, and that was screwing with the test.


[bug] Upgrading from v1.12.5 to v1.13.0 introduced a character-eating issue.

Please describe the bug

https://github.com/sparklemotion/nokogiri/releases/tag/v1.13.0
There's some kind of issue/change between these versions that is eating ampersand characters (&). As far as I'm aware, this isn't happening with any other characters, but definitely could be.
We had upgraded to v1.13.8 during our Rails upgrade, and that's when we started noticing this issue. We backtracked the versions to figure out when it started happening, and narrowed it down to v1.12.5 last working as expected.

Help us reproduce what you're seeing

Environment
# Nokogiri (1.13.8)
    ---
    warnings: []
    nokogiri:
      version: 1.13.8
      cppflags:
      - "-I/Users/tylercook/.rvm/gems/ruby-2.6.1/gems/nokogiri-1.13.8-x86_64-darwin/ext/nokogiri"
      - "-I/Users/tylercook/.rvm/gems/ruby-2.6.1/gems/nokogiri-1.13.8-x86_64-darwin/ext/nokogiri/include"
      - "-I/Users/tylercook/.rvm/gems/ruby-2.6.1/gems/nokogiri-1.13.8-x86_64-darwin/ext/nokogiri/include/libxml2"
      ldflags: []
    ruby:
      version: 2.6.1
      platform: x86_64-darwin20
      gem_platform: x86_64-darwin-20
      description: ruby 2.6.1p33 (2019-01-30 revision 66950) [x86_64-darwin20]
      engine: ruby
    libxml:
      source: packaged
      precompiled: true
      patches:
      - 0001-Remove-script-macro-support.patch
      - 0002-Update-entities-to-remove-handling-of-ssi.patch
      - 0003-libxml2.la-is-in-top_builddir.patch
      - 0004-use-glibc-strlen.patch
      - 0005-avoid-isnan-isinf.patch
      - 0006-update-automake-files-for-arm64.patch
      - '0008-htmlParseComment-handle-abruptly-closed-comments.patch'
      - '0009-allow-wildcard-namespaces.patch'
      libxml2_path: "/Users/tylercook/.rvm/gems/ruby-2.6.1/gems/nokogiri-1.13.8-x86_64-darwin/ext/nokogiri"
      memory_management: ruby
      iconv_enabled: true
      compiled: 2.9.14
      loaded: 2.9.14
    libxslt:
      source: packaged
      precompiled: true
      patches:
      - 0001-update-automake-files-for-arm64.patch
      datetime_enabled: true
      compiled: 1.1.35
      loaded: 1.1.35
    other_libraries:
      zlib: 1.2.12
      libiconv: '1.16'
      libgumbo: 1.0.0-nokogiri

Hi, @tylerjc! Thanks for asking this question. I spent a little bit of time investigating this afternoon and this is a super interesting issue!
First, let me just ask a favor, which is that in the future please don't use screenshots. It's easier for maintainers to read and reproduce problems if you use regular old text.
characterizing the behavior change
OK, let's do this. Here's the script I'm going to use to explain what's going on here:
#! /usr/bin/env ruby

require "bundler/inline"

ENV["NV"] ||= "1.12.5" # =>

gemfile do
  source "https://rubygems.org"
  gem "nokogiri", "=#{ENV["NV"]}"
end

Nokogiri::VERSION # =>

doc = Nokogiri::XML::Document.parse("

")
frag = doc.at_css("p").parse("H&M Storage") # =>

doc = Nokogiri::HTML::Document.parse("

")
frag = doc.at_css("p").parse("H&M Storage") # =>

When I run this with Nokogiri v1.12.5, we see:
#! /usr/bin/env ruby

require "bundler/inline"

ENV["NV"] ||= "1.12.5" # => "1.12.5"

gemfile do
  source "https://rubygems.org"
  gem "nokogiri", "=#{ENV["NV"]}"
end

Nokogiri::VERSION # => "1.12.5"

doc = Nokogiri::XML::Document.parse("

")
frag = doc.at_css("p").parse("H&M Storage") # => [#<Nokogiri::XML::Text:0x384 "H&M Storage">]

doc = Nokogiri::HTML::Document.parse("

")
frag = doc.at_css("p").parse("H&M Storage") # => [#<Nokogiri::XML::Text:0x398 "H&M Storage">]

when I run it with v1.13.0 we see:
#! /usr/bin/env ruby

require "bundler/inline"

ENV["NV"] ||= "1.12.5" # => "1.13.0"

gemfile do
  source "https://rubygems.org"
  gem "nokogiri", "=#{ENV["NV"]}"
end

Nokogiri::VERSION # => "1.13.0"

doc = Nokogiri::XML::Document.parse("

")
frag = doc.at_css("p").parse("H&M Storage") # => [#<Nokogiri::XML::Text:0x384 "H Storage">]

doc = Nokogiri::HTML::Document.parse("

")
frag = doc.at_css("p").parse("H&M Storage") # => [#<Nokogiri::XML::Text:0x398 "H&M Storage">]

OK, so take note that v1.12.5 and v1.13.0 behave the same if we are working with a Nokogiri::HTML::Document, but the behavior changes if we are using a Nokogiri::XML::Document.
diagnosis
I git-bisected when this change was introduced, and it is commit 38c2f16a from #2388, which addressed an issue described at #1158. The summary of that change from the changelog is:

Error recovery from in-context parsing (e.g., Node#parse) now always uses the correct DocumentFragment class. Previously Nokogiri::HTML4::DocumentFragment was always used, even for XML documents.

What's happening here is that, in 1.12.5:

Node#inner_html parses its argument as an XML document fragment (XML instead of HTML because the original document is XML::Document)
initial parsing fails because there is invalid markup (the bare & character) and libxml2 does not recover from errors during "in-context fragment parsing")
the fallback behavior at https://github.com/sparklemotion/nokogiri/blob/v1.12.5/lib/nokogiri/xml/node.rb#L839 is to use Nokogiri::HTML::DocumentFragment to perform fragment parsing (using the more robust but less appropriate fragment parsing without a node context)

but in v1.13.0:

Node#inner_html still parses its argument as an XML document fragment
initial parsing still fails because there is invalid markup
but the fallback behavior is to use Nokogiri::XML::DocumentFragment because the original document is an XML::Document

We feel this new behavior is more correct, though I appreciate it breaks in your use case in an unexpected way.
possible workarounds for you
If this is an HTML document, I'd suggest starting with a Nokogiri::HTML::Document instead of a Nokogiri::XML::Document, and the behavior should be what you want.
If this is an XML document, but you truly want to parse HTML fragments, then I'd suggest being explicit about that by using code like this:
doc = Nokogiri::XML::Document.parse("

")
frag = Nokogiri::HTML::DocumentFragment.parse("H&M Storage")
doc.at_css("p").children = frag.children
doc.to_s # => "<?xml version=\"1.0\"?>\n
H&M Storage
\n"

thinking about Node#inner_html=
You would be justified in thinking, "well jeez, I used a method called inner_html, why didn't it parse it as HTML", but the awful truth is that Node#inner_html= is just a convenience alias for Node#children= and it was never our intention for those two methods to behave differently.
I'm thinking about whether #inner_html= should always parse HTML. Although I suspect there would be a lot of people who think either way is "more intuitive," it mostly doesn't make sense to me to pretend provide a way for an XML document to contain HTML content, given that they are different specs with different validity expectations and parsing behaviors.
So I'm going to leave it the way it is, but I will add some clarifying documentation to that method to make it clear it's a convenience alias for children= and may not actually parse the argument as HTML.
Does all this make sense? Happy to answer questions.

I made a couple of small updates to my previous post for clarity.

I've drafted #2656 which clarifies this method in the doc string. Any feedback for me on this? If not I'll merge that in the next day or so and close this. Happy to discuss after that if you'd like!

@tylerjc Does what I said above make sense? Do the docs I've written at #2656 explain the situation more clearly?

OK, closing and merging the docs at #2656. Please let me know if you have any other thoughts.


Support 3 digit semantic versioning

What is the problem?
A description of what the problem is.
The spec says:
X-Broker-API-Version: 2.14
The version numbers are in the format MAJOR.MINOR using semantic versioning.
Actually semantic versioning [1] says:
"A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. "
Therefore semver libraries. e.g. [2], do not accept dotted-two formatted versions and require dotted-tri format instead.
[1] https://semver.org/
[2] https://github.com/coreos/go-semver/blob/e214231b295a8ea9479f11b70b35d5acf3556d9b/semver/semver.go#L77
Who does this affect?
Does this affect service broker authors, platform authors or developers?
Developers who implement brokers.
Do you have any proposed solutions?
A description of any potential solutions.
Use a 3 digit version, e.g. 2.14.0
Additional context
Add any other context or screenshots can go here.

Thanks for raising this @sklevenz
I agree that the it would be better if the specification used the proper MAJOR.MINOR.PATCH of semver, however I think changing this could potentially break existing Service Brokers. I can imagine some brokers have code written to split the version string in a certain way that may not be compatible with the improved format.
On the call today we also discussed that we don't really have much use today for making patch version changes, so even if we went ahead and implemented this it is unlikely it would provide much benefit.
Aside from being able to use semver libraries, do you see other benefits to adopting patch?

@Samze Thanks to follow up on this.
I understand your point of view and see that changing the specification is not that easy.
If someone uses a Semver library, it's just a small stumbling block. Perhaps it is sufficient to give a little hint in the specification.
You are also welcome to close this problem. The solution is very simple. If it's not a semver, just don't use a semver library ;-)

@sklevenz happy to accept a PR if you want to add some clarifying text! Will close this for now.


toRelative formatter crashes with EXC_BAD_INSTRUCTION

I faced problem as in title, when I call .toRelative(since:style:locale:) on my date which as string is f.e. "2022-06-07 13:12:06 +0000" my app crashes. Crash stack from Console app prints:
Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   SwiftDate                     	       0x10425f4ee specialized static RelativeFormatter.suitableFlavour(inList:forLocale:) + 1230
1   SwiftDate                     	       0x10425e46d specialized static RelativeFormatter.format(date:to:style:locale:) + 1517
2   SwiftDate                     	       0x104252e9b DateRepresentable.toRelative(since:style:locale:) + 507
3   MyApp                      	       0x103f8d8cf 0x103f76000 + 96463

The line where I call that is the last one below:
 var locales = Locales.english
 let style = RelativeFormatter.timeStyle()
 return creationDate.toRelative(style:style, locale: locales)

Maybe is significant that I call that in SwiftUI.
The problem occurs after a few launches on OS X 10.15 and 12.4 at this moment, architecture x86_64.
The error is:

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace SIGNAL, Code 4 Illegal instruction: 4
Terminating Process:   exc handler [830]

Thanks for every help!

Can u provide the code where this is happening, your own code ?


Fix I-Score and D-Score Parent/Child Rollup Functionality

💡 Summary
Current implementation of I-Score and D-Score are not calculating correctly for organizations that are a child of a parent organization. i.e. parent organization score is correct, child organization score is not
Motivation and context
This needs to be fixed because we will need to generate correct scores for both parent and child organizations simultaneously
Implementation notes

Will need to update SQL views to include organizations_uid and parent_org_uid
Once that data is brought over to the python side, any data attributed to a child organization needs to be duplicated
One copy of the data will have the child's organization_uid
The other copy is the exact same, but will have the parent_org_uid attached to it
This will allow both the child and parent org to keep track of their data for scoring purposes
This duplication will happen on the python side at runtime and will not duplicate anything in the actual database

Acceptance criteria
How do we know when this work is done?

[X] Update SQL views so that they return both organizations_uid AND parent_org_uid
[X] Implement duplication function to create one copy of the data for the child and one record for the parent
[X] Adjust any remaining python code to accommodate these changes
[X] Test for correct functionality

I-Score and D-score have been updated to correctly handle parent/child score generation


Feature_Request

Is your feature request related to a problem? Please describe.
Yes, the current website lacks clear navigation and easy access to our social media profiles, which can hinder user engagement and connectivity.
Describe the solution you'd like
I propose enhancing the gooter for better interaction and adding social media links to increase user engagement and connectivity. This will involve reorganizing the footer for more intuitive access and integrating interactive social media icons in the footer.
Describe alternatives you've considered
Alternatives considered include placing social media links in the header or within the main content area, but adding them to the footer ensures consistent visibility across all pages without cluttering the main navigation area
Demo Video/Screenshot (Mandatory )

Are you contributing under any open-source program ?
gssoc

@nirajsingh015 this same issue is already existing in this repo & already been assigned to another contributor.


reorganizing environment variables doc

Signed-off-by: anaxceron<EMAIL_ADDRESS>Restructured CLI documentation included in Completing advanced tasks to the following hierarchy:
Using environment variables

Using environment variables
Formatting environment variables
Setting environment variables in an automation server
Using the prompt feature
Writing scripts

@gejohnston @zFernand0  -- updated per team feedback

to publish the content


Pair code team

Make sure that there are no linter errors.
Make sure that you used correct GitHub flow.
Make sure that you documented your work in a professional way.
We included a screenshot of Template 1 for reference, but you should follow the template that you chose.
Make sure that:
Name field accepts up to 30 chars.
Email field accepts only emails.
Message field accepts up to 500 chars.
All fields have placeholder text.
All fields have the correct type.
A user cannot submit the form if one or more of the fields is empty.
Collect data by using the Formspree service.
In order to lay out the elements on the page you should use flexbox.
You don't need to implement any functionality that requires JavaScript.
You must stick to the design as much as possible (e.g., font, colors, images, text, margins) using the templates in Figma.
Implement the button interactions (enable, hover, etc.).

@bobb-Rob
we @ticoniq & @abdozayan12  worked on this repo with @tchasinga


 Anyway, the tests passed.

🚀 Deployed to staging by @iwiznia in version: 1.1.94-1 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


fix(selectableitem): remove cascading div styling

Signed-off-by: Machiko Yasuda<EMAIL_ADDRESS>Impact: minor
Type: bugfix|refactor

SelectableItem / SelectableList in Horizontal mode

Moved CSS styles from SelectableList down to the child, SelectableItem so that the styles only apply to the detail element, and not any other div that is in SelectableList.

Screenshots

Should look the same

Test cases

Test that isHorizontal lists look and work the same way: https://deploy-preview-407--stoic-hodgkin-c0179e.netlify.com/#!/AddressReview
Test this branch on projects that use the Component Library

Test instructions for an app that uses Component Library

Change package.json to:  "@reactioncommerce/components": "reactioncommerce/reaction-component-library#236-machikoyasuda-fix-horizwrap",
docker-compose up --build
Open the app and find somewhere where a horizontal SelectableList is used - often in AddressReview

🚀 Preview deployed
Built with commit 046ae4a45e1a42f14d42eb52ce8fe3e2dc9cab91
https://deploy-preview-407--stoic-hodgkin-c0179e.netlify.com

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Default required

Describe the PR
Added new option (defaultRequired) for swag init
Additional context
I ran into a problem that I have to put validate required next to each field. This is not very convenient when a lot of code has already been written and you have to add the same thing to the tags for each field. I decided that this option will help not only me, but also the community.
Also added the ability to add validate optional fields.
Please merge it)

@AndreyAndreevich I don't like the idea to have a switch that will turn all the generated documentation upside down, but it may be useful to lazy developers.
Please open an issue describing this feature so we can have evidence of this implementation.

@AndreyAndreevich we can't merge this due to conflicts.


Map interaction is blocked when HTML Elements are clicked

Describe the bug
!! This issue is related to the latest build v2.0.0-alpha.6 from the fork of @tafelnl !!
when the map is initialized, any native element of the map can be interacted with. however, as soon as an HTML element like fab-button, menu, modal etc. is clicked, interaction with the map is blocked.
Furthermore a slight input lag is noticeable after interacting with html.

on ion-fab buttons this only occurs when you long press on it. Short press works.
on ion-modal click (click the "+" ion-fab-button to open modal) on ion-header or ion-content will block the interaction. completely. But if you first open the modal, then interact with the map behind and then with ion-modal, the map will work still.
the same behaviour of ion-modal also goes for the sidemenu.

To Reproduce
link to repo:
https://github.com/DwieDima/capacitor-maps-example
Expected behavior
interaction should also be possible after clicking on html elements with no input lag.
Screenshots
interaction works with modal, when map is clicked first

interaction breaks with modal, when modal is clicked first

interaction breaks on sidemenu

Additional context

IOS

We also have this some times. We could not reproduce it very reliably, sometimes it starts working again (e.g. after clicking the "my location" button). It seems to be a bit random. But since it's code, it most probably isn't. But we just could not reproduce it the exact same way every time, it always differs a little. What about you?

This happens to me every time I follow the steps described above.
Clicking on the mylocation button won't fix it on my side. I have to restart the app.

@tafelnl i managed to get a workaround for this by adding ontouchstart event listerner for the div container after map is initialized.

      element.ontouchstart = function (ev) {
        CapacitorGoogleMaps.updateMap({
          mapId: result.googleMap.mapId,
        });
      };

on the first tap, there is still a input lag, but the interaction works

@DwieDima Could you try using my implementation, because I think this is a problem on how the custom view is implemented. I know that this is not the @tafelnl fork but maybe we can a find a solution there to fix this.

@va2ron1 wow, it works here as expected and very smoothly! (modal lag is from bad recording)
No issues like before, no input lag, no blocking after clicking on HTML elements.
@tafelnl maybe this would be worth to be reviewed?

Awesome. Definitely going to take a look at it (I am on my phone right now). Could you explain the difference between our and your implementation @va2ron1 ? And has yours any cons? Or is it just better haha

@tafelnl Honestly I have not fully tested your implementation, apart from a few lines that are fixes for Ionic, I think that both has pro and cons. In my implementation I replaced the bridged view a custom view with the webView and the mapView and I used both views has reference to return the correct view in the hitTest. Your implementation just add the mapView to the webView and that is really a problem.
// this is the same as
self.bridge?.viewController?.view = self.bridge?.viewController?.webView
// So, this is adding the mapView inside the webView
self.bridge?.viewController?.view.addSubview(customMapView.view)

Ahh I think I understand now. So a con of your implementation would be that other plugins/libraries/ capacitor itself, might not have the correct reference for the viewcontroller anymore (since its now the CustomMapView is assigned to it instead). I wonder if that could actually break something in practice. Did you encounter scenarios where it did break something?

I can’t say, I haven’t used a lot of plugins with Capacitor like I used to with Cordova and my current project with this plugin I haven’t found any issue.

Will try it out. Does this have support for multiple maps being created? Because when a new map is created, it overwrites the viewcontroller right?

Awesome! I took a quick peek at it already and it looks really good. I'll see if I can test and merge this soon!

@va2ron1 Would it be possible to have support for multiple map instances at the same time?
Btw, I cleaned some commits and did some rebases. So all your changes are now present on this branch: https://github.com/DutchConcepts/capacitor-google-maps/commits/feat/ios-mapview-behind-webview

@tafelnl I made a few changes and now support multiple map instances
https://github.com/va2ron1/capacitor-googlemaps-native/tree/development/ios
Note: This assume that you called CapacitorGoogleMaps.initialize per view/page.
A Better Solution Could Be: Reset the map views when the view/page change, but I tried a few things and I didn't get any results. Also Capacitor has this shouldOverrideLoad and there we can know the current URL and if it change, reset the custom map views, but I get the same URL with/without a Framework.

@tafelnl Since you mentioned. I added custom marker icon on Android, doesn't have cache like iOS.
https://github.com/va2ron1/capacitor-googlemaps-native/tree/development/android

@va2ron1 @tafelnl I'd like to test this fix out on iOS and it's not clear which repo and branch I should be using. Please advise. Thank you!

@jjozwiak At some point, everything will be in main repo, is being prepared to be published. For now, is here.

@va2ron1 Got it working. This is great. Thanks for your work on this!

@tafelnl this branch doesn't have all the commits from this pull request.
Otherwise, using all the corresponding commits, the examples from this branch didn't work as expected and is because the pixel validation in the hitTest has the wrong point, need to be changed from convertedPoint to point
I would made and submit the change but I don't know to what branch or repo.

Thanks for your help. Was able to get it to work now :dancing_women: And it works superb :+1:
I updated the feat/ios-mapview-behind-webview branch with the correct commits. I removed the ability to add a custom background to the scrollview as it is not in the scope of this project right now. (unless it breaks something of course, but as far as I could understand and test, it doesn't).
Also I added a new example in which it is all working here.
Only thing that's still causing issues, is when a certain div overflows and thus enables scrolling for that div. When that div gets scrolled on top of an already existing mapview instance, the touch gets delegated to the mapview, instead of the div that's in front of it. I made an example for this as well here.

I found the problem with the way I did it. In simple words the view I'm getting is the view from the web as it is, because of that the size of the view is not same size as the screen and the point I'm getting doesn't have the scroll offset on it and the pixel color take the wrong spot. There're other ways to do this but Capacitor limit us by not wrapping the WKWebView.
Having all the map views inside the WebView make things more harder to find the better solution.
My solution was to use WKContentView that only contains the HTML Elements and get the right pixel, this view is always the subview at index 0 without the map views but I'm assuming that the api from WKWebView will be always like that in case that change this will break.
The changes are here. I also tested it with all the examples.

Awesome. I cherry picked your commit into the upstream branch. Will test it soon!

Works like a charm now! Thanks @va2ron1
I merged your commits to the next branch in #144. Will close this issue now.


[BEAM-242] Set javadoc less strict around missing return or param sta…

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[X] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[X] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[X] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[X] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

…tements

LGTM. Will merge as soon as CI passes.


Set up Speckle Ribbon

Set up the Revit plugin so it creates its own Speckle ribbon tab and any required panels inside it.

@radumg since (I think) SpeckleRevit will be the one button, do we really need it's own Ribbon panel? Should it not go in the 'Add-Ins' panel? Don't know what is expected from Revit users.

For one button the Add-Ins ribbon is better suited, that's usually where people look first, too.
It could be placed in an ootb tab as well, e.g. "Collaborate" but I am not sure this is intended use and it will be a bit trickier to program as those are for Autodesk functionalities.


update can-i-use-lite library for browserslist

small package lock change

Merging in - small package lock change and avoids console warnings about the outdated db


Allow disabling basic authentication for shoot clusters

What this PR does / why we need it:
It is now possible to disable basic authentication for shoot clusters by setting .spec.kubernetes.kubeAPIServer.enableBasicAuthentication=false. This required the new VPN 0.16.0 version that supports that the vpn-seed can authenticate via a client certificate against the shoot's kube-apiserver.
Consequently, independent of whether basic auth is enabled or not, the vpn-seeds now always use their client certificates.
Additionally, the liveness and readiness probes for the shoot kube-apiserver's no longer use basic auth credentials but a static token (that doesn't have any privileges at all, but it allows authenticating against the kube-apiserver to query the /healthz endpoint).
Special notes for your reviewer:

:warning: This PR depends on #1339 which needs to be merged first.
To see only the relevant changes for this feature please see https://github.com/gardener/gardener/commit/7bc2396e757f31aa4f9e38c2bc4de46d22158147.
Along the way I moved the monitoring and logging related functions into their own .go files in the botanist package.

/cc @holgerkoser @grolu @petersutter @vasu1124 @vlerenc @ccwienk @ThormaehlenFred
Release note:

It is now possible to disable basic authentication for shoot clusters by setting `.spec.kubernetes.kubeAPIServer.enableBasicAuthentication=false`. By default, basic authentication is still enabled for all shoots.

Rebased after merge of #1339. PTAL :)

Thanks for the review, I addressed the suggestions. PTAL again :)


Closes #38 by providing a definition file

Adds a definition file for the oasgraph API. It cannot use /types/Options.ts as this has some fields marked as mandatory and they are not.
I am not positive how the npm package is built for this project so this might not be in strictly the right place, but hopefully it is of some use or a basis for further discussion on this issue.

@treffynnon Hey, thank you for this contribution! This is fantastic. It will definitely improve the lives of TypeScript developers using OASGraph.
However, after discussing it with my colleague @ErikWittern, we believe the best way to move forward is to auto-generate the definition file using the Typescript declaration compiler option. We are also going address issues with the Options type, as you have already started.
Please do not take this the wrong way! We will not accept this pull request but your contribution is highly appreciated! We are simply going to take a slightly different method of addressing these issues. Thank you once again and keep an eye out for the next commit!

That's great news. I just wanted to prompt discussion and generating a
declaration is far better. Please tag a new release with the definitions
soon :)
On Wed., 27 Feb. 2019, 05:19 Alan Cha<EMAIL_ADDRESS>wrote:

Closed #113 https://github.com/strongloop/oasgraph/pull/113.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/strongloop/oasgraph/pull/113#event-2165888642, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAD-v9OdiGBgac-awwomSKTCkDITZBQ1ks5vRYiwgaJpZM4bRlgu
.

@treffynnon OASGraph v0.14.1, which has Typescript declaration files, is official out! 🎉

Perfect! I've deleted my custom types/declarations and using the package supplied one already. Thank you.


Errors building version 18.08 GUI using MSVC 15.8.2

This happened with version 18.05 also.  I simply download, decompressed, and loaded the solution.  Are there more steps?

This is all in one for most people (e.g. people wanting to compile the CLI, Linux users as they have dependencies in their distro directly...), but not for people wanting GUI and on Windows.
You need wxWidgets.
No plan to add it to the download as it is big and useless for most people, but maybe adding some info for Windows users wanting the GUI is better.

Thank you!  Now, I've downloaded the WxWidgets into its own folder external to my Mediainfo, built it and successfully ran the sample there.  Some instructions on how to incorporate it into MediaInfo project would help when there's time (see my UserName).


supabase start not respecting local .temp service versions

Describe the bug
supabase start is ignoring the local services version config.
To Reproduce

Run supabase link and link to porject
Run supabase start
Get issue

Expected behavior
supabase start runs the correct container version.
Screenshots

System information

Version of CLI: 1.142.1
Versions of services: [from supabase services command]

This works with v1.136.2


Update to cli to match newest code and readme standards

Just an update to align to all the learnings we've had with future implementations.

FYI @henrymbuguakiarie for the updates!


0.3.0 documentation changes

A to-be-improved list of things to document for the upcoming 0.3.0, with links to possible documentation when available:

[x] Admin API

[x]  New routes to document in the sidebar, /plugins_configurations should be considered deprecated in favour of /apis/{api}/plugins mashape/kong#257
[x] Update the tutorials to use the new routing (/apis/{api}/plugins and /consumer/{consumer}/keyauth) which will stop confusing users about the famous "API_ID" as a form parameter.
[x] It now supports application/json Content Type. mashape/kong#236
[x] It now supports PUT calls. mashape/kong#236

[ ] Proxy

[ ] Support for path routing. mashape/kong#282
[ ] Support for alternate Host header: X-Host-Override. mashape/kong#246
[x] Headers sent to the upstream server when using authentication plugins

[x] Plugins

[x] HTTP logging docs. mashape/kong#244
[x] File logging has a new option to specify a path to a file. mashape/kong#202
[x] Document the SSL plugin, and SSL features. mashape/kong#254
Document the Analytics plugin. mashape/kong#272
[x] Document the response transformations plugin.
[x] Document the request size limiting plugin

[ ] Chore

[ ] Document that openresty must be patched in the Source install for SSL support

Not related to 0.3.0, but still missing

[x] Document the default logging format.
[ ] Document how the proxy layer works. #80 Also related to the new path routing and the new X-Host-Override header.

Size payload plugin?

Who removed the important comments that were posted below this? With the summary of how to document the Proxy layer? -_-

#80 + #89


Potential approaches for performance improvements in cftime.num2date

Issue
While debugging a user issue, a performance limitation of cftime.num2date was put in sharp relief in pydata/xarray#6284.  Essentially num2date gets slower the farther the encoded times are from their reference date.  We sort of knew about this when we adopted the new decoding algorithm in #176, but it didn't seem that serious until we encountered an array with 15+ million times.  Arrays of times that large are admittedly rare, but it could be good to explore some options for improving the performance of num2date, since, as suggested by @rabernat and as I show below, there is some room for improvement.
A minimal example that illustrates this performance issue is the following:
In [1]: import cftime; import numpy as np

In [2]: encoded_times = 365 * 2000 + np.linspace(0, 30, 10000)

In [3]: %timeit cftime.num2date(encoded_times, "days since 0001-01-01", "proleptic_gregorian")
3.21 s ± 34.1 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

If we bring the reference date closer to the encoded times, we obtain an over 250x speedup.
In [4]: encoded_times = np.linspace(0, 30, 10000)

In [5]: %timeit cftime.num2date(encoded_times, "days since 1999-09-04", "proleptic_gregorian")
11.5 ms ± 142 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

This example uses 10,000 times, and even there 3 seconds is slow.  With 15 million times, it would take over an hour.  With a better reference date, however, 15 million times would take about 15 seconds (still slow, but bearable).
Possible solutions
@rabernat suggested two potential performance optimizations that seem fairly natural to try:

One possible performance optimization you could make in cftime.num2date would be to use the true reference date just for the first value of the times arrray. Then you could say times_delta = times - times[0] (re-reference everything to the first timestep) and update the reference date accordingly. Going even further, you could imagine computing each time relative as a timedelta relative to the previous timestep.

Results
I implemented these locally -- along with a couple more possible optimizations -- and did some profiling.  There are a few use-cases to consider when profiling.  For each of these, to emphasize the original issue, I used a distant reference date.   I implemented these in a branch and ran the profiling script in this gist to generate these results (note for simplicity for now I did not cover all edge cases involving zero-size or masked arrays).  The example above corresponds with the "Ordered narrow" case.  These are all for 10,000 times.

Ordered narrow
Ordered long
Unordered narrow
Unordered long

Existing
3390 ms
5780 ms
3350 ms
5420 ms

Rebase times using first date
12.7 ms
2510 ms
12.9 ms
1450 ms

Rebase times using median_low date
12.6 ms
1270 ms
13.1 ms
1170 ms

Iterate using relative timedeltas without sorting
14.4 ms
15.7 ms
15.3 ms
1550 ms

Iterate using relative timedeltas with sorting
15.1 ms
16.3 ms
16.4 ms
15 ms

Rebasing the times either using the first date of the array or the median date works well for arrays with narrow time ranges, but does not do as well for arrays that span a long range of times.  Not surprisingly, sorting is required to get the best performance with the iterative relative timedelta approach in the case of an unordered long time range array.  Note even in the sorting case I am careful to restore the original order of the times, so that is factored into the performance as well.
In summary, I think the iterative approach that sorts and then restores the order of the original dates provides consistently good performance, though it is not necessarily the fastest approach for every use case.  If this all makes sense, I can try and sort out the edge cases and put together a cleaned up PR that implements this optimized approach.
cc: @dcherian
(Updated the "Unordered long" case to cover a similar span of time to the "Ordered long" case -- previously it did span as much time).

Wow, those are some pretty impressive speed-ups!  Please do submit a PR.

Great!  See #270 for the PR.

Closed by #270.


updated field handling of audio start and blocksize

This was still being handled in a separate if/else block for the field. That API (for the audio at least) is now the same for all platforms. So this could be removed.

this got fixed twice


QueryException

Hi there,
I have a problem with storage method and your pacake.
This is my Album model:
<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

use Dimsav\Translatable\Translatable;

class Album extends Model
{
    use Translatable;

    protected $table = 'albums';

    public $translatedAttributes = [
        'name',
        'intro',
        'description',
        'slug',
    ];

    protected $fillable = [
        'name',
        'intro',
        'description',
        'slug',
    ];

}

This is my AlbumTranslation model:
<?php

namespace App;

use Spatie\Sluggable\HasSlug;
use Spatie\Sluggable\SlugOptions;

use Illuminate\Database\Eloquent\Model;

class AlbumTranslation extends Model
{
    use HasSlug;

    public $timestamps = false;

    protected $fillable = [
        'name',
        'intro',
        'description',
        'slug',
    ];

    /**
     * Get the options for generating the slug.
     */
    public function getSlugOptions() : SlugOptions
    {
        return SlugOptions::create()
            ->generateSlugsFrom('name')
            ->saveSlugsTo('slug')
            ->doNotGenerateSlugsOnUpdate();
    }
}

And this is my store method:
<?php
...
    public function store(Request $request)
    {
        $this->validate($request, [
            'name'        => 'required',
            'description' => 'required',
        ]);

        $album = new Album;

        $album->translateOrNew('en')->name        = $request->name;
        $album->translateOrNew('en')->description = $request->description;
        $album->save();
    }

Output:
 // (2/2) QueryException
SQLSTATE[HY000]: General error: 1364 Field 'name' doesn't have a default
value (SQL: insert into `albums` (`cover_image`, `updated_at`, `created_at`)
values (this-is-an-awesome-album.png, 2017-06-23 01:32:48, 2017-06-23 01:32:48))

And:
(1/2) PDOException
SQLSTATE[HY000]: General error: 1364 Field 'name' doesn't have a default value

Any help with this? :smiley:

@abr4xas it seems that $request->name is empty, you should either validate the request, or if empty name is allowed, just make the name column nullable

@krecebli no, $request->name is filled

@abr4xas maybe you also have the name column in albums table? If yes, drop it or make nullable.

@krecebli, I do not understand, the fields to translate should only be in my model AlbumTranslation ?

@abr4xas yes, otherwise they may conflict

@krecebli oh... That's my problem. Thanks !!

@abr4xas welcome :)


Add votes download as csv

Fixes Issue https://github.com/snapshot-labs/snapshot/issues/3138

Yes. I've been thinking it for a while. To me it's acceptable I put the download button as POAP does https://poap.gallery/event/62252  or hide the button in the three dot dropdown list since this is also a functional feature of the proposal

@bonustrack @hjjlxm any thoughts?

Looks great with the icon in top right, we should add a loading indicator when trying to download the CSV, sometime it can take long for example on this proposal: https://snapshot-jj2fxidij-snapshot.vercel.app/#/ens.eth/proposal/0xd810c4cf2f09737a6f833f1ec51eaa5504cbc0afeeb883a21a7e1c91c8a597e4

@bonustrack yep it already has loading

@samuveth Ok great I can see the loading now. Can we sort vote by voting power? Also I'm not able to import a CSV properly, it break in some field somehow, does it work for you?

@bonustrack okay changed to sorted by balance although I think sorted by timestamp also makes sense inside a sheet. For the fields breaking I can't reproduce here is a screenshot from google sheets

Can you change "balance" to "voting_power" or "vp"? balance assume you holding something like a token, but its not always the case.


Unable to use custom scalar with this starter

I'm following the documentation on custom scalars from packages and trying to add the JSON scalar to the grand-stack-starter. I am getting an error whenever I try to start the api:
Error: Type "JSON" not found in document.
    at ASTDefinitionBuilder._resolveType (/app/node_modules/graphql/utilities/buildASTSchema.js:134:11)

The only changes I made to the starter are those outlined in the docs: added a scalar JSON to the schema and a new resolver:
schema.graphql
scalar JSON

type Foo {
  aField: JSON
}

type User {
  id: ID!
  name: String
  friends: [User] @relation(name: "FRIENDS", direction: "BOTH")
  reviews: [Review] @relation(name: "WROTE", direction: "OUT")
  avgStars: Float @cypher(statement: "MATCH (this)-[:WROTE]->(r:Review) RETURN toFloat(avg(r.stars))")
  numReviews: Int @cypher(statement: "MATCH (this)-[:WROTE]->(r:Review) RETURN COUNT(r)")
}

type Business {
  id: ID!
  name: String
  address: String
  city: String
  state: String
  reviews: [Review] @relation(name: "REVIEWS", direction: "IN")
  categories: [Category] @relation(name: "IN_CATEGORY", direction: "OUT")
}

type Review {
  id: ID!
  stars: Int
  text: String
  business: Business @relation(name: "REVIEWS", direction: "OUT")
  user: User @relation(name: "WROTE", direction: "IN")
}

type Category {
  name: ID!
  businesses: [Business] @relation(name: "IN_CATEGORY", direction: "IN")
}

type Query {
    usersBySubstring(substring: String, first: Int = 10, offset: Int = 0): [User] @cypher(statement: "MATCH (u:User) WHERE u.name CONTAINS $substring RETURN u")
}

graphql-schema.js
import { neo4jgraphql } from "neo4j-graphql-js";
import GraphQLJSON from 'graphql-type-json';
import fs from "fs";
import path from "path";

export const typeDefs = fs
    .readFileSync(
        process.env.GRAPHQL_SCHEMA || path.join(__dirname, "schema.graphql")
    )
    .toString("utf-8");

export const resolvers = {
    JSON: GraphQLJSON,
    Query: {
        usersBySubstring: neo4jgraphql
    }
};

What am I doing wrong here?

I'm also having the same issue. When using any of the 'Custom scalars' examples provided in Apollo's Graphql Tools docs, the Apollo Server crashes with a

Type "MyCustomScalar" not found in document

error (or similar):
[nodemon] starting `babel-node src/index.js`
/Users/myUser/GRAND/api/node_modules/graphql/utilities/buildASTSchema.js:134
    throw new Error('Type "' + typeRef.name.value + '" not found in document.');
    ^

Error: Type "MyCustomScalar" not found in document.
    at ASTDefinitionBuilder._resolveType (/Users/myUser/GRAND/api/node_modules/graphql/utilities/buildASTSchema.js:134:11)
    at ASTDefinitionBuilder.buildType (/Users/myUser/GRAND/api/node_modules/graphql/utilities/buildASTSchema.js:218:79)
    at ASTDefinitionBuilder._buildWrappedType (/Users/myUser/GRAND/api/node_modules/graphql/utilities/buildASTSchema.js:227:24)
    at ASTDefinitionBuilder.buildField (/Users/myUser/GRAND/api/node_modules/graphql/utilities/buildASTSchema.js:248:18)
    at /Users/myUser/GRAND/api/node_modules/graphql/utilities/buildASTSchema.js:302:21
    at /Users/myUser/GRAND/api/node_modules/graphql/jsutils/keyValMap.js:28:31
    at Array.reduce (<anonymous>)
    at keyValMap (/Users/myUser/GRAND/api/node_modules/graphql/jsutils/keyValMap.js:27:15)
    at ASTDefinitionBuilder._makeFieldDefMap (/Users/myUser/GRAND/api/node_modules/graphql/utilities/buildASTSchema.js:299:49)
    at fields (/Users/myUser/GRAND/api/node_modules/graphql/utilities/buildASTSchema.js:284:23)
[nodemon] app crashed - waiting for file changes before starting...

I've been banging my head against this issue for about a week now. Any help would be appreciated.


New version: WestWind.MarkdownMonster version <IP_ADDRESS>

Checklist for Pull Requests

[X] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Hi @aisgbnok,
Does this package have another dependency?

Hmm, not that I know of. Testing in Sandbox (W11 - 22635.3930):

They only list .Net and WebView2 on their website:

https://markdownmonster.west-wind.com/download

@stephengillie
It looks like it is needed only if you use the Save to PDF feature.