refactor: update badges on main table

Main table refactored to distinguish more clearly between the Telegraph system status and the status of a notification.
Drawer now displays the message sent as part of a notification and all the logs associated with a notification from most to least recent.

Looks great - thanks for making these changes, really improved the readability of our dashboard.


make ResNet and DenseNet more flexible for usage on smaller images

ResNet and DenseNet both are implemented to work best for datasets containing larger images like ImageNet. This is due to the the convolutional stem with a kernel_size of 7, a stride of 2 and an additional max-pooling layer. Moreover, most of the specifications for feature map sizes and number of basic building blocks/layers are fixed/hardcoded.
Both publications however mention experiments carried out on the Cifar10 dataset. For using those architecture on datasets consisting of smaller images, the implementation is lacking some flexibility.
The proposed changes allow changing specifications of the convolutional stem, number of building blocks/layers and the number of channels in the feature maps. Those changes are implemented without losing any backwards compatibility, i.e. all pre-trained models still can be used.
Moreover, shorthand models are defined following the definitions in the original experiments. ResNets used for Cifar10 are mainly characterized by the 'depth' with other settings taken from the paper. DenseNets used for Cifar10 are characterized by the 'growth_rate' and the 'depth' with settings taken from the publication analogously.

Hey @StadlerMaximilian, I see why this is useful, but I can't decide if we want this or not. We'll have to wait for @fmassa for that. In the meantime, there are two issues that you need to address before this can get merged:

Our linter is failing with
./torchvision/models/resnet.py:129:47: W291 trailing whitespace
./torchvision/models/resnet.py:130:85: W291 trailing whitespace
./torchvision/models/resnet.py:135:95: W291 trailing whitespace
./torchvision/models/resnet.py:136:107: W291 trailing whitespace
./torchvision/models/resnet.py:144:39: W291 trailing whitespace
./torchvision/models/resnet.py:152:98: W291 trailing whitespace
./torchvision/models/resnet.py:182:121: E501 line too long (127 > 120 characters)
./torchvision/models/resnet.py:184:109: W291 trailing whitespace
./torchvision/models/resnet.py:194:121: E501 line too long (135 > 120 characters)
./torchvision/models/resnet.py:196:121: E501 line too long (134 > 120 characters)
./torchvision/models/resnet.py:197:112: E226 missing whitespace around arithmetic operator
./torchvision/models/resnet.py:400:1: E302 expected 2 blank lines, found 1
./torchvision/models/resnet.py:401:46: W291 trailing whitespace
./torchvision/models/resnet.py:403:93: W291 trailing whitespace
./torchvision/models/resnet.py:407:106: W291 trailing whitespace
./torchvision/models/resnet.py:412:1: W293 blank line contains whitespace
./torchvision/models/resnet.py:416:85: W291 trailing whitespace
./torchvision/models/resnet.py:417:102: W291 trailing whitespace
./torchvision/models/densenet.py:152:121: E501 line too long (127 > 120 characters)
./torchvision/models/densenet.py:212:1: E302 expected 2 blank lines, found 1
./torchvision/models/densenet.py:293:1: E302 expected 2 blank lines, found 1
./torchvision/models/densenet.py:296:83: W291 trailing whitespace
./torchvision/models/densenet.py:298:52: W291 trailing whitespace
./torchvision/models/densenet.py:306:82: W291 trailing whitespace
./torchvision/models/densenet.py:307:87: W291 trailing whitespace

Please address this.

The following failing tests are related:
FAILED test/test_quantized_models.py::ModelTester::test_resnet18 - AssertionE...
FAILED test/test_quantized_models.py::ModelTester::test_resnet50 - AssertionE...
FAILED test/test_quantized_models.py::ModelTester::test_resnext101_32x8d - As...

Could you look into that?

I think this PR may be related to these issues: https://github.com/pytorch/vision/issues/1570 and https://github.com/pytorch/vision/issues/1166#issuecomment-515371986
Let's see if something changed meanwhile...

@StadlerMaximilian In the light of https://github.com/pytorch/vision/issues/1570#issuecomment-558632419 I think you should hold fixing the errors above before you get green light that this will be implemented.

First of all, thank you for the comments and sorry for the trivial errors. I should have checked that in more detail.
I haven't considered that a list of modules (currently) cannot be used in torch scripts (except when using a nn.ModuleList) which lead to the AssertionError, as e.g. mentioned in the PyTorch issue #36061. Using a nn.ModuleList however would destroy the compatibility with pre-trained models.
My workaround is to limit the ResNet up to 4 layers (as the original existing implementation) and use nn.Identity to 'fill' layers if less are specified. This keeps the original structure of self.layer1, ...., self.layer4 which is compatible with torch scripts, but allows smaller networks and still introduces flexibility in changing the number of features used in those blocks. In particular, reproducing the paper's results on CIFAR10 is possible.
However, it is certainly not the most elegant form to define smaller models. What is your opinion to introduce such a feature using such a workaround?

@StadlerMaximilian Problem is that @fmassa rejected a previous proposal of the same feature as mentioned above. If nothing substantial has changed since then, I don't think we will go through with this PR. Mind that I can't make this decision; We'll have to wait for @fmassa for that. If I were you, I would stop working on this feature and wait for his feedback. Otherwise it might be wasted time.

@pmeier Thank you for the feedback. I am aware of the discussion about this issue. I needed those changes for a project anyways. And since I did some mistakes w.r.t the CI pipeline, I spent some time looking at this pipeline and how to write code correspondingly. So it is definitely not a waste of time for me.
I understand the arguments with respect to consistency. However, as it was pointed out in the original issue, the general principles of the architecture do not change for different datasets. Besides changes in the specification of the architecture (like the convolutional stem, the number of basic building blocks, and the number of channels in the features maps), the models are the same. From a systems engineering point of view, it would make more sense to make the underlying model more flexible and define specific variants for certain datasets (like ImageNet). Architecture implementations like ResNet or DenseNet specify short-hand notations for specific model variants anyways (e.g. _resnet and resnet18 calling _resnet with specific model parameters). The usage of pre-trained models is specified for those and not for the underlying base class (e.g. ResNet). As torchvision currently does not provide "pre-trained models for different datasets than ImageNet / COCO / Kinetics", one simple thing to do is keep those short-hand definitions for those pre-trained models only while allowing flexibility in the underlying architecture implementation.
On the other hand, changes allowing more flexibility probably would require similar changes for consistency reasons (all the models should work on the same classification task to some extent).

Hi @StadlerMaximilian
Thanks for opening the PR and sparkling the discussion.
I think the difficulty in here is that the design space for a given family of models is potentially very large. We should try to keep a balance between simplicity and generality. The underlying implementation of ResNet is generic enough to cover the models we have in torchvision, but as you noted it's not generic enough for other use-cases (like CIFAR).
I would actually prefer to be consistent and only have models in torchvision that have:

pre-trained weights (so that users can directly use it and do transfer learning)
been trained on a standard large-scale dataset (to make the model as generic as possible)
expect images of a common input size (so ImageNet-scale input, we have exceptions like Inception, but most models expect 224x224)

As such, I would prefer if we don't move forward with this PR, but thanks a lot for it, it is very well implemented!
In the future, if you could please open an issue first so that we could discuss about the addition of new models, it would be better as it would avoid situations like this, where you have spent time working on the PR which we might not merge in torchvision, which is a pity.


Speak to the GOV.UK Design System team about their approach for measuring the value

What
Speak to the GOV.UK Design System team about their approach for measuring the value
Why
The GOV.UK Design System team recently did an exercise on measuring the value of their design system and we could potentially learn a lot from them.
Further detail
Tim Paul's talk: Measuring the value of the GOV.UK Design System

Received some interesting feedback from some of the GOV.UK Design System team members regarding measuring value.
They recommend some techniques could be replicated for the NHS digital service manual, such as finding out how much time was spent in the research, design and development of a style, component or pattern, and then multiplying this by the number of teams using it for a simple time metric of how a Design System offers value.
However, they also provided useful feedback that some parts of a Service Manual and Design System are much harder to analyse and "show" value for, such as the community and interactivity between users that a Service Manual and Design System can provide.

Next steps

[ ] Feedback the GOV Design System catchup session findings to the whole Service Manual team
[ ] Ask the GOV Design System team if they continue to work on any of their work to show the value of the GOV Service Manual and Design system
[ ] Agree as a team what (if any) ways of working we want to try and replicate for this topic following the feedback provided by the GOV Design System team

Ask the GOV Design System team if they continue to work on any of their work to show the value of the GOV Service Manual and Design system

Tim Paul advised that the "measuring value" work that GDS previously completed was "more of a one-off" and that "some of the data [we] used would currently be very hard to sample regularly".
Tim recommended the "best, easy-to-measure data point we have for growth is Downloads of GOV.UK Frontend from NPM". I believe @AdamChrimes has done something similar with the NHS.UK frontend previously. However, this is "by no means perfect - it doesn't really give us a sense of absolute usage"


feat(copy): Add capability to transform copied files on the way

Relates to issue 113.

@linbudu599 I'd really appreciate if you would take a look at this.


Added cmdlets to get Pester failures

Get-PSPesterFailure will parse the Pester log from start-pspester and extract the failures as objects
Format-PSPesterFailure will format the failures similar to output from Pester (you can use directly without Get-PSPesterFailure)

Hi @SteveL-MSFT, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Steve Lee (POWERSHELL)). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

@iSazonov good suggestion, I'll add something to the existing testing guidelines

In future, it would be good to use it to reduce logs on appveyor and travis-ci to only display failed tests.

Only query that I would has is should these functions be added to the PowerShell repo or would it make more sense that they be added directly into Pester?
My rational behind adding to Pester is that I can see use cases for them being used outside of just testing the PowerShell Code base so to me it would make more sense for these to be added to Pester.

