TST: More realistic zmq test.

Now the test ensures that event and descriptor documents go
through 0MQ successfully. As far as we can tell nothing is
broken, but this is a better test for future-proofing the code.

Codecov Report

Merging #805 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #805      +/-   ##
==========================================
- Coverage    85.8%   85.78%   -0.03%
==========================================
  Files          18       18
  Lines        4805     4805
==========================================
- Hits         4123     4122       -1
- Misses        682      683       +1

Impacted Files
Coverage Δ

bluesky/tests/utils.py
75.52% <0%> (-0.19%)
:arrow_down:

Continue to review full report at Codecov.

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

I think coverage is confused.


trees are not ordered by adaptation nor by suitability when compactobjectives is false

trees are not ordered by adaptation nor by suitability when compactobjectives is false (SCSM and Czech tools)

Bug corrected (commit 1d39a2c)


Margin and fontSize alignment of TagCount

RHINENG-7746
The tag number and icon seems to be misaligned and font-size is off in the context of surrounding content.
Before:
fontSize: 16px
margin: 10px

After:
fontSize: 14px
margin: 6px

Any changes or improvements to this PR are welcome.

Preview: https://react-component-groups-pr-component-groups-225.surge.sh

@jiridostal looks good, thank you. Let me just check quickly on the variables. It's preferred to use them instead of hardcoded values

Let's use the variable over the hard coded values so all changes can be adopted with future variable updates! Thanks!

Also, The tag count styling seems to be a little off, not sure if this is still in the works with another issue on text and icon color

@kaylachumley yeah, the remaining issues will be tracked separately. Thank you!


(udc_test.py) Incompatible shapes: [80,1] vs. [160,1] error even after changing the batch size

Getting the below error, please help.
`INFO:tensorflow:Results after 1180 steps (0.934 sec/batch): loss = 0.493843, recall_at_1 = 0.399258474576, recall_at_10 = 1.0, recall_at_2 = 0.592213983051, recall_at_5 = 0.868485169492.
Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 1022, in _do_call
return fn(*args)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 1004, in _run_fn
status, run_metadata)
File "/usr/lib/python3.5/contextlib.py", line 66, in exit
next(self.gen)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/framework/errors_impl.py", line 469, in raise_exception_on_not_ok_status
pywrap_tensorflow.TF_GetCode(status))
tensorflow.python.framework.errors_impl.InvalidArgumentError: Incompatible shapes: [80,1] vs. [160,1]
[[Node: prediction/logistic_loss/mul = Mul[T=DT_FLOAT, _device="/job:localhost/replica:0/task:0/cpu:0"](prediction/Squeeze, prediction/ToFloat)]]
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "udc_test.py", line 39, in
estimator.evaluate(input_fn=input_fn_test, steps=None, metrics=eval_metrics)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/util/deprecation.py", line 247, in new_func
return func(*args, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 436, in evaluate
name=name)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 816, in _evaluate_model
max_steps=steps)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/graph_actions.py", line 754, in evaluate
session.run(update_op, feed_dict=feed_dict)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 767, in run
run_metadata_ptr)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 965, in _run
feed_dict_string, options, run_metadata)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 1015, in _do_run
target_list, options, run_metadata)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 1035, in _do_call
raise type(e)(node_def, op, message)
tensorflow.python.framework.errors_impl.InvalidArgumentError: Incompatible shapes: [80,1] vs. [160,1]
[[Node: prediction/logistic_loss/mul = Mul[T=DT_FLOAT, _device="/job:localhost/replica:0/task:0/cpu:0"](prediction/Squeeze, prediction/ToFloat)]]
Caused by op 'prediction/logistic_loss/mul', defined at:
File "udc_test.py", line 39, in
estimator.evaluate(input_fn=input_fn_test, steps=None, metrics=eval_metrics)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/util/deprecation.py", line 247, in new_func
return func(*args, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 436, in evaluate
name=name)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 800, in _evaluate_model
eval_ops = self._get_eval_ops(features, labels, metrics)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 1106, in _get_eval_ops
features, labels, model_fn_lib.ModeKeys.EVAL)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 1047, in _call_model_fn
model_fn_results = self._model_fn(features, labels, mode=mode)
File "/home/rohitg/Documents/chatbot-retrieval-master/udc_model.py", line 83, in model_fn
tf.concat(0, all_targets))
File "/home/rohitg/Documents/chatbot-retrieval-master/models/dual_encoder.py", line 81, in dual_encoder_model
losses = tf.nn.sigmoid_cross_entropy_with_logits(logits, tf.to_float(targets))
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/ops/nn_impl.py", line 162, in sigmoid_cross_entropy_with_logits
return math_ops.add(relu_logits - logits * targets,
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/ops/math_ops.py", line 816, in binary_op_wrapper
return func(x, y, name=name)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/ops/math_ops.py", line 1037, in _mul_dispatch
return gen_math_ops.mul(x, y, name=name)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/ops/gen_math_ops.py", line 1613, in mul
result = _op_def_lib.apply_op("Mul", x=x, y=y, name=name)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/framework/op_def_library.py", line 763, in apply_op
op_def=op_def)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/framework/ops.py", line 2371, in create_op
original_op=self._default_original_op, op_def=op_def)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/framework/ops.py", line 1258, in init
self._traceback = _extract_stack()
InvalidArgumentError (see above for traceback): Incompatible shapes: [80,1] vs. [160,1]
[[Node: prediction/logistic_loss/mul = Mul[T=DT_FLOAT, _device="/job:localhost/replica:0/task:0/cpu:0"](prediction/Squeeze, prediction/ToFloat)]]
`

for udc_test.py you can set test_batch_size to 8, as a batch_size in udc_hparams.py
https://github.com/dennybritz/chatbot-retrieval/blob/master/udc_test.py#L15

Sangheli thanks, it worked, but now while running udc_predict.py am getting error
 File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 1047, in _call_model_fn     model_fn_results = self._model_fn(features, labels, mode=mode)   File "/home/rohitg/Documents/chatbot-retrieval-master/udc_model.py", line 29, in model_fn     batch_size = targets.get_shape().as_list()[0] AttributeError: 'dict' object has no attribute 'get_shape'

wich version of tensorflow you use? in tensorflow 0.11 all works correct (python 3.5)

The version am using is 0.12.0 and python 3.5

i have some problems while running this code in tf 0.12 or 0.10

Do I need to switch to .11?

yes, this helped me

Do I need to train data again or I can use the same output data there?

I don't know, I'm trained every time  I trying to solve problems, on gt 770 4gb train time about 1-2 hours(16 000 steps), to get perfect results on ubuntu text corpus, in other issues author says he train 2000 steps, to get good result

Thanks for helping me out :D

Cool it worked with .11, I wonder what is the prob with .12

@Sangheli please I am getting the same error on training, should I change batch_size or eval_batch_size in udc_hparams.py to 8 and test_batch_size in udc_test.py to 8 too ?

In my case I changed both.
In udc_hparams.py
tf.flags.DEFINE_integer("batch_size", 64, "Batch size during training") tf.flags.DEFINE_integer("eval_batch_size", 8, "Batch size during evaluation")
In udc_test.py
tf.flags.DEFINE_integer("test_batch_size", 8, "Batch size for testing")
After that it  started working. I had to rerun the train script. Also I changed my tf to version .11

if move

batch_size = targets.get_shape().as_list()[0]

to

if mode == tf.contrib.learn.ModeKeys.EVAL:
_____batch_size = targets.get_shape().as_list()[0]

code work correctly on tf 0.12 in predict mode, but you need change call of predict function, as in example https://github.com/Sangheli/chatbot-retrieval/blob/master/udc_predict.py#L68
without flag as_iterable

Can any of you make a pull request to fix this issue?

udc_predict.py return only POTENTIAL_RESPONSES zero position value


Fix ProductNames wildcard processing

🗣 Description
ProductNames does not accept wildcard to override config file.  This fixes the handling of of ProductNames in both command line and config file.
Closes #884
Closes #843
💭 Motivation and context
This will allow users to get expected results when overriding the ProductsNames via command line.
🧪 Testing

Added unit test to check for ProductNames wildcard handling, all pass
Fix unit test for ScubaConfig reset
Ran InvokeSCuBA with configuration file and wildcard ProductNames override

✅ Pre-approval checklist

[X] This PR has an informative and human-readable title.
[X] PR targets the correct parent branch (e.g., main or release-name) for merge.
[X] Changes are limited to a single goal - eschew scope creep!
[X] Changes are sized such that they do not touch excessive number of files.
[X] All future TODOs are captured in issues, which are referenced in code comments.
[X] These code changes follow the ScubaGear content style guide.
[X] Related issues these changes resolve are linked preferably via closing keywords.
[X] All relevant type-of-change labels added.
[X] All relevant project fields are set.
[X] All relevant repo and/or project documentation updated to reflect these changes.
[X] Unit tests added/updated to cover PowerShell and Rego changes.
[X] Functional tests added/updated to cover PowerShell and Rego changes.
[X] All relevant functional tests passed.
[X] All automated checks (e.g., linting, static analysis, unit/smoke tests) passed.

