[Bug]: Some bugs about Padim and PatchCore (or maybe it's just a problem I'm having)

Describe the bug
There are three problems in this submission, all of which I encountered while training my own dataset：
1: padim
When I use padim, I set padim's backbone to resnet18, and the program runs correctly and gets the results I want at this time.
I looked at the padim README.md and found that Padim performs even better when Backbone is Wide ResNet-50. So I modified the corresponding config.yaml of padim. But I only modified the backbone. as follows:
backbone: resnet18 ——>  backbone: wide_resnet50_2
I have downloaded the corresponding pre-training file correctly. After modifying it to Wide ResNet-50, padim will report an error directly after a period of training (or is it when the training is completed and validated? Please see my screenshot below for details) and it reports an error directly. I don't think this should be the case. When I use other models (e.g. fastflow, etc.), I just modify the backbone without modifying other parameters and the training is done correctly in the end.

Q1: So my first question is: why is this happening after modifying Padim's backbone network to Wide ResNet-50 and how should I fix it

2:patchcore
patchcore I got the onnx model correctly with the corresponding results when setting Backbone to Wide ResNet-50. But when I use OnnxRuntime to infer the model, it reports an error directly.
I can ensure that my code for inference using OnnxRuntime is correct, and I am using OnnxRuntime correctly to infer the Onnx model for some other methods provided by Anomalib. But only PatchCore is problematic, and its specific error message will be given later in the form of a screenshot.

Q2: So my second question is how should I properly use OnnxRuntime to reason about my PatchCore's corresponding Onnx model

3: How to calculate the confidence score
This is not a bug, just a question I have. I checked how the final confidence score is calculated in the source code section, but I'm still confused.
As you can see, in the Prediction corresponding result graph, normal(59%) is clearly shown in the top left corner:

I would like to know what I should do when I use OnnxRuntime to rewrite the inference part myself, instead of using one of the four inference programs provided by Anomalib。
Q3: So my third question is: when I write my own program with OnnxRuntime (GPU) reasoning, how should I get the "normal" or "abnormal" judgments and how should I calculate the corresponding confidence score. It would be great if you could provide me with a demo of this, because I am new to this, so it might be difficult to implement the program based on some hints.

Thank you very much for seeing this, the problem is relatively long delayed too long, I hope to get your guidance, thank you very much!
Dataset
Other (please specify in the text field below)
Model
PatchCore
Steps to reproduce the behavior
Pytorch :                 1.12.1+Cu113
GPU:                        RTX2080Ti
onnx:                        1.12.0
onnxruntime-gpu:   1.14.1
CUDA:                      11.3
OS: win10
CPU: Intel Core i7-8700K
Expected behavior
I would appreciate suggestions and solutions for problem 1, problem 2 and problem 3. Thank you very much, because my native language is not English, I may not be accurate, I hope you will understand more, thank you again!
Screenshots
1: Specific information on training errors when Padim sets backbone to wide_ResNet50_2
I was concerned that the screenshot related to question 1 might not have all the information, so I printed out the log related to question 1. The screenshots related to question 2 and question 3 are clear, so I won't repeat them here