@kilasuit Your proposal looks very good. I think it would be better to create a Issue in Pester repo and don't block this PR.

@iSazonov - As much as I agree with your suggestion, I do feel that the onus to do so would lie with @SteveL-MSFT considering that this is his PR & his code etc etc

@kilasuit I created https://github.com/pester/Pester/issues/645 as a feature request to Pester.  I think this could be solved in a number of ways and this PR was specifically to solve a problem I encountered where we have a large number of tests for PowerShell (and growing!) and needed an easy way to just see the failures so I can investigate before pushing my changes

Is this the best way to do it?
I think you are tapping too late in the pipeline. The pipeline is something like this (pseudo code):
Invoke-Pester -PassThrough | Out-NUnitXml | Store-Xml | Parse-XunitReport | Filter-Failures | Print-Fails
You are at the end, looking at the nUnit report in XML. Instead you can tap into the pipeline right after Invoke-Pester. Get the result object PSObjects (-PassThru), filter to failures with Where, and then either use your print functions, or  you can reuse the internal Pester functions.
#store the results in a variable
$results = invoke-pester -passthru

#get first successful result (you'd do -ne "Success")
$result = $results.TestResult | Where {$_.Result -eq "Passed"} | Select -first 1

#get reference to internal Pester print function (see output.ps1 in Pester, for other output functions)
 $writePesterResult = &(Get-Module Pester) {Get-Command Write-PesterResult}

#print the result
&$writePesterResult $result
#outputs:  [+] adds positive numbers 44ms

Or just wait for us to put it directly in Pester. 😃 I just wanted to highlight what is in my opinion a better way to approach this problem.

@nohwnd I think you're right, we can close this PR and wait for pester/Pester#645


improve zafira integration points for qps-infra docker container

I'd like to have workable integrations zafira items right after starting qps-infra containers.
As I see we can automatically enable integrations for:
jenkins
rabbitmq
email
...

See new integrations.env file https://github.com/qaprosoft/zafira/blob/master/integrations.env
Include reference to variable in postgres component https://github.com/qaprosoft/zafira/blob/master/docker-compose.yml#L11
To inject variables into postgres on startup - make sure appropriate ENABLED flag equals true (it only injects if integration enabled https://github.com/qaprosoft/zafira/blob/master/database/zafira-init.sh#L12)


HDDS-4699. Remove unused OzoneClientUtils

What changes were proposed in this pull request?
Remove unused OzoneClientUtils.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-4699
How was this patch tested?
Test on local.

LGTM

LGTM

Thanks @amaliujia @ayushtkn @cku328 for reviewing.

Thanks @amaliujia @ayushtkn @cku328 for reviewing.


common: fix illegal path check

common: fix illegal path check
Description:
InstanceImplPosix::illegalPath() checks if a path illegal by comparing whether
it begins with "/dev", "/sys" or "/proc". Unfortunately, I build and run Envoy
test cases in "/develop" folder, which is totally legal, but because it begins
with '/dev' it is considered illegal. This fix makes the check more robust.
Testing: InstanceImplPosix::canonicalPath() is not mock-able right now, no new test case added.
Signed-off-by: lhuang8<EMAIL_ADDRESS>

bazel tsan failed:

yeah the Bazel TSAN issue is known, Lizan is working on a fix

/retest

please merge master to pick up tsan fix

@derekargueta @lizan @zuercher All checks passed, could you please take a look?

This still needs unit tests. I left an earlier comment describing how to test this without requiring the existence of various special paths. Let me know if that doesn't make sense.

@zuercher unit tests added.

/azp run


[usbdev, rtl] Fix auto-generated files

Signed-off-by: Greg Chadwick<EMAIL_ADDRESS>

Seems low risk to merge. This fixes the quick lint pass, so I suggest merging as soon as that has passed.

Success! Let's get this in to un-break stuff.


I have made an animation using armature and shape keys and like to export it in .glb format. At result animation of using armature exported correctly but animation of using shape keys not exporting at all. In NLA editor there are two tracks one for armature and one for body. armature animation is exporting but body animation is not exporting at all in .glb format. Thanks

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
.blend file/ .gltf
If applicable, a zipped folder containing a .blend file for exporter issues and a .gltf file for importer issues. Please take care to include all resources, such as textures in the .zip file.
Version

OS: [e.g. macOS, linux]
Blender Version [e.g. 2.82, 2.83, or build date]

Additional context
Add any other context about the problem here.

Hello,
Thanks for the report.
Please do not explain your entire problem in the title.
Also, as requested in body of template, please provide needed information (Blender version & the .blend file you are trying to export).
Without these data, I can't investigate your issue, and the problem will not be solved.

More than a month without any answer, I am going to close this ticket.


Remove ',uuu' from logs

We hoped it would give us the ~microseconds~ milliseconds, but it didn't.

If you want microseconds you want %S.%f no?

Oops - I meant milliseconds. I think microseconds would be a bit excessive. I don't want to spend more time on this, so will merge as-is.


#908 Optimize dependencies

closes #908

Could this pull request apply to Garnet as well (Tsavorite)?

Could this pull request apply to Garnet as well (Tsavorite)?

No; we don't include these there (and don't switch on TargetFramework)


Readme modification, (optimization, fix and adding some missing infos)

Pull Request Template for Home Assistant / Lovelace Card Repository
Overview
I updated the readme to the latest changes, refining some info, adding a few links to simplify navigation (especially for the fields and languages), and made a few minor fixes/additions here and there
Type of Change

[ ] Bugfix
[ ] New feature
[ ] Enhancement
[x] Documentation update
[ ] Refactoring
[ ] Other (please describe):

Appologies everyone, I forgot that the release on push action is active here...


Mention coverage job in readme

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

Coverage data is based on head (128a5a0) compared to base (8acd1d1).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main       #9   +/-   ##
=======================================
  Coverage   93.33%   93.33%
=======================================
  Files           1        1
  Lines          15       15
=======================================
  Hits           14       14
  Misses          1        1

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

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


Enable the access handler to connect to the rds database

Enables the Access Handler to connect to the RDS database

We might want to wait on merging this until after we release the preview feature


Missing packages when running nixos tests

Describe the bug
Packages are missing when running nixos tests.
Steps To Reproduce
Flake:
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.05";
  };

  outputs = { self, nixpkgs }:
  let
    system = "x86_64-linux";
    nixos-lib = import (nixpkgs + "/nixos/lib") {};
    hostPkgs = nixpkgs.legacyPackages.${system};
  in {
    checks.${system}.nixosTest = nixos-lib.runTest {
      name = "simple test";

      nodes.machine = { pkgs, ... }: {
        environment.systemPackages = [
          pkgs.gitAndTools.git
        ];
      };

      hostPkgs = hostPkgs;

      testScript = ''
        machine.start(allow_reboot = True)

        machine.wait_for_unit("multi-user.target")
        machine.wait_until_succeeds("pgrep -f 'agetty.*tty1'")
        machine.screenshot("postboot")

        with subtest("git"):
          machine.succeed('mkdir -p /tmp/git-test')
          machine.succeed('cd /tmp/git-test')
          machine.succeed('git init /tmp/git-test')
      '';
    };
  };
}

Running nix build .#checks.x86_64-linux.nixosTest fails with the error:
warning: Git tree '/tmp/nixos-test' is dirty
error: attribute 'gitAndTools' missing

 at /nix/store/5m9801ag8r5w13fl1jdvsj6pr66znrbr-source/flake.nix:17:11:

     16|         environment.systemPackages = [
     17|           pkgs.gitAndTools.git
       |           ^
     18|         ];
(use '--show-trace' to show detailed location information)

If I change the line pkgs.gitAndTools.git to hostPkgs.gitAndTools.git or to pkgs.git, the build succeeds.
The same problem exists also e.g. for the pkgs.kate package.
Expected behavior
runTest should not remove packages from hostPkgs.
Additional context
I dont know, if it is an expected behaviour or some bug, but I found nothing about this behaviour in NixOS manual.
Notify maintainers

@roberth
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.5.9, NixOS, 23.05 (Stoat), 23.05.20231027.1a3c95e`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.6`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Hi @kirillrdy, thanks for quick response!
OK, I understand now. I fixed the issue by not using the aliases (pkgs.gitAndTools.git -> pkgs.git, pkgs.kate -> pkgs.plasma5Packages.kate).
It would be helpful, if there is some note about this (aliases not being included) in the NixOS manual.
Also a suggestion how to find the non-aliased package path would help. I just used nix search nixpkgs <package-name> and just guessed what is the non aliased path.

I expected this problem when I found this setting during a test framework refactor, but it did not occur to me when I briefly looked into this issue. I'm glad that we figured out that it is important and needs to be fixed. See #265836


Add parameter $cmdacl

This changeset adds a new parameter $cmdacl that allows to set ACLs for monitoring commands using cmdallow and cmddeny. The previous behaviour on Archlinux is respected by the defaults.
For instance, setting:
chrony::cmdacl: ['cmdallow <IP_ADDRESS>', 'cmddeny 1.2.3', 'cmdallow all 1.2']

Would result in this snippet being written to the final configuration file:
cmdallow <IP_ADDRESS>
cmddeny 1.2.3
cmdallow all 1.2

I didn't implement cmdallow and cmddeny separately because they can be used several times and in the order desired by the caller.

CI failing in master too, there's a file in .gitignore that has been committed:
~/puppet-chrony $ grep "\.project" .gitignore
.project
~/puppet-chrony $ stat .project
  File: ‘.project’
  Size: 206       	Blocks: 2          IO Block: 4096   regular file

@aboe76

@nbarrientos removed the .project file.

Thanks for the review, @aboe76. If you manage to win the fight against the acceptance tests it'd be cool if you could cut and tag a new release :)