✅ Pre-merge checklist

[ ] PR passed smoke test check.

[ ] Feature branch has been rebased against changes from parent branch, as needed
Use Rebase branch button below or use this reference to rebase from the command line.

[ ] Resolved all merge conflicts on branch

[ ] Notified merge coordinator that PR is ready for merge via comment mention

✅ Post-merge checklist

[ ] Feature branch deleted after merge to clean up repository.
[ ] Verified that all checks pass on parent branch (e.g., main or release-name) after merge.

For issue #884 Invoke-Scuba -ConfigFilePath config.yaml -ProductNames * works now, the OPA issue still exists but it is being working on in another issue (#894).
For Issue #843 I ran the script that Thom wrote and it still doesnt seem like the [ScubaConfig]::ResetInstance() is fixed

Please include script referenced so I can evaluate.

For issue #884 Invoke-Scuba -ConfigFilePath config.yaml -ProductNames * works now, the OPA issue still exists but it is being working on in another issue (#894).
For Issue #843 I ran the script that Thom wrote and it still doesnt seem like the [ScubaConfig]::ResetInstance() is fixed

Please include script referenced so I can evaluate.

https://github.com/cisagov/ScubaGear/issues/843#issue-2098658096
this one

For issue #884 Invoke-Scuba -ConfigFilePath config.yaml -ProductNames * works now, the OPA issue still exists but it is being working on in another issue (#894).
For Issue #843 I ran the script that Thom wrote and it still doesnt seem like the [ScubaConfig]::ResetInstance() is fixed

Please include script referenced so I can evaluate.

#843 (comment)
this one

For issue #884 Invoke-Scuba -ConfigFilePath config.yaml -ProductNames * works now, the OPA issue still exists but it is being working on in another issue (#894).
For Issue #843 I ran the script that Thom wrote and it still doesnt seem like the [ScubaConfig]::ResetInstance() is fixed

Please include script referenced so I can evaluate.

#843 (comment)
this one

The script is not used how the class was intended to be used.  But I made a change to accommodate if it is misused (setting config directly instead of 'loading' from a config file).  Good catch.

@nanda-katikaneni PR is ready for merge to main


go: Unbreak Go tests.

Tests were failing with error message: "grpc: no transport security set"
This is due to a recent change in grpc-go: https://github.com/grpc/grpc-go/issues/307

lgtm

Seems like the google3 version doesn't support this yet, might have to add a regexp on import to replace:
, grpc.WithInsecure()
with nothing...

I've talked with the grpc-go guy. He won't do his import immediately because there are other upcoming changes as well. He'll CC us on his google3 import when he does it.
In the meantime, let's go with your suggest workaround.


Protecting BIOS/UEFI/firmware

If we are implementing safe sharing of bare-metal systems between untrusted parties, we need to put some thought into preventing viruses/backdoors/trojan horses from infecting the firmware.
As was mentioned in yesterday's meeting, many platforms support updating the firmware from within a booted operating system. Thus, we need to find a way of protecting this potential vector from infection.
This also includes not allowing end-users to access IPMI directly, so we'll likely need to write an IPMI proxy.

Verbiage was added to the deployment guide to address this issue. It is up to the HaaS deployer to address firmware security.


Add Dark Mode Theme To "Mahatma Gandhi Biography" Frontend Project

Describe the Feature you want to end
I would like to add a button that would change to dark mode for the website.
Expected behavior

Screenshots (optional)

Additional context (optional )

@MohitGupta121 sir kindly assign me this issue


Proposal: API/UI to Edit Daemon Configuration

This proposal builds upon the persistent configuration file proposal and exposes an API and UI for runtime editing of the daemon configuration.  Where possible, configuration changes will be performed immediately on the running daemon and yield a 204 response.  When not possible, the configuration changes will be recorded in the configuration file and take effect on a subsequent restart of the daemon, and yield a 202 response, with a response body message indicating a restart of the daemon is required for the changes to take effect.  Multiple changes may be applied in one operation, or individual changes can be performed one at a time.
An initial implementation is envisioned to only support KV store and label configuration.  Additional settings may be added over time.  Initial configuration of the KV store would be supported without requiring a restart, however changing the KV store would require restarting the daemon.  Updating daemon labels would be supported without requiring a restart.
If the configuration change requires a restart, subsequent queries for the configuration will return the persistent configuration and a status of “restart required”  Future enhancements could offer a query parameter to distinguish active from persisted state.
Display current configuration
GET /config
Display current configuration
Example request:
GET /config HTTP/1.1

Example response:
HTTP/1.1 200 OK
Content-Type: application/json

{
    “status”: “active”,
    “configuration”: {
        "cluster-advertise": “<IP_ADDRESS>:2376”,
        "cluster-store": “etcd://<IP_ADDRESS>:2379”,
        "cluster-store-opt": {
            “kv.cacertfile”: “/etc/docker/ssl/ca.pem”,
            “kv.certfile”: “/etc/docker/ssl/cert.pem”,
            “kv.keyfile”: “/etc/docker/ssl/key.pem”
        },
        “label”: {
            “storage”: “ssd”,
            “rack”: “42”
        }
    }
}

Change configuration
POST /config
Change configuration
Example request:
POST /config HTTP/1.1

{
    "cluster-advertise": “<IP_ADDRESS>:2376”,
    "cluster-store": “etcd://<IP_ADDRESS>:2379”,
    "cluster-store-opt": {
        “kv.cacertfile”: “/etc/docker/ssl/ca.pem”,
        “kv.certfile”: “/etc/docker/ssl/cert.pem”,
        “kv.keyfile”: “/etc/docker/ssl/key.pem”
    },
    “label”: {
        “storage”: “ssd”,
        “rack”: “42”
    }
}

Example response:
HTTP/1.1 204 OK

If the caller attempts to change a setting (or a map key) that was passed to the daemon as a CLI argument, the request will be rejected with a 403 response code, and a payload indicating the setting was specified via a command line argument.  To change the setting, the daemon flags must be changed manually.
To remove a setting from the configuration file, the key is passed with an empty string value in the POST.
The following examples illustrate the UI for configuration management:
% docker config set \
cluster-store=etcd://<IP_ADDRESS>:5678 \
cluster-advertise=tcp://<IP_ADDRESS>:2376 \
cluster-store-opt=kv.cacertpath=/etc/docker/ssl/ca.pem \
cluster-store-opt=kv.certpath=/etc/docker/ssl/cert.pem \
cluster-store-opt=kv.keypath=/etc/docker/ssl/key.pem \
label=storage=ssd

% docker config ls
cluster-store=etcd://<IP_ADDRESS>:5678
cluster-advertise=tcp://<IP_ADDRESS>:2376
cluster-store-opt=kv.cacertpath=/etc/docker/ssl/ca.pem
cluster-store-opt=kv.certpath=/etc/docker/ssl/cert.pem
cluster-store-opt=kv.keypath=/etc/docker/ssl/key.pem
label=storage=ssd

Just reading up on this;

your example shows setting all options at once; I take its also possible to set/update options individually?
can I export/import (save/load) all options from the CLI?
does the CLI give feedback if a daemon restart is required?
-should changing options be more atomic? I.e. what if half the options have direct effect, and the other half require a restart of the daemon?

