WEF setup fails on retry due to running service

Operating System Version: Windows 10 Pro x64
Provider (VirtualBox/VMWare): VirtualBox
Vagrant Version: 2.2.3
Packer Version: 1.3.4
Is the issue reproducible or intermittent?: Reproducible

Description of the issue:
During initial setup, I received the error shown below.  I've attempted to start the provisioning again using both vagrant up --provision and vagrant up wef --provision but both eventually error out with the second error below indicating that the wecsvc service is already running.
I was able to fix this by updating the install-wefsubscriptions.ps1 file with a check to see if the service is running. Suggest adding additional error handling.
else
{
    Write-Host "WEF Subscriptions already installed, moving on"
    if ((Get-Service -Name wecsvc).Status -ne "Running")
    {
      net start wecsvc
    }
}

Initial Error
wef: ï»¿Windows Event Collector service was configured successfully.
==> wef: Running provisioner: shell...
C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/communicators/winrm/helper.rb:61:in `winrm_port': undefined method `each' for nil:NilClass (NoMethodError)
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/communicators/winrm/helper.rb:22:in `winrm_info'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/communicators/winrm/communicator.rb:190:in `create_shell'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/communicators/winrm/communicator.rb:130:in `shell'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/communicators/winrm/communicator.rb:107:in `block in ready?'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/timeout.rb:93:in `block in timeout'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/timeout.rb:33:in `block in catch'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/timeout.rb:33:in `catch'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/timeout.rb:33:in `catch'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/timeout.rb:108:in `timeout'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/communicators/winrm/communicator.rb:106:in `ready?'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/machine.rb:274:in `guest'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/provisioners/shell/provisioner.rb:170:in `provision_winrm'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/provisioners/shell/provisioner.rb:27:in `provision'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/provision.rb:138:in `run_provisioner'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:95:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/environment.rb:526:in `hook'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/provision.rb:126:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/provision.rb:126:in `block in call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/provision.rb:103:in `each'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/provision.rb:103:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/providers/virtualbox/action/clear_forwarded_ports.rb:15:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/providers/virtualbox/action/set_name.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/providers/virtualbox/action/clean_machine_folder.rb:17:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/call.rb:53:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/call.rb:53:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/call.rb:53:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/box_check_outdated.rb:36:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/providers/virtualbox/action/check_virtualbox.rb:26:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/call.rb:53:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builtin/call.rb:53:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/providers/virtualbox/action/check_virtualbox.rb:26:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/machine.rb:239:in `action_raw'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/machine.rb:208:in `block in action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/environment.rb:614:in `lock'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/machine.rb:194:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/machine.rb:194:in `action'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.3/gems/logging-2.2.2/lib/logging/diagnostic_context.rb:474:in `block in create_with_logging_context'

Error 2
==> wef: Running provisioner: shell...
    wef: Running: scripts/install-wefsubscriptions.ps1 as c:\tmp\vagrant-shell.ps1
    wef: Installing WEF Subscriptions
    wef: Copying Custom Event Channels DLL
    wef: WEF Subscriptions already installed, moving on
    wef: powershell.exe : The requested service has already been started.
    wef:     + CategoryInfo          : NotSpecified: (The requested s...y been started.:String) [], RemoteException
    wef:     + FullyQualifiedErrorId : NativeCommandError
    wef:
    wef: More help is available by typing NET HELPMSG 2182.
The following WinRM command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

powershell -ExecutionPolicy Bypass -OutputFormat Text -file "c:\tmp\vagrant-shell.ps1"

Stdout from the command:

Installing WEF Subscriptions
Copying Custom Event Channels DLL
WEF Subscriptions already installed, moving on

Stderr from the command:

powershell.exe : The requested service has already been started.
    + CategoryInfo          : NotSpecified: (The requested s...y been started.:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

More help is available by typing NET HELPMSG 2182.

@grayfold3d I'll definitely add that code to check service status in the next commit. To unblock yourself for now, just destroy and re-create the box and let me know if this error happens again during provisioning:
vagrant destroy wef -f
vagrant up wef

Fixed in #210


Question: Search by index with equal comparison

Is it somehow possible to search by index with equal comparison (by value)? Do You planed to create a custom method for that?
Thanks!

Hi Sergey,
In order to do an equal comparison by value, you'll need to execute an AscendGreaterOrEqual and then do a comparison on each item from inside the iterator.
Example code: https://github.com/tidwall/buntdb/issues/18#issuecomment-281130798
Perhaps it's possible to add something like an AscendEqual method which wraps around the method above.

Thanks!


Improve deployment.yml in webhook use case

Hi @daisy-ycguo we have bigger problem running the web hook use case, the way it is specified in manifest and deployment files, fails with arbitrary error (more details in issue #311 )
./wskdeploy -m tests/usecases/webhook/manifest.yml -d tests/usecases/webhook/deployment.yml
2017/08/16 10:46:57 open tests/usecases/webhook/https://raw.githubusercontent.com/apache/incubator-openwhisk-catalog/master/packages/github/webhook.js: no such file or directory
2017/08/16 10:46:57 Error happened during execution, please type 'wskdeploy -h' for help messages.

since we have the action file available under src/, can you also update the location in the manifest file and make sure wskdeploy is able to deploy web hook use case? If not, please open another issue if wskdeploy fails with valid manifest and deployment files.

@daisy-ycguo Please verify Priti's assessment that this will not run if a user supplies valid values for the parameters.

@pritidesai @mrutkows I made changes. Please review again. Now It is runnable in my environment.

@priti @daisy-ycguo I am tempted to merge this, but have asked @houshengbo to explain what the best approach would be to inject (guest) credentials for this and other test/use cases for automation in Travis CI.  We will want another issue to work on this automation and once working copy it for our other integration tests.


Using multidimensional arrays in fake fields

Bug report
What I did:
I've created a json-column for my fake fields. During create, I've created a nested attribute:
    [                 'name'  => 'fake_attribute1[dings]',                 'label' => 'Fake Attribut 1.1',                 'type' => 'text',                 'fake'  => true,                 'store_in' => 'fake_test'             ]
Those values are stored as expected in the database.
What I expected to happen:
I've expected to see the values in the update form.
What happened:
Error:

htmlspecialchars() expects parameter 1 to be string, array given

What I've already tried to fix it:
Backpack, Laravel, PHP, DB version:
Backpack: 3.4
Laravel: 5.7
PHP: 7.2
DB: MySQL 5.7

Hi @Brotzka ,
Sorry for the late reply, but maybe it helps someone else with the same problem that stumbles into this thread. fake_attribute1[dings] is not the way we intended for fake fields to be defined. They should be defined as regular fields (so no square brackets - neither [ nor ]).
Fake fields are stored in a JSON you specify, but they're then pulled out just like they were real attributes. So you don't need to do $article->extras->fake_attribute, you can just do $article->fake_attribute. Same with defining the field, you should just specify the fake attribute in the field name, you don't need the column name there.
Hope it helps someone.
Cheers!


Supports querying on live cells with type hash

At the moment, to transact with a UDT, the users have to enter the typeScript.args in the UI and typeScript.codeHash is hardcoded to targeting the sUDT. In the future, both the args and codeHash would be dynamic variables, so we shouldn't hardcode them at that stage. On the other hand, requiring the users to enter both the variables are cumbersome and error-prone. Ideally, the users should only need to enter a unique identifier to locate the UDT they want to operate on.
Therefore, in the use case of UDT in Neuron, we need to be able to locate a type script with a type hash, which is the identifier used on the Explorer sUDT page. Being able to locate the cells using a type hash is not only more friendly to the users, but also its user experience is more consistent with the identifier used in the Explorer.
Thus, I am wondering if it is possible to have lumos indexer supports querying on type hash since it will be very useful for both Neuron and the 3rd party clients.
As this may involve the change to the ckb-indexer, I guess @quake may help in providing some guidelines here as well.

lumos, and the underlying ckb-indexer, actually do support querying only on code hash + hash type, but not args. In fact, what ckb-indexer does is that it does prefix search: it would serialize code hash, hash type and args into a flat array, and use it as a prefix to locate all related cells. That means if you use empty args, you are basically searching all cells with matching code hash and hash type.

Apart from that, I do want to want to learn what you mean when you say "locate a type script with a type hash", what is type hash here specifically?

Apart from that, I do want to want to learn what you mean when you say "locate a type script with a type hash", what is type hash here specifically?

Sorry for the confusion here. I mean the hash of a type script.

I'm really not sure what the hash of the type script alone can do. All you can do is querying some cells, there won't be any further action that can be performed on a hash of type script alone. Part of me even hold the feeling it is a mistake for us to introduce the concept of hash of type script, we should always just use the script.
If the ultimate goal here is to allow representing a UDT with a single identifier, why not just concat code_hash, hash_type and args of a type script? If that feels too long, I think we should introduce some naming solution much like what we have as CKB address.

Thanks for the suggestion.
We think having type script address to do this makes a lot of sense.


Recent update broke autocompletion

System information

OS: Windows 10
TypeScript Hero version: 1.8
VSCode version: 1.19

Description
Few days ago, the plugin worked perfectly. But with the recent update, autocompletion completely disappeared during typing. I can't automatically import a component or a service in Angular.
Moreover, I looked inside the log file and it seems OK, no error, only

2017-12-16T15:34:30.049Z - info: [DeclarationIndexMapper] rebuilding all indices
2017-12-16T15:34:38.966Z - info: [DeclarationIndexMapper] built index for workspace "project" {"durationMs":8915}

Steps to reproduce

type the component name
No suggestion provided

Came here to report the same thing.

Sorry to be a pain, any word on this?

same here


bazel/cc_configure.bzl breaks builds for C libraries

It forces use of g++ to even compile .c files, causes failure.
@htuch

cc https://github.com/istio/proxy/pull/260

Which C libraries are these?

gRPC

Basically, Bazel is completely broken today and tries to build C files with gcc instead of g++ (see https://github.com/bazelbuild/bazel/issues/2840). We needed to override this for C++. I think it wouldn't be much work to convert bazel/cc_configure.bzl to sanely handle both C and C++ with gcc and g++ respectively. I can do this, but not for a few days as I'm committed right now to the cmake-Bazel handoff, so if you need it before then, we welcome PRs.

Yes I understand. For now we can live without using cc_configure so it is not urgent, will do a PR if I have cycle.

This is fixed now, using the wrapper script in https://github.com/envoyproxy/envoy/pull/2631.


Allow File Locksmith being selected from new Windows 11 context menu

PowerToys is a very useful toolkit to have, especially with PowerRename and File Locksmith, yet first one can be selected from old and new context menu of W11, but latter only in old one. Why not both for File Locksmith as well?

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

ID: 4aa0101c-da3b-4681-8646-bfbbc6dba4e4
Version Independent ID: 4aa0101c-da3b-4681-8646-bfbbc6dba4e4
Content: PowerToys File Locksmith utility for Windows
Content Source: hub/powertoys/file-locksmith.md
Product: dev-environment
Technology: powertoys
GitHub Login: @mattwojo
Microsoft Alias: mattwoj

Thanks for taking the time to let us know about this and we sincerely apologize for the delayed response. The scope of this feedback channel covers specific documentation fixes, but I can help redirect you to the right channel to get an answer to your question. The community of experts and Microsoft Engineers over in the PowerToys repository can handle any product-specific feedback or issues.
If you do create an over there, we would appreciate if you could share that link here so we can track the progress and incorporate any technical details into our documentation if changes are made. Though I'm marking this Issue as closed now, please treat this thread as an open thread for follow-ups. Thanks!

link


Add readable test suites and move PanicOnError after metric Observe

This change is

Pull Request Test Coverage Report for Build 730

9 of 9 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.08%) to 73.424%

Totals

Change from base Build 727:
0.08%

Covered Lines:
1409

Relevant Lines:
1919

💛  - Coveralls


Add Description Field to Campaign Run Node

FEATURE OVERVIEW
User Story
Runs for campaigns for different reasons. Sometimes we add a scholarship to a campaign, sometimes there is a celebrity influencer, sometimes there is a sponsor. All of this context as to why we start a new run is not logged anywhere central to all teams, making it hard to make sense of different runs from a data/campaigns/tech perspective.
What we would like is to add a description field to a run (maybe in the Basic Info Section) that would allow a campaign lead to add a few lines of description as to why they are creating a new run of the campaign.

Additional Information (optional)
Maybe the field could have help text like, "Describe why you are creating a new run. Write it with enough context so that a future campaign lead could read it and immediately understand why a new run was created. Will this run have a scholarship? Is there a celebrity endorsing the campaign? Does the campaign have a new sponsor? In which countries is this run going to be available? etc."
Why This Matters
It's important for different teams to understand the context for creating a new run, and to help attribute campaign activity.

@chloealee mind taking a look at this while waiting for organz

@angaither so sorry - just seeing this now! Do you want me to jump on this now before moving forward with more organize work? @sbsmith86 and I just broke up some work and I was about to start creating the endpoints to hit the API on the backend and pass info to frontend.

@namimody do we also want the description to show up on this page (I've put a placeholder where it will be)?

@chloealee thanks for asking! Sure -- let's expose the run description on this view, but could we make the order:
Campaign
Campaign Closed State
Run Description
Thanks!!!

@namimody sure thing!


Fix: wrong assumption on routeName

Current assumption always validates to true. I guess the initial intention was to throw an error if a route does not start with a forward slash.
fixes #50

This will solve it, I'm merging it now

Merged! It will be published to pub.dev today


default calendar incorrectly calculates offsets for full day events. in format=relative

Please only submit reproducible issues.
the issue is the code uses startDate.fromNow() to calculate the date offset, but fromNow() uses wall clock time (hours/minutes) which causes date rounding..
the code needs to be changed to use startDate.from(moment().format("MMDDYYY"))
timeWrapper.innerHTML = this.capFirst(moment(event.startDate, "x").from(moment().format("YYYYMMDD")));
to use start of day comparisons..
will attach a PR with the changes.

The PR is merged.


Raceday Operations Dashboard - Mobile portal item text needs update

The Raceday Operations Dashboard - Mobile (https://afmiedev.esri.com/arcgis/home/item.html?id=84e6f39a706e440983a97f1fad98cc9a) portal item text needs update:
Summary:
A Mobile Operations Dashboard for Fire/Rescue to use when managing incidents on race day.
Description:
A Mobile Operations Dashboard for Fire/Rescue to use when managing incidents on race day.
The title of the item should also be changed to "Race Day Operations Dashboard - Mobile "

Since we will recreate this content on NSEC, I am closing this issue.


Problem with Path Finder

Hi
I have just installed Traffic Manager Plus to try and manage some road connections. Having then set up a pair of traffic lights on two crossings I an now having major problems with the way the system is routing vehicles.
The junctions are as follows:

A two way 4 lane road (East-West)across a edge of a manufacturing area, to the North of it.
A second two way 4 lane approaching it from the South, which has been tunnelled under a highway and links to the rest of the city and bus station.
Opposite route 2 there is a one way 2 lane road leading into the manufacturing area. To the East and West of the manufacturing area there are two way roads.
From the highway there is a one way link bridged across the highway with a link from the other lane. This then joins route 2 leaving space for 3 lorries before it meets route 1.
Also from that junction, there is a exit route which links to the highway, with an underpass to the far lane.
To the East, there is also a two way 2 lane road back into the city.
There are three bus routes running from the South, going East, North and West on reaching the manufacturing area. They all route back along the East side of route 1.

Without the traffic lights installed these junctions work as one would expect. I then set up a pair of timed traffic lights to manage the traffic flow. The routing is

Allow traffic from the South and let it enter routes 1 and 3, Allow the East side of route 1 to turn left (this is a LHD system).
Stop the traffic from the city and allow the traffic from the highway.
Stop the traffic from the highway and stop route 2 where it joins route 1. Allow the West side of route 1 to proceed and stop the East side.
Stop the West side and allow the East side to run.

This should enable the system to manage the junction correctly. Initially it seems to work and the traffic flows as I would expect. But then it goes out of control.

The traffic on the West side of route 1 continues down the East side, and then turns right and uses route 6, including to get to the highway.
The traffic on the East side of route 1 is routed directly down route 6.
The highway traffic that was using the bridge across the highway now links to route 2 South of the highway.
The three buses get as far as the route 1 and route 2 junction, turn right and loop back through the manufacturing area to get to route 6.
The bus route that was turning right onto the East side of route 1 now loops into the manufacturing area and uses the West side of route 2 to get to the East side.

It appears that the path finding functionality believes that there is no South bound route down route 2, and that the highway bridge link across is missing. If I move the bus stations on the East side of route 1 and place them onto route 2 the bus route resets to the correct route.
If I close route 6 I find that the bus routes just terminate, and despawn buses, on the last bus station. I have left it running and it seems that the system totally ignore the South bound route down route 2.
In terms of traffic I am running with the Extended Public Transport UI and Improved Public Transport 3.1.6. I have Traffic++ but have not yet activated it.
Is there a problem with your system regarding path finding?

it's a possibility. The PathManager needs a serious overhaul right now. My suggestion is to use Traffic++ in combination with this. It solves the pathing issues. Then just use this for traffic light managment / timings. They work really well together like that. I'm working on a patch for Improved AI so that it will work with that mod as well.


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-main" workflow

AWS CodeBuild CI Report

CodeBuild project: DDKIntegrationTestsD8472609-5SCHWjldmWcf
Commit ID: 298a472a36e371a4123eda245a7d9bf7e631a04c
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Questions about processing camera poses for different dataset

Hi, many thanks for your wonderful works and efforts. I'm trying to adapt some module in monosdf into my work, but I find some problems in producing appropriate data format for monosdf.
As you explained for preprocess/scannet_to_monosdf.py in #75 : 2 stands for -1 to 1 and +3 because we assume each camera sees 1.5 meters forward in scannet.
scale = 2. / (np.max(max_vertices - min_vertices) + 3.)
Could you explain more about the magic number 3. ? why should we take depth sensor detection ranges into consideration?  And why this extra "3." varies from different dataset processing, such as Replica#69 and DTU #21
@niujinshuchong I really appreciate your efforts to solve our question!

I encountered the same issue. The results are excellent when training with the dataset’s provided trajectories, but when using trajectories generated by COLMAP, the results are poor. I attempted to normalize COLMAP’s trajectories along the primary axis to the range [-1, 1] while proportionally scaling the other two axes, but the effect is still unsatisfactory. Do you have any recommendations for integrating COLMAP? Additionally, how should parameters similar to '3' be set during the transformation?


Image picker crashes and restarts the app

The image picker restarts the app usually on a real devices anytime  you try to pick from gallery or take a picture

Please use the issue tracker to report issues.
Closing as this is not an actual PR.


Send array of access rules to set

If capability exists, now sends full list of duplicates
If duplicates in the request array, send 400 and index of offending object
Updated tests

request is array of objects, each containing access ID
if need to delete individual capability, add array of caps to
be deleted to the object
Added policy text generation function (TODO, refactor POST API to use this)
Updated test

Added cascade delete on capability table if access rule deleted
Added unique constraint on access id + capability


Then performance of DFM is over qualified

I test DFM on MIND-small. Find the performance of DFM outperforms all the baselines except your proposed model.
This is puzzling, since DFM is proposed in 2018 and the framework is naive. The experiment can be find in https://colab.research.google.com/drive/1UE6Gmhphk12c7PBH1DBEZ6R8QFensZT1?usp=sharing
Do you have similar situation? Could you share your thinking on this?

This may be because that I always tried to optimize the baselines. In some cases, the baselines are over-optimized (e.g., NRMS). Especially, I found that some models are fit to small dataset, i.e., MIND-small. For details, you can contact me via my email<EMAIL_ADDRESS>

Thanks


⚠ Bofrost.de has degraded performance

In e89a113, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1067 ms

Resolved: Bofrost.de performance has improved in 52454f4 after 10 minutes.