Already did 0.3.0 had your changed
Op ma 5 aug. 2019 23:41 schreef Nacho Barrientos<EMAIL_ADDRESS>
Thanks for the review, @aboe76 https://github.com/aboe76. If you manage
to win the fight against the acceptance tests it'd be cool if you could cut
and tag a new release :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aboe76/puppet-chrony/pull/47?email_source=notifications&email_token=AANXTVCJJEW7N73GAHAJMPLQDCM67A5CNFSM4IJJK4B2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3TFJYY#issuecomment-518411491,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANXTVB3TPZBY5BYPYMWJC3QDCM67ANCNFSM4IJJK4BQ
.

Already did 0.3.0 had your changed

Thanks, got confused because you didn't tag. The latest tag available is v0.2.5. Nevermind, I will work on top of the current master internally, try to get the CI green and cut an internal release.
Thanks!

Ow will tag to night
Op di 6 aug. 2019 10:39 schreef Nacho Barrientos<EMAIL_ADDRESS>
Already did 0.3.0 had your changed
Thanks, got confused because you didn't tag. The latest tag available is
v0.2.5. Nevermind, I will work on top of the current master internally,
try to get the CI green and cut an internal release.
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aboe76/puppet-chrony/pull/47?email_source=notifications&email_token=AANXTVBORC6XTWVOJ2HMP6LQDE2DPA5CNFSM4IJJK4B2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3UMJGQ#issuecomment-518571162,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANXTVFWZCMSO5XA3NJEEJLQDE2DPANCNFSM4IJJK4BQ
.


Holi Festival Filters #640

Related Issues or bug
Fixes: #[640]
Proposed Changes

Added a new folder "Festive-Filter/Holi Festival Filter" inside the Snapchat filter folder containing all the required files

@akshitagupta15june ma'am pls add the labels!


Don't support  ">=、<=、>、<"?

I read the official documents, find the rangeShardingAlgorithm supporting ">=、<=、>、<", but it has no effect, just support "between and". WHY?  My version is 4.0.0-RC2.

Duplicate with #1819


How to set up your own app?

The SDK is very complex. There's functions going into the native library, and coming out somewhere else. This makes it hard to grasp what's happening and to make my own application.
Could you give some directions how one is supposed to implement one's one application on this platform? What do you recommend?
I could adapt the demo scripts, but would have to stay in your namespace (Microsoft.Azure.SpatialAnchors.Unity.Samples) which seems wrong.
I could copy everything to my own namespace, but stuff starts to break anyway.
I could integrate against AzureSpatialAnchorsBridge.cs but that would take me a year given its 10.000 lines.
Any tips?
Thanks in advance.

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

ID: 42599e6f-3abc-e5c3-fdb7-f59b68cf2b6e
Version Independent ID: 4f3b38e7-1ac0-569c-b1ba-13c0e2c4df3f
Content: Quickstart - Create iOS Unity app with Azure Spatial Anchors
Content Source: articles/spatial-anchors/quickstarts/get-started-unity-ios.md
Service: azure-spatial-anchors
GitHub Login: @craigktreasure
Microsoft Alias: crtreasu

@jelmerS2 Thanks for the question! We are investigating and will update you shortly.

@jelmerS2 Thanks again for all your feedback! Would you please post this as a feedback here https://feedback.azure.com/forums/919252-azure-spatial-anchors  and share the link on this issue? This will allow the community to upvote and for the product team to prioritize what is included into their plans.
We also have the "Give Product Feedback" button in our documents now to take you directly to the appropriate feedback page.


[Staging & Production] Add-ons: inconsistent list order in configuration table for Project Settings and user Settings

Steps

Go to the user settings, add-on configuration table
Go to a project settings, add-on configuration table

Expected
The order would be consistent from one to the other so a user would not mistakenly click incorrectly.
Actual
Project settings for add-on configuration are listed alphabetically.  User settings are listed in a random, illogical order.

This is fixed.


Add description option to map! macro

vim.keymap.set has an option which allows setting a description to a key mapping.
This add an optional 4th argument to the map! macro setting that description.

@Nsidorenco added a simpler implementation in 3a9642c


"peers online" is erratic

unclear how many people are "in the room".

just made some updates which i think significantly improved this....only time will tell, though


ORAXEN : 1.20.6 problem NOTE_BLOCK (WORKING IN 1.20.4 & 1.21)

Hey !
Problem to setup ore from ORAXEN Oraxen-1.181.0 and minecraft 1.20.6 but working in 1.20.4 &1.21 !. I only see NOTE_BLOCK.


Hint: Apply TestLessThanEqual corresponding to Fix Issue #102

implements TestLessThanEqual.
makes cases for running the tests.

Implemented as commented.
Naming convention :


Reinstated Bazel Windows local build

bug fixed for no pollers on Linux
reintroducing changes reverted by #18390
note that all pollers are correctly included for Linux builds

Yeah, we just discussed this with Bill. We may need to get the Bazel team involved to figure out the right way to do this, if doable at all.


Update go-containerregistry from v0.1.3 to v0.2.1.

Changes
v0.1.3 contained a dependency (which contained another...) eventually including
a version of jwt-go with CVE-2018-20699 in it. That library has been abandoned,
so the Go ecosystem is slowly picking up various changes to remove this dependency.
This also required "unpinning" go-autorest, which we seemed to be doing because of
knative. Tests build and pass without this, so let's see what happens.
/kind cleanup
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[X] Includes tests (if functionality changed/added)
[X] Includes docs (if user facing)
[X] Commit messages follow commit message best practices
[X] Release notes block has been filled in or deleted (only if no user facing changes)

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes
NONE

/retest

Looks like tests are failing trying to pull hello:latest from Dockerhub. I think it's a rate limiting issue!
I'll try to figure out why we're pulling this image...

Hmm, that might be a red herring: This is in the dind-sidecar example test, where we first try to build an image then run it. There's no "set -e" in the bash script, so we continue after the image build fails:
        Status: Downloaded newer image for ubuntu:latest
         ---> f643c72bc252
        Step 2/3 : RUN apt-get update
         ---> Running in d0dd2faacc8c
        io.containerd.runc.v2: failed to adjust OOM score for shim: set shim OOM score: write /proc/343/oom_score_adj: invalid argument
        : exit status 1: unknown
        REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
        busybox      latest    219ee5171f80   7 days ago    1.23MB
        ubuntu       latest    f643c72bc252   2 weeks ago   72.9MB
        Unable to find image 'hello:latest' locally
        docker: Error response from daemon: pull access denied for hello, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
        See 'docker run --help'.

/retest
This still isn't reproing for me...

/lgtm

/test pull-tekton-pipeline-build-tests

/test pull-tekton-pipeline-integration-tests


scrollTop() scrollBottom()  no effect  when  datas  changeing

scrollTop()
scrollBottom()
if I want to let it  always on the Top or Bottom when  data changed. but  It no effect.  it always on the  penult area.
waitting  for your help. thanks!

Hey, did you find workaround for the issue?

Hi @FengLinZhang @patrykcieszkowski, I can add callback to refresh method which will be called after refresh. In that callback you could call scrollBottom method. Currently it doesn't work because scrollBottom change scrollbar state before refresh method finishes it's work.
Are you ok with that solution?

@souhe sure, that sounds great!


fix(obstacle_avoidance_planner): adding missing functionality for footprint marker

Description
This PR is to add missing functionality of footprint marker in obstacle_avoidance_planner since refactoring done in https://github.com/autowarefoundation/autoware.universe/pull/2796 .

Related links
closes #4190

Tests performed
Same as mentioned in original PR : https://github.com/autowarefoundation/autoware.universe/pull/2689

Notes for reviewers
Original PR : https://github.com/autowarefoundation/autoware.universe/pull/2689
Refactoring PR : https://github.com/autowarefoundation/autoware.universe/pull/2796

Interface changes
N.A.

Effects on system behavior
This PR creates a separate footprint marker and appends it to marker_array in obstacle_avoidance_planner for easier debugging.

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

@mehmetdogru : May you please have a look and confirm it is doing the functionality intended as original implementation ?

@TakaHoribe - @kosuke55 - @takayuki5168 :
May anyone have a look please ?


Add procon-ip to the latest repository