just some quick thoughts (didn't look into the code yet)

Thanks for taking a look!  (No code yet - I'd like to try to get consensus on the approach first.)
Yes, the intention was to support individual or bulk change.  I'll update the proposal to clarify that.
On the subject of import/export round-trip via the CLI, I don't oppose making that work, but I'm not sure what the use-case is to motivate it.  Since this builds upon the configuration file proposal, I think leveraging the file directly for those scenarios might make more sense.
For the active vs. restart state of the daemon, yes, I agree that should be exposed. I'd like to try to keep the display output consistent and easily parseable, so how about an additional sub-command
% docker config status
Active

% docker config status
Restart required

No code yet - I'd like to try to get consensus on the approach first.)

Oh! You're right; was reading on my phone, lol

On the subject of import/export round-trip via the CLI, I don't oppose making that work, but I'm not sure what the use-case is to motivate it. Since this builds upon the configuration file proposal, I think leveraging the file directly ...

That could be an option, yes; assuming that we always use a configuration file. Being able to do it via the API, would allow using a different storage mechanism for these configurations. Thinking of having an easy, standardized way to configure a daemon with a pre-made configuration file.
I think @nathanleclaire may be interested in having a look at this (for docker machine)

For the active vs. restart state of the daemon, yes, I agree that should be exposed. I'd like to try to keep the display output consistent and easily parseable, so how about an additional sub-command

My biggest concern was ending up in a situation where configuration changes are only partly applied until the daemon is restarted; I haven't given that a lot of thought yet, but wondering if that could result in nasty situations.
How would this API interact with (e.g.) SystemD unit files / drop-ins? Would those need changes? Which one would take precedence?

Once we have an agreed upon way to configure the docker daemon, yes, I think it make sense for other related tools to follow that same pattern.
I think we should follow the common practice where command line flags take precedence over configuration file settings. Ultimately I think the init system should not carry the configuration, although that may take a few releases to realize.  The system daemon would rely on the configuration in the file for all the settings.  Running the daemon by hand would be the use-case where CLI flags still make sense.

IANTM (just CCed in the thread), but my feeling is that having the daemon update configuration in-place is an extremely dangerous idea, especially through a mechanism like you've outlined here.  I'd generally expect Docker daemon configuration changes to require a restart or at least a UNIX signal to the process.  All of the state management logic (and tracking what's allowed to change in place vs. what's forbidden) blows up the scope of implementing such a configuration file 10x.

What's the motivation for wanting to change configuration while the process is running?

@nathanleclaire I think only specific things would be supported here.
Specifically, being able to join (or potentially leave) a cluster is extremely helpful.

In addition to cluster membership, engine labels are used by many schedulers and users want to be able to update them dynamically.

It would be interesting to explore just reloading the config instead of dynamically change through the API.

Some thoughts:

should we allow tweaking of individual properties?  In cases like this, where you expose an API to modify something, you're basically distributing the write-access to the resource. There's usually less of a chance of conflicts, or overwrites, if everyone is forced to ssh to the box and modify a config file than there is if someone POSTs what they think is a tweak to the latest, when in fact they forgot to GET it first to be sure.  Allowing modifications to individual properties reduces the problem.  I'd still support full update though too.

this PR assumes all changes are written to disk so that a restart of the daemon will pick-up those new config file settings.  On today's call someone asked if we were going to detect changes to the on-disk config file. I don't have an opinion yet on whether we should or not, but if we did then we could easily look at this PR as exposing API on the config file itself rather than the daemon. Meaning, this API updates the config file - then the daemon cron-like process that looks for a modified config file will pick up the new values irrespective of whether the mods were done via the API or via vim.

on the point of rejecting API requests that modify cli settings, I would prefer to not do that. Let's do what they asked for since, to me, they're saying "run it with these properties from now on".  Besides, trying to track (and check) which properties were set via the cmd line vs config file just feels like a lot more work than it's worth.

FYI, there's also an existing PR for updating daemon settings; https://github.com/docker/docker/issues/17560

Related to: https://github.com/docker/docker/pull/16978   I think

with the new daemon config file stuff we may want to revisit this one (and #16978)
ping @calavera @icecrime

@duglin do you have a direct need for an API now? Wondering if we should wait one release, to see how the current config-file works out / stabilizes, before adding more features.

@thaJeztah that's fine with me.

One thing we might want to consider in the next release as a stepping stone towards this is a more machine friendly way to determine if the configuration is good.  The current setup requires OS specific tailing of log files looking for patterns which is error prone.

One potential approach would be to add something to /info that gets updated when the signal triggers the daemon to load the configuration to let us know if the dynamic config load was successful or if it encountered errors.

Keep thinking of something similar to apachectl configtest

That could work well for manual user testing, but makes it tricky when you're trying to automate configuration management from within a self-hosted privileged container.

ah, right, API
ignore me😊

We now have the daemon.json, and in future will integrate with InfraKit, which possibly could provide some options here.
I'll close this issue, but let me know if something is still needed

@thaJeztah is there a way to determine what daemon.json is currently in use? Also is there a way to determine if there were any command line overrides? I think both those would be necessary in the case where we want to programmatically reconfigure a daemon.

@endophage setting options both on the CLI and in daemon.json currently will result in an error, but we may want to design a different behavior for that. For active configuration, see https://github.com/docker/docker/issues/21559, and https://github.com/docker/docker/pull/27473#issuecomment-265830228

Good to know on CLI+daemon.json, that definitely makes things easier.
Don't see a solution in those linked items though for finding the active configuration. Simply doing cat /etc/docker/daemon.json is overly naive as a different configuration location can be passed to dockerd. Short of looking up the dockerd process, parsing how it was run to see if an alternate config was passed, and falling back to the default /etc/docker/daemon.json, I don't see a way to get either the actual active configuration, or the location of the configuration file that was loaded.


link to download the dataset in broken

Hi, I am trying to run some experiments with your method but I found that the link to the data is broken. Could you please fix it or point me to the correct link to the data?

Sorry for the problem, here is the dataset link:
Data
Thanks for pointing this out!


YARN code improvements

Story
A number of code improvements as noted in the tasks list

Looks this this is fixed.


Update README.md

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


Indent in complex expressions should respect last line indent

ENTER in the first line does not indent

ENTER should respect last line indent

https://github.com/Microsoft/RTVS/commit/30b7dcc86b562c3678d27ea21130cbbb4c34a3b8


Update sdk(for UpgradeDBEngineVersion etc.)

Summary

Update sdk(for UpgradeDBEngineVersion etc.)

Test

[x] Should success UpgradeDBEngineVersion API

🍋🉑


Error when creating docker volume

Hello,
I'd like to test out the azure driver with rancher, however I am getting the following error after following the setup instructions.
docker volume create -d azurefile --name docker -o share=docker
job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
Error response from daemon: create docker: VolumeDriver.Create: error creating azure file share: storage: service returned error: StatusCode=403, ErrorCode=AuthenticationFailed, ErrorMessage=Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:a5e77a67-001a-00c0-12f0-ed4629000000
Time:2016-08-04T01:32:22.1578801Z, RequestId=a5e77a67-001a-00c0-12f0-ed4629000000, QueryParameterName=, QueryParameterValue=

I can see the service seems to be running fine, but there is an error:
systemctl status azurefile-dockervolumedriver job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory ● azurefile-dockervolumedriver.service - Azure File Service Docker Volume Driver    Loaded: loaded (/etc/systemd/system/azurefile-dockervolumedriver.service; enabled; vendor preset: enabled)    Active: active (running) since Thu 2016-08-04 01:15:38 UTC; 22min ago      Docs: https://github.com/Azure/azurefile-dockervolumedriver/  Main PID: 21249 (azurefile-docke)     Tasks: 5    Memory: 6.3M       CPU: 113ms    CGroup: /system.slice/azurefile-dockervolumedriver.service            └─21249 /usr/bin/azurefile-dockervolumedriver
I've tried changing the storage key, same error.
I'm running the standard Xenial image, not sure if there is anything else I would need to do.

@mildlyill  It indeed looks like an issue with your storage credentials. How does your /etc/default/azurefile-dockervolumedriver file look like?
Alternatively you can stop the service (systemctl stop azurefile-dockervolumedriver) and invoke the driver directly (see azurefile-dockervolumedriver --help)  with your credentials. Please try that and keep the process running while you try to create a volume and see if it succeeds.

Thanks for the quick response. I ended up re-installing everything and it is now working,. Sorry for jumping the gun with this!


Which shader versions are supported in headless?

Hi,
I'm trying to use the Headless context, but getting errors like bundled: ERROR: 0:1: '' :  version '330' is not supported. I've tried 330, 150, 140, 130 and then finally 120, which seems to compile and run (though having trouble verifying if it looks good; ReadPixels is giving me a hard time with stack overflows). Looking at the mesa documentation it looks like they're supporting 330 though, so my question is: am I doing anything wrong (do I need to link with mesa some how? or is there a settings flag to enable newer shader versions?) or is glutin using an older version of mesa?
I'm on OSX Yosemite 10.10.5

OS X uses their own OpenGL implementation, and not Mesa.
Versions 2.1, 3.3 and 4.2 are supported, and the one you actually get depend on the parameters you pass when creating the context. However a crappy implementation on the side of glutin is not excluded (several things related to OS X in glutin are crappy).

Hm yeah something seems to not work, I tried explicitly loading 3.3:
let window = glutin::HeadlessRendererBuilder::new(1024, 768)
  .with_gl(glutin::GlRequest::Specific(glutin::Api::OpenGl, (3, 3)))
  .build().unwrap();

And then changing the shader version to 330 in my (very simple) shader, but I still got:
thread '<main>' panicked at 'bundled: ERROR: 0:1: '' :  version '330' is not supported

Posted an issue for this here: https://github.com/tomaka/glutin/issues/635


Impossible to translate the _error page

I'm migrating to the v8 and I have a problem when I try to translate my _error page because only supports the getInitialProps. Is this scenario contemplated?

As mentioned in the README, getIntialProps is not supported. However, you can use getServerSideProps on your error page and achieve the same result.

When I try to use the getServerSideProps on the _error page I'm getting this error running the build:
Error: Error for page /_error: pages with getServerSideProps can not be exported

Im having the same issue too...
-next-i18next lib needs to be initialized via getServerSideProps() or getStaticProps()
-My error page requires to be translation enabled AND dynamically generated (either via getServerSideProps() or getInitalProps())

I don't understand why this is closed. This problem is unresolved, the propsed solution does not work.

The custom error page supports all data-fetching methods. @magnattic Please refer to the docs.

@isaachinman Where do you read that in the docs? The _error page only supports getInitialProps. See also this comment from a next maintainer confirming this.
I tried it myself and got

Error occurred prerendering page "/500". Read more: https://nextjs.org/docs/messages/prerender-error
Error: Error for page /_error: pages with getServerSideProps can not be exported. See more info here: https://nextjs.org/docs/messages/gssp-export

Yes, that example is using getStaticProps though, not getServerSideProps. :) Also it's not the _error page, but the 404 page (not sure if that difference matters).
You said multiple times in this thread that getServerSideProps is supported, but I don't think that is true. At least I haven't seen how that would work and all my attempts failed. As far as I understand now, the _error page has to be statically generated and cannot include any runtime info. I might be wrong though.
When I use getStaticProps I can use the translations. I just can't include any runtime info from the request (like response error message). Or if it's possible, I haven't found out how yet.

The exact same pattern would work with getServerSideProps.

I appreciate that you are taking the time to help, but as I said unfortunately that's not true. I copy pasted the example you provided and replaced getStaticProps with getServerSideProps. I get the error which seems quite clear:

Build error occurred
Error: pages/404 can not have getInitialProps/getServerSideProps, https://nextjs.org/docs/messages/404-get-initial-props

Are you working on a different version of nextjs? I am currently on next v10.1.3

Hi I face the same issue as @magnattic.
404 pages support only getStaticProps()
This limitation seems to be coming from Nextjs itself.
The only way to get the error page to be passed dynamic props is via the
_error getInitialProps(). Though nextjs supports this next-i18next's latest
version does not support it. Best option is roll back to older version of
the module, it supports getInitialProps, or wait until nextjs itself
supports getServerSideProps for 404 page.
Its sort of a dilemma atm..
On Thu, 17 Jun 2021, 00:38 magnattic, @.***> wrote:

I appreciate that you are taking the time to help, but as I said
unfortunately that's not true. I copy pasted the example you provided and
replaced getStaticProps with getServerSideProps. I get the error which
seems quite clear:
Build error occurred
Error: pages/404 can not have getInitialProps/getServerSideProps,
https://nextjs.org/docs/messages/404-get-initial-props
Are you working on a different version of nextjs? I am currently on next
v10.1.3
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/isaachinman/next-i18next/issues/1020#issuecomment-862641836,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA6GWASUEDNO6HFDWUTN4GLTTDZCVANCNFSM4YRAI33Q
.

Just want to mention that getInitialProps should also work, if you pass the props correctly. Relevant line of code here. Please don't be afraid to read source code!

I faced the same issue when upgrading an old project from next-i18next v4 (before it used Next i18n routes).
The problem with _error.jsx is that it only supports getInitialProps. This function can be invoked on the client if an error has occurred after page load. This means that we can’t use serverSideTranslations in _error.jsx.
So what I did was creating pages/404.jsx and pages/500.jsx to handle not-found pages and server-side errors. Those pages call serverSideTranslations inside getStaticProps –  no problems with that. Then for client-side errors I imported react-error-boundary and used it in _app.jsx. Translations work in it well as long as corresponding namespaces are preloaded by all pages. Error messages can be put into the common namespace because they can appear on any page.
Seems like the new setup works – I have been able to fully remove _error.jsx from the project.

https://nextjs.org/docs/advanced-features/error-handling#handling-client-errors
For those looking to do this without adding another dependency (TS):
PageErrorBoundary.tsx
import { Component } from "react";
import { TFunction, withTranslation } from "next-i18next";

type Props = {
  t: TFunction;
};

type State = {
  hasError: boolean;
};

class PageErrorBoundary extends Component<Props, State> {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  componentDidUpdate(
    prevProps: Readonly<Props>,
    prevState: Readonly<State>,
    snapshot?: any
  ): void {
    // Resets state on page switch (from page with error to other page)
    if (prevState.hasError) this.setState({ hasError: false });
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  render() {
    if (!this.state.hasError) return this.props.children;
    return <p>{t("client-side-error-occured")}</p>
  }
}

export default withTranslation("common")(PageErrorBoundary);

In app.tsx, wrap Component with PageErrorBoundary and you're done.

Next.js:

Error does not currently support [...] getStaticProps or getServerSideProps [ed. only getInitialProps]

next-i18next:

serverSideTranslations is not compatible with getInitialProps, as it only can execute in a server environment, whereas getInitialProps is called on the client side when navigating between pages.

Next.js Error component source code: https://github.com/vercel/next.js/blob/v12.1.4/packages/next/pages/_error.tsx

Why is this issue closed? 🤔
_error.jsx is a replacement for Next.js Error component. Error component doesn't work with data-fetching methods like getServerSideProps or getStaticProps. next-i18next supports only getServerSideProps or getStaticProps. So I believe there is no way to translate Error using next-i18next

I faced the same issue when upgrading an old project from next-i18next v4 (before it used Next i18n routes).
The problem with _error.jsx is that it only supports getInitialProps. This function can be invoked on the client if an error has occurred after page load. This means that we can’t use serverSideTranslations in _error.jsx.
So what I did was creating pages/404.jsx and pages/500.jsx to handle not-found pages and server-side errors. Those pages call serverSideTranslations inside getStaticProps – no problems with that. Then for client-side errors I imported react-error-boundary and used it in _app.jsx. Translations work in it well as long as corresponding namespaces are preloaded by all pages. Error messages can be put into the common namespace because they can appear on any page.
Seems like the new setup works – I have been able to fully remove _error.jsx from the project.

@kachkaev Is there any case when the server can respond with a status code, that not equals 404 or 500? For example, 403. What page will be shown in this case ? 🤔

@kaguya3222 FYI: I achieved this with a workaround. I posted my solution here: https://stackoverflow.com/a/76390043/13929165

I am also facing this issue, wondering how I would be able to translate my error pages. The only alternative while still using next-i18next I see would be to serve error pages only in english.

@isaachinman @adrai
Why is this issue closed ?
It is clearly still a problem.
The exact problem - https://github.com/i18next/next-i18next/issues/1020#issuecomment-1090060525
The best work around for now seems to be remove the Custom _error page and adopt an Error Boundary at Page level or load the translation on client side.
These are far from the ideal solution.

see https://github.com/i18next/next-i18next/issues/1950#issuecomment-1248489253
and https://github.com/i18next/next-i18next/issues/1950#issuecomment-1372633266

I believe I found a proper workaround.
You can use the 500.page.js as your error page as a fallback to the _error.page.js
By throwing an error when attempting to render _error.page.js, that will force next.js to fallback to 500 which can be SSG with all the translations you need.
One caveat is that you get an additional log for an error, but that's small price to pay.
// _error.page.js
import * as Sentry from "@sentry/nextjs";

function CustomErrorPage() {
  return null;
}

// This custom error page is only used to record issues in Sentry
// This will throw an error and force Next.js to render the static 500.page.js
//
CustomErrorPage.getInitialProps = async contextData => {
  // In case this is running in a serverless function, await this in order to give Sentry
  // time to send the error before the lambda exits
  await Sentry.captureUnderscoreErrorException(contextData);

  if (contextData.res) {
    throw new Error(
      "_error page reported issue to sentry - redirecting to 500.page.js",
    );
  }

  return {};
};

export default CustomErrorPage;

/// 500.page.js
import React from "react";

import { serverSideTranslations } from "next-i18next/serverSideTranslations";

import ErrorPage from "components/ErrorPage/ErrorPage";
import { init } from "components/i18n/source";

export default function CustomErrorPage() {
  return <ErrorPage />;
}

export async function getStaticProps({ locale: ctxLocale }) {
  // FIXME: This is a Next.js bug where locale is sometimes undefined
  // https://github.com/vercel/next.js/issues/32309
  const locale = ctxLocale || "en-US";
  const translations = await serverSideTranslations(locale, ["common"]);

  init(locale, translations._nextI18Next.initialI18nStore);

  return {
    props: {
      ...translations,
    },
  };
}


[Request] TrafficMonitor - Lite Version

Package Request
Information
Name:
TrafficMonitor - Lite Version
Description:
Lite version of TrafficMonitor.  Does not required Administrator to run, does not contain GPU, Hard Disk or temperature monitoring
Homepage:
https://github.com/zhongyang219/TrafficMonitor
Download link(s):
https://github.com/zhongyang219/TrafficMonitor/releases
Some indication of popularity/repute:
TrafficMonitor full version is already in extras bucket.
https://github.com/ScoopInstaller/Extras/blob/master/bucket/trafficmonitor.json

Can you make a PR? Should be simple.


ISO 19115 CI_RoleCode added to vocab.ices.dk

I would like the ISO 19155 CI_RoleCode added to vocab.ices.dk for use in oceanography and beyong.
Codetype: CI_RoleCode
Codetype description: Function performed by the responsible party
Items within the list can be found at
https://standards.iso.org/iso/19115/resources/Codelists/cat/codelists.html
https://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml
http://vocab.nerc.ac.uk/collection/G04/current/

@HjalteParner what was the decision from DIG?

@cekv which decision?

https://vocab.ices.dk/?ref=1434
Update the Description of the CodeType
Link to the valid references

@Osanna123 will you also add the missing items? Oceanography at least need the Distributor role as well for now

Description in https://vocab.ices.dk/?ref=1434 is improved, missing concepts are added.
@HjalteParner note only Custodian, originator and owner are visible. Others can be made visible on demand.

@Osanna123 I will also need Distributor to be visible.
Thanks for your effort


Add support for DOM standard interfaces

This is a great library and it's already been extremely useful for a number of things. 🙂👍
Is there a design reason why the APIs deviate from the DOM standard, or is it just the way it ended up?
I won't go into too much detail here, but the fact that property names and functions have different names and types is extremely disruptive, if you're trying to integrate with existing code and tests, etc. - and especially in TypeScript.
To be clear, I'm not asking for or expecting a full implementation of the DOM standard - I'm not asking for any new features per se. But even code that requires a subset of a DOM interface does not immediately work without remapping the node model to something compatible first.
Would you be at all open to changing this? I might be able to help. (It would be a break change, of course.)
(I apologize if this has already been asked and answered - it seems unlikely I could be the first person to ask, but I did search your issues and, to my surprise, I didn't find anything.)

Transferred to domhandler, as this is more appropriate here.


⚠ Bofrost.be has degraded performance

In ed675d0, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 941 ms

Resolved: Bofrost.be performance has improved in ab44ee4.


Enabling Config Values to Use ENV Variables

This Pull-Request enables the config files to have variables as "$OPENAI_API_KEY" in place of the actual value.
This is needed not to share sensetive data in dotfiles over source control (git).

Thanks for your contribution, I'll be releasing a new version promptly.


remove fixed width from "Top User" badge tooltip.

Fixes Issue: #2 by removing the fixed width on the tooltip of the badge.

Merged. Thank you.


Headers not being accurately detected

Describe the bug
The header in the hierarchy is not being correctly identified if "Show headers" is enabled.
To Reproduce

Create a note Test note with backlinks
Create a note Test note with links, with the content:

## Test header 1
- Some text
## Test header 2
- [[Test note with backlinks]]

View the Influx panel on Test note with backlinks

Expected behavior
The header identified for the backlink will be "Test header 2"
Screenshots

Desktop (please complete the following information):

OS: macOS
Version [e.g. 22]

Additional context
N/A

I'm also having this issue, but inconsistently. For example, I record bulleted meeting notes all under a H1 heading, but only the heading appears in the linked file.
In another case from last week, the header connection worked just fine.

I am also having this issue inconsistently.  Also on MacOS, Ventura 13.3.1.

I'm also having this issue. Apparently, all occurrences are reported under the first matching header.

I observed the same issue with a note like this:
[[A]]

# Heading

where Heading is detected as heading for the link [[A]].
I guess this is related to #32. It would be really nice if the closest headline would be used instead of the topmost one.


fixed wrong gc calculation

Before the task state refactoring the class ExpungeOverdueLostTasksActor had following logic to filter unreachable tasks which received 24 hours no updates:
  def filterLostGCTasks(tasks: Map[PathId, AppTasks]): Iterable[Task] = {
    def isTimedOut(task: Task): Boolean = {
      task.mesosStatus.fold(false) { status =>
        val age = clock.now().toDateTime.minus(status.getTimestamp.toLong * 1000).getMillis.millis
        age > config.taskLostExpungeGC
      }
    }
    tasks.values.flatMap(_.tasks.filter {
      case TemporarilyUnreachable(task) if isTimedOut(task) => true
      case _ => false
    })
  }

During the refactoring the filter was changed to
tasks.values.flatMap(_.tasks.filter(task => isTimedOut(task.mesosStatus)))
which misses the fact that it should filter the unreachable tasks, which I re-introduced with this PR by adding task => task.isUnreachable && isTimedOut(task.mesosStatus)

LGTM, I guess that we need to cherry-pick this, so a changelog entry would be nice =)

LGTM after the style updates.

Thanks for fixing this nasty bug!


Restructured "Experimental features" article

Rendered article for review:
https://review.docs.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/experimental-features/?branch=pr-en-us-1426

Docs Build status updates of commit 49b34ed:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-edge/devtools-guide-chromium/3d-view/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/experimental-features/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/inspect-styles/edit-fonts.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/media/experiments-devtools.msft.png
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/media/search-console-icon.msft.png
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/media/search-console-new-tab.msft.png
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/whats-new/2020/06/devtools.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/whats-new/2020/08/devtools.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/whats-new/2020/10/devtools.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/whats-new/2021/02/devtools.md
:white_check_mark:Succeeded
View

microsoft-edge/puppeteer/index.md
:white_check_mark:Succeeded
View

microsoft-edge/toc.yml
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit a2135ff:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-edge/devtools-guide-chromium/3d-view/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/experimental-features/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/inspect-styles/edit-fonts.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/media/experiments-devtools.msft.png
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/media/search-console-icon.msft.png
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/media/search-console-new-tab.msft.png
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/whats-new/2020/06/devtools.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/whats-new/2020/08/devtools.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/whats-new/2020/10/devtools.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/whats-new/2021/02/devtools.md
:white_check_mark:Succeeded
View

microsoft-edge/puppeteer/index.md
:white_check_mark:Succeeded
View

microsoft-edge/toc.yml
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@captainbrosset - re:

I'm failing to see where search-console-icon.msft.png and search-console-new-tab.msft.png are being used in the doc you changed. I can't see any content that uses those images. Did I miss something? Or should the images be removed from the PR?
Related to the above images: they appear to be using the dark theme and should probably use the default light theme instead.

I'll now delete those two png files.  Those png files were from the Closed (not Merged) PR when the new feature was accidentally added to the Experiments article (it's not an Experiment).  In that PR, I also did the full edit of the Experiments article.  To preserve that edit-pass, I created the present PR by branching from that PR.


⚠ Bofrost.at has degraded performance

In 6dfb188, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1979 ms

Resolved: Bofrost.at performance has improved in 424f819.


[feat] Show heal in progress status

Ref: https://github.com/zwave-js/zwavejs2mqtt/issues/969#issuecomment-812457763

Hi,
is there some function we can call through driver function-feature to get a list of healed nodes (or possibly "unhealed" nodes) while waiting for this feature?

Hi @jmgiaever I dunno, @AlCalzone is there a method to actually check if a node is healing?

What's wrong with the progress events that the driver emits while healing?

Nothing wrong with them, that's the way I will implement this. It's just a temporary solution asked by @jmgiaever until I implement one on the UI.
BTW I will try to implement it this afternoon if I have some free time

At the moment, you can't see in zwjs2m which nodes that is healed and which isn't. Some battery powered devices takes a long time (in this case days, about a week now and still waiting) to heal.
Manual wake-up helps this process, but it would be nice to have a solution to easily see which nodes is not healed yet. I guess this is something that lacks in zwjs2m.
But we have the option to issue a «custom JS call» through the UI, and I was hoping that a call to the driver could help me figure out which nodes I need to wake up - while waiting for the feature in zwjs2m.

@jmgiaever

I was hoping that a call to the driver could help me figure out which nodes I need to wake up

That's not possible, because the feature is designed differently.

Thank you so much @robertsLando. Just upgraded and now doing a heal. How can I use the new feature?

You should just see a new column in control panel ui that shows heal status of the nodes

Hm, but I can't see it.

Tried clearing cache too.

Doh, my mistake! I had obviously selected columns sometime in the past, and pressing «reset table» fixed it.
Sorry for that.... but the column is empty. Had to stop the heal and start it over again. Not sure if that's related to that the field was hidden when starting the first heal.

ATM that field is refreshed only while doing an heal, no info is persisted on the nodes :)

Ah, then it makes sense why it disappears. I've seen that you're going to store the state now on nodes, from the bug I filed. It will make this feature golden, as the heal might take long an there's big chances that I will close the browser (e.g turn of machine to bring with on a remote job) before I'll start investigate which nodes I must wake up manually. Thank you. Great job! :)