| Name                  | Type                     | Params
0 | image_threshold       | AnomalyScoreThreshold    | 0
1 | pixel_threshold       | AnomalyScoreThreshold    | 0
2 | model                 | PadimModel               | 24.9 M
3 | image_metrics         | AnomalibMetricCollection | 0
4 | pixel_metrics         | AnomalibMetricCollection | 0
5 | normalization_metrics | MinMax                   | 0
24.9 M    Trainable params
0         Non-trainable params
24.9 M    Total params
99.450    Total estimated model params size (MB)
Epoch 0:   6%|▋         | 1/16 [00:18<04:31, 18.09s/it, loss=nan]C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\loops\optimization\optimizer_loop.py:138: UserWarning: training_step returned None. If this was on purpose, ignore this warning...
self.warning_cache.warn("training_step returned None. If this was on purpose, ignore this warning...")
Epoch 0:  75%|███████▌  | 12/16 [00:18<00:06,  1.57s/it, loss=nan]
2023-04-26 17:48:24,493 - anomalib.models.padim.lightning_model - INFO - Aggregating the embedding extracted from the training set.
Validation: 0it [00:00, ?it/s]2023-04-26 17:48:24,712 - anomalib.models.padim.lightning_model - INFO - Fitting a Gaussian to the embedding collected from the training set.
Validation:   0%|          | 0/4 [00:00<?, ?it/s]
Validation DataLoader 0:   0%|          | 0/4 [00:00<?, ?it/s]
Epoch 0:  81%|████████▏ | 13/16 [01:07<00:15,  5.22s/it, loss=nan]
Epoch 0:  88%|████████▊ | 14/16 [01:08<00:09,  4.88s/it, loss=nan]
Epoch 0:  94%|█████████▍| 15/16 [01:08<00:04,  4.60s/it, loss=nan]
Epoch 0: 100%|██████████| 16/16 [01:09<00:00,  4.36s/it, loss=nan, image_F1Score=0.480, image_AUROC=0.793]
C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\torchmetrics\utilities\prints.py:36: DeprecationWarning: torchmetrics.functional.auc has been move to torchmetrics.utilities.compute in v0.10 and will be removed in v0.11.
warnings.warn(*args, **kwargs)
Epoch 0: 100%|██████████| 16/16 [01:09<00:00,  4.36s/it, loss=nan, image_F1Score=0.480, image_AUROC=0.793]Traceback (most recent call last):
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\torch\serialization.py", line 379, in save
_save(obj, opened_zipfile, pickle_module, pickle_protocol)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\torch\serialization.py", line 604, in _save
zip_file.write_record(name, storage.data_ptr(), num_bytes)
MemoryError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\torch\serialization.py", line 380, in save
return
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\torch\serialization.py", line 259, in exit
self.file_like.write_end_of_file()
RuntimeError: [enforce fail at C:\actions-runner_work\pytorch\pytorch\builder\windows\pytorch\caffe2\serialize\inline_container.cc:319] . unexpected pos 98176448 vs 98176336
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "D:/MyCode/4_HC/Time/202304/Anomalib_Seg/anomalib-main/tools/train.py", line 76, in
train()
File "D:/MyCode/4_HC/Time/202304/Anomalib_Seg/anomalib-main/tools/train.py", line 61, in train
trainer.fit(model=model, datamodule=datamodule)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 608, in fit
call._call_and_handle_interrupt(
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\trainer\call.py", line 38, in _call_and_handle_interrupt
return trainer_fn(*args, **kwargs)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 650, in _fit_impl
self._run(model, ckpt_path=self.ckpt_path)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 1112, in _run
results = self._run_stage()
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 1191, in _run_stage
self._run_train()
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 1214, in _run_train
self.fit_loop.run()
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\loops\loop.py", line 200, in run
self.on_advance_end()
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\loops\fit_loop.py", line 295, in on_advance_end
self.trainer._call_callback_hooks("on_train_epoch_end")
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 1394, in _call_callback_hooks
fn(self, self.lightning_module, *args, **kwargs)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\callbacks\model_checkpoint.py", line 304, in on_train_epoch_end
self._save_topk_checkpoint(trainer, monitor_candidates)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\callbacks\model_checkpoint.py", line 363, in _save_topk_checkpoint
self._save_none_monitor_checkpoint(trainer, monitor_candidates)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\callbacks\model_checkpoint.py", line 669, in _save_none_monitor_checkpoint
self._save_checkpoint(trainer, filepath)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\callbacks\model_checkpoint.py", line 366, in _save_checkpoint
trainer.save_checkpoint(filepath, self.save_weights_only)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 1939, in save_checkpoint
self._checkpoint_connector.save_checkpoint(filepath, weights_only=weights_only, storage_options=storage_options)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\trainer\connectors\checkpoint_connector.py", line 511, in save_checkpoint
self.trainer.strategy.save_checkpoint(_checkpoint, filepath, storage_options=storage_options)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\pytorch_lightning\strategies\strategy.py", line 466, in save_checkpoint
self.checkpoint_io.save_checkpoint(checkpoint, filepath, storage_options=storage_options)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\lightning_fabric\plugins\io\torch_io.py", line 54, in save_checkpoint
_atomic_save(checkpoint, path)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\lightning_fabric\utilities\cloud_io.py", line 67, in _atomic_save
torch.save(checkpoint, bytesbuffer)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\torch\serialization.py", line 381, in save
_legacy_save(obj, opened_file, pickle_module, pickle_protocol)
File "C:\ProgramData\anaconda3\envs\HC_Anomalib\lib\site-packages\torch\serialization.py", line 225, in exit
self.file_like.flush()
ValueError: I/O operation on closed file.
进程已结束,退出代码-1073740791 (0xC0000409)
Pip/GitHub
pip
What version/branch did you use?
latest
Configuration YAML
Same as the official Yaml, only the dataset part has been replaced with its own dataset

Logs
None

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Thanks for your patience @laogonggong847. I'll try to reply to your questions one by one.
Padim Training with WideResNet-50
I'm unfortunately unable to reproduce this.  When I use the default settings by just changing the backbone to wide_resnet50_2, I can train the model. Can you share your config file. For the record, here is my output after the training:
python tools/train.py --model padim
/home/sakcay/Projects/anomalib/src/anomalib/config/config.py:280: UserWarning: config.project.unique_dir is set to False. This does not ensure that your results will be written in an empty directory and you may overwrite files.
  warn(
Global seed set to 42
2023-08-11 07:15:33,911 - anomalib.data - INFO - Loading the datamodule
2023-08-11 07:15:33,911 - anomalib.data.utils.transform - INFO - No config file has been provided. Using default transforms.
2023-08-11 07:15:33,911 - anomalib.data.utils.transform - INFO - No config file has been provided. Using default transforms.
2023-08-11 07:15:33,912 - anomalib.models - INFO - Loading the model.
2023-08-11 07:15:33,912 - anomalib.models.components.base.anomaly_module - INFO - Initializing PadimLightning model.
/home/sakcay/.local/lib/python3.10/site-packages/torchmetrics/utilities/prints.py:36: UserWarning: Metric `PrecisionRecallCurve` will save all targets and predictions in buffer. For large datasets this may lead to large memory footprint.
  warnings.warn(*args, **kwargs)
2023-08-11 07:15:33,916 - anomalib.models.components.feature_extractors.timm - WARNING - FeatureExtractor is deprecated. Use TimmFeatureExtractor instead. Both FeatureExtractor and TimmFeatureExtractor will be removed in a future release.
2023-08-11 07:15:35,087 - timm.models.helpers - INFO - Loading pretrained weights from url (https://github.com/rwightman/pytorch-image-models/releases/download/v0.1-weights/wide_resnet50_racm-8234f177.pth)
2023-08-11 07:15:35,549 - anomalib.utils.loggers - INFO - Loading the experiment logger(s)
2023-08-11 07:15:35,550 - anomalib.utils.callbacks - INFO - Loading the callbacks
/home/sakcay/Projects/anomalib/src/anomalib/utils/callbacks/__init__.py:142: UserWarning: Export option: None not found. Defaulting to no model export
  warnings.warn(f"Export option: {config.optimization.export_mode} not found. Defaulting to no model export")
2023-08-11 07:15:35,561 - pytorch_lightning.utilities.rank_zero - INFO - GPU available: True (cuda), used: True
2023-08-11 07:15:35,561 - pytorch_lightning.utilities.rank_zero - INFO - TPU available: False, using: 0 TPU cores
2023-08-11 07:15:35,561 - pytorch_lightning.utilities.rank_zero - INFO - IPU available: False, using: 0 IPUs
2023-08-11 07:15:35,561 - pytorch_lightning.utilities.rank_zero - INFO - HPU available: False, using: 0 HPUs
2023-08-11 07:15:35,561 - pytorch_lightning.utilities.rank_zero - INFO - `Trainer(limit_train_batches=1.0)` was configured so 100% of the batches per epoch will be used..
2023-08-11 07:15:35,561 - pytorch_lightning.utilities.rank_zero - INFO - `Trainer(limit_val_batches=1.0)` was configured so 100% of the batches will be used..
2023-08-11 07:15:35,561 - pytorch_lightning.utilities.rank_zero - INFO - `Trainer(limit_test_batches=1.0)` was configured so 100% of the batches will be used..
2023-08-11 07:15:35,561 - pytorch_lightning.utilities.rank_zero - INFO - `Trainer(limit_predict_batches=1.0)` was configured so 100% of the batches will be used..
2023-08-11 07:15:35,561 - pytorch_lightning.utilities.rank_zero - INFO - `Trainer(val_check_interval=1.0)` was configured so validation will run at the end of the training epoch..
2023-08-11 07:15:35,561 - anomalib - INFO - Training the model.
2023-08-11 07:15:35,664 - anomalib.data.mvtec - INFO - Found the dataset.
2023-08-11 07:15:35,685 - pytorch_lightning.utilities.rank_zero - INFO - You are using a CUDA device ('NVIDIA GeForce RTX 3090') that has Tensor Cores. To properly utilize them, you should set `torch.set_float32_matmul_precision('medium' | 'high')` which will trade-off precision for performance. For more details, read https://pytorch.org/docs/stable/generated/torch.set_float32_matmul_precision.html#torch.set_float32_matmul_precision
/home/sakcay/.local/lib/python3.10/site-packages/torchmetrics/utilities/prints.py:36: UserWarning: Metric `ROC` will save all targets and predictions in buffer. For large datasets this may lead to large memory footprint.
  warnings.warn(*args, **kwargs)
/home/sakcay/.local/lib/python3.10/site-packages/pytorch_lightning/callbacks/model_checkpoint.py:613: UserWarning: Checkpoint directory /home/sakcay/Projects/anomalib/results/padim/mvtec/bottle/run/weights/lightning exists and is not empty.
  rank_zero_warn(f"Checkpoint directory {dirpath} exists and is not empty.")
2023-08-11 07:15:36,684 - pytorch_lightning.accelerators.cuda - INFO - LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0,1]
/home/sakcay/.local/lib/python3.10/site-packages/pytorch_lightning/core/optimizer.py:183: UserWarning: `LightningModule.configure_optimizers` returned `None`, this fit will run with no optimizer
  rank_zero_warn(
2023-08-11 07:15:36,688 - pytorch_lightning.callbacks.model_summary - INFO -
  | Name                  | Type                     | Params
-------------------------------------------------------------------
0 | image_threshold       | AnomalyScoreThreshold    | 0
1 | pixel_threshold       | AnomalyScoreThreshold    | 0
2 | model                 | PadimModel               | 24.9 M
3 | image_metrics         | AnomalibMetricCollection | 0
4 | pixel_metrics         | AnomalibMetricCollection | 0
5 | normalization_metrics | MinMax                   | 0
-------------------------------------------------------------------
24.9 M    Trainable params
0         Non-trainable params
24.9 M    Total params
99.450    Total estimated model params size (MB)
Epoch 0:   0%|                                                                                | 0/10 [00:00<?, ?it/s]/home/sakcay/.local/lib/python3.10/site-packages/pytorch_lightning/loops/optimization/optimizer_loop.py:138: UserWarning: `training_step` returned `None`. If this was on purpose, ignore this warning...
  self.warning_cache.warn("`training_step` returned `None`. If this was on purpose, ignore this warning...")
Epoch 0:  70%|████████████████2023-08-11 07:15:39,024 - anomalib.models.padim.lightning_model - INFO - Aggregating the embedding extracted from the training set.dation: 0it [00:00, ?it/s]
2023-08-11 07:15:39,176 - anomalib.models.padim.lightning_model - INFO - Fitting a Gaussian to the embedding collected from the training set.
Epoch 0: 100%|█████████████████████████████████████████████████████████████| 10/10 [00:31<00:00,  3.13s/it, loss=nan, pixel_F1Score=0.705, pixel_AUROC=0.983]2023-08-11 07:16:12,716 - pytorch_lightning.utilities.rank_zero - INFO - `Trainer.fit` stopped: `max_epochs=1` reached.
Epoch 0: 100%|█████████████████████████████████████████████████████████████| 10/10 [00:36<00:00,  3.60s/it, loss=nan, pixel_F1Score=0.705, pixel_AUROC=0.983]
2023-08-11 07:16:12,846 - anomalib.utils.callbacks.timer - INFO - Training took 36.16 seconds
2023-08-11 07:16:12,846 - anomalib - INFO - Loading the best model weights.
2023-08-11 07:16:12,846 - anomalib - INFO - Testing the model.
2023-08-11 07:16:12,850 - anomalib.data.mvtec - INFO - Found the dataset.
2023-08-11 07:16:12,850 - pytorch_lightning.utilities.rank_zero - INFO - You are using a CUDA device ('NVIDIA GeForce RTX 3090') that has Tensor Cores. To properly utilize them, you should set `torch.set_float32_matmul_precision('medium' | 'high')` which will trade-off precision for performance. For more details, read https://pytorch.org/docs/stable/generated/torch.set_float32_matmul_precision.html#torch.set_float32_matmul_precision
2023-08-11 07:16:12,851 - anomalib.utils.callbacks.model_loader - INFO - Loading the model from /home/sakcay/Projects/anomalib/results/padim/mvtec/bottle/run/weights/lightning/model-v2.ckpt
2023-08-11 07:16:14,951 - pytorch_lightning.accelerators.cuda - INFO - LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0,1]
Testing DataLoader 0: 100%|████████████████████████████████████████████████████████████████████████████████████████████████████| 3/3 [00:14<00:00,  4.85s/it]2023-08-11 07:16:30,522 - anomalib.utils.callbacks.timer - INFO - Testing took 15.568396091461182 seconds
Throughput (batch_size=32) : 5.331313483572217 FPS
Testing DataLoader 0: 100%|████████████████████████████████████████████████████████████████████████████████████████████████████| 3/3 [00:14<00:00,  4.91s/it]
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃        Test metric        ┃       DataLoader 0        ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│        image_AUROC        │    0.9976190328598022     │
│       image_F1Score       │    0.9919999837875366     │
│        pixel_AUROC        │    0.9825913310050964     │
│       pixel_F1Score       │    0.7047178745269775     │
└───────────────────────────┴───────────────────────────┘

I feel the issue could be related to something else.


Tooltip when hovering tool type icon

closes #10

I signed it!

@housseindjirdeh the centering of tooltip is not an easy thing to do, but we can do different styles for each position. So once the icons are stacked, we can display the tooltip on their left, once the icons are side by side we display the tooltip on top. What do you think?

@emersonlaurentino Ooh that's an option. 🤔
I think that might actually look better! But I don't want you to work on it if it's too much effort. If you would rather merge it the way it is, please let me know. Otherwise, definitely could be nice to have it show on the left when they're stacked vertically :)

@housseindjirdeh no problem, I will.

@housseindjirdeh Fixed the problem of the stacked icons and added a prop to the component tooltip called pointing to indicate where the tooltip should point.


User-Generated Tokens Causing Project Config Changes

I have a site running Craft CMS <IP_ADDRESS> and Patron 2.4.0. I've noticed something occurring that could cause problems, if I'm understanding the process correctly. As far as I'm able to tell, each time a user authorizes my site with an OAuth login, a Token is generated. That action also creates a new a Project Config YAML file for that new Token in the config/project/plugins/patron/tokens directory.
This would cause un-version-able Project Config changes to occur on the live environment, which I anticipate being difficult to work with. Every time a user authorizes the app on the live site, a new Token file will appear in the Project Config folder, which I will have no way of tracking and which may cause Project Config conflicts.
Is there some way to work around that issue or to disable a new file from being created for each token? Or I am missing something? Should I just gitignore that directory?
Thanks for your help and your time!

Hello,
I actually haven't used this in a manner where there are a lot of integration logins; primarily I use a single integration user which results in a token or two.  Not to say your use case is incorrect, I just haven't considered it before.
I suppose the best long term approach would be to set a flag to disable the tokens from being managed under project config.  I'll need to do some testing around this to make sure they use case works well, but I think that's the best direction.


Update CMakeLists to use GNUInstallDirs

Currently, installation targets are hardcoded to bin/lib etc... On PLATFORM_LINUX=1, GNUInstallDirs should be used instead.

I've merged your changes (with some refactoring in) internally, but my refactoring (mostly pushing all the repetitive changes in per-project CMakeLists.txt files into macros) has broken something and I haven't had a chance to dig further into it yet.  It may be a few weeks before I finish it up.

This has been merged in and it is working it's way through our CI.


PubSub Protobuf communication example

Can you please provide examples how to configure PubSub Protobuf communication as alternative for JacksonPubSubMessageConverter

Pub/Sub uses gRPC which is "Protobuf communication", regardless of the choice of the converter. The converter is only used to convert the message payload, but it still ends up being transferred in a protobuf. If you want to bypass all conversion, just use ByteString to represent your payload everywhere.
In any case, the short of it is that you are already using protobufs.


Uncaught TypeError: this.action.disposalAction is not a function

[Enter steps to reproduce:]

...
...

Atom: 1.40.0 x64
Electron: 3.1.10
OS: Mac OS X 10.14.6
Thrown From: autoclose package 0.0.2
Stack Trace
Uncaught TypeError: this.action.disposalAction is not a function
At /Users/leonardorochacouto/.atom/packages/autoclose/lib/autoclose.coffee:39

TypeError: this.action.disposalAction is not a function
    at Object._paneItemChanged (/packages/autoclose/lib/autoclose.coffee:39:29)
    at /packages/autoclose/lib/autoclose.coffee:26:8
    at Function.simpleDispatch (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:1209208)
    at Emitter.emit (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:1210649)
    at Workspace.didChangeActivePaneItemOnPaneContainer (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:424404)
    at WorkspaceCenter.paneContainer.onDidChangeActivePaneItem.t (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:14:44396)
    at Function.simpleDispatch (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:1209208)
    at Emitter.emit (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:1210649)
    at PaneContainer.didChangeActiveItemOnPane (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:446737)
    at Pane.setActiveItem (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:455581)
    at Pane.activateItem (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:457751)
    at TabBarView.onClick (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:1160295)

Commands
  3x -7:27.7.0 core:backspace (input.hidden-input)
     -7:24.8.0 core:save (input.hidden-input)
     -6:36.8.0 core:select-all (input.hidden-input)
     -6:36.4.0 core:backspace (input.hidden-input)
     -5:15.4.0 core:select-all (input.hidden-input)
     -5:14.3.0 core:copy (input.hidden-input)
     -5:02.2.0 core:paste (input.hidden-input)
     -5:00.5.0 core:save (input.hidden-input)
     -4:46.3.0 tree-view:copy-full-path (span.name.icon.icon-file-text)
  3x -3:22.6.0 core:backspace (input.hidden-input)
     -3:18.9.0 core:save (input.hidden-input)

Non-Core Packages
atom-beautify 0.33.4
atom-ternjs 0.20.0
autoclose 0.0.2
busy-signal 2.0.1
csslint 1.2.0
emmet 2.4.3
intentions 1.1.5
linter 2.3.1
linter-jshint 3.1.16
linter-ui-default 1.7.1

this red window keeps popping up everytime i click into a file tab in Atom

same, please help

My pull request (https://github.com/awaw00/autoclose/pull/16) from over a year ago fixed this issue, but it has not been merged into master. This error is simply due to the deprecation of dispoalAction. Just open autoclose.coffee and replace @action.disposalAction() with @action.dispose().


Add GetFileHash and VerifyFileHash tasks

Add tasks for computing the file hash and verifying an expected file hash using SHA256, SHA384, or SHA512. These tasks were originally part of aspnet/buildtools, then moved to dotnet/arcade. I've polished them up and added better tests/logging. I'm not set on the API names so let me know if there is a better MSBuild convention for the task and property names.
Resolves https://github.com/Microsoft/msbuild/issues/3369
cc @jeffkl

Updated with PR feedback.

Microsoft.Build.UnitTests.GetSDKReferenceFiles_Tests.GetSDKReferenceFilesTestFixture.VerifyReferencesLoggedX64

Test failure seems unrelated to my change. https://ci2.dot.net/job/Microsoft_msbuild/job/master/job/innerloop_Windows_NT_Full_prtest/597/testReport/junit/Microsoft.Build.UnitTests.GetSDKReferenceFiles_Tests/GetSDKReferenceFilesTestFixture/VerifyReferencesLoggedX64/
@dotnet-bot test Windows_NT Build for Full please

Are these tasks expensive enough to have them yield and reacquire the engine?

I'd imagine it depends on the size of the file.  I don't think it would be used to hash huge files, but perhaps it could check the file size and then yield?

Do we already have a good way to run benchmarks?

It's not easy yet to add arbitrary tests. Probably easiest way would be to create github repos where hashing / checking hook up in the design time build target graph. The you could create a couple of repos with increasing file size / number of files hashed.

But maybe it's only worth doing this when we actually observe slow run times. :)

I've updated with PR feedback.

Linux failures appear to be unrelated to my changes. Is this a known issue?
"/mnt/j/w/Microsoft_msbuild/master/innerloop_Ubuntu16.04_CoreCLR_prtest/artifacts/Debug/bootstrap/netcoreapp2.1/MSBuild/MSBuild.dll". Beginning retry 1 in 1000ms. The process cannot access the file '/mnt/j/w/Microsoft_msbuild/master/innerloop_Ubuntu16.04_CoreCLR_prtest/artifacts/Debug/bin/MSBuild.Bootstrap/publish/MSBuild.dll' because it is being used by another process. [/mnt/j/w/Microsoft_msbuild/master/innerloop_Ubuntu16.04_CoreCLR_prtest/src/MSBuild.Bootstrap/MSBuild.Bootstrap.csproj]

@dotnet-bot test Ubuntu16.04 Build for CoreCLR please

Linux failures appear to be unrelated to my changes. Is this a known issue?

I'll take a look if any fail on your latest commit

It must have just been flakiness. Re-running Ubuntu passed. But if you want to investigate that failure more, there's a link: https://ci2.dot.net/job/Microsoft_msbuild/job/master/job/innerloop_Ubuntu16.04_CoreCLR_prtest/619/


Unable to attach Team to a Component/Topology in Teams Spec

I am getting the following error:
{
    "code": "23505",
    "details": "Key (name, properties)=(team.update, {\"team_id\": \"01889ef8-1f09-d790-841d-e5c0b6f40ee9\"}) already exists.",
    "hint": null,
    "message": "duplicate key value violates unique constraint \"event_queue_name_properties\""
}

Spec Data:
components:
  - name: mission-control
    namespace: mission-control
    selector: app=mission-control

@mainawycliffe should be fixed now. Can you please test this one more time?


Add robustnerf mask to mipnerf360

To enable robustnerf the flag config.data_loss_type should be set to 'robustnerf'. If enabled the create_robustnerf_mask creates a mask that is multiplied to data_loss to enable ignoring parts of the scene. The mask is created based on a revolving percentile of the loss. Since the loss only gets aggregated in the main training loop, the current percentile is recorded in the stats and the aggregated loss_threshold is then passed to the train_steps.
The implementation is based on "RobustNerf: ignoring distractors with robust optimization".
This is a work in progress.
Passes all the tests in the default setting.

Just FYI there is a typo in config.py: enable_robutnerf_loss should be enable_robustnerf_loss. The other instances of this config flag seem fine though.

Thanks for the catch. I'll update shortly with robustnerf functionality updated.


term_start can't redirect input from file

My English is poor, so if I make any mistake, please forgive me.
I made a plugin to compile and run c++ source file, and I found that it doesn't work when I attemp to redirect the executable's input from a file. I tried with vim -u NONE -N, but it still didn't work.
The mininum code that can reproduce this issue:
call term_start('cat.exe', {'in_io': 'file', 'in_name': 'input.txt'})

In which cat.exe acts like cat on *nix.
I'm using Windows, and I didn't test this on other platform, so I'm not sure if this is caused by Windows.

My English is poor, so if I make any mistake, please forgive me.
I made a plugin to compile and run c++ source file, and I found that it doesn't work when I attemp to redirect the executable's input from a file. I tried with vim -u NONE -N, but it still didn't work.
The mininum code that can recure this issue:
call term_start('cat.exe', {'in_io': 'file', 'in_name': 'input.txt'})

In which cat.exe acts like cat on *nix.
I'm using Windows, and I didn't test this on other platform, so I'm
not sure if this is caused by Windows.

Yes, this is caused by windows.  The WinPTY library used does not
support redirection.  You will have to find another way to do this.
--
What the word 'politics' means: 'Poli' in Latin meaning 'many' and 'tics'
meaning 'bloodsucking creatures'.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

@91khr: I don't know much about Windows, but it seems that since 8.1.0870, Vim supports an alternative to winpty: ConPTY.  Does it help?  I'm not sure but you might need to set the global option 'termwintype' to conpty.


Merge the 3 pattern matching modules

Reduce back to 2 interfaces

Matchable - uses lambda's for internal matching
Matching - builds cases externally Matching.whenIsValue(1).then(i->i+2).match(1); - which can help IDEs

Merge /drop functionality from the other 2 builders into Matchable and Matching.

PR : https://github.com/aol/cyclops/pull/179


Power control functions

If you are interested in power control functions, please follow this issue for updates. We will also need testers.

Is this ready for pre-release?

The most helpful thing right now is making sure pymodbus 3.0.0 is ok in Release v2.2.6-pre.3  because I'm not going to do work on control functions for older pymodbis versions.

The most helpful thing right now is making sure pymodbus 3.0.0 is ok in Release v2.2.6-pre.3 because I'm not going to do work on control functions for older pymodbus versions.

Been running it since you released it, not seen any issues yet. I am also using pymodbus 3.0.0 as part of solaredge-meter-proxy and it is working fine there too.
Will keep my eyes out for any issues. Thanks for your hard work on this.

Same here have been running it since you released, no problems seen

Accidentally closed.

StorEdge power control functions are ready to get a pre-release, which will come immediately after the 2.2.6 release.
Based on PR #133 by @mpredfearn I've added commits 315e83fd4cfbf6625f5ec17746c75b94622c0ba4, 3ed64a57c5a17db01e04e7db044091e67e779279, 61a4c315c8da8d47932383cecf6a52a29b579b62, and 0f59f161bda547d377c1bd1a2bbbfc4df513f928 to get it to what I feel is pre-release ready.
I messed things up a bit by accidentally merging #133 before another pre-release so I reverted it in #153, but then #154 will revert that revert which will happen as soon as 2.2.6 is released.

Excellent work, I sent you some $$$ and would encourage others to do the same. Ready to test when you are ready, let me know if there is anything you want to specifically focus on.

Release v2.2.7-pre.1 is now available.

thanks, i have been playing with this and i see the following:
2022-11-03 21:10:12.418 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 0.418 seconds (success: True)
2022-11-03 21:10:27.323 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.number] set SE5000H-RW000BNN4_74098B35_storedge_backup_reserved to 0.0
2022-11-03 21:10:27.357 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 30
2022-11-03 21:10:27.361 ERROR (SyncWorker_3) [pymodbus.client.tcp] Connection to (<IP_ADDRESS>, 1502) failed: [Errno 111] Connection refused
2022-11-03 21:10:27.366 ERROR (MainThread) [custom_components.solaredge_modbus_multi] Error fetching SolarEdge Coordinator data: Could not open Modbus/TCP connection to <IP_ADDRESS>
2022-11-03 21:10:27.369 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 0.012 seconds (success: False)
so on every change the connection to the  modbus is lost

It does immediately disconnect at the end of the write (that's supposed to happen) and the next step is to request a data update which requests a reconnect, but the inverter rejected the connection. It works on my modbus simulator but it's possible the disconnect-then-reconnect is happening too fast for a real inverter.
I can try removing the disconnect call.

Changed in Release v2.2.7-pre.2

@WillCodeForCats pre.2 is working perfectly.
I'm not 100% sure what all the options do, any idea where i can find some documentation for this?
I'm looking for a way to charge my battery overnight for a certain time of certain load

I can make a wiki page that describes the different settings with the docs I have.
I can't give you a direct answer on which ones to set since I don't have batteries on my system, but hopefully someone that does have a battery can say which combination to use and we can add that to the wiki too.

I've created wiki page: https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Power-Control-Options

I'm thinking about changing the sensor names because I don't like how they currently appear on the dashboard in cards where you just see a pile of things called "storedge" with the most useful part of the entity name cut off by default.
Current default:

Possible new default:

Or keep StorEdge naming in selectors only:

i like the second screenshot the most, as the storeEdge keyword is not always correct, you can also have a setisi installed with and external battery (my installation)
also the twiki page is a good start,
but whats the difference between the storedge control mode, default mode and remote mode?

The way I understand it is that the "remote" settings temporarily override the default mode for the length of the timeout, then it goes back to operating in the default mode.

yeah indeed, i like the temporary naming

The way I understand it is that the "remote" settings temporarily override the default mode for the length of the timeout, then it goes back to operating in the default mode.
Edit: rereading docs again and maybe "remote mode" could be called "temporary mode", "remote charge limit" as "charge limit", "remote discharge limit" as "discharge limit", then "remote command timeout" could be "temporary mode timeout". If the limit values are applied to either "default" or "remote" mode then having remote in the name makes it look like they only activate during remote mode.

I'm not sure that it is temporary mode, where are you reading that?
I've had my battery in remote command mode for weeks. I thought it needed to be in order to accept remote Storedge Modbus commands.

From a UI perspective I find all of the "remote" references confusing. The docs are written from the perspective of the inverter, but if you're working inside the Home Assistant UI then HA is the "remote". The original naming is taken straight from the docs. For me a user should not have to refer to docs to understand the basic meaning of a setting, and if I'm not able to keep track of what each mode does and how the others are affected while developing/testing without having to keep looking up which is which then the presentation is bad.
I would change "Remote Control" to "Manual Control", drop every reference to "remote" in all settings, and differentiate the default command mode and the command mode affected by the timeout setting by calling it a temporary mode since it will expire based on the timeout value then revert operation to the default mode.
Although I realize people may be coming from another integration and what it called things, I don't want to be constrained by design decisions in other integrations that confuse me.
These are the groupings that make sense to me based on how the docs explain how things work:

Basically if I'm a user then I should be able to look at that for the first time and get a general idea what the settings might do.

Is it a good idea to deviate from the manual and any other implementation? I'd argue not but it is your code.

I also don't get why it would be called temporary mode when it can be turned on indefinitely. How can something be both temporary and permanent at the same time?
Remote mode was obvious to me. I have a TV remote, it lets me control the TV remotely. I have an Inverter remote mode, turning it on lets me control the inverter remotely. I don't really get where the confusion is coming from?

Is it a good idea to deviate from the manual and any other implementation? I'd argue not but it is your code.

I mean, I don't want to copy someone else's work just because that's what everyone is already used to blindly just because they exist. If it was good enough I wouldn't have spent all this time learning how to develop for HA and writing a new integration for my system. I posted my backstory on the HA forums.
There's a technical note that someone leaked that wasn't available publicly from SolarEdge, so it was written with a technical intent and not as a manual for end users. The integration should be end user experience first.

I also don't get why it would be called temporary mode when it can be turned on indefinitely. How can something be both temporary and permanent at the same time?

The docs define that register as "the operating mode during the defined time frame" and "when expired, it reverts to the default mode". I considered the definition of the word "temporary" as "lasting for only a limited period of time" so that's where I approached it from.
What I don't know though is if the timer starts counting when the timeout register is written, the timeout command mode is written, or both. In any case it clearly says limited time up to a max of 24 hours (86400 seconds).

Remote mode was obvious to me. I have a TV remote, it lets me control the TV remotely. I have an Inverter with remote mode, turning it on lets me control the inverter remotely. I don't really get where the confusion is coming from?

It just isn't for me. I was going to just let it go until someone else started asking questions, but then if people are asking basic questions then that's probably a sign to reconsider the presentation. The names were already pretty long where I was having to look at screens like this and try and remember what position a setting was in for testing:

There's literally three things called "Storege Rem..." and while the middle one is obviously different since it's seconds (it's the timeout for the register called "Storedge Remote Mode" accoding to the docs, a name which gives no indication it's related to the timeout) the other two are literally indistinguishable as presented by default in HA with the original names.
I should be able to read it and know what it is, not have to remember its relative position or open new windows to figure out which is which.
And then let's circle back "remote mode" where after I read the docs I found out aren't actually related as directly as the names imply. If "Storedge Control Mode -> Remote Control" then I would think that is directly related to the setting called "Storedge Remote Mode". But then I read the docs and it's totally not. "Storedge Remote Mode" is directly related to "Storedge Remote Command Timeout", whereas when in "Remote Control" mode it's actually "Storedge Default Mode" that is the effective setting unless it's counting a timeout. The naming is all over the place. But it's not anyone's fault because that's how the docs are written in how the names it uses don't always line up with how the docs then describe how they are related when considering someone who may never actually read those docs.

You would not even be able to guess at what temporary mode does if you didn't know. You would however at least be able to take an educated guess as to what remote mode might do.

There's no indication in the original which setting is tied to the timeout setting. I know now that "Storedge Remote Command Timeout" and "Storedge Remote Mode" are the ones that go together, but I didn't know that the first time I loaded it on my dev system since they're not named in a way that suggests that to me.
Remember that I have not been exposed to how the other integration did these things so I'm coming at all of this like a new user experiencing them for the first time through PR #133. So between my "first time user" confusion, continuing to second guess them looking at code, questions about them were made by another user here, and this conversation even exists is a clear sign that the naming is unclear and potentially confusing.

I mean, I don't want to copy someone else's work just because that's what everyone is already used to blindly just because they exist. If it was good enough I wouldn't have spent all this time learning how to develop for HA and writing a new integration for my system. I posted my backstory on the HA forums.

I hear you but sticking to the manual is a fairly accepted strategy. I could see deviating from the manual if it is absolutely unavoidable but this feels like a solution in search of a problem. We would be copying the manual not the other integration.

There's a technical note that someone leaked that wasn't available publicly from SolarEdge, so it was written with a technical intent and not as a manual for end users. The integration should be end user experience first.

Yes but it used specific terms, terms that are now in wide use within the community.

The docs define that register as "the operating mode during the defined time frame" and "when expired, it reverts to the default mode". I considered the definition of the word "temporary" as "lasting for only a limited period of time" so that's where I approached it from.

The timeout can be set (and I believe defaults) to zero making the mode indefinite. This is why I think temporary mode is a poor name. I have been running in Remote Command Mode for months. Would it make sense for me to make the same comment calling it Temporary Mode?

What I don't know though is if the timer starts counting when the timeout register is written, the timeout command mode is written, or both. In any case it clearly says limited time up to a max of 24 hours (86400 seconds).

Remote command mode is not limited to 24 hours if you set timeout to 0 (again I think this is the default)

Remote mode was obvious to me. I have a TV remote, it lets me control the TV remotely. I have an Inverter with remote mode, turning it on lets me control the inverter remotely. I don't really get where the confusion is coming from?

It just isn't for me. I was going to just let it go until someone else started asking questions, but then if people are asking basic questions then that's probably a sign to reconsider the presentation. The names were already pretty long where I was having to look at screens like this and try and remember what position a setting was in for testing:

If we are going to deviate from the manual can we at the very least have a translation document showing how to translate from SolarEdge manual and all other tooling to our own custom naming? I really feel like this change is bad but I doubt I will be able to convince you. Can you let some others weigh in too before making these changes?

There's literally three things called "Storege Rem..." and while the middle one is obviously different since it's seconds (it's the timeout for the register called "Storedge Remote Mode" accoding to the docs, a name which gives no indication it's related to the timeout) the other two are literally indistinguishable as presented by default in HA with the original names.

I'm not sure solving UI issues in Home Assistant by butchering the names to fit is the best way forward.

I should be able to read it and know what it is, not have to remember its relative position or open new windows to figure out which is which.

I agree in theory, where I don't agree is that "Temporary Mode" is any clearer than "Remote Command Mode". Especially for something that is in fact not temporary at all.

And then let's circle back "remote mode" where after I read the docs I found out aren't actually related as directly as the names imply. If "Storedge Control Mode -> Remote Control" then I would think that is directly related to the setting called "Storedge Remote Mode". But then I read the docs and it's totally not. "Storedge Remote Mode" is directly related to "Storedge Remote Command Timeout", whereas when in "Remote Control" mode it's actually "Storedge Default Mode" that is the effective setting unless it's counting a timeout. The naming is all over the place. But it's not anyone's fault because that's how the docs are written in how the names it uses don't always line up with how the docs then describe how they are related when considering someone who may never actually read those docs.

Sure but sticking to established norms is less confusing than making our own standards which others do not follow.
Consistency with SolarEdge Apps, SolarEdge Manuals and existing SolarEdge knowledge (users, fitters) is hugely important. Deviating from that adds complexity, both for you and end users.

There's no indication in the original which setting is tied to the timeout setting. I know now that "Storedge Remote Command Timeout" and "Storedge Remote Mode" are the ones that go together, but I didn't know that the first time I loaded it on my dev system since they're not named in a way that suggests that to me.

Sure, and I couldn't write C the first time I tried. Not everything is simple enough to understand at first glance. Hiding the complexity by making up our own names will just move the complexity not eliminate it.

Remember that I have not been exposed to how the other integration did these things so I'm coming at all of this like a new user experiencing them for the first time through PR #133. So between my "first time user" confusion, continuing to second guess them looking at code, questions about them were made by another user here, and this conversation even exists is a clear sign that the naming is unclear and potentially confusing.

You also have not been exposed to the official apps, the solaredge batteries etc. I get that you kinda want to go your own way with this but don't forget this is an integration with SolarEdge Inverters. We are playing in their sandpit. If we can't rename the setting in all the documentation, the official apps and in the installers heads we shouldn't rename it at all.

If there is an actual user manual for the commands, not the technical note, it should be submitted to the docs directory. Otherwise any argument about following the manual won't sway me.

Submit screenshots from the apps (English please) so I can see what they show and exactly what words they use.

If there is an actual user manual for the commands, not the technical note, it should be submitted to the docs directory. Otherwise any argument about following the manual won't sway me.

Would you please stop skipping over the fact that temporary mode isn't temporary.
How does it make any sense to have a temporary mode that can be on indefinitely?

Would you please stop skipping over the fact that temporary mode isn't temporary.

I find it somewhat offensive that you're accusing me of "skipping over" facts. I quoted the tech note word for word.

I have a battery here, the setting has been set to remote command mode since I got it installed several months ago. I have asked several times why temporary mode makes sense. I'm sorry if that offends you, it certainly isn't my intention.
Can you see why I think a setting called "temporary" that isn't temporary is poorly named?

The tech note is already been proven to be inaccurate in one case, further inaccuracies are not a surprise, so they should be documented on the wiki as they are brought up:
https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Known-Issues
Telling me I'm ignoring facts and wanting to go my own way are offensive, after all the time and effort I've put into this.

Ok so can we discuss the fact that temporary mode can be on indefinitely. Does that not strike you as confusing?
Please don't suggest I've not appreciated your hard work on this project when I'm the first person to sponsor you and you are the first person I have ever sponsored to write code (being a programmer myself).

That still doesn't mean we can name a setting that can be indefinitely set as temporary. You defined the word temporary above and indefinite does not match that definition.

Temporary mode was what I thought of first and is not some final word. I work very loosely and was presenting possible alternatives to @Cereal2nd who asked the quesiton.
I'm trying to find a manual for the solaredge app to see what it says but haven't found anything that describes battery commands yet.

I'm also looking for something concrete, I'm not at home right now but I will be tomorrow, I'll get some screenshots out the app (and the web portal).
I'm only one data point but I'm against changing names from SolarEdge defaults. If we absolutely must do it we need to think long and hard about the names to make sure they make sense. I can't help but feel this thinking time could be better spent elsewhere.

Out of interest I don't understand why matching a technical note is not of equal importance to matching a manual? Ultimately it is highly likely to be developers (or at least technically minded users) installing this tool and turning on the advanced settings which are gated behind a disclaimer.

I see it as a guideline because it's not published on the SolarEdge website, already has two documented errors (the timeout behavior and the behavior of the kWh counters), how well it works varies between users, and at least one person has reported trying to contact SolarEdge support for issues related to tech note was ignored. I can't remember where all the comments were but there was someone running a fancy smart panel system that needed to integrate over modbus and the devs of that system had to work magic with SE behind the scenes first. There's also two users that I know if both with the new SolarEdge branded battery banks, one reports data and the other doesn't, even though they have the same batteries.
About the only thing that is accurate in it are the register addresses. But then even the procedure to be able to change these settings is incorrect, it says certain registers need to be written before others will be accepted but in another issue someone reported that it works even though the register the tech note says is required was set to disabled in their system. So those parts of the tech note are inaccurate too.
Compared to the sunspec modbus tech note which doesn't really contain any surprises and its behavior is consistent to real life, which is published on the SolarEdge website. The power control tech note was either withdrawn from download for some reason or never intended to be public in the first place, and the reason it's available looks more like a leak than something SolarEdge indented to be out there. By comparison the power control tech note comes across as something that would be given to developers that have some kind of dev agreement with SolarEdge (like that smart panel system which I can't remember the name).
One example in naming is where the tech note says "Storage AC Charge Policy" (original PR used "Storedge AC Charge Limit" note storage vs. storedge) but in SetApp it's called "AC Charge Limit" on my inverter (I can view and set some storage settings and all of the export limit settings even though I can't access them over modbus). So from that I would assume there are more differences - I only checked a few screens as some of them are very different to the point where I need to do more research, but my takeaway is that the tech note should not be the final word on naming since deployed equipment doesn't use those names.

So as I dig deeper into this I find that tech note naming was only loosely followed, which only establishes a precedent for that other integration, but not necessarily one that should be followed here based on issues already identified.
Examples:
Original named "Storedge Remote Mode" is named "Remote Control Command Mode" in the tech note.
Original named "Storedge Control Mode" is named "Storage Charge/Discharge Default Mode" in the tech note.
Original named "Storedge Remote Mode" is named "Remote Control Command Mode" in the tech note.
The original transposes "storage" with "storedge" in every name. Easy to miss but nevertheless not tech note accurate.
The tech note itself fails to follow a naming convention for similar setings: "Remote Control Charge Limit" vs. "Remote Control Command Discharge Limit". Original further deviates with "Storedge Remote Charge Limit" and "Storedge Remote Discharge Limit"
I don't want this to sound like I'm nitpicking the contributions of PR #133 which are greatly appreciated and critical to getting those features implemented faster than I was able to do on my own, but if the argument against my name changes are about being tech note accurate with the original, well, it never was tech note accurate.
As far as "temporary": naming it alternate or secondary with alternate or secondary timeout and add a known issue note that alternative or secondary mode may be treated as default by the inverter if timeout is set to zero. But prefixing "storedge" and "remote" multiple names adds long repetitive prefixing to entity names that can chop the name into ellipses in the HA UI (which I dislike seeing). However, since names in HA can be changed by the user, the user can simply rename all the entities to their preferred names and a wiki note with how to rename and a renaming map from other names would be a better solution IMO for people coming over from another integration.

So as I dig deeper into this I find that tech note naming was only loosely followed, which only establishes a precedent for that other integration, but not necessarily one that should be followed here based on issues already identified.
Examples:
Original named "Storedge Remote Mode" is named "Remote Control Command Mode" in the tech note.
Original named "Storedge Control Mode" is named "Storage Charge/Discharge Default Mode" in the tech note.
Original named "Storedge Backup Reserved" is named "Storage Backup Reserved Setting" in the tech note.
The original transposes "storage" with "storedge" in every name. Easy to miss but nevertheless not tech note accurate.

Sounds like something the marketing department would do just before release. (s/Storage/StorEdge).

The tech note itself fails to follow a naming convention for similar setings: "Remote Control Charge Limit" vs. "Remote Control Command Discharge Limit". Original further deviates with "Storedge Remote Charge Limit" and "Storedge Remote Discharge Limit"

Looks like they are trying to keep the names under a certain length in the tech note (less than 32 chars).

I don't want this to sound like I'm nitpicking the contributions of PR #133 which are greatly appreciated and critical to getting those features implemented faster than I was able to do on my own, but if the argument against my name changes are about being tech note accurate with the original, well, it never was tech note accurate.

Accuracy isn't nitpicking, you are absolutely correct to point out inconsistencies.

As far as "temporary": naming it alternate or secondary with alternate or secondary timeout and add a known issue note that alternative or secondary mode may be treated as default by the inverter if timeout is set to zero. But prefixing "storedge" and "remote" multiple names adds long repetitive prefixing to entity names that can chop the name into ellipses in the HA UI (which I dislike seeing)

I agree the prefixing can get a bit long. I'm not sure how "alternative" is shorter than "remote" however.

However, since names in HA can be changed by the user, the user can simply rename all the entities to their preferred names and a wiki note with how to rename and a renaming map from other names would be a better solution IMO for people coming over from another integration.

Sure, it might be worth having a compatibility shim that lets people transition from the old integration. The only thing is that's not going to be fun for you when you start getting bug reports with various different names in use.

Edit: I also think that using "StorEdge" should be avoided because there's new inverter models that support batteries that no longer use the StorEdge branding.

StorEdge does seem to be the old branding.

These are probably issues where the community can step in if there's a need.
I already have different naming for all inverter registers, so anyone coming over already has to deal with updating entity names and I'm not aware of any major complaintst. The name change wasn't a problem for Remko's energy dashboard. Someone who has used both could contribute a wiki page with an old name -> new name table for that.
I really don't like "remote" in the names becasue it simply doesn't make sense to me mentally and probably never will since I won't be using it regularly to become accustomed to what they actually do vs. what the name implies. But if battery users are stuck on it then it can stay. The only major drawback is lack of support from me about something I can't keep straight in my head, but others can answer those questions when they come up.

I have 3 inverters, 2 of which have SE energy banks connected to them via energy net. All firmwares at latest from SetApp. For me setting the “Storedge Remote Mode” to anything different than the “Storedge Default Mode” observes the  “Remote Command Timeout” perfectly, returning to the default after this timeout expires.

These are probably issues where the community can step in if there's a need.

I'm happy to maintain this once you've decided on names.

But if battery users are stuck on it then it can stay.

I seem to be in the minority here as others want it changed. I also seem to have a weird misconfiguration as it looks like Storedge Remote Mode should in fact be temporary. I have also been messing with Modbus on my inverter so it is entirely possible I have screwed something up.

What batteries/inverters do you have? It may just be difference in equipment where people with newer equipment don't experience the same behavior as people with older equipment.
@DougMunford just reported that his Energy Bank batteries are not affected by the "reset to zero" issue that were reported by other users with LG batteries, so that behavior got turned into an option in the latest pre-release.

I have a SE energy bank here but I don't have a SolarEdge meter and I've been using my own, both with https://github.com/nmakel/solaredge_meterproxy and with a custom package I've been developing for an ESP32. It could be that in the process of developing this I've gotten my inverter into a weird state.

So, when I first switched the control mode to remote the import/export limit values were set at 5000, the default mode was not set and the timeout was set at 3600 seconds 1 hour). The inverters and batteries had only been used in MSC (out of the box) or installer account power profile ToU mode applied before now.
Batteries:

Inverters:

Separate question, but do you know what Status = 10 is? It's not defined in any of the specs I have.

I ran them dry. This is what the app reports right now while they are at 10.

I get 10 when my battery is ran to empty too. I have a SE branded batterySent from my iPhoneOn 8 Nov 2022, at 18:58, DougMunford @.***> wrote:
I ran them dry. This is what the app reports right now while they are at 10.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

Thanks, will add Power Saving mode in the next release.

I see status 6 in my logs too, I'll set an alert so I can find out what the app shows next time it happens.

6 I believe is a full battery whilst on MSC (charging from PV), where as 1
is full when charging from remote control PV and AC.
On Tue, 8 Nov 2022 at 21:15, DougMunford @.***> wrote:

I see status 6 in my logs too, I'll set an alert so I can find out what
the app shows next time it happens.
—
Reply to this email directly, view it on GitHub
https://github.com/WillCodeForCats/solaredge-modbus-multi/issues/136#issuecomment-1307834468,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQ3KT4OMJZI6R3Q7TAQWAM3WHK7GHANCNFSM6AAAAAARD4ZEBA
.
You are receiving this because you commented.Message ID:
@.***>

This was my b1 status today:
[image: image.png]
Charging battery from 2am, it was full just after 3am. Actually, my
automation then puts the system into a disabled state (meaning i supply the
house from the grid), which is probably 1.
3 is charging. Then 6 is as mentioned, full during an MSC charge.
On Tue, 8 Nov 2022 at 21:21, Edward Ashforth @.***>
wrote:

6 I believe is a full battery whilst on MSC (charging from PV), where as 1
is full when charging from remote control PV and AC.
On Tue, 8 Nov 2022 at 21:15, DougMunford @.***> wrote:

I see status 6 in my logs too, I'll set an alert so I can find out what
the app shows next time it happens.
—
Reply to this email directly, view it on GitHub
https://github.com/WillCodeForCats/solaredge-modbus-multi/issues/136#issuecomment-1307834468,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQ3KT4OMJZI6R3Q7TAQWAM3WHK7GHANCNFSM6AAAAAARD4ZEBA
.
You are receiving this because you commented.Message ID:
@.***>

Oh, the logs are interesting, This is where my 0 figures were reported:

Sorry, adding the other battery makes it clearer:

When in a status of 0 the values are also reported as 0.

Interesting, when I had some other figure than 3600 set as the remote timeout it was reset to 3600 on one of these availability and init events. This kit is very weird.

On the naming thing, yes it needs to be clearer to the user. I find it interesting that the UI for an installer in their monitoring app also changes names of modes to be programmed to make things clearer.
Documentation

Status 6 doesn’t reflect in the app. I’ve had one battery charging while the other was not while in status 6, the app just shows charging. While in status 6 the battery has DC current and DC power are reported as 0. I wonder if this is some sort of BMS pause?

Observations:
Setting the “Storedge Remote Mode” on a follower inverter does not stick, whatever is on the leader overrides it. Setting it on the leader also pushes the same setting to the follower, there is no need to action both, they act in unity. This is NOT the case for the other settings. Both of these inverters have SE Energy bank batteries attached via Energy Net comms.

Actually I don't think there's a way to always determine the leader inverter... it will probably almost always be the inverter with the network connection and the first address, but it doesn't have to be (I have network on my follower inverter so I can have parallel testing going and it will respond to modbus too).

Agreed, until I renumbered mine to better fit the requirements of this integration the leader was number 3, a product of adding to the system over time.  All of my inverters have wired Ethernet although that isn’t really necessary as they are linked via RS485. Setting mode config on the follower does no harm, it just instantly changes back. Perhaps just a note in the wiki?

On the naming thing, yes it needs to be clearer to the user. I find it interesting that the UI for an installer in their monitoring app also changes names of modes to be programmed to make things clearer.
Documentation

Here's how I translated the mode names using that doc:

Off -> Solar Power Only (Off)
Charge from Excess PV Power Only -> Charge from Clipped Solar Power
Charge from PV First -> Charge from Solar Power
Charge from PV and AC -> Charge from Solar Power and Grid
Maximize Export -> Discharge to Maximize Export
Discharge to Match Load -> Discharge to Minimize Import
No change: Maximize Self Consumption

My test dashboard looks like this:

All of the naming stuff is in PR #173

Planning to merge #173 soon for another pre-release. After that there will probably be one more pre-release after I do more abuse and validation testing on it.

Release v2.2.7-pre.8 is now available. It contains a large amount of changes to naming and validation for power control functions.

Release v2.2.7-pre.10 includes a new delay option after sending commands for inverters that stop responding while they process a command. Default is 3 seconds with a config range of 0 to 10 seconds (setting it to 0 disables it).
I fast tracked this one and did very little testing on it, hopefully no bugs or regressions.

Unless there are any outstanding problems or things I missed, pre.10 will probably be the final pre-release.

Release v2.2.7 is now available.

Now that we have a release with all the power control functions I'll go ahead and close this issue, but I've created discussion #207 with a reference back to here.


Webhook doesn't send on repository delete event

Gitea version (or commit ref): 1.11.0+dev-331-g055f6d229
Git version: not needed
Operating system: Docker container from gitea/gitea
Database (use [x]):

[ ] PostgreSQL
[x] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[x] Yes (provide example URL)
[ ] No
[ ] Not relevant

Log gist:

Description
No notifications are sent via webhook upon the deletion of the repository. The notification is not a joke either when specifying a webhook in the repository settings, or when specifying a global webhook.

@matrozov That's not global webhook. It's a default webhook.

This is happening to me but with the push event.

This has been fixed in master (due to become 1.13), and I've opened a backport to fix this for 1.12.

Fixed by #13008


Overlapping text on adjacent spans that also overlap

When 2 adjacent spans have starts and durations that cause an overlap, the first spans text is not occluded by the second span.  See the top highlighted call out in the image above.

NOTE: This is a holder issue for me as I'm going to try and fix it myself.

It seems to be preferable to use the waterfall plugin for this situation - move your requests data to the waterfall section on initialization and all will be fine.)
The flame chart (as a concept, not this project) does not allow situations where you can have two nodes overlap in duration.

It's still the best visualization for the idea of a trace however.  the difference being the concept of async function calls.  real world data HAS async function calls so ensuring this can support those visualizations cleanly is ideal.  Even modern javascript has the concept of async calls now.

those async functions are awaited time, maybe that time could be colored with some diagonal lines to represent them as async

In the javascript world, all asynchronous operations are still executed sequentially (because we have the event loop) and there can be no overlap. The exception occurs only if there are multiple threads. And in this case, you need to build several flame charts and this can be done using the plugin system.
Specifically, requests are displayed separately from code execution.

This is how we visualised our async functions.
The part with diagonal lines was a passive (async time) and other part with flat color is an active function time.

so... while we have all been discussing this.. this DOES allow you to have overlapping time frames... I'm doing some final testing but I believe I've got all the cases figured out to support it smoothly.  My coming PR also simplifies the render to a single render queue that is called sequentially rather than having 3 render queues that are called sequentially.  It was the 3 render queues that caused the issue here as the text renders occurred after ALL the rectangle renders.  This mean for the canvas. it placed text over everything even though the calls to add to queue happened in a different order.  By collapsing the queues to a single one we can render in order with the expectation that last in wins.
Additionally adding in a simple fix to properly grab the hit-region for overlapping spans.  It's pretty slick and the changes look to be just as performant.
PR incoming soon.

Could you provide a code snippet that would cause such a trace with overlapping frames?

I updated the demo to randomly generate such an example.

yes. but that is manually generated data.
Can you provide a javascript code snippet that can provide such a trace?

[overlapping-exampl.txt](https://github.com/pyatyispyatil/flame-chart-js/files/8344135/overlapping-exampl.txt)
you can import this data into the demo

Ok, I think there is a misunderstanding here, so I will put it this way
Can you provide a chrome profile where function calls would overlap?
A real usecase where such trace with overlapped frames would happen in javascript world.
Or is this not about javascript at all?
Because I don't see how this scenario could happen in javascript, since it is not a multithreaded language.

this is not javascript... these are server traces of things being profiled like a php, ruby, python, dotnet or java application etc...  The flame chart visualization works wonderfully for these types of representations and thats what I use if for.

I think we should find another solution for this case. As I saw in the PR that you opened, the current solution breaks core engine optimizations and looks like it doesn't solve the problems you want to solve. I think it's preferable to use something like logic in waterfall data with intervals and timings in the same node.
Because the case where we have two or more nodes in the same period also breaks the timeframe plugin logic (in the top plugin in the UI you can see broken line on your screenshot) and possibly broken tree cluster logic.

If you check the picture that I posted above, the diagonal lines are what we achieved with intervals.
Function nodes can have an interval entry which contains start and stop of an interval (which represents the time where function was just waiting for some async stuff)

Is this fix released?

@fizerkhan  No.(
I'll deal with this problem later when I have time.
I closed this issue because the discussion was not a very correct solution and the situation described in the first message is divorced from reality, because spans cannot intersect with each other - this will break the tree structure.

@pyatyispyatil Thanks for the quick response.
In Telemetry data, more than one span can have the same start time and different duration due to its async nature.
Do you think the flame chart is not designed for Async's spans (or parallel spans)? I am just curious.
If you have a better solution, Please suggest it. We will work on it and give you the PR request.

I think you need to combine the use of waterfall chart and flame chart. In waterfall you can display multiple independent spans with intersecting timelines, and in turn in the flame chart you can display their “content”
If your asynchrony involves multi-threaded execution of spans, that is, each span can execute its own code, then most likely you need to use several independent flame charts and display data in them depending on the thread. There is a similar thing in the examples.


Support for simpler view matching via Testing Tags

Recently, while testing lists of items that provide multiple views I favored modifying content descriptions based on the view model associated with an item position. Doing this, I was able to easily match a view using withContentDescription. This is much simpler than using the numerous combined matches from before with allOf().
As we don't want to overwrite the proper content descriptions according to our accessibility guides, providing a method of matching according to some specific testing tag would be great. This testing tag should only be available during testing environments, similar to how idle resources work now.
Bonus points for determining some easy method of automagically adding these tags, but utility methods are the baseline.

Closing this issue, as it is now implemented with Cappuccino version 0.8.1.


Create Find k’th largest element in an array.java

#Issue Id you have worked upon -
#145
Find k’th largest element in an array
Briefly explain your program logic -
A simple solution would be to use an efficient sorting algorithm to sort the array in descending order and return the element at (k - 1) 'th index. The worst-case time complexity of this approach will be 0(n.log(n)) , where n is the size of the input. We can improve the time complexity using the following methods:
Screenshots(Attach 2 screenshots of your own input and output) -
Input:
arr = [7, 4, 6, 3, 9, 1]
k = 2
Output:
The 2nd largest array element is 7
Checklist:
Eg - If your code follow the below guidelines. Kindly change [] to [x]
All the conditions should be fulfilled for considering your code for merging -
[x] I have mentioned the question as comment in my solution file.
[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code.
[x] My code gives the correct output.
[x] I confirm that I have not copied the code from anywhere. In case its found that I have copied I can be banned from the repository.
[x] I affirm that I strictly follow contributing guidelines and code of conduct.

Hello Sarthak, Can you please merge this now.

@Architgupta001,
Kindly attach screenshot instead to manually writing the output

@Architgupta001,
Since no response had been received. This issue is being closed.


software abused....

Wilder and Kutiekatj9 have been caught abusing the software already to victimize people and talk smack about the people they just victimized in a pattern.

@ForkInABlender this repository is for discussing the development of the bot. If you have an issue with other users you're welcome to write to Modmail.


Querying document after Inline Projection returns no results

I'm a Marten noob, but a big fan so far. Forgive me if this question is basic.
I'm trying to do something that I thought was simple, and I'm not exactly sure where I'm screwing up.

I have an Aggregate Foo, which is sourced from an event NameChanged.
I registered an Inline Projection of Foo in my DocumentStore setup.
I create a Foo, change its name, and start a new Event Stream.
I save changes on the store.
I can fetch the event stream by ID.
When I try to query for all existing Foo objects, nothing returns.

I was expecting this to work, given this section: https://martendb.io/documentation/events/projections/#sec2
    public class Sandbox
    {
        [Fact]
        public void Marten_InlineProjections_Should_Work()
        {
            var store = DocumentStore.For(options =>
            {
                options.Connection(new ConnectionStringProvider().GetConnectionString());
                options.Events.InlineProjections.AggregateStreamsWith<Foo>();
            });

            var foo = new Foo();
            foo.ChangeName("Bar");

            try
            {
                using (var session = store.LightweightSession())
                {
                    session.Events.StartStream<Foo>(foo.Id, foo.GetChanges());
                    session.SaveChanges();

                    var events = session.Events.FetchStream(foo.Id);
                    // this passes
                    events.Count.ShouldBeGreaterThan(0);

                    var foos = session.Query<Foo>().ToArray();
                    // this fails
                    foos.Length.ShouldBeGreaterThan(0);
                }
            }
            finally
            {
                store.Advanced.Clean.DeleteAllEventData();
                store.Advanced.Clean.DeleteAllDocuments();
            }
        }
    }

    public class Foo
    {
        public Guid Id { get; set; }
        public string Name { get; private set; }
        private List<NameChanged> _changes;

        public Foo()
        {
            _changes = new List<NameChanged>();
        }

        public IEnumerable<NameChanged> GetChanges() => _changes;

        public void ChangeName(string newName)
        {
            _changes.Add(new NameChanged(newName));
        }

        public void Apply(NameChanged @event) => Name = @event.NewName;
    }

    public class NameChanged
    {
        public string NewName { get; }

        public NameChanged(string newName)
        {
            NewName = newName;
        }
    }

Change foo.GetChanges() to foo.GetChanges().ToArray(), otherwise the list is stored instead of the individual event. I ran into this technicality myself.

Also you never generate a Guid for the Id.

Yep, that works. Thanks!


Position and velocity Hz ashtech

I am using the astech driver to another gnss that uses the nmea protocol.
When consulting the gps status in nsh the velocity frequency is 0.
In code, comparing  to ublox driver i saw that is missing a _rate_count_vel++. Was that on purpose?
Another issue is that the position frequency is multiplied by 2. I think that is because of the gga and pos message. Is possible that they give differente position coordinates and because that the frequency is double?

No, you're right, the velocity rate seems to had been missing. Can you test #8?

Another issue is that the position frequency is multiplied by 2.

What do you mean exactly?

That seems to solve the problem.
Well, i have the gnns running at 5Hz and in nsh shows that is at 10Hz. And it's because of  _rate_count_lat_lon++; in GGA and POS messages.

I see. Do the GGA & POS provide the same position? If so, from what I see POS provides all the information that GGA does plus more. We can then simply ignore GGA if we receive both messages. Can you test this? I don't have an ashtech gps.

Well, like i said, i don't have a ashtech gps. i have other gps that uses the same nmea protocol.
I tested it, and they have the same position coordinates.

I extended the driver, can you test #9?

That worked!
Thanks for your work.


There seems to be a bug, at least in version 2.7.0. You can reproduce it easily by clicking on this link and pressing the "go" button: http://jsonpath.herokuapp.com/?path=$..book.length()
It displays 0 as a result instead of 4. Are there no unit tests for this?
Can you please fix that?


feat(Illari): 100hp Healing Pylon

:tada: This PR is included in version 1.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Using node-gyp in Windows with Windows version of Node and Python and MSYS2 GCC

Currently, node-gyp in Windows need VS for working, but I have MSYS2 with GCC and don't want to install another C compiler. In #1240 , the only solution is use MSYS2 version of Node and Python, which means Windows version of Python should be dropped. what should I do if I want to use node-gyp in Windows with Windows version of Node and Python and MSYS2 GCC? (idk is patch by @smaudet finished)

https://github.com/search?q=repo%3Anodejs%2Fnode-gyp+MSYS2&type=issues

https://github.com/search?q=repo%3Anodejs%2Fnode-gyp+MSYS2&type=issues

do you mean I should read all those issues?

@cclauss Sorry, but I can't find anything help. What should I do? Or should I wait for support?

I'd start by making a fork of node-gyp and trying to build the smallest project with it.


Draft: Model Hand Landmark.

Ticket
None
Problem description
Add model Hand Landmark to trace.
This test depends on fixture manage_depedencies which was developed in PR 137. So, review PR 137 first, and then I continue to finish this PR in case of any change according to PR 137.
What's changed
Add model Hand Landmark.

Need to decide what to do with a file and whether we have to enable git lfs.

Need to decide what to do with a file and whether we have to enable git lfs.

I chosen git lfs since it's a common way to handle such a problem. I closed this PR and opened another PR #171.


How to validate a COPC file?

Hi! I'm working on converting las files to copc.laz format and have successfully generated the output files. However, I am looking for ways to validate the generated COPC files.
I came across this link https://github.com/copcio/copcio.github.io?tab=readme-ov-file#validation..But the https://validate.copc.io/ option doesn't show any output and I am not sure how to use the cpp version.  So, is there any alternate ways to validate the COPC files? (maybe using Python API or pdal CLI similar to pdal info).
Thanks.

If it is a small enough file, just drag and drop it onto https://validate.copc.io

https://github.com/hobuinc/copcverify (maybe that's what you meant by "cpp version") builds easily with cmake (no dependencies). You just say "copcverify [--dump --chunks] ".

If it is a small enough file, just drag and drop it onto https://validate.copc.io

Thanks @hobu ..I tried that but after uploading the file the UI just vanished. I dig a bit deeper into the Network requests and found that the Cesium API is not getting authenticated

https://github.com/hobuinc/copcverify (maybe that's what you meant by "cpp version") builds easily with cmake (no dependencies). You just say "copcverify [--dump --chunks] ".

Thanks @abellgithub I'll try this and get back. I might need to look into how to set this up for use in a Jupyter notebook though.

https://validate.copc.io works for me. If you post a link to your file we can provide some details.
As for Jupyter, laspy has COPC read support, so you might try that.

Thanks! I'll try to provide a link for the file.
Although, I setup the copcverify as suggested by @abellgithub and getting following output -
(base) root@workspace8ilyebp6oygo74dk:~/copcverify# ./copcverify "maap-documentation-examples/copc/data/usa_neonsrer_2019_NEON_D14_SRER_DP1_L090-1_2019091314_unclassified_point_cloud_0000004.copc.laz"
terminate called after throwing an instance of 'lazperf::error'
  what():  Invalid LAS file. Incorrect magic number.
Aborted

Does that mean that the file is not correct?

Originally, I was thinking if it would be a good utility to have a pdal validation for COPC similar to https://cogeotiff.github.io/rio-cogeo/Is_it_a_COG/#3-cog-validation is there for COGs. Maybe another filter imitating the same effect as copcverify.
As most of the times the users are interested in just validating if the generated output is cloud-optimized or not.
PS: @hobu I am able to get info for this file using pdal info as follows. We assumed that it is a valid COPC since it used readers.copc by default. Is that a valid assumption? Or could it anytime be possible that pdal info is showing the info but the file is not a valid COPC file?

If pdal info reports a .copc element, it is COPC data.
You need to post a link to an example file for us to tell you any more.

Here's the link to the file - https://drive.google.com/file/d/1mR7x4_vz8xrHf0wLmBZxP56Zbc1qPibH/view?usp=sharing

It has one point in it. Are you trying to mess with us? 😉

Ahh extremely sorry @hobu .. I didn't realize yet there is only one point in this file. I'll check with another example and close this issue. Thanks for all your help.

I updated copcverify. It should no longer throw the exception you received.


Enhancement: Update Ranger talent text

Kiwi4BBQ wrote:

It appears like Foundry is using old wording on the ranger's Herbalism class talent.

Fixed in PR #819


Disable neutron-lbaas plugin

Gophercloud job broke on running db migration on neutron-lbaas [1].
However, neutron-lbaas is deprecated so simply removing it should
be fine.
[1] http://logs.openlabtesting.org/logs/27/927/70f04e44e91c14b867c5ead4b8e859b57864213e/check/gophercloud-acceptance-test/8ab8306/

approved

I prefer not to remove since it is deprecated only and I am not sure there are other dependencies @jtopjian will this be a problem?

@dims @hongbin please see comment

I can totally understand disabling it for newer releases, but I'd like to have at least one stable release to be able to check neutron-lbaas. No problem at all if it's not tested by default (meaning, I don't mind having to do a manual "recheck foo" to test neutron-lbaas).
I'm very much in favor of always being able to test as much as possible, being mindful that deprecated and even removed services are still out in the wild. It's not always possible for sites to upgrade (for a myriad of reasons) and so I try to keep Gophercloud as widely compatible as possible.

@hongbin For github.com/gophercloud/gophercloud/acceptance/openstack/loadbalancer/v2, I think it's totally fine to run in Octavia only.
For the older github.com/gophercloud/gophercloud/acceptance/openstack/networking/v2/extensions/lbaas_v2, that should be run with the neutron-lbaas service.

@jtopjian from the test results of https://github.com/gophercloud/gophercloud/pull/967 , i saw this error:
FAIL	github.com/gophercloud/gophercloud/acceptance/openstack/loadbalancer/v2	600.026s
The gate was setup by an independent Octavia but it didn't pass. Is it a bug in the test suite or it is a CI issue?

TestLoadbalancersCRUD

That looks like a legitimate issue with the test itself. Although that test passes fine on vexxhost.

TestLoadbalancersCascadeCRUD

This one looks strange. No idea why it would be running for more than 10 minutes.
What octavia release is being used?

According to http://logs.openlabtesting.org/logs/67/967/7fbc3bfa7dbba1ac0264dab27ec84020c19cd964/check/gophercloud-acceptance-test/7ccbd2e/logs/devstacklog.txt.gz , it is using the master branch in this commit:
2018-04-30 18:53:04.622 | b4632d7 Remove PluggedVIPNotFound references

I'm not sure then. All Octavia tests pass on vexxhost which is the test environment I have easy access to for Octavia.
In order for me to look into this in more detail I'll need to create a local devstack environment that matches what's being used here. I won't have time to do that for a while.

I could try allocate some time to reproduce it as well, possibly in this or next weekend. Then, for now, let's proceed to revert the octavia patch which will disable the octavia acceptance test and make the CI happy.

Sounds like a plan.
In the meantime, I'll continue using vexxhost to manually test any further Octavia PRs that come my way.

To summary, here is the current progress of the Octavia CI:

We enabled octavia in https://github.com/theopenlab/openlab-zuul-jobs/pull/171
** This PR enabled both octavia and neutron-lbaas in devstack
** After the PR, the Gophercloud CI failed with error "IOError: [Errno 21] Is a directory: '/'" (see http://logs.openlabtesting.org/logs/67/967/7fbc3bfa7dbba1ac0264dab27ec84020c19cd964/check/gophercloud-acceptance-test/e432753/logs/devstacklog.txt.gz).

We disabled neutron-lbaas in https://github.com/theopenlab/openlab-zuul-jobs/pull/187
** This PR enabled octavia with neutron-lbaas disabled
** After the PR, the Gophercloud CI failed with error "FAIL	github.com/gophercloud/gophercloud/acceptance/openstack/loadbalancer/v2	600.026s" (see http://logs.openlabtesting.org/logs/67/967/7fbc3bfa7dbba1ac0264dab27ec84020c19cd964/check/gophercloud-acceptance-test/7ccbd2e/job-output.txt.gz).

We proceeded to revert the two PRs above
** https://github.com/theopenlab/openlab-zuul-jobs/pull/188
** https://github.com/theopenlab/openlab-zuul-jobs/pull/189


frontend: Replace scrollbars with perfectScrollbars. [working]

The commits from #5926 that work properly & pass tests.

Automated message from Dropbox CLA bot
@vaidap, it looks like you've already signed the Dropbox CLA. Thanks!

@vaidap there's one major issue with this, namely that the various selectors you use are way too broad.  using $(".settings") will attach a scrollbar to everything with a class named "settings", which one can imagine being used in a lot of places.  I merged several commits, tweaked to use more precise selectors; use git log -p to see them.
We use precise, scoped selectors like $("#subscription_overlay .settings") basically everywhere in our CSS and JavaScript, because not doing that often leads to subtle bugs showing up elsewhere where some configuration affects more than you'd intended :).

right sidebar user list has this behaviour: when searching for users, it doesn't reset to the very top, but adapts in size. should it jump back to the top?

I think it should reset-to-top when you add more to the filter, yeah.

I think we've now added these in all of the places referenced.  Thanks for all your work on this @vaidap!


SpaceService: Models

Added "Space" and "Space Type" models for front.

These changes are implemented in the main feature/space-service branch.


Add a quick access chapter list to reader.

Add a button to the bottom bar that would show a chapter list. There are a couple of possibilities for the implementation.

Modal bottom sheet
Fullscreen dialog
Left or right drawer

I am leaning more towards the left drawer.

I'd prefer a full screen dialog honestly


Seeking help toggling burger using isModalOpen

Nextjs/Typescript novice here. I have a mobile menu using America's Favorite Modal (awesome!) however, I cannot sort out how to access the modal state "isOpen" from a sibling component. I am using Hamburger React
Everything is working great except I need to toggle the burger when
Here's what I have so far…
const MenuMobile = () => {
  return (
    <>
      <ModalToggler
        slug='menuMobile'
        className={styles.burger}>
        <Hamburger
          color='var(--light)'
          duration={0.25}
          label='Show menu'
          size={28}
          rounded
          // Todo: toggle burger on menu item click - use isModalOpen?
          // toggled={isOpen} toggle={setOpen}
        />
      </ModalToggler>
      <Modal slug='menuMobile'>

              <ModalToggler slug='menuMobile'>
                <Link href='/how-it-works'>How It Works</Link>
              </ModalToggler>

etc.

@ballermatic you can call the useModal() hook and read from modalState, like this:
const { modalState } = useModal()
const isOpen = modalState.menuMobile?.isOpen

Let me know if this works for you!

That worked! I knew it was something obvious but couldn't figure it out. Thanks!

Niiice! Happy to help.


fix: #11 capturing "YYYY-MM-DD" formats

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

Project coverage is 100.00%. Comparing base (149d466) to head (f29e794).
Report is 8 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #13   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines           20        21    +1
  Branches         4         5    +1
=========================================
+ Hits            20        21    +1

Flag
Coverage Δ

100.00% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

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


V2: Fix most memory leaks and increase performance

Fixed memory leaks found in the application service + minor performance improvements throughout

Just a few comments to removed. If you made your orgs public after creating this issue you need to close and open for the bot to re-do it's thang.


batch/v1beta1 CronJob is deprecated

Description
batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
Environment
OS:
Version:
Steps To Reproduce

Expected behavior

Actual Behavior

Additional context

This issue is resolved by #69 and can be closed


Use yarn to download packages

Please open a new issue and completely fill out the provided issue template.


Documentation for RxJava and Aggregates

Fixes #419 and #420

LGTM, rebased and merged as 39cf1e272de929d6da83d0fe4546e86072158e41 along with fixing above comments 2c40db0cd8e122ff8d8436a10ab98ee7389aa503


Fix mongoskin version

newer version of mongoskin 1.4.11 breaks the app initialization.

no longer relevant, since we've moved to the standard mongodb driver


Add context to errors using anyhow

ref #1
This adds context to most of the errors, except direct invocations of do_swrk_with_response, as the result that it returns, specifically rcp::criu_resp is not compatible with anyhow's Result type requirements.
Please take a look.
Thanks :)

@adrianreber please take a look. Thanks :)

Overall this looks good. Thanks. We are using bin.rs as our test script. Can you check for one of the newly added error messages in bin.rs (if that is possible). Please also add a Signed-off-by line to your commit message to make the DCO checker happy.

Hey, apologies for the delay, I have added the signed-off.
I haven't added any new errors, only added contexts to existing errors, so I think all are already covered in bin.rs.
@adrianreber  Please take a look, Thanks :)

@adrianreber ping!


cmd/go: ignore unused modules more intelligently.

What version of Go are you using (go version)?

$ go version
go version go1.15.1 darwin/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/nick.revin/Library/Caches/go-build"
GOENV="/Users/nick.revin/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/nick.revin/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/nick.revin/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.15.1/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.15.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/zq/pjk9rp297blc98tc4phgv6b80000gp/T/go-build258952378=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Tried to verify and tidy go modules.
The background:
One of the direct dependencies of the project has an indirect dependency of bitbucket.org/ww/goautoneg but it turns out that this project has been removed/abandoned recently.
Moreover, all the dependencies are vendored and despite the fact that operator-sdk requires a whole chain of its own dependencies the aforementioned bitbucket.org/ww/goautoneg is not actually needed or used since I can't find it in the vendor directory.
Thus the project can be built without issues because all the dependency requirements are met but the go mod commands are not working since they cannot find the repository with bitbucket.org/ww/goautoneg
This issue looks similar to #26602 but the problem is more subtle. While one of the declared indirect dependencies is actually missing we are not using it anyway.
This change https://go-review.googlesource.com/c/go/+/255960/ introduces the -e flag to mod tidy and mod vendor commands
It would be great to allow similar best effort strategy for other go mod subcommands. Because currently if some indirect dependency cannot be loaded or resolved none of the commands can be used. They just print out the failing subtree and exit.
What did you expect to see?
$ go mod verify -e
not all modules verified
go<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>reading https://api.bitbucket.org/2.0/repositories/ww/goautoneg?fields=scm: 404 Not Found
$ # does best effort package verification ignoring the failing path.

What did you see instead?
$ go mod verify
go<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>reading https://api.bitbucket.org/2.0/repositories/ww/goautoneg?fields=scm: 404 Not Found

Duplicate of #36460

(That issue has been basically my main project for the year, and this example is exactly the kind of use-case we intend to address with it.)