Hi there,
as suggested by your bot (ylabonte/ioBroker.procon-ip#6 or ylabonte/ioBroker.procon-ip#7), I would like to add my adapter for the ProCon.IP pool control unit to your latest repository. Meanwhile there are also a few users that mentioned, it would be nice, to have the adapter available from your official repos. But this was inside the closed forum of the adapter's target device...
I am not clear about the process, so I think all necessary information could be taken from the adapter repository. I have tried to follow all of your checklists and guidelines for adapter development. Please just let me know if you need any further information.
Best regards
Yannic

RE-CHECK!

Automated adapter checker
ioBroker.procon-ip

:thumbsup: No errors found

[ ] :eyes: [W400] Cannot find "procon-ip" in latest repository

Add comment "RE-CHECK!" to start check anew

RE-CHECK!

Automated adapter checker
ioBroker.procon-ip

:thumbsup: No errors found

[ ] :eyes: [W400] Cannot find "procon-ip" in latest repository

Add comment "RE-CHECK!" to start check anew

Hi, here some review comments:

you have not provided a custom_m.html so please setsupportsCustoms to false!
you added the code to use Auto Adapter encryot/decrypt but you did not provided "encryptedNative" array with the fieldnames in io-package, so most likely there will be NO encryption at all! (changing this will break itfor your users potentially!) Additionally when you do it that way make sure to rename your "own" encrypt/decrypt methods in index_m.ht,l - else they conflict with the ones also build in in Admin
Please do not use setObjectAsync (https://github.com/ylabonte/ioBroker.procon-ip/blob/master/src/main.ts#L257, also https://github.com/ylabonte/ioBroker.procon-ip/blob/master/src/main.ts#L351 ...) because this can lead to custom settings being removed in older js-controller versions. User setObjectNotExistsAsync please
I was not able to find the place where info channel and info.connection  objects were created (https://github.com/ylabonte/ioBroker.procon-ip/blob/master/src/main.ts#L127) Plese add them to the instanceObjects in io-package... see e.g. tuya adapter or such
please make sure that onUnload also stops the timouts in get state service. unload currently is doing nothing. Else it will break the compact mode - did you ever tested the adapter in compact mode?

Please also have a look at  https://github.com/ioBroker/ioBroker.repositories#development-and-coding-best-practices

Hi @Apollon77,
thanks for your investigation! I will transfer your feedback into one or more issues, fix all points and maybe refactor some additional parts regarding the best practices posted above. Afterwards I will resolve the merge conflict in this PR and leave a comment here again.

Just to have this mentioned: I have re-tested the current release regarding the encryption. It is correct that I totally leveraged the built-in mechanism. But I did it that way, that the desired fields are in fact encrypted using my AES encryption/decryption functions with cryptjs. Anyways I will fix this to behave as desired by ioBroker! I just wanted to explain that there is a working encryption mechanism as I promised with my release notes. 😅
Sample objects.json from my testing environment:
{
  "controllerUrl": "U2FsdGVkX1/gdLPf/o2lRKj9V8EPuayj4exhc9MKfkUb98HLZiWrkMViwhdpx3oS",
  "basicAuth": true,
  "username": "U2FsdGVkX1/28QEx0Cs/kAPJ9EAQpcz0E8OrL7SKUFQ=",
  "password": "U2FsdGVkX1+wkLL3K9Ke1QxU8Ps7w4e55rnkNkKigsA=",
  "updateInterval": "15000"
}

Hello again,
I (hopefully?) resolved all issues arose from your feedback, created a pull request from that changes to the version you have reviewed and finally have resolved the merge conflict that meanwhile existed on this pull request.
The closed issues overview of the corresponding milestone might be a good entrypoint, if you want to review the changes in relation to the bullet points of your review.
One thing that is not visible from within the code changes: I have tested the adapter in compact mode. Simply for testing multiple instances of the adapter at once running in a single group. And after that succeeded my productive system runs the adapter together with a harmony and a fakeroku instance in one compact group.
Just let me know, if there is anything else you need to know or I should do.


Host it on free CDN (jsDelivr / CDNJS)

Hello @andris9,
I think it would be fantastic if you could host your plugin on free CDNs. It's reliable, fast and easy to use! I think it'll be great for everybody, not only me.
Here are the guidelines:

https://github.com/jsdelivr/jsdelivr/blob/master/CONTRIBUTING.md
https://github.com/cdnjs/cdnjs#adding-a-new-or-updating-an-existing-library.

Lemme know if you need some help with this.
Cheers

I'm not really familiar with these providers. I see though that jsdeliver offers an automatic update scheme, so maybe you'd be willing to set up jsdelivr support yourself?

Here's the PR: https://github.com/jsdelivr/jsdelivr/pull/7544
Would it be possible to add a minified version of your plugin in the repo?

I created the grunt task and released new version with minified file v0.1.4

Awesome @andris9 ! I will edit the pull request. I will close this issue as soon as the PR gets merged.

It's live @andris9 http://www.jsdelivr.com/projects/simpleStorage. I'm closing this. Would be great if you could update the README.md to add something about the CDN use.


goto seems only to be working on second call when data is not loaded yet

Description
By calling goto(t) when t is outside the loaded data rage, the correct chunk loading is being triggered, but the chart first jumps to the desired time range, jumps then back to the current time. Once the data loading is done and I trigger goto(t) again, everything works as expected. How can I avoid this and jump to t right away or can be informed that the loading is done so I can call goto(t) again?
Code
Code can be based on DataHelper.vue from tests, but requires a dynamic chunk loading.
<button v-on:click="goto">GOTO</button>
methods: {
    goto() {
        this.$refs.tvjs.goto(<timestamp>)
    }
}

Additional info: once I call goto(t) the second time and the chart is at the correct time range the chart crashes on scrolling (100% cpu load, page not responding any longer), tested on Chrome and Safari


Replace gradle with maven

+1

+2

I understand Gradle is a different tool, which means a learning curve again.
Having mavenLocal() declared in the repositories was a mistake and PRs are up to fix that. The right way is to go with a local init scripts for devs having to integrate development on an Ehcache 3 dependency with Ehcache 3 dev itself.
The same technique could probably resolve the request from issue #734 - ping @mathieucarbou.

@lorban : see m'y workaround when I need thé poms:
https://gist.github.com/mathieucarbou/fb791e084995bb5c12ffd817608c753d
curl -Ls https://goo.gl/qIapwy | sh


Device doesn't stay connected on iOS

I'm using this library to connect to a device but the device keeps disconnecting with this error DisconnectedPeripheral by lost signal. However the devices are sitting right next to each other. This happens on iOS every time. After about 2 - 10 seconds the device disconnects. On android the device stays connected so I know there is nothing wrong with the device.
Steps to reproduce

Connect to a device with iOS

Wait 2 - 10 seconds

Watch the device disconnect

Expected behavior
The device should stay connected
Actual behavior
The device drops connection even though the devices are right next to each other
Configuration
Plugin version: 1.1.0
OS: iOS 10.2
Devices: iPhone 5, iPhone 6 Plus
Other things I've tried:
Toggling Bluetooth off and on, on the phones and the target device.
Rebooting the phones, and the target device.
Replacing batteries in target device.
I suspect you will have a hard time reproducing this. Is there anything else I can try, or something that might give you more to go on?

@rusty21 Try to intall a 3rd party ble explorer app (like LightBlue) and try to connect your device and check if the problem still occurs. You can then post your results here :)

I used LightBlue like you suggested, and the device appears to stay connected. So that means either theres something wrong with my code, or the Plugin.Ble library. I've actually got a pcl that is shared between my iOS and Android app. Both platforms go through this pcl to interact with ble devices. So both platforms run the same code, but one works and the other doesn't. Any ideas?

RSSI seems to be between -27 and -41

I think I've figured it out. I'm using this code to connect to the device.
var tokenSource = new CancellationTokenSource ();
tokenSource.CancelAfter ((int)TimeSpan.FromSeconds (20).TotalMilliseconds);
await CrossBluetoothLE.Current.Adapter.ConnectToDeviceAsync (device, cancellationToken: tokenSource.Token);

The token gets canceled after 20 seconds and the device disconnects. Am I doing it wrong? Is there a different way I should be canceling if a device takes longer than 20 seconds to connect?

Ok. Nice catch :). It seems that we don't dispose the cancellation token registration even after the successfull connection, meaning that even after a successfull connect the original the token source can be used to cancel the connection.

Meh. fixing this isn't done with adding a using :(

should be fixed in 1.2.0


Allow a trailing wildcard to match when the final url segment is missing

This allows you to define a route like:
<app-router>
 <app-route path="/user/*" template="/user-page.html"></app-route>
</app-router>

And have it match /user in addition to /user/sub.
In combination with #67, you can then do sane nested routing without redraws
of the whole layout.

I think if I change the pattern matching rules it will be to add new options like optional patterns with () and multiple segments with **. I want to keep it as close to file globbing as possible where * matches 1 segment exactly where it isn't optional. I'll have to think about a new set of rules for a while. The set I have right now is pretty simple and not that powerful.
That said, you could use a regular expression in this case, but you wouldn't be able to get patch varialbes.
<app-route regex path="/\/user*./i" template="/user-page.html"></app-route>

The expression you want to be sure of matching only the path you're looking for is probably actually /^\/user\/*.*/i, and who wants to do that every time, or force users to work that out?
I know other routers handle a trailing wildcard this way - a trailing wild segment matches if empty, which leaves you with /user/, or /user once you drop the slash.
I was also going to look at adding **.

Yeah, regex is not fun if you haven't used it much. I want to look over some of the common routers like these and work out what they're all doing.
react router
https://github.com/rackt/react-router/blob/master/docs/guides/path-matching.md
react router component (alternative react router)
http://strml.viewdocs.io/react-router-component
angular ui-router
https://github.com/angular-ui/ui-router/wiki/URL-Routing
backbone
http://backbonejs.org/#Router
flatiron director
https://github.com/flatiron/director#api-documentation
node file globbing
https://github.com/isaacs/node-glob

Interested in this thread.  Been looking at a few routers, app-router seems promising.  I'm looking at a use case where nested routers could be decoupled from a previous path, so something like:
path="/**/user/:userId"
- could have a leading path of a number of things, such as:
- /foo/123/user/456 or
- /foo/123/bar/456/baz/789/user/123 or
- /foo/123/bar/456/baz/789/user/123?some_param=9876

I'd like to be able to load sub-modules that are concerned with just a particular chunk of the uri and still be able to get variable binding.
To support arbitrary url patterns now it seems like you can just use all params:
?foo=123&bar=456&baz=789&user=9876

But, that does make for uglier urls, and you miss out on the ability to declare those params i the route path.  Meaning:
path="*"  // nothing needed to catch params foo, bar, baz... but now I'm not using paths in a meaningful way

Very interesting dilemma.

Quick add to your router list, router.js is under Ember.js, and form what I've heard its supposedly the most powerful JS router.
router.js
https://github.com/tildeio/router.js/

The Ember router looks similar to the React router. The user manually appends the view in the route's callback. I like the concept but I don't know how I would do it in HTML. I talked about it a little here https://github.com/erikringsmuth/app-router/issues/53.
I think there are three things we need to tackle to make the app-router handle multiple routers.

We need the parent route to match zero to many child routes.
We need the child to ignore the URL prefix.
We need an option for the parent router to not re-render if only the child route changed. https://github.com/erikringsmuth/app-router/pull/67#issuecomment-69747202

Your example URLs + 1. The parent route should match all of them and the child route should match everything except the first URL.

/foo/123
/foo/123/user/456
/foo/123/bar/456/baz/789/user/123
/foo/123/bar/456/baz/789/user/123?some_param=9876

Brain dumping syntaxes here...
parent routes

/foo/:num/**
/foo/:num/?**
/foo/:num**
/foo/:num(/**)

child routes

/**/user/:userId
**/user/:userId
user/userId

The thing to ballance is syntax simplicity and algorithm simplicity for speed's sake.
Globstar ** has the nice property of matching zero-to-many path segments. I think something like this might be simple enough to implement.
parent

/foo/:num/**

child

/**/user/:userId

The react-router has the additional feature of relative routes which ignore the prefix when they don't start with a /. https://github.com/rackt/react-router/blob/master/docs/guides/path-matching.md That would mean user/userId would also work as a child route.
Do you guys have a preference on any of these syntaxes?

Nice thinking, chewing on this.

I think one of these is the right option for optionally dropping the slash:
/foo/:num/?**
/foo/:num(/**)

The first looks a bit janky, and the second makes me think it might be a match group.  I think the second option looks better though.

This is the react style route /foo/:num/?**
And this is the backbone style route /foo/:num(/**)
Although that's not entirely true because they use a different syntax than ** for multiple segments.
I like the globstar syntax for multiple segments so I started implementing it here https://github.com/erikringsmuth/app-router/compare/globstar. It can also do optional trailing paths with /foo/:num/** since a globstar can match zero segments.

I got globstars ** working and tagged a new release 2.4.0. I also added support for relative routes.
https://erikringsmuth.github.io/app-router/#/api#path
The parent route can be set up like this.
/foo/:num/**

and the child route
user/:userId

which is the same as

/**/user/:userId


WIP: Add support for project and path specific configs.

Work in progress PR to give atom support for project specific configuration files.
Requirements
Description of the Change
The purpose of this change is to add the ability for atom to act upon path and project specific configuration files (instead of just a global ~/.atom/config.{json, cson}. After these changes, key/value pairs set within a .atom/config.{json, cson} on any  mounted root will be honored by the editor. Additionally, packages will be able to set project specific settings on atom.config.
This pull request includes mostly changes to the internals of atom.config. While all existing APIs (even private class methods of atom.config) still work, their implementation has in many cases been moved out to more generic functions that can be called on arbitrary setting contexts.
Previously, the only settings context in atom was the global context, which was acted upon by the various methods of the atom.config class. There are now multiple settings contexts, each with different precedences. While atom.config.set still acts upon only the global context, atom.config.get now looks through all of the settingsContext objects, grabbing values in order of precedence. The settings contexts are:

Dirty Settings. Any setting changed by atom.config.set within the current atom session will be added to the dirty settings, which have the highest precedence. This is to prevent issues where a value is set by a package, but then cannot be retrieved because a settings context of higher precedence has already defined it.

Project Settings. Atom config now has the concept of a "project", which packages can write settings to by calling atom.config.resetProjectSettings.

Path Settings. Atom config now stores settings contexts for each of the roots mounted in the current atom session.

Global Settings. This is the original settings context found in ~/.atom/config.{json, cson}

Alternate Designs
Why Should This Be In Core?
Benefits
To allow users of atom to have project and path specific configuration, instead of just a personal .atom directory. It also lays the groundwork for other project-specific code within atom. Future directions include the ability to include suggested packages in a project(!!), and other features currently in ~/.atom, such as project specific init.js files.
Possible Drawbacks
Although no APIs were changed, the behavior of atom.config.get has been changed. get now searches through all the settings contexts, while it previously only looked through the global settings. These changes include new tests and pass previous tests, but because of the centrality of atom.config to the operation of many packages, and the many changes made to the file, we should be on the lookout for possible regressions introduced by these changes.
Verification Process
New tests were added to ensure proper behavior and to protect against regressions.
Applicable Issues
WIP

Is it really the best API choice to overload atom.config.get like this? What if a package very specifically wants to know what the user's global setting is, and has some particular reason to ignore project or path settings? It's now inaccessible, unless there are no "higher priority" settings.
Example alternative api
atom.config.set('myGlobalSetting')
atom.config.get('myGobalSetting')

atom.config.project.set('myProjectSetting', 'value')
atom.config.project.get('myProjectWideSetting')

atom.config.rootPath.set('myRootPathSetting', 'value')
atom.config.rootPath.get('myRootPathSetting')

// Explicitly request automatic resolution
atom.config.autoResolve.get('mySettingThatMayBeInAnyScope')

@skylize, The main reason we decided to go with this API design is that we want project specific settings to be applied to packages that are already using the atom.config.set and atom.config.get APIs. For example, lets say a project wants to set the default tabwidth to 15. To do this, they put inside their project's config.json something along the lines of tabwidth: 15.
In this case, existing packages are already calling atom.config.get('tabwidth') to get the tab width. If we were to implement the separate API atom.config.project.get..., then the existing packages would not be getting these new project specific settings, and the changes would not be applied.
Essentially, the reason we decided to overload is that moving the API to atom.config.project... or atom.config.paths... would make these new configs useless for any package that isn't written to respect the new API.
If a package really wants to know what a user's global setting is, than they could use the (non-public) atom.config.getRaw{Scoped}ValueFromAPI.
@matthewwithanm

Thx for the reply @philipfweiss.
Your argument definitely seems sensible at first glance. I certainly see the benefit of making the default API automatically add the new features for existing packages.
You say that "project/path configs are read-only by design". This sounds nice from the perspective of simplicity, but that also means all project/path settings must be set explicitly by the user in the Settings pane.
From a UI perspective, this can easily become a PITA for the user depending on the specific setting. If a package has a good method of adjusting certain configs based on user interaction and the user wants those changes stored at a project or path level, then developers should have the ability to store these interactive configs on the project.
With that in mind, it would be much better from the user's perspective if the API gave developers a reasonable way to opt in to explicitly handling project/path configs separately from global ones, thus allowing users to opt in to allowing the package to make project and path specific adjustments on their behalf.

Hi @skylize, I think there might be a confusion about what these changes are doing. It is not the case that "all project/path settings must be explicitly set by the user in the settings pane".
The typical user will interact with these changes in the following way:

Project owner writes a .atom/config.js in the project's home directory. The can put things in here such as suggested packages, default tabwidth, editor color, or whatever.
A user loading this project will get these settings by default whenever they have mounted the project root, since .get will resolve to the project specific settings context. One can imagine a new team member joining a project getting their team's settings just because their directory already has the config file within it (and doing no work otherwise). No other work is involved from the user's perspective. This functionality is currently in VSCode.

There is no mechanism for the user to programmatically write to the project's config.js through atom. They can change their global settings by going into the settings pane, or they can make a change to the config file and commit it. Changing the settings in the settings pane will write to the global settings file, and change the setting for that instance of atom (since it will be written to dirty settings), but it will not change the project config and the next time the user loads the project it will read from the same project config and reset the settings.

but it will not change the project config and the next time the user loads the project it will read from the same project config and reset the settings

This sounds terrible. User interacts with a package that used to save some settings permanently to a global config, and now those settings get disposed of on every restart in favor of project config, with no opportunity for packages to "just do the right thing". 👎 👎

and now those settings get disposed of on every restart in favor of project config

that's not what's happening. Any package that uses config.set still ends up writing to the user's ~/.atom/config.json as it always has.
I'd give it a spin or read through the code if you have further questions.

and now those settings get disposed of on every restart in favor of project config

that's not what's happening. Any package that uses config.set still ends up writing to the user's ~/.atom/config.json as it always has.

Ummmm.... If that's not what's happening, then why did @philipfweiss say this?

Changing the settings in the settings pane will write to the global settings file, and change the setting for that instance of atom (since it will be written to dirty settings), but it will not change the project config and the next time the user loads the project it will read from the same project config and reset the settings.

Okay. I guess I slightly mispoke when I said "disposed of". But what good is it to write to .atom/config.json if those settings will always be shadowed by some another file somewhere else in the system? There is effectively zero difference to the user between shadowed and disposed of. The point is that every time they restart, they lose all the custom settings they worked out for themselves to make their own workflow a little easier.
User should be able to customize her own editor, no matter what the project leader says the default config should be.
Maybe you will make the Project Leader happy by always resetting to his chosen config. Maybe you will even make the New Junior Dev think that he is happy on his first day at work.
But after a few weeks of having to rebuild his own custom config every single time he opens up his editor, he's probably going to lobby his boss to switch to VS Code.

I'd give it a spin or read through the code if you have further questions.

This conversation began as a discussion of API. Any attempt to "give it a spin" in this context would be a very significant time investment because I would need to build a package that puts a new and unfamiliar API through its paces.
Since the concerns are very high-level, and not to do with any specific details of the code-quality (which I assume is amazing), it seems preferable to keep discussions at that same high level, rather than me spending hours digging through code to discover something that somebody here could be explain to me in a paragraph.

I sincerely apologize if I am coming across aggressively to anybody. I shared what I thought was a possible flaw in the API, only to discover that the API was chosen because it supports an interface that (as so far described) sounds to me like it will be very unfriendly to users. If I am wrong, I am more than happy for someone to correct me. I am not here to argue, but rather to try and assist with making Atom the best it can be, and to get the jump on what I see as a potential problem before it gets pushed onto the master branch.

/cc @damieng @daviwil

What does 'project' mean in this context?  Today it means the set of root folders with associated window state but such a concept doesn't have a project-specific location to store a settings config file.

Hey all! Good points here! Hopefully I can clear some things up and enumerate the options and their tradeoffs 😊
We have broad agreement that there should be different "layers" of configuration, each with different precedence, and that config.get() should get the value from the layer of the highest precedence that contains the setting.
The real question is "what does config.set() update?" (Of course, we can add arguments or other API to make it target a specific layer if needed, but what is its default behavior?) It seems reasonable that it should update the global config (~/.atom/config.json) since that's the current behavior. But we also need to maintain the invariant that getting a value after setting it returns the value you set it to.
In other words, we always need to write to the layer of highest precedence.
Possible solutions are (1) to make sure that the global config always has the highest precedence (as suggested by @Arcanemagus), (2) write to a different (or multiple) files, or (3) write to both the global config and an in-memory "dirty settings" which has the highest precedence (as currently done in the PR).
The tricky part here is that precedence involves two concepts: ownership (user vs the project owner's) and breadth (global vs per-folder).

Per-folder
Global

User

~/.atom/config.json

Project Owner
./.atom/config.json

Just considering the "ownership axis", solution 1 seems good: the user's choice is favored over the owner's. However, this is ignoring the "breadth axis," which is a pretty severe limitation. Note that it would be impossible for a user to even override their own settings on a per-folder basis. (Incidentally, it looks like this is the case with Sublime while VSCode gives precedence to per-project settings.)
On the other hand, an approach that didn't require the global user config to be given the highest precedence would allow us to fill in the user/per-folder slot of the matrix, say with a ./.atom/config-user.json. This file would specify per-project overrides, have the highest priority, and (unlike ./.atom/config.json) wouldn't be checked in to version control. (This is actually something we've already discussed but figured could be added later.) Again, solution 1 precludes this because it requires the global user config to have the highest precedence.
For these reasons, I think solution 1 isn't worth the tradeoffs. Solution 2 is a possibility but has many unanswered questions. (Do we write to more than one config? Do we need to implement config-user.json immediately to avoid changing version controlled configs?). Solution 3 ("dirty settings") has the issues you've outlined but I'm not sure I agree about the severity; it seems pretty sensible that owner-contributed settings wouldn't be updated automatically, and that it's the responsibility of the project owner not to put crazy stuff (themes) in there.

What does 'project' mean in this context? Today it means the set of root folders with associated window state but such a concept doesn't have a project-specific location to store a settings config file.

This is actually not meant to be public API and is a way for us (the Nuclide team) to experiment with the concept of a project that isn't directly analogous to the set of root folders. At Facebook, people tend to mount the root of a monorepo even when they're working on a conceptual "project" deeply nested within it. This would give us a way to tell Atom to use its config even though it wasn't a root.

How will atom.config.get know which folder provides the right context-specific setting?
It seems to me the safest option is to make atom.config.set and atom.config.get stay with just setting global and each should have an optional parameter that can specific a folder to get a more specific configuration from.
The negative is that it does mean existing atom apps/plugins need to be updated to take advantage of this but I don't see how atom.config.get is going to know the context otherwise.
Additionally this approach means we don't have to do the dirty settings hack.

Meeting outcome from discussion with Facebook on project config:

FB are redefining their PR to just be an explicit project config proposal.  i.e.   myProject.atomProject.json will be a file that will contain an array of root paths and associated config.  If you open from new File menu option or -p on command line it will open it as a project not as a text file.  atom.config.get will read from this config then global.  There will be no folder-level stuff here.
(RFC-001](https://github.com/atom/atom/pull/16698) will be tweaked to be for the root-folder level config that LSP needs which IDE team will develop.  It will only deal with root folder configs (not project level) and any atom.config.get/set call will specify the folder name (because we can't magically guess which folder the call was running in as we don't have separate contexts for each root folder that they could honor for it)
We'll rework the File/Atom menu a bit to make the project stuff clearer
Initial config file editing/viewing will be to open the file in Atom as a file and edit as text - I have some ideas on how we can make settings-view provide something down the line that is understandable that I bounced off Simurai at mini-summit (edited)


Cannot use bigtable-hbase and bigtable-dataflow together

If the two jars are used together, the BigtableOpitons is one is shaded, but not in another. Cannot use them together.

This was fixed in one of the previous releases of the cloud bigtable client.  Which version are you on now?

I'm closing this issue, since I don't think this is an actionable request on our end.  Please upgrade to the latest client.  If that does not work, please reopen this issue.

I am using 0.9.1. This is the latest release. Reopening the issue.
On Thu, Aug 11, 2016 at 12:03 AM, Solomon Duskis<EMAIL_ADDRESS>wrote:

I'm closing this issue, since I don't think this is an actionable request
on our end. Please upgrade to the latest client. If that does not work,
please reopen this issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/cloud-bigtable-client/issues/958#issuecomment-238960584,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACGoUmgAsXmdN2g5TjIjG6rbRtcPL2FIks5qehmDgaJpZM4JhU8a
.

Can you please help me reproduce this problem?  Code snippets and pom.xml are welcome.

FYI, if you want to use bigtable-hbase, see https://github.com/sduskis/cloud-bigtable-examples/tree/master/java/dataflow-connector-examples for the way we do it.  If you'd like, feel free to reach out to me in the email on my profile with more detailed information, or you can add the information here.

maybe this helps... There are two versions of BigtableOptions and BigtableSession.  Use the ones prefixed by the package name: com.google.bigtable.repackaged.com.google.cloud

The following code when compiled with both bigtable-hbase-1.1 and
bigtable-dataflow in
its dependencies. The version I am using is 0.9.1
Note that the usage of Options is done deep into a jar (not in the code I
have written). I do not even have an import for BigtableOptions in my code.
public static void main(String... args) {
CloudBigtableOptions options =
PipelineOptionsFactory.fromArgs(args).withValidation().as(CloudBigtableOptions.class);
options.setBigtableInstanceId(System.getProperty("bigtable-instance-id"));
options.setBigtableProjectId(System.getProperty("bigtable-project-id"));
options.setBigtableTableId(System.getProperty("bigtable-name"));
options.setStagingLocation("gs://" +
System.getProperty("storage-bucket-id") + "/staging/dataflow");
Scan scan = new Scan();
scan.addFamily("p".getBytes());
scan.setCacheBlocks(false);
CloudBigtableScanConfiguration config =
CloudBigtableScanConfiguration.fromCBTOptions(options)
.toBuilder().withScan(scan).build();
Pipeline p = Pipeline.create(options);
p
.apply(Read.from(CloudBigtableIO.read(config)))
"gs://" + System.getProperty("storage-bucket-id") + "/topic-dump"));
p.run();
}
On Fri, Aug 12, 2016 at 2:22 AM, Solomon Duskis<EMAIL_ADDRESS>wrote:

maybe this helps... There are two versions of BigtableOptions and
BigtableSession. Use the ones prefixed by the package name:
com.google.bigtable.repackaged.com.google.cloud
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/cloud-bigtable-client/issues/958#issuecomment-239288790,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACGoUizpW6PCfS00m1h4Lu_77UhVF7etks5qe4uogaJpZM4JhU8a
.

Gotcha.  We shade bigtable-hbase into bigtable-hbase-dataflow, i.e. the relevant components of bigtable-hbase are in bigtable-hbase-dataflow, but the packages are renamed.  If you remove bigtable-hbase-1.1, you should be good to go.  Sorry for the confusion.

I'll categorize this as a bug in our shading process.  It shouldn't be too hard to fix for the next release.  Thanks for the catch, and sorry for the trouble.  In the meantime, removing bigtable-hbase.* will fix the problem.

This was fixed with the 0.9.2 release.

Thanks Solomon.
I do not see bigtable-client 0.9.2 version in mvnrepository (there are
0.9.2 version for a bunch of related artifacts though bigtable-hbase,
bigtable-dataflow etc...).
https://mvnrepository.com/artifact/com.google.cloud.bigtable/bigtable-client
On Tue, Aug 30, 2016 at 2:37 AM, Solomon Duskis<EMAIL_ADDRESS>wrote:

This was fixed with the 0.9.2 release.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/cloud-bigtable-client/issues/958#issuecomment-243256487,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACGoUowyMTiq48ddNmshsxHq8vhcKCPMks5qk0n6gaJpZM4JhU8a
.

bigtable-client was a parent project that I didn't expect anyone to rely on.  I renamed bigtable-client to bigtable-client-parent.


Exec command should make component required

Currently the spec does not define the component in an exec as required. I am wondering if that's the case, what is the point in have an exec command at all? If the there is an exec command in a devfile, it is to be executed in a container; which is to be represented by the component property.
https://github.com/devfile/api/blob/master/pkg/apis/workspaces/v1alpha2/commands.go#L125

@l0rd wdyt about this one ? It seems we should make the component mandatory right ?

I don't see much usage on a command without a component. Without the component info, the tools using the devfile won't know where are they going to execute the command.

Agreed. The component should be mandatory for exec commands. On the other hand apply commands should not require that.

So this:
// Describes component to which given action relates
// +optional
Component string `json:"component,omitempty"`

Becomes:
// Describes component to which given action relates
//
Component string `json:"component"`

?????

Yes, exactly.

So, I think this is a good idea. But one thing I'm wondering is, will this cause issues for overriding parent commands in devfiles if the component isn't specified?
E.g.
schemaVersion: 2.0.0
metadata:
  name: nodejs
  version: 1.0.0
parent:
  uri: https://raw.githubusercontent.com/odo-devfiles/registry/master/devfiles/nodejs/devfile.yaml
  commands:
    - id: install
      exec:
        commandLine: npm install && echo hi

Is currently valid, and changes the commandLine for the install command. But, will it still be valid if we make component required?

For example, https://github.com/devfile/api/blob/master/samples/devfiles/simple-devfile.yaml#L30 includes:

id: helloWorld
exec:
env:
- name: "USER"
value: "John Doe"
commandLine: 'echo "Hello ${USER}"'

This example would now be invalid. Is this acceptable?

@mmulholla yes, that would become invalid because the exec command has no component to execute itself.

So given this and what John pointed out do we still want this change?

For example, https://github.com/devfile/api/blob/master/samples/devfiles/simple-devfile.yaml#L30 includes:

id: helloWorld
exec:
env:

name: "USER"
value: "John Doe"
commandLine: 'echo "Hello ${USER}"'

This example would now be invalid. Is this acceptable?

Yes, it seems this is an error in this example file, that was not reported because of the fact that component is optional for now.
IMO this should not prevent us from doing the change proposed in this issue.

So, I think this is a good idea. But one thing I'm wondering is, will this cause issues for overriding parent commands in devfiles?
E.g.
schemaVersion: 2.0.0
metadata:
  name: nodejs
  version: 1.0.0
parent:
  uri: https://raw.githubusercontent.com/odo-devfiles/registry/master/devfiles/nodejs/devfile.yaml
  commands:
    - id: install
      exec:
        commandLine: npm install && echo hi

Is currently valid, and changes the commandLine for the install command. We don't specify the component of the overridden command since we're not changing it. Will this still be valid if we make component required?

In fact that won't be a problem since the override generator takes care of that when generating the Override Structs. It makes all the fields optional, apart from those that are strictly required because they are used as merge keys in a list.
So even with the change proposed here to implement this issue, the command override described by @johnmcollier and quoted above will still be valid.

Agreed. The component should be mandatory for exec commands. On the other hand apply commands should not require that.

@l0rd Do you mean that Apply command should not require a mandatory component ? What would an Apply command without a component field mean ?

Agreed. The component should be mandatory for exec commands. On the other hand apply commands should not require that.

@l0rd Do you mean that Apply command should not require a mandatory component ? What would an Apply command without a component field mean ?

@davidfestal you are right. It should be mandatory for apply commands as well.


find example data for map

find candidates for cool demo layers

Idea: Education levels based on census areas
https://catalogue.data.gov.bc.ca/dataset/education-level-summaries-for-bc-census-subdivisions-2016-census
Can see differences in education levels b/w areas and examine potential barriers

Idea: Where can I find salmon for a fishing trip weekend!
https://catalogue.data.gov.bc.ca/dataset/provincial-fish-ranges-generalized
Can see a large variety of fish species, filter for certain ones, and find some fishies nearby!

Idea: Coal fields
https://catalogue.data.gov.bc.ca/dataset/coal-fields-of-bc-with-coal-bed-methane-potential
Can see that there are coals mines nearby, didn't realize that still happened here in BC (fun fact: Robert Dunsmir made his fortune off the coalmine up island and lived in craigdaroch castle!)

Idea: Kids have Caribou Nightmeres
https://catalogue.data.gov.bc.ca/dataset/2b217585-f48d-4d9f-b7ba-746909ac35ca
https://catalogue.data.gov.bc.ca/dataset/95da1091-7e8c-4aa6-9c1b-5ab159ea7b42
Find out which school your kids should go to if they keep having nightmares of Caribou.

Idea: Find areas of traditional Indigenous use
https://catalogue.data.gov.bc.ca/dataset/first-nation-traditional-use-study-sites-polygons
Cool to see areas that are traditionally significant to Indigenous peoples.


Exception handler

I'm sure there's some nicer asyncio-ier way here, but this solves my problem of handling occasional database exceptions due to RDS auto-upgrading.
Currently: if an unhandled exception occurs in either the application code-provided handler callback function that processes one event, or in the event counter, atomicpuppy will handle it by just logging and continuing event processing.
Now: if you call .set_exception_handler(func), it will call your function when that happens, then continue event processing.

Whoops, this (fe11969e) got released to PyPI as without merging or tagging


Support namespaced models

Adds support for namespaced model associations:

drops any namespace from the auto-inferred association_name. E.g Post::Translation will yield translations instead of the otherwise incorrect post/translations, which in turn was otherwise leading to the error in Cocoon Undefined method 'new_record' for nil:NilClass.
allows to manually define the association name if the auto-inferred name is not yet correct
fixes the inferred name of the associated model's dashboard class (should be Post::TranslationDashboard and not TranslationDashboard)

This is required when working with PaperTrail (PaperTrail::Version), Globalize (Post::Translation), or supposedly any other namespaced models.
The association can be configured as follows:
# app/dashboards/post_dashboard.rb
class PostDashboard < Administrate::BaseDashboard
  ATTRIBUTE_TYPES = {
    translations: Field::NestedHasMany.with_options(class_name: "Post::Translation"),
    ...
  ]
end

Fixes https://github.com/nickcharlton/administrate-field-nested_has_many/issues/8.

I'm just getting to look at things on here now. Do you think you'd be able to add a test or two to verify this is working correctly?

@nickcharlton I tried this:
As the tests on master are currenty broken I first had to add this to spec/dummy/app/assets/config/manifest.js (not sure if that's the right place):
//= link administrate/application.js
//= link administrate-field-nested_has_many/application.js
//= link administrate/application.css
//= link administrate-field-nested_has_many/application.css

Then to run the 7 tests I did this, which worked:
RAILS_ENV=test bundle exec rails db:create db:schema:load
bundle exec rspec

However I then wanted to perform changes in the gem source code and this is where I got lost, I don't know anything about gemspecs, appraisals, etc. It looked like the dummy app loads is referring the published gem and thus ignoring my local changes. So I don't know how to proceed. There is no info in this repo's README on how to contribute developments.

Okay, great. That's a good start!
I should spend some time documenting some things to make it easier, but you shouldn't need to worry about the Gemspec or Appraisals (I'll worry about those when I next make a release).
Is there enough in: https://github.com/nickcharlton/administrate-field-nested_has_many/blob/master/spec/lib/administrate/field/nested_has_many_spec.rb or https://github.com/nickcharlton/administrate-field-nested_has_many/tree/master/spec/features to get you going?
If you'd be able to contribute the beginnings of a test, I can work through the bits where it's not working because the state of the repo rather than your specific changes.

@nickcharlton yes I saw the spec contents but when running spec/features/has_many_spec.rb I couldn't make the tests refer to the actual local code instead of the published gem (it seems). I checked this by renaming the class NestedHasMany to NestedHasMany2 in lib/administrate/field/nested_has_many.rb and then referring to this in spec/dummy/app/dashboards/school_dashboard.rb, but couldn't resolve it. I started to write a test but I'm completely blind as I can't run it so don't feel confident to provide any of that code.

@nickcharlton Okay I was mistaken in my previous message, I was just confused by a bug in the dummy app codebase (accepts_nested_attributes_for was missing).
I've made the required changes and added two tests, which now all pass on my machine.
By checking out revision 95cb2bed (Move Student to Foo namespace) you can see that tests break, and thus that the modifications to NestedHasMany are required.

Great! I pulled out two of your commits (a7bbd52, 95c56e3), as I thought these we valuable on their own. Then just squashed the rest. I'll merge it now


www.GitHub.com/etenterprises1.gift4u

@marzvrover /https://www.google.com/collections/s/list/8jWHlRfYSMqQ_9EySEqiZw/yVlpPM2iNHk
[{```
+/AUTOTOOLS.
$100,000,000.00/@/USDOLLARS
From<EMAIL_ADDRESS>To: sharissa Leslie Rockwell
Supplied by: US_President<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>@etenterprises1
@etcbi.com
@master-ui-web-et
(www.GitHub.com/etenterprises1.gift4u=
It's the line that is Missouri athletic club I'm gifting to my mother for Christmas
)```}]

Please someone verify this info verify that I have the wealth to be able to gift however y'all know how or can and snail mail to my mother please so that she can retire this is my Christmas gift to my mother for 2024.

@marzvrover /https://www.google.com/collections/s/list/8jWHlRfYSMqQ_9EySEqiZw/yVlpPM2iNHk
[{```
+/AUTOTOOLS.
$100,000,000.00/@/USDOLLARS
From<EMAIL_ADDRESS>To: sharissa Leslie Rockwell
Supplied by: US_President<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>@etenterprises1
@etcbi.com
@master-ui-web-et
(www.GitHub.com/etenterprises1.gift4u=
It's the line that is Missouri athletic club I'm gifting to my mother for Christmas
)```}]
Gifted to sharirock50@gmail.com/@/sharissa rockwell


E 04823 tickets b 18472 and b 18457 int

Feature E-04823

Frontend: B-18472
Backend: B-18457

Summary
These two tickets introduce new business logic and refactoring with how service member duty location, grade, and weight allotments function within MilMove. At a high level, grade and duty location has moved from the service member to the order. Additionally, grades now reflect a "true" value that is calculated by weight allotment and assigned to a DBWeightAuthorized. DBWeightAuthorized is directly tied to the maximum billable weight of a move. When a service member grade is updated, it immediately updated the maximum billable weight, whether it be increasing or decreasing the maximum amount.
Verification Steps for Reviewers

[ ] Do grade updates on the order accurately update the correct weight for the move? Entitlements can be found here: pkg/models/entitlements.go
[ ] Have the BL acceptance criteria been met for this change?
[ ] Was the CircleCI build successful?
[ ] Has the code been reviewed from a standards and best practices point of view?
[ ] Has the branch been pulled in and checked out?

Setup to Run the Code

Instructions for starting storybook
Instructions for starting the MilMove application
Instructions for running tests

How to test
Frontend:

Create a new customer profile and ensure you see the correct weight allowances based on your grade and dependents value. You can see this when adding shipments, as a TOO or services counselor, and throughout the flow.
When adding your grade and dependents to the orders, go back and edit them and make sure the weight allowance changes to reflect that.
Ensure that Current duty location and Grade are no longer seen in the Service Info or Profile section, and are instead associated with the orders on the review page after adding orders and before submitting the move.

Backend:

Login as a TIO
Select a move
Navigate to move details -> allowances
Make note of the "Weight allowance"
Update the grade to something that will change the weight allowance (See pkg/models/entitlements.go)
Review
Login as a Counselor
Select a move
Navigate to move details -> allowances
Make note of the "Weight allowance"
Update the grade to something that will change the weight allowance (See pkg/models/entitlements.go)
Review
Additionally, you can set the HasDependents value on the order to true or false, then update the grade again to review how dependents affect the weight allowance.

Screenshots

Warnings

:warning:

Files located in legacy directories (src/shared or src/scenes) have
been edited. Are you sure you don’t want to also relocate them to the new file structure?
View the frontend file org ADR for more information

  Generated by :no_entry_sign: dangerJS against 0f463ee9876461396f90d9e28edeac68775ee882

@traskowskycaci
Load testing is G2G!

@traskowskycaci Load testing is G2G!

Woooo!


fix(techdocs-node): Allow for dictionaries in pymdx plugin settings

Hey, I just made a Pull Request!
Fixed issue in techdocs yaml parser which didn't allow for dictionaries/mappings in pymdx plugin configuration.
:heavy_check_mark: Checklist

[X] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[X] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[X] All your commits have a Signed-off-by line in the message. (more info)

It seems I duplicated https://github.com/backstage/backstage/pull/26432 oops


Update storage-account-keys-manage.md

From the Azure CLI, as https://docs.microsoft.com/en-US/cli/azure/storage/account/keys?view=azure-cli-latest#az_storage_account_keys_renew suggests, "primary" and "secondary" work, but "key1" and "key2" do not.  I've no idea if the other access flavours (e.g. Powershell) also need changing.

@SomeoneElseOSM : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@SomeoneElseOSM - Thanks for making that fix!
#sign-off


[vite] The "attributes" property of ModuleInfo is not supported.

Using the plugin in Vite gives this error :
[vite] Internal server error: [vite] The "attributes" property of ModuleInfo is not supported.

Line of interest: https://github.com/justinfagnani/rollup-plugin-css-modules/blob/614a3aa677f641b614058b2672848b4368c78d09/src/index.ts#L18
Output of this.getModuleInfo(id) when running this line:
{
  id: '/home/xxx/gits/test/node_modules/vite/dist/client/client.mjs',
  meta: {}
}

Versions
vite/4.5.0
linux-x64
node-v20.10.0

Also something to consider when building a Vite plugin : https://vitejs.dev/guide/api-plugin#plugin-ordering


部署到now.sh出现错误

502: BAD_GATEWAY
Code: NO_RESPONSE_FROM_FUNCTION
ID: hnd1::jcrw7-1594344104611-15b40ab0c163

请问你解决了么？我也报这个错

now.sh现在是存在问题的， 因为我的now帐号已经被封， 暂时无法解决。
建议使用heroku和vps方法部署。

Dame it, my github account is forbidden by Vercel as well. Just because deploy this project for two month!
I have revised the some little bugs of current version ,but I can't believe this make things more terriable subsequently.😡
Strongly suggest author to Tell our user, don't try this binding with your usually using Github account. 😡😡


Remove double-application of projection in distinct.

Fixes #1856.

I expect the new test will fail on some other connectors. I’ll mark it pending once I see the Travis results.

Realized I broke the test with a naïve find/replace meant to clean it up. Fixed now.


Update readme to include docker-compose generation steps

Issue

Link: https://github.com/NebraLtd/helium-miner-software/pull/272
Summary: Switched to generate a docker-compose.yml file based on a jinja2 template with a settings.ini file

How
Added readme steps for generating the docker-compose.yml file

Thanks for sorting this @SebastianMaj very helpful 👍


Increase Mac build's TestFX setup timeout to 5 seconds

Attempts to resolve #608

I'm going to test just the Mac build a couple of times to see if that fixes things:

Mac build successful

Hopefully, this will fully resolve the Mac build issue.


Object (abstract) property wrongly seen as TypeVar or generic type in isinstance

Environment data

Language Server version: 2021.5.1 (pyright df8b6b3c)
OS and version: Ubuntu 20.04
Python version (& distribution if applicable, e.g. Anaconda): Python 3.7.9 64-bit (conda)

Code Snippet
from abc import abstractmethod
from typing import Any, Union, Generic, TypeVar, Type, Tuple

T = TypeVar("T")

class A(Generic[T]):
    @property
    @abstractmethod
    def _elem_type_(self) -> Union[Type[T], Tuple[Type[T], ...]]:
        raise NotImplementedError

    def check_type(self, var: Any) -> bool:
        return isinstance(var, self._elem_type_)

    def execute(self, var: Union[T, Tuple[T]]) -> None:
        if isinstance(var, self._elem_type_):
            print("single")
        else:
            print("iterable")

Expected behaviour
Not give a Pylance error
Actual behaviour
The use of isinstance() in check_type() method is OK; the use of isinstance() in execute() gives the following Pylance typing error:
{
	"resource": "/home/verhaegs/eda/test/test_generic.py",
	"owner": "_generated_diagnostic_collection_name_#2",
	"code": {
		"value": "reportGeneralTypeIssues",
		"target": {
			"$mid": 1,
			"external": "https://github.com/microsoft/pylance-release/blob/main/DIAGNOSTIC_SEVERITY_RULES.md#diagnostic-severity-rules",
			"path": "/microsoft/pylance-release/blob/main/DIAGNOSTIC_SEVERITY_RULES.md",
			"scheme": "https",
			"authority": "github.com",
			"fragment": "diagnostic-severity-rules"
		}
	},
	"severity": 8,
	"message": "Second argument to \"isinstance\" must be a class or tuple of classes\n  TypeVar or generic type with type arguments not allowed",
	"source": "Pylance",
	"startLineNumber": 16,
	"startColumn": 28,
	"endLineNumber": 16,
	"endColumn": 44
}

Thanks for the bug report. This will be addressed in the next release.

This issue has been fixed in version 2021.5.3, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202153-19-may-2021


Underlay IPVLAN is valid option only for BMS cluster

Moved to opentelekomcloud/ui-cluster-driver-otc#9


Adding WebGL BLS signature verification via JS

@tommygames just a reminder this is here
i am in no need of this, just want to make sure it doesnt get lost
Just need a review/test of the js BLS work


Rewire the static directory

It's now no longer a symlink from the old website, but a symlink from this website folder. This way we can easily add new static assets.

I also removed things that were unused

Are we sure we want to check in a 4+ meg text file?


Revert "Disable failing browsers in CI configuration"

This reverts commit 7e09d27f5680de198b7b363f574f531f4f1aa180.

Nice. Great to get these back in.

I haven't looked deeply into it, but some of these browsers seem to still fail?

#460 passes but #449 doesn't.


Fee zero - is it possible to change in LND?

Now the LND has minimum fee rate as 1/1,000,000
If i try to use zero i get error "fee rate of 0 is too small, min fee rate is 1e-06" (v0.6.1-beta)
But other nodes already has fee as 0 / 0: ACINQ channel example (and capacity 1 BTC too! ;-)
It turns out that all nodes based on LND software will be noncompetitive with Eclair software... Is it possible to allow fee rate & base fee as 0?

A fee rate of 1 msat is essentially zero. But yes you're correct that we currently don't permit that value to be set to zero atm. I wouldn't say 0 vs 1 msat for fees will make an implementation competitive or non-competitive as that's not the only thing that path finding takes into account. What will make a node competitive is proper management of their established channels, not over saturating the network with their own channels, and high availability.


Parallelize some phases of compilation between a crate and its dependency

 Issue by brson
Saturday Sep 08, 2012 at 22:00 GMT
For earlier discussion, see https://github.com/rust-lang/rust/issues/3431
This issue was labelled with: A-an-interesting-project, A-build, E-hard, I-wishlist in the Rust repository

With a single driver building multiple crates we can start running more parts of the compilation process in parallel.
The basic idea is to output the metadata about a crate before code generation so that the next compile can proceed based on that metadata.
rustc gets modified in a few ways:

Just before trans we serialize the bulk of the metadata and insert a hook to give the multi-crate driver an opportunity to copy it to another task to begin the next compilation phase.  There will still be some metadata that needs to be serialized after trans.
Insert another hook into crate resulotion for reading the metadata binary. The multi-crate driver will use this to receive the metadata output from previous crates and feed them to the next crates.

The end result is that parsing and analysis will be largely done in parallel with code generation for multi-crate builds.
Beyond that we can also parse all crates in parallel.
This would require that we make sure we are using LLVM in a threadsafe way, unless we can get all the trans passes onto a single thread.
Related to #2237

Mostly a duplicate of https://github.com/rust-lang/rust/issues/44587 but that one's more plausible (but still a bad idea IMO) in that it wants to make Cargo manage the metadata/codegen split. As noted over there, "codegen only from metadata" also overlaps with MIR-only rlibs (https://github.com/rust-lang/rust/issues/38913). Parts of this issue are also already obsolete, we have multithreaded LLVM now, though not multi-threaded MIR->LLVM IR codegen yet, and there's active work on parallelizing the latter and the rest of rustc internally (https://internals.rust-lang.org/t/parallelizing-rustc-using-rayon/6606 and more speculatively https://github.com/rust-lang/rust/issues/47518). There's also ideas to remove the crate-at-a-time compilation model in the long term. So besides being a duplicate, this issue has been mostly outpaced by development already and will likely become completely obsolete before anything further happens with it.


fix a wrong comment.

1. "let g:override_spf13_bundles = 1" should be placed in
".vimrc.before.local", since ".vimrc.bundles.local" source too late.
2. ".vimrc.before.local" is the only choice for this local customize.

At last, I have verified this.

Signed-off-by: guanjianzhe<EMAIL_ADDRESS>

 You should sign our Contributor License Agreement in order to get your pull request merged.