PR reaedy to fix this


Measurable Ratings: display rating_scheme_item descriptions

This will help users understand complex rating schemes.
On the measurable view (may be add a rating scheme widget on the summary section?):

On the app rating section:

Sounds good, are you planning on the impl ?

Not currently planned Dave, may be in a future sprint.


Converted remaining pages into global

Converted remaining pages into global css and kind of completed the Home page, if you guys feel any thing need to be done differently, we can first merge my branch into the global-styles and we can proceed with development on the global style branch, from there onwards.
I have no idea at what stage the main branch is at currently, so let decide afterwards, whether we should merge the global-styles branch also to main branch and clear out the multiple branches created and left open.

This section needs refinement, the tags are overlapping

Also the styling in design is this way 👇

In this section the title and cards should start from the same point. The view more button should be placed in line with title

Same with the following section, also here the entire word should uppercased

BG colour. Aayein?

Rest is fine for now ✌

Ill update the issues for 2nd and 3rd sujjestion. For the 1st sujjestion, the word belt, lets create and issue, as i am facing it challenging to solve.

I guess, for suggestion 3 the bgcolor looks fine as of now, we can change it to something else later, based on further UI improvement.
For suggestion 2, i was thinking of having the view more link as a oval shape button, which will be at the center of the cards and the card at the right most behind the view more button will be blurred.
For Suggestion 1 i have created an issue.
We can merge this branch as of now, and someone can take forward from the global-styles branch.

Suggestion 2 done, we can merge the PR


How to use getSocket return value in PHP?

I would like to use Mosquitto-PHP together with React-PHP.
React-PHP uses stream_select to detect if a socket is ready for something.
The socket parameter used in stream_select and socket_select are resources, but the Mosquitto-PHP getSocket function returns a long integer.
I have never written any extension code my self, but tried to look at the code for stream and sockets, to see if I could change the unix socket to a PHP resource before returning from getSocket. But they seem to use two different resources.
Does anybody know how to convert a unix socket (integer) to a PHP resource?

I'm not entirely sure if this is useful, as I've not played with React and Mosquitto together yet, but I do have an example of using the result of getSocket with ext/event:
https://github.com/mgdm/Mosquitto-PHP/blob/master/examples/event.php
Does that help at all?

@mgdm Thank you very much.
It turned out that I forgot to revert my attempt to return a resource from the getSocket function. :innocent:
But I learned about the pecl event extension, and found that React-PHP actually supports it already, I just had to uninstall the libevent extension first.
After I found my bug in the getSocket function I reverted it back to libevent again and both seems to work fine.
My previous test with socket_select and stream_select both failed, but somehow the libevent based extensions can handle the long integer file descriptor. That is good enough for me.

@kernelguy Did you try to specifically make a PHP socket resource and register it?
Looking at PHP's socket_create() a PHP socket resource is created from the integer reference returned from the POSIX socket() call. This is thrown into a struct with its type and is registered as a PHP resource and returned using;
RETURN_RES(zend_register_resource(php_sock, le_socket));
https://github.com/php/php-src/blob/master/ext/sockets/sockets.c#L1391
(slightly different in earlier branches https://github.com/php/php-src/blob/5.5.9/ext/sockets/sockets.c#L1391)
Surely something very similar must be doable on an already existing socket?
Scope might be a problem, though. At least le_socket is gettable using php_sockets_le_socket() if that's in scope, but don't know about php_socket structure.
An alternative socket_create() could probably do it, but it would be annoying to have to deal with a homebuilt PHP compared to an extension.
Mikkel

It doesn't return a resource right now, but when I get a spare minute I'll try it and see if it actually works.

Got it to compile using this patch. Haven't tested it runtime yet ;).
I'm on Ubuntu 14.10 using PHP-5.5.12.
On master branch they use zend_register_resource() instead of ZEND_REGISTER_RESOURCE() in socket_create(). (valid link to non-master; https://github.com/php/php-src/blob/PHP-5.5.12/ext/sockets/sockets.c#L1370).
diff --git a/mosquitto.c b/mosquitto.c
index 7bb5a51..df25888 100644
--- a/mosquitto.c
+++ b/mosquitto.c
@@ -9,6 +9,7 @@
 #include "zend_API.h"
 #include "ext/standard/php_filestat.h"
 #include "ext/standard/info.h"
+#include "ext/sockets/php_sockets.h"
 #include "php_mosquitto.h"

 zend_class_entry *mosquitto_ce_client;
@@ -602,7 +603,19 @@ PHP_METHOD(Mosquitto_Client, getSocket)
        PHP_MOSQUITTO_RESTORE_ERRORS();

        object = (mosquitto_client_object *) mosquitto_client_object_get(getThis() TSRMLS_CC);
-       RETURN_LONG(mosquitto_socket(object->client));
+       php_socket *php_sock = emalloc(sizeof *php_sock);
+       php_sock->bsd_socket = mosquitto_socket(object->client);
+       php_sock->type = AF_INET;
+       php_sock->error = 0;
+       php_sock->blocking = 1;
+       php_sock->zstream = NULL;
+
+    if (IS_INVALID_SOCKET(php_sock)) {
+        php_error_docref(NULL, E_WARNING, "Unable to create php_socket resource");
+        efree(php_sock);
+        RETURN_FALSE;
+    }
+       ZEND_REGISTER_RESOURCE(return_value, php_sock, php_sockets_le_socket());
 }
 /* }}} */

Cool, thanks! If you get a chance to test it Is quite happily merge a PR :-)

On 4 Mar 2015, at 16:55, Mikkel Kirkgaard Nielsen<EMAIL_ADDRESS>wrote:
Got it to compile using this patch. Haven't tested it runtime yet ;).
I'm on Ubuntu 14.10 using PHP-5.5.12.
On master branch they use zend_register_resource() instead of ZEND_REGISTER_RESOURCE() in socket_create(). (valid link to non-master; https://github.com/php/php-src/blob/PHP-5.5.12/ext/sockets/sockets.c#L1370).
diff --git a/mosquitto.c b/mosquitto.c
index 7bb5a51..df25888 100644
--- a/mosquitto.c
+++ b/mosquitto.c
@@ -9,6 +9,7 @@
#include "zend_API.h"
#include "ext/standard/php_filestat.h"
#include "ext/standard/info.h"
+#include "ext/sockets/php_sockets.h"
#include "php_mosquitto.h"
zend_class_entry *mosquitto_ce_client;
@@ -602,7 +603,19 @@ PHP_METHOD(Mosquitto_Client, getSocket)
PHP_MOSQUITTO_RESTORE_ERRORS();
    object = (mosquitto_client_object *) mosquitto_client_object_get(getThis() TSRMLS_CC);

  RETURN_LONG(mosquitto_socket(object->client));

  php_socket *php_sock = emalloc(sizeof *php_sock);

  php_sock->bsd_socket = mosquitto_socket(object->client);

  php_sock->type = AF_INET;

  php_sock->error = 0;

  php_sock->blocking = 1;

  php_sock->zstream = NULL;

if (IS_INVALID_SOCKET(php_sock)) {

   php_error_docref(NULL, E_WARNING, "Unable to create php_socket resource");

   efree(php_sock);

   RETURN_FALSE;

}

  ZEND_REGISTER_RESOURCE(return_value, php_sock, php_sockets_le_socket());

}
/* }}} */
—
Reply to this email directly or view it on GitHub.

@mikini Nice digging ;-)
I tried it and got a runtime error on a missing IS_INVALID_SOCKET.
After adding the following right after the include lines it works:
#ifdef PHP_WIN32
# include <win32/sockets.h> /* Not tested */
#else
# define IS_INVALID_SOCKET(a)	(a->bsd_socket < 0)
# define set_errno(a) (errno = a)
#endif

I looped the following test code:
            $read   = array($client->getSocket());
            $write  = null;
            $except = null;
            debug_log("print_r(\$read): ".print_r($read, true));
            $num_changed_sockets = socket_select($read, $write, $except, 30);
            if ($num_changed_sockets === false) {
            } else if ($num_changed_sockets > 0) {
                $client->loop(0);
            }

And the first call to getSocket returns a valid resource, but the second caused socket_select to bark an exception:
[04-Mar-2015 18:13:39 UTC] print_r($read): Array
(
[0] => Resource id #20
)

[04-Mar-2015 18:13:39 UTC] Polling mqtt loop
[04-Mar-2015 18:13:39 UTC] print_r($read): Array
(
[0] => Resource id #23
)

[04-Mar-2015 18:13:39 UTC]
Exception: ErrorException
1 WARNING socket_select(): unable to select [9]: Bad file descriptor

Hi folks,
I made a PR to return resources instead, and added an example of its usage, in this PR: https://github.com/mgdm/Mosquitto-PHP/pull/23
If that's any use to you, then I'll merge it. I've got tests for it in another branch too that will land shortly.

Thanks for following up on this, Michael.
The PR looks fine, but one major issue came up after digging into @kernelguy 's loop problem;
When the socket resource is out of scope the PHP garbage collector seems to deallocate the php_socket structure AND close the POSIX file descriptor inside it.
As mosquitto_socket() will continue to return the (now closed) socket fd, subsequent use of any resource returned by getsocket() will fail with EBADF/"Bad file descriptor".
Output from PHP with "php_error_docref(NULL, E_NOTICE, "socket fd: %i", sockfd);" in getSocket() and var_dump($socket) in a loop doing assignment of getSocket() to $socket then socket_select():
Notice: Mosquitto\Client::getSocket(): socket fd: 26 in /web/https/mosquitto2.php on line 41
resource(2) of type (Socket)

Notice: Mosquitto\Client::getSocket(): socket fd: 26 in /web/https/mosquitto2.php on line 41
resource(3) of type (Socket)
Warning: socket_select(): unable to select [9]: Bad file descriptor in /web/https/mosquitto2.php on line 49
socket_select() failed, reason: Bad file descriptor

Of course this also sever the mosquitto client library's connection with the MQTT broker. Can't elaborate on the correct way for the library to react to being back-stabbed like this. But at least I think mosquitto_socket() ought to check whether it has a valid socket before returning it. I'm cooking up a mosquitto bug report raising this question.
Regarding Mosquitto-PHP, could getSocket() somehow mark the socket resource to be non-collectable by the GC to prevent it from closing the mosquitto file descriptor?
Mikkel

Ah ha. I have an idea, I'll attempt to implement it. Basically, we can up the ref count on the zval that getSocket() returns, so that it won't be GCed until the Mosquitto\Client does. It means I need to keep a handle to that zval inside the mosquitto_client_object structure so I can free it when the Client goes away.

Sounds exactly like "the right thing" to do ;).
I've reported mosquitto bug 461714 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=461714) regarding the validity of the mosquitto_socket() fd.

The ref count solution works for me.
I still have one issue though: When I close the mosquitto server, I get an onDisconnected event which is correct.
Then when I start the server again, I get the on connected event, where I make a call to getSocket to get the resource to listen on incoming data in reactphp.
But now, using this socket, I get a lot of spurious "socket ready for read" events, even though no data is available.
I tried to run some tests on the handle, like feof and stream_get_meta_data, but both fails because it is not a streaming resource.
Could it be that getSocket still returns the old socket?


feat: add test

issue: #8
Was added support for test

Please remove package lock json and I think the PR can be merged

I think is more a rebase in this case. As this PR includes new packages, the lockfile changed.

@Israel-Laguan @Katsu08 i think is ready to merge


throw if detekt cannot find any files, i.e input was most likely configured wrong

Expected Behavior
Detekt task exits at least with a non 0 code - preferably with a message that input was configured wrong
Current Behavior
Detekt is happy
Context
I had a project which was a multi-project build. I have configured detekt as follows:
detekt{
 input = files(subprojects*.collect { it.projectDir })
}

At some point I simplified the structure and converted it to a single project. Detekt continued to run but did not analyse anything and I have not detekted (:wink:) that for a long time

I can't reproduce your issue. Which version of detekt are you using? Could you provide a sample project to demostrate this?

I can't reproduce your issue. Which version of detekt are you using? Could you provide a sample project to demostrate this?

The latest one I reckon, you can try out https://github.com/robstoll/niok/commit/c4917338abc38bfe0d008b40cba8afa02380d558
With the next commit I fixed the input again and I had to fix a few issues detekt detected:
https://github.com/robstoll/niok/commit/fb376a43c86b571c98896e78389e491ac4fbaf8e

The latest one I reckon, you can try out https://github.com/robstoll/niok/commit/c4917338abc38bfe0d008b40cba8afa02380d558
With the next commit I fixed the input again and I had to fix a few issues detekt detected:
https://github.com/robstoll/niok/commit/fb376a43c86b571c98896e78389e491ac4fbaf8e

How should a computer program detect whether such a configuration was on purpose or not. Is entirely possible that projects don't contain Kotlin but rather Java, Scala or source code of other JVM languages.
Detekt reports in all kinds of flavours show how many files have been analyzed.
I'm thinking about the following cases, where detekt is frequently used.

Template projects that as the name suggests contain no Kotlin sources.
Not every single project in multi-projects contains Kotlin sources.

Detekt task exits at least with a non 0 code

Why should it exit with a different code? Which other static source code analyzers yield an error due to the set of input source files being empty?

How should a computer program detect whether such a configuration was on purpose or not. Is entirely possible that projects don't contain Kotlin but rather Java, Scala or source code of other JVM languages.
Detekt reports in all kinds of flavours show how many files have been analyzed.
I'm thinking about the following cases, where detekt is frequently used.

Template projects that as the name suggests contain no Kotlin sources.
Not every single project in multi-projects contains Kotlin sources.

Detekt task exits at least with a non 0 code

Why should it exit with a different code? Which other static source code analyzers yield an error due to the set of input source files being empty?

Is entirely possible that projects don't contain Kotlin but rather Java, Scala or source code of other JVM languages.

I don't get why you think I am talking about Kotlin only here. is detekt { input =...} only for Kotlin?
Anyway, I am not talking about any specific language, the use case I am talking about here is that I have messed up input so that detekt has basically 0 files to analyse. That's almost always an error and not on purpose. Otherwise there is no point in setting up detekt at all IMO. There is also not a need for a flag such as allow 0 files IMO, one implement a flag on its on and not apply the detekt plugin in such cases

Why should it exit with a different code?

I guess you are in a sarcastic mood ifor something and can answer yourself why a program which has an erroneous setup exits with something different than 0 :wink:

Is entirely possible that projects don't contain Kotlin but rather Java, Scala or source code of other JVM languages.

I don't get why you think I am talking about Kotlin only here. is detekt { input =...} only for Kotlin?
Anyway, I am not talking about any specific language, the use case I am talking about here is that I have messed up input so that detekt has basically 0 files to analyse. That's almost always an error and not on purpose. Otherwise there is no point in setting up detekt at all IMO. There is also not a need for a flag such as allow 0 files IMO, one implement a flag on its on and not apply the detekt plugin in such cases

Why should it exit with a different code?

I guess you are in a sarcastic mood ifor something and can answer yourself why a program which has an erroneous setup exits with something different than 0 :wink:

I don't get why you think I am talking about Kotlin only here. is detekt { input =...} only for Kotlin?

Suppose input = mydir:
How should detekt know whether mydir contains no Kotlin source files on purpose or not?
It's entirely possible that a directory without Kotlin code at the given point in time is configured on purpose.

input so that detekt has basically 0 files to analyse.

This can be seen in the built-in reports of detekt. Why should detekt terminate because of that?
By the way, you can implement this behavior with detekt's custom report feature. If there is actually 0 analyzed code, you could throw an exception.

I guess you are in a sarcastic mood or something and can answer yourself why a program which has an erroneous setup exits with something different than 0 😉

Excuse me, this wasn't meant sarcastic. It was a serious question.
Which other static source code analyzers yield an error and terminate due to the set of input source files being empty?

I don't get why you think I am talking about Kotlin only here. is detekt { input =...} only for Kotlin?

Suppose input = mydir:
How should detekt know whether mydir contains no Kotlin source files on purpose or not?
It's entirely possible that a directory without Kotlin code at the given point in time is configured on purpose.

input so that detekt has basically 0 files to analyse.

This can be seen in the built-in reports of detekt. Why should detekt terminate because of that?
By the way, you can implement this behavior with detekt's custom report feature. If there is actually 0 analyzed code, you could throw an exception.

I guess you are in a sarcastic mood or something and can answer yourself why a program which has an erroneous setup exits with something different than 0 😉

Excuse me, this wasn't meant sarcastic. It was a serious question.
Which other static source code analyzers yield an error and terminate due to the set of input source files being empty?

It's entirely possible that a directory without Kotlin code at the given point in time is configured on purpose.

I agree that the directory can be empty at the point of configuration but when running detekt then, IMO, detekt should fail if it does not need to analyse anything at all. I don't know detekt well enough, maybe my assumption that input = can only be specified once leads to the confusion here; or in other words, maybe I should change the title of the issue to throw if detekt does not need to analyse any files (again, I am not talking about Kotlin files exclusively, I am talking about 0 files of what any kind).

Which other static source code analyzers yield an error and terminate due to the set of input source files being empty?

Don't know any on top of my head but I think it makes sense to error on misconfiguration instead of happily exit with 0 which in turn means the build/CI will not fail, giving the dev creating e.g. a PR as well as the reviewer a false view of the actual state (i.e. that the source code might be full of violations.)
I know a test-runner which exits with 0 if it cannot find any tests to execute and IMO this is the same use case. junit5 fails if --fail-if-no-tests is specified

It's entirely possible that a directory without Kotlin code at the given point in time is configured on purpose.

I agree that the directory can be empty at the point of configuration but when running detekt then, IMO, detekt should fail if it does not need to analyse anything at all. I don't know detekt well enough, maybe my assumption that input = can only be specified once leads to the confusion here; or in other words, maybe I should change the title of the issue to throw if detekt does not need to analyse any files (again, I am not talking about Kotlin files exclusively, I am talking about 0 files of what any kind).

Which other static source code analyzers yield an error and terminate due to the set of input source files being empty?

Don't know any on top of my head but I think it makes sense to error on misconfiguration instead of happily exit with 0 which in turn means the build/CI will not fail, giving the dev creating e.g. a PR as well as the reviewer a false view of the actual state (i.e. that the source code might be full of violations.)
I know a test-runner which exits with 0 if it cannot find any tests to execute and IMO this is the same use case. junit5 fails if --fail-if-no-tests is specified

I know a test-runner which exits with 2 if it cannot find any tests to execute and IMO this is the same use case. junit5 fails if --fail-if-no-tests is specified

Technically we could add a flag in the config file to achieve this. I'm unsure of the usefulness of this flag as it seems more an edge case to me 🤔
Also JUnit 5, as you mentioned, is returning a success if there are no tests to run (as they have the aformentioned flag).
Moreover the detekt task is a SourceTask. I don't know your exact detekt configuration, but you can probably add a doLast that will fail the task if source is empty or not.

I know a test-runner which exits with 2 if it cannot find any tests to execute and IMO this is the same use case. junit5 fails if --fail-if-no-tests is specified

Technically we could add a flag in the config file to achieve this. I'm unsure of the usefulness of this flag as it seems more an edge case to me 🤔
Also JUnit 5, as you mentioned, is returning a success if there are no tests to run (as they have the aformentioned flag).
Moreover the detekt task is a SourceTask. I don't know your exact detekt configuration, but you can probably add a doLast that will fail the task if source is empty or not.

First of all, feel free to close this issue, it's an idea, but I can live without it (can add an own check).
IMO a static analysis tool which tries to detect problems should also detect a wrong setup which is a problem as well and IMO a big problem because it covers up all real problems sitting there in the code. IMO this check should not be behind a flag but better behind a flag than nothing.

I don't know your exact detekt configuration

This was the erroneous configuration:
https://github.com/robstoll/niok/commit/fb376a43c86b571c98896e78389e491ac4fbaf8e#diff-49a96e7eea8a94af862798a45174e6ac43eb4f8b4bd40759b5da63ba31ec3ef7L71
As you can see, I have mis-configured input and pointed it to an empty list. The project had once subprojects where this configuration was correct but not anymore and I forgot to change it when I refactored the project to a single project. Since detekt was always green, I did not detect it for a long time.

First of all, feel free to close this issue, it's an idea, but I can live without it (can add an own check).
IMO a static analysis tool which tries to detect problems should also detect a wrong setup which is a problem as well and IMO a big problem because it covers up all real problems sitting there in the code. IMO this check should not be behind a flag but better behind a flag than nothing.

I don't know your exact detekt configuration

This was the erroneous configuration:
https://github.com/robstoll/niok/commit/fb376a43c86b571c98896e78389e491ac4fbaf8e#diff-49a96e7eea8a94af862798a45174e6ac43eb4f8b4bd40759b5da63ba31ec3ef7L71
As you can see, I have mis-configured input and pointed it to an empty list. The project had once subprojects where this configuration was correct but not anymore and I forgot to change it when I refactored the project to a single project. Since detekt was always green, I did not detect it for a long time.

I've done a bit more research on this front just to understand what was happening.

but you can probably add a doLast that will fail the task if source is empty or not.

This is the check you can add to your build.gradle if you want your build to fail once the input is empty.
 gradle.taskGraph.afterTask {
     if(it.state.noSource && it.path == ":detekt"){
         throw new StopExecutionException("Detekt has an empty input")
     }
 }

What happened in your case was that you provided an empty input for detekt. The detekt task is a SourceTask that exists with the NO-SOURCE status if the input is empty. Technically our code not ever runs, and Gradle just realise that the task has no input so it can be skipped.
This is making adding a failOnEmptyInput config property even more complicated, as the culprit in this case was of Gradle and of how task execution is computed.

IMO a static analysis tool which tries to detect problems should also detect a wrong setup which is a problem as well and IMO a big problem because it covers up all real problems sitting there in the code.

Agree. Though in this specific case you instructed Detekt to pick an input that turned out being empty. I have several examples of Gradle modules that have no source code but have Detekt applied (a BOM, an Android resource only module, etc.). For those modules is totally reasonable to have Detekt just being skipped and resulting in a success.
The problem was that what you consider a "wrong setup" could be valid instead for another use case.
What we could do is list the snippet I posted in our official documentation, so others can benefit from it.

I've done a bit more research on this front just to understand what was happening.

but you can probably add a doLast that will fail the task if source is empty or not.

This is the check you can add to your build.gradle if you want your build to fail once the input is empty.
 gradle.taskGraph.afterTask {
     if(it.state.noSource && it.path == ":detekt"){
         throw new StopExecutionException("Detekt has an empty input")
     }
 }

What happened in your case was that you provided an empty input for detekt. The detekt task is a SourceTask that exists with the NO-SOURCE status if the input is empty. Technically our code not ever runs, and Gradle just realise that the task has no input so it can be skipped.
This is making adding a failOnEmptyInput config property even more complicated, as the culprit in this case was of Gradle and of how task execution is computed.

IMO a static analysis tool which tries to detect problems should also detect a wrong setup which is a problem as well and IMO a big problem because it covers up all real problems sitting there in the code.

Agree. Though in this specific case you instructed Detekt to pick an input that turned out being empty. I have several examples of Gradle modules that have no source code but have Detekt applied (a BOM, an Android resource only module, etc.). For those modules is totally reasonable to have Detekt just being skipped and resulting in a success.
The problem was that what you consider a "wrong setup" could be valid instead for another use case.
What we could do is list the snippet I posted in our official documentation, so others can benefit from it.

Thanks for the analysis. Surely good to include the snippet 🙂👍
Personally, I would add a flag doNotFailOnEmptyInput which one needs to use in case of a BOM pom project or similar. I would even go that far to not provide a flag at all. Instead, such projects should simply not apply detekt because its for nothing. Or does detekt also check non-source related stuff?

Thanks for the analysis. Surely good to include the snippet 🙂👍
Personally, I would add a flag doNotFailOnEmptyInput which one needs to use in case of a BOM pom project or similar. I would even go that far to not provide a flag at all. Instead, such projects should simply not apply detekt because its for nothing. Or does detekt also check non-source related stuff?

Instead, such projects should simply not apply detekt because its for nothing

Agree, but if you use subprojects {} or allprojects {} block in your top level build.gradle file (as a lot of our users are doing), you're applying the plugin to all the modules.
The current behavior makes sure those modules with not source are not breaking your overall builds.

Instead, such projects should simply not apply detekt because its for nothing

Agree, but if you use subprojects {} or allprojects {} block in your top level build.gradle file (as a lot of our users are doing), you're applying the plugin to all the modules.
The current behavior makes sure those modules with not source are not breaking your overall builds.

I most of the time use subprojects or configure(...) instead of a build.gradle in the subproject. So I would do the following
configure(subprojects.filter{ !it.name.contains("-bom") }){
  apply(...)
}
//or
subprojects {
  if(!it.name.contains("-bom")) apply(...)
}

And there you have your flag. No big deal IMO. But I see that you are hesitant to take a more restrictive approach than the current one in the sense of fail-if-no-input by default. Fine with me, I brought up my points, I think it's clear by now that both approaches require more or less the same amount of implementation in detekt and for the workaround. In the end, members of detekt need to decide more on a principal level IMO.

I most of the time use subprojects or configure(...) instead of a build.gradle in the subproject. So I would do the following
configure(subprojects.filter{ !it.name.contains("-bom") }){
  apply(...)
}
//or
subprojects {
  if(!it.name.contains("-bom")) apply(...)
}

And there you have your flag. No big deal IMO. But I see that you are hesitant to take a more restrictive approach than the current one in the sense of fail-if-no-input by default. Fine with me, I brought up my points, I think it's clear by now that both approaches require more or less the same amount of implementation in detekt and for the workaround. In the end, members of detekt need to decide more on a principal level IMO.

I agree with @schalkms and @cortinico. Your point have sense but it could break other users flows. It seems that the use cases where you want empty source sets are legit. So I'm going to close this issue.
I do appreciate this kind of uses related with UX. Few people report things like this. But I think that in this case it's better to keep the plugin as it is now.

I agree with @schalkms and @cortinico. Your point have sense but it could break other users flows. It seems that the use cases where you want empty source sets are legit. So I'm going to close this issue.
I do appreciate this kind of uses related with UX. Few people report things like this. But I think that in this case it's better to keep the plugin as it is now.


*.sch-bak files looks like distraction

Looks like without a .gitignore some less useful files have made into this repo like *.sch-bak
Is there any interest for me to PR removal and some .gitignore?

Excuse me, can you explain?

GIT is version control system right? When we use version control we address the need for backup files (sch-bak) with GIT approach not file based approach?

This file is a backup file from KiCad.

Yes, that's a backup file from KiCad. That's exactly why it should not be published in any git repository.

Does it matter? I mean, it's just a simple backup file.