Allow staff visualizers to be split into multiple lines

Added a line parameter to the midi-visualizer element that determines how many lines the notes are split into.
Also updated some packages to fix some vulnerabilities.

Looks like a cool contribution. Do you have a demo I could look at?
Also, please don't update yarn.lock/package-lock.json in the same PR. These are long diffs and it's hard to see what's going on there. I would prefer if you could make an issue listing what needs to be updated, and I can take care of it.

Sure! I removed the yarn.lock and package.lock changes and added an example of the multi-lined visualizer to the demo (index.html). Is this ok?

Sorry, it took me a while to get around to this! Thanks for the demo, I now see better what this is doing.
I agree it would be useful to have the staff visualizer split into multiple lines. However, I see a couple of issues with the approach:

Splitting evenly by notes (in the middle of a bar) seems inadequate:

In sheet music, breaks should always occur at downbeats.
I guess the reason why we would want this feature is for the score to fit on screen without having to scroll horizontally. So ideally it should take in a desired maximum width or just fit the container responsively, rather than being based on the number of lines (which would require trial and error to get it right, and it would work only for one piece of music, as can be seen from the demo). (Another possibility would be to specify the number of measures per line, but even that isn't ideal as measures within one piece can have different widths.)
The functionality makes sense for the staff visualizer, but not so much for the other visualizer types (especially the waterfall one). For this reason, I'm not a fan of having this as a property on all visualizers.

In short, it seems intricate to do this right and it would require some interaction with the actual score rendering logic, which is not accessible from here. Therefore I think it would be preferable to add this feature directly to staffrender, which is what is used to render the scores. I think it's better to keep the visualizers here as thin wrappers around the ones defined in @magenta/music (unless we fully implement a new visualizer type here, which would also be fine).


video-card fixed

What type of PR is this? (check all applicable)
#913

[ ] ♻ Refactor
[ ] ✨ New Feature
[ ] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 👷 Example Application
[ ] 🧑💻 Code Snippet
[ ] 🎨 Design
[ ] 📖 Content
[ ] 🧪 Tests
[ ] 🔖 Release
[ ] 🚩 Other

Description

This PR [adds/removes/fixes/replaces] this [feature/bug/etc].
Related Tickets & Documents

Resolves #
Mobile & Desktop Screenshots/Recordings

Added code snippets?

[ ] 👍 yes
[ ] 🙅 no, because they aren't needed

Added tests?

[ ] 👍 yes
[ ] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

No tests? Add a note

Added to documentation?

[ ] 📜 readme
[ ] 📜 contributing.md
[ ] 📓 general documentation
[ ] 🙅 no documentation needed

No docs? Add a note

[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?

@Pratham271 Thank you ! 🥳

@Pratham271 thanks for the fix. the code is duplicated each time we add a video. do you want to open another issue to make your changes standardized in the Video component and then use the <Video> component in the blog posts? that would be an amazing contribution

Yess should I open a new one

@Pratham271 yes you can open a new PR thanks!


Add typedefs to instance configurations.

This is meant to follow pull request https://github.com/unhuman-io/obot-controller/pull/104. See delta changes.
NOTE: This will need to go in after (but alongside) https://github.com/unhuman-io/motorlib/pull/70
NOTE: Does not update the motorlib submodule in this pull-request. Upon merging the appropriate motorlib pointer will need to be uploaded to match motorlib/0320_typedefs.
Significant structural change to handle "instance types" via typedefing. This doubles down on the "using GlobalType = InstanceClass" pattern and makes it accessible across compilation units.
It adds a bit of initial bloat and complexity, since now there is an additional file for every config: a <config>_types.h. The benefit is that it will now be possible to encapsulate parts of the code and also share more of the boiler plate. It naturally allows for composition of instance and board config specification, which is best laid out for the obot_g474 projects.
The advantage of this method is that it keeps each individual implementation clean (no bloat from templates) and avoids the problematic overhead of virtual base methods (vtable look-up is slow). A disadvantage is that no nested types are allowed; a type cannot include another type (see USBCommunication as a problematic example).
This is accomplished by creating a system_types.h header that includes the specialized instance type header via a compiler define flag TYPE_HEADER_DEFINE.
Critical files to look at and review:

Makefiles - these have been modified to add the compile time define for the type header location.
system_types.h - shows how the types are setup and provides the template for the system types.
usb_communication.h - class converted into a template to allow "nested" type definition.
config_obot_g474_motor_hall.cpp - a reasonably simple example of how the new system works.

For the obot_g474 projects a new instance can be setup by copying the pattern of motor_hall:

Make a copy of config_obot_g474_motor_hall_types.h to follow the pattern: config_obot_g474_<INSTANCE>_types.h
Modify the includes and set the instance types as desired. Note the potential inclusion of a board types file that can be selected to match the desired platform.
Make a copy of config_obot_g474_motor_hall.cpp to follow the pattern: config_obot_g474_<INSTANCE>.cpp.
Finish configuration of the instance as you would normally do. I suggest using the explicit types (e.g. QEPEncoder) instead of the generic type names, since this will catch errors if you change the system-types and it appears to make the IDE happier.

Builds successfully at the following submodule versions:
bingjeff/obot-controller@2ca4c30f5ec0cb4b0ad3b07cbd8f867414cfa76f obot-controller (heads/0320_typedefs)
bingjeff/calibration@7bea65c7b7320e72cc4f4da40f02f070449b435a calibration (heads/main)
bingjeff/motorlib@855e9de982d57ccf83c457ec747de30657b7683f motorlib (heads/0320_typedefs)
bingjeff/motor_messages@b30880c1691602e1d069573222386560855d5fc6 motorlib/motor_messages (remotes/upstream/main)

I'm still a little gun-shy about the submodule thing ... this can't possibly build as submitted, it requires https://github.com/bingjeff/motorlib/commit/855e9de982d57ccf83c457ec747de30657b7683f and I left motorlib alone. Let me know if there is a better way to manage this.


feat: add support for karpenter 0.34.0 or newer

what

update eks/karpetner and eks/karpenter-provisioner to support Karpenter v0.34.0
update controller's iam policy to be nearly identical to the policy included with Karpenter's CloudFormation template

only changed the arn and alike for resources to match cloudposse's deployed resources

allow deployment to existing k8s namespaces
reduce code smell

why

Karpetner v0.34.0 included multiple breaking changes

moved chart values for settings.aws to settings
replaced Provisioner with NodePool resource
replaced AWSNodeTemplate with EC2NodeClass

references

closes #982

Superseded by #1039 and #1056


Feedback Submission - tutorials - Create your first Substrate blockchain - /tutorials/v3/create-your-first-substrate-chain

What browsers are you seeing the problem on?
No response
Feedback
hello all, not sure where to resolve this but I seem to be running into issues for the front-end-node, everything compiles but I get this error  Error Connecting to Substrate
{ "isTrusted": true }

Duplicate, closing.
See https://github.com/substrate-developer-hub/substrate-front-end-template/issues/209


Supervisor has an LDAPIdentityProvider.idp.supervisor.pinniped.dev CRD

Purpose: A first step toward the Supervisor supporting LDAP servers as an upstream IDP type.
GIVEN I have installed the Pinniped Supervisor
WHEN I kubectl create LDAPIdentityProvider
THEN it is created
AND I can read it, delete it, etc.
Details of the fields allowed in the CRD TBD (see previous research from the team).

This should be covered by https://github.com/vmware-tanzu/pinniped/issues/440.


Fail to install by poetry.

Describe the bug
I have tried to add and install vsphere-automation-sdk-python by using poetry.
poetry add "git+https://github.com/vmware/vsphere-automation-sdk-python.git"

However, the following error was raised:
Creating virtualenv mavis in /Users/user/Documents/project/.venv

Updating dependencies
Resolving dependencies... (37.0s)

  RuntimeError

  Unable to retrieve the package version for None

  at ~/.poetry/lib/poetry/inspection/info.py:143 in to_package
      139│         name = name or self.name
      140│
      141│         if not self.version:
      142│             # The version could not be determined, so we raise an error since it is mandatory.
    → 143│             raise RuntimeError(
      144│                 "Unable to retrieve the package version for {}".format(name)
      145│             )
      146│
      147│         package = Package(

As a result, I checked the requirements.txt and find out that if I add vapi-client-bindings==3.9.0, I get the same error message.
  ValueError

  Could not find a matching version of package vapi-client-bindings

  at ~/.poetry/lib/poetry/console/commands/init.py:367 in _find_best_version_for_package
      363│         )
      364│
      365│         if not package:
      366│             # TODO: find similar
    → 367│             raise ValueError(
      368│                 "Could not find a matching version of package {}".format(name)
      369│             )
      370│
      371│         return package.pretty_name, selector.find_recommended_require_version(package)

Reproduction steps
- Run poetry add.

  poetry add "git+https://github.com/vmware/vsphere-automation-sdk-python.git"

Expected behavior
Expected to install successful without error raised.
Additional context
No response

Installation using Poetry is currently not tested/supported.

@aragorn1025
I hit the same issue. I can avoid it by the following command
poetry run pip install -U pip setuptools
poetry run pip install --upgrade git+https://github.com/vmware/vsphere-automation-sdk-python.git

Any chance of getting this to be supported??

Any chance of getting this to be supported??

Sorry! Not in immediate future. I'm closing this issue as not planned.
Can you please try the workaround mentioned by @ttanigaki and see if it helps?

Closing this,  as there is no near term plan to fix this issue.

@ttanigaki
Thank you for the solution.
@jobingeo
There's another question about requirements.txt. I saw there's a dependent module that can't be downloaded.
vapi-client-bindings == 3.9.0

I search this module and found out that I can only get the newer one. (link here)
vapi-client-bindings == 7.0.0

Will this have any effect?

I search this module and found out that I can only get the newer one. (link here)
vapi-client-bindings == 7.0.0

Will this have any effect?

The vapi-client-bindings  lib you see in pypi repo is a dummy one. We just reserved it in PyPi for the future onboarding of SDK libs. For now, please don't rely on these libs from PyPi. Please use these libs locally following the SDK installation instruction here.
From above error stack/comments,  It seems this could have a potential impact here.

Maybe this can be useful for other poetry users.
For me, with poetry 1.3 I can do poetry add https://github.com/vmware/vsphere-automation-sdk-python/archive/refs/tags/v<IP_ADDRESS>.tar.gz which works.
For poetry 1.1 I have to do add all the dependencies using  poetry add https://github.com/vmware/vsphere-automation-sdk-python/archive/refs/tags/v<IP_ADDRESS>.tar.gz https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/nsx-policy-python-sdk/nsx_policy_python_sdk-<IP_ADDRESS>.0-py2.py3-none-any.whl https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/nsx-python-sdk/nsx_python_sdk-<IP_ADDRESS>.0-py2.py3-none-any.whl https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/nsx-vmc-aws-integration-python-sdk/nsx_vmc_aws_integration_python_sdk-<IP_ADDRESS>.0-py2.py3-none-any.whl https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/nsx-vmc-policy-python-sdk/nsx_vmc_policy_python_sdk-<IP_ADDRESS>.0-py2.py3-none-any.whl https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/vapi-client-bindings/vapi_client_bindings-4.0.0-py2.py3-none-any.whl https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/vapi-common-client/vapi_common_client-2.37.0-py2.py3-none-any.whl https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/vapi-runtime/vapi_runtime-2.37.0-py2.py3-none-any.whl https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/vmc-client-bindings/vmc_client_bindings-1.61.0-py2.py3-none-any.whl https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/vmc-draas-client-bindings/vmc_draas_client_bindings-1.20.0-py2.py3-none-any.whl
In my pyproject.toml I get :
[tool.poetry.dependencies]
# vsphere-automation-sdk work around
vsphere-automation-sdk = {url = "https://github.com/vmware/vsphere-automation-sdk-python/archive/refs/tags/v<IP_ADDRESS>.tar.gz"}
vmc-draas-client-bindings = {url = "https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/vmc-draas-client-bindings/vmc_draas_client_bindings-1.20.0-py2.py3-none-any.whl"}
vapi-runtime = {url = "https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/vapi-runtime/vapi_runtime-2.37.0-py2.py3-none-any.whl"}
vapi-common-client = {url = "https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/vapi-common-client/vapi_common_client-2.37.0-py2.py3-none-any.whl"}
nsx-policy-python-sdk = {url = "https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/nsx-policy-python-sdk/nsx_policy_python_sdk-<IP_ADDRESS>.0-py2.py3-none-any.whl"}
nsx-python-sdk = {url = "https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/nsx-python-sdk/nsx_python_sdk-<IP_ADDRESS>.0-py2.py3-none-any.whl"}
nsx-vmc-aws-integration-python-sdk = {url = "https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/nsx-vmc-aws-integration-python-sdk/nsx_vmc_aws_integration_python_sdk-<IP_ADDRESS>.0-py2.py3-none-any.whl"}
nsx-vmc-policy-python-sdk = {url = "https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/nsx-vmc-policy-python-sdk/nsx_vmc_policy_python_sdk-<IP_ADDRESS>.0-py2.py3-none-any.whl"}
vapi-client-bindings = {url = "https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/vapi-client-bindings/vapi_client_bindings-4.0.0-py2.py3-none-any.whl"}
vmc-client-bindings = {url = "https://github.com/vmware/vsphere-automation-sdk-python/raw/master/lib/vmc-client-bindings/vmc_client_bindings-1.61.0-py2.py3-none-any.whl"}

For those interested, I added a script in this related issue to generate this dependency list.


2 issues

1: every video except a random simpsons video just says this video isnt available
2: clicking on channels just crashes my server
, #2's error is javascript let url = player.streamingData.formats[0].url
TypeError: Cannot read properties of undefined (reading 'formats')
(no error for problem 1)

the channel issue doesnt happen anymore but now every video (inspect logs) says it cant find (video watch id).ogg


Option to charge an economy amount to spawn in a wand.

Would it be possible to add an option to charge an economy amount for the ability to spawn in a wand? i.e. if a person has permission to spawn in a specific wand name with /mgive, charge them $500 so they can't spam the command over and over again?
As well as a permission node to bypass the economy charge.

I'm not really big on having players use commands. Can you just set up a shop and sell the wands? You can limit shops by permission. Or just give them the shop spell to have on their wands, or on a separate item.

Well the idea behind it is because I provide specific wands to players for cosmetics.  But if I provided the wand and the permission node to spawn it back with a  $500 in-game charge, then players will always have a way to get their unlocked cosmetic wand back without being able to spam the command over and over again.
This is also assuming giving the individual wand spawn permission doesn't also grant them the ability to spawn it in for others.

Unfortunately no to your last question, you'd have to make a wand shop for each appearance...
I think the best options here would be:

A system that lets players have unlocked wand appearances, and an easy way to get them (either by spawning a new wand, or changing their existing wand, etc). Where you could charge each time this happens.

A way to add a permission node to each item in a shop.

Both of these things are something I'd like to do, so let me know if either of them suits you.
I don't forsee adding something that charges for command use, though I'd wager there are other plugins out there already that would do that if that's the route you want to take.

I personally would like each cosmetic item to be a separate item with its own name / lore instead of being able to change the appearance (damage value). But the 2nd option could work for me. Either by only showing items in the shop players have permission for or showing all items but display a red stained glass icon instead of the wand icon for items players don't have permission for and only allow buying the wand if they have the permission.

Added in latest dev build- here's an example of use:
https://github.com/elBukkit/MagicPlugin/blob/master/Magic/src/examples/elworld/spells.yml#L2221
unlockedwandshop:
  inherit: buyshop
  parameters:
      confirm: true
      confirm_filler: stained_glass:3
      items:
      - item: wand|default
        cost: 500
        permission: unlocked.beginner
      - item: wand|student
        cost: 500
        permission: unlocked.student
      - item: wand|apprentice
        cost: 500
        permission: unlocked.apprentice
      - item: wand|master
        cost: 500
        permission: unlocked.master

Hope that works for you!


Brian/fix library linking

Pull Request Test Coverage Report for Build 4626

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 4621:
0.0%

Covered Lines:
919

Relevant Lines:
919

💛  - Coveralls


Mimelib dependency is governed by the European Union laws applicable to Estonia.  This is a problem.

Issue Summary

Sendgrid >4.10.0 uses MailParser 0.6.1 (https://github.com/sendgrid/sendgrid-nodejs/blob/v4.10.0/package.json#L30)
MailParser 0.6.1 uses MimeLib 0.2.19 (https://github.com/nodemailer/mailparser/blob/v0.6.1/package.json#L20)
MimeLib 0.2.19 uses European Union Public License 1.1 (https://github.com/andris9/mimelib/blob/master/LICENSE#L3)
Applicable law is determined by the "law of the European Union country where the Licensor resides or has his registered office." https://github.com/andris9/mimelib/blob/master/LICENSE#L276
MimeLib's licensor resides in Tallin, Estonia (https://github.com/andris9) (Roping in @andris9 into this conversation)
EUPL is frustratingly nebulous, and this StackExchange comment gets to the heart of the matter: "If you believe Wikipedia, the dynamic linking situation of the EUPL is completely up in the air, subject to the legal breezes of each individual jurisdiction. So we have even less 'principle' to apply to predicting the legal view of dynamic linkage with an EUPL license than we do with the GPL."  https://opensource.stackexchange.com/questions/1524/is-it-possible-to-use-a-library-under-the-eupl-license-for-a-commercial-closed-s/1529#1529

Is there any chance of SendGrid can use https://www.npmjs.com/package/mailparser-mit instead to get around this nebulousness?
Steps to Reproduce

Use Sendgrid in a project
Show the mimelib LICENSE.md to an intellectual property lawyer
Steel yourself for blistering legal concerns

Technical details:

sendgrid-nodejs Version: master (all)
All node.js versions

Hey, I can see your problem. There's an easy fix – just make a donation to the Nodemailer project (see https://nodemailer.com/about/license/ for options) and I'll change the license from EUPL to MIT of the related repos. This way you'd only have to bump the version number of the dependencies but no actual code changes would be needed.

NodeMailer v0.6.1 as a dep of MimeLib ^0.2.19 (https://github.com/nodemailer/mailparser/blob/v0.6.1/package.json#L20)
Therefore, if we preemptively downgrade mimelib to v0.3.0 in our projects package.json via yarn's resolution feature via:
"resolutions": {
  "mimelib": "0.3.0"
}

Then all version of mimelib will refer to the MIT version and we resolve the problem.
Thanks!

I just upgraded mailparser and it does not uses mimelib anymore but the home-made libmime which uses MIT licence.
https://github.com/nodemailer/mailparser/blob/v2.3.4/package.json#L15
https://github.com/nodemailer/libmime/blob/master/LICENSE
Issue: https://github.com/sendgrid/sendgrid-nodejs/issues/762
PR: https://github.com/sendgrid/sendgrid-nodejs/pull/763


Import Error

Hi there,
I have made multiple attempts to use mob-suite and keep running into the same error (stated below). It seems the programme does not call Bio.SeqUtils correctly and therefore can't load the gc_fraction module. I have tried installing via conda, pip and using the install via python setup.py method and all have resulted in this same error. Is there any solution for this? I'd really like to use this software. Thanks!
Traceback (most recent call last):
File "/X/anaconda3/envs/mob-suite/bin/mob_cluster", line 33, in
sys.exit(load_entry_point('mob-suite==3.1.9', 'console_scripts', 'mob_cluster')())
File "/X/anaconda3/envs/mob-suite/lib/python3.7/site-packages/pkg_resources/init.py", line 479, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/X/anaconda3/envs/mob-suite/lib/python3.7/site-packages/pkg_resources/init.py", line 2861, in load_entry_point
return ep.load()
File "/X/anaconda3/envs/mob-suite/lib/python3.7/site-packages/pkg_resources/init.py", line 2465, in load
return self.resolve()
File "/X/anaconda3/envs/mob-suite/lib/python3.7/site-packages/pkg_resources/init.py", line 2471, in resolve
module = import(self.module_name, fromlist=['name'], level=0)
File "/X/anaconda3/envs/mob-suite/lib/python3.7/site-packages/mob_suite-3.1.9-py3.7.egg/mob_suite/mob_cluster.py", line 10, in
from mob_suite.utils import
File "/X/anaconda3/envs/mob-suite/lib/python3.7/site-packages/mob_suite-3.1.9-py3.7.egg/mob_suite/utils.py", line 2, in
from Bio.SeqUtils import gc_fraction
ImportError: cannot import name 'gc_fraction' from 'Bio.SeqUtils' (/X/anaconda3/envs/mob-suite/lib/python3.7/site-packages/Bio/SeqUtils/init.py)

Hello, I just replied to your email. I think your issue is linked to Biopython package older version that did not have the gc_fraction module. I would suggest to make sure your BioPython version is >= 1.80


Indicating viml vs lua stuff

Hi @all,
I'd like to ask if it may be possible to indicate on your awesome awesome-neovim repo such plugins, etc. which are using viml vs those which are lua (maybe also mentioning fennel stuff).
For me it would be interesting to see this on your page without the need to check the referenced repo.

I think this would be a good idea but I don't think it will work for this list directly. Too hard to update all the items, hard to distinguish these manually, more upkeep if the plugins update their code to use more lua and/or vimscript.
In practice, in my experience, most Neovim specific plugins are already primarily using lua and only a few are using vimscript primarily. Fennel or teal also can be cool to see but hard to manage as they may add teal or fennel or use the resulting code and stop using these.  Some may use third party RPC connections as well, which makes it a little harder convey.
This seems better for a third party to use the GitHub API or other tooling that can automatically view the vimscript, lua, or other language usage in the code. This helps keep submissions simple as a list for plugin developers to add and keeps it updated as things change. A few other tools are using this list to populate additional information and I feel this is a good balance for the time being. If you make a tool to view this information, we can add it to the Resource section.


Attribute name is missing of upn

Open: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims
Scroll to "Claims in id_tokens" Table.
Scroll to the end of the table
Note that Attribute name is missing for the upn "User Principal Name".

I have to execute the code and need to expand the Claims List to get this name. Please update the Document.

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

ID: 2906fe9e-319d-3625-441d-d28c9251b450
Version Independent ID: 168fde63-9b86-41a9-f1cc-7b5a0e2e5d7a
Content: Learn about the different token and claim types supported by Azure AD
Content Source: articles/active-directory/develop/active-directory-token-and-claims.md
Service: active-directory
GitHub Login: @CelesteDG
Microsoft Alias: celested

@nirnaybansal Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

Hello @nirnaybansal - Thank you for your feedback and for your patience. We refactored the old topic into two separate topics: ID tokens and Access tokens. The info about the upn claim is in the https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens topic.

#please-close


We need to supply shape dumps

In our original vision we would make the entire dataset available easily for bulk downloads as shape files, css, excel, xml etc. Lets start with shapefile and the others can easily follow:

[ ] Write a view for postgres that includes the geometry, geometry x and y as text, mandatory fields as location and all core fields. Discuss with Mark if we want to include other fields too.
[ ] Write a cron job that does a nightly pgsql2shp dump of the data into a download directory. I do not propose to keep archives at this stage so I suggest to always replace the old extract when the new one is ready
[ ] Update the 'get the data' section on the landing page to include a link to download the latest shp. Design it so that we can easily add other formats there in the future. We can convert to various formats using ogr2ogr so this should be trivial.

shapefile is missing a projection file

when opening Venezuela.dbf    I get 'General Error. General input/output error'


GitHub Binary - Support Archives

Description
binary.github can download a binary from a GitHub release, but we don't support archives (tar.gz). We should unarchive these and stick the binaries into the directory

Would the directory be a user specified directory?

Would the directory be a user specified directory?

Yea. The direction is mandatory in the spec

For the most part, this seems straight forward except for one thing. Pulling a binary is easy. On Unix platforms (BSD, Linux, MacOS), tar should be available so calling tar or gunzip isn't much of an issue for a command step. However, I don't think Windows has the tar programs apart of the base system.

7zip can deal with most of that - and looking at package managers, this is their approach.
Can (or maybe the question is "should?") comtrya have a configuration testing for 7zip dependency on a windows machine for these binaries?

With which, we can check to see if 7zip is in the path. The question here is, should we build in that we pull 7zip from winget if not present or bubble up a warning to the user and stop exeuction of that code path?

I think this depends on the way chosen to support this, and how complex of a solution do you want to introduce.
I can think of a whole bunch of 'complications' to the code base that can come in here - just not sure what would strike the correct balance in this case:

default behavior would rely on the existence of a specific extractor in path (7z.exe on windows, tar in linux, etc.)
comtrya could allow a choice of specifying an external extractor command line (making this more system agnostic, with sensible defaults per system)
It could allow this to be defined per file-type/extension
When extraction is required, test for existence of the extractor executable and prompt if it's missing (maybe with a hint of what to add as a depends on deployment tip.

This might be useful
https://github.com/cargo-bins/cargo-binstall

So looking at the source tree. Perhaps we should also rename the src/lib/src/actions/binary to "src/lib/src/actions/github" and rename the current github.rs file?
Well I guess it comes down to a greater question. When we pull down archived files, is it right to assume they are binaries? Someone could also be pulling down just the archived source with the same functionality.

download.github or download.release maybe?

I've recently stumbled over this issue and i'm wondering if it's still a valid feature request?
As @martintc already implemented two (closed) working implementations for that issue i'm curious why they got closed without merging.
I'm happy to implement that feature if no one is working on that right now (but TBH: i've never done that much with rust  - go is my preferred language :sweat_smile: )

Will close this based on the last PR. If we want to implement some different behavior, feel free to open a new issue.
That PR allows for running an unarchive action.


D450 (bundle) imu availability ?

Required Info

Camera Model
{ d4550 bundle version }

Firmware Version
(newest)

Operating System & Version
{Win (8.1/10) / Android

Kernel Version (Linux Only)
(e.g. 4.14.13)

Platform
PC/Raspberry Pi/ NVIDIA Jetson

SDK Version
2

Language
{C/C#/opencv/python/unity }

Segment
{Smartphone/VR/AR}

Issue Description
Does the 450 bunde ( caseless version ) sensor features the same IMU as the cased version of the d455 ?
Is it compatible with android librealsense library?

Hi @TheBricktop  The Depth Module versions of RealSense cameras do not feature the IMU that the IMU-equipped cased cameras (D435i and D455) have, as their purpose is dedicated to depth processing.  The diagram below illustrates which sensors are provided on the D450 module.

Hey @MartyG-RealSense I've noticed on some reseller sites that the companion d4 v3 visual processor for d450 actually has imu integrated as is in the spreadsheet from June 2020.

You are correct, the data sheet document for the 400 Series cameras has a footnote mention at the bottom of page 20 of the current edition.  Thanks very much for highlighting this feature!

I think that this somewhat should be mentioned on the Intel store site beneath the D4 board for d450 module .

The RealSense support forums are not involved in the RealSense online store.  I will certainly remember the information for future enquiries of this type though - thanks very much.

Thanks!


Added json-tree 0.5.0 parser

Note that this is a lazy parser which is why a visit is done to cause actual parsing of the document in the isValidJSON.

In the meantime we made it to version 0.9.0, should we update?


Add Authentication

Authentication and Authorization.
Currently the endpoints can be accessed by anyone and they are able to read and write or even worse delete.
[x]Secure the REST API adding authentication.
[]Protect the routes.

EPIC

[x] As a user, I should be able to login securely, so that my task information can only be accessed by  only me.

User stories

[x] As a user, no one should update/ delete / view my task, to feel secure
[ ] As a user, I should be able  to view my task, to feel secure
[ ] As a user, I should be able to delete my task, to feel in control
[ ] As a user, I should be able to update my task, to feel in control

I created a new collection in the database that will store user information as the goal collection stores goals.
In order to complete the user stories above, I used JsonWebToken to generate, decode and verify tokens for authentication and authorization purposes. i.e to match goals to their users.
I also used bcrypt to protect user passwords against rainbow table attacks and I also made sure not to store their passwords in the database.


[0.2] Add RUSTC_WRAPPER support to build script

(backport https://github.com/rust-lang/libc/pull/3842)
(cherry picked from commit 8dba4a03d23ff979eba11afac4ff0b605267cddb)

This looks fine, but any reason it doesn't use the exact same pattern as https://github.com/rust-lang/libc/pull/3842?if let rather than match

While backporting to 0.2, the Windows with rust 1.19 checks failed due to the filter() API not being stable yet for that version of rust. Using match rather than let... else with filter() fixed that.

Makes sense, thanks for the clarification.

This MR broke compilation of libc when using clippy-driver as my RUSTC_WRAPPER. I think the root cause is clippy-driver not this MR though. The clippy-driver doesn't "wrap" rustc properly, in that its output from --version isn't the same as rustc, so it can't be parsed.
For anyone else having this problem, I am currently able to workaround it by setting using RUSTC_WORKSPACE_WRAPPER, instead of RUSTC_WRAPPER. However, this brings the question to mind, by bypassing this, am I missing out on something?

Libc will need to use $RUSTC_WRAPPER $RUSTC --rustc --version when $RUSTC_WRAPPER $RUSTC --version produces output that begins with "clippy". I've need logic to handle the same thing in rustversion for a long time:
https://github.com/dtolnay/rustversion/blob/1.0.17/build/build.rs
https://github.com/dtolnay/rustversion/blob/1.0.17/build/rustc.rs

Good point, it feels like we had this same discussion somewhere else very recently. @nathaniel-bennett would you be able to put up a fix?


Live REST API & Dso list component

This PR connects to #98 and connects to #111
It contains:

The switch to the live REST API
The DSO List component
A start to the Browse Component (but still in strong need of refactoring)

My apologies for the fact that it isn't split up neater, but I'm out of time.
Known issues:

Going to the URL of any page in a paginated list will always send you to the first page
Downloaded files will always have the filename "retrieve"

Going to the URL of any page in a paginated list will always send you to the first page

The last commit fixes this issue

@artlowel : apologies, I didn't get to testing this. But, I'd say go ahead and merge once you are satisfied.  If you have any concerns, we can wait to merge post-OR2017, and simply use your demo site for any demos at OR.

I've tested it a bit and all seems to work properly. I've just found a minor issue between the pagination and the browser's back button.
For example, if you navigate to the item of the second page of the collection's item list, then go back in history, it goes to the first page of the item list instead of to the second. The pagination shows the second page as active, though.

@rivaldi8 I can reproduce the problem but I'm going to merge it, and open a separate issue for it


Command palette shows only the first OS keybinding listed in package.json for a given command

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.58.0-insider
OS Version: Linux x64 5.10.41-1-MANJARO snap

Steps to Reproduce:

Open command palette (ctrl+shift+p)
See a command with a keybinding for a different OS than the one you're running, indicated next to the command name

If a keybinding is defined with different bindings per OS in the package.json, it seems that only the first one defined is shown to the user in the command palette, rather than showing the correct keybinding for the user's OS. This has caused confusion with an extension I maintain.
With the below keybinding defined in Calva's package.json, it seems only the "mac" shortcut is shown in the command palette, regardless of the user's OS.
{
    "command": "paredit.forwardSexp",
    "mac": "alt+right",
    "win": "ctrl+right",
    "linux": "ctrl+right",
    "when": "calva:keybindingsEnabled && editorLangId == clojure && editorTextFocus && paredit:keyMap =~ /original|strict/ && config.calva.paredit.hijackVSCodeDefaults && !calva:cursorInComment || calva:cursorAfterComment"
}

Just for testing - because if I make a keybinding in vscode itself it complains if it is missing the key field and associated value - what happens if you add a "key": "alt+right" to your package.json?  Does it make a difference as to whether the correct one is shown in the Command Palette?

@alexdima do I use this wrong?
https://github.com/microsoft/vscode/blob/dc4b317192d606fd244e6d7723b18249054ed13a/src/vs/platform/quickinput/browser/commandsQuickAccess.ts#L127-L127
That is how command palette get's to know the keybinding to render.

If I add a "key": "alt+right" to the package.json for that binding, it still shows the Mac binding. Just to test another case since in the previous case the key value and the mac value are the same, I also added "key": "ctrl+right" to that binding (in place of the key value just mentioned), and it still shows the Mac binding.

Here's some more info that I've copied over here from PR #126760 which I think I should close and maybe reopen when I have a better understanding of how things are wired.
Here's is the code from keybindingResolver.ts that eventually gets called when the command palette is summoned:
	public lookupPrimaryKeybinding(commandId: string, context?: IContextKeyService): ResolvedKeybindingItem | null {
		let items = this._lookupMap.get(commandId);
		if (typeof items === 'undefined' || items.length === 0) {
			return null;
		}

		const itemMatchingContext = context &&
			Array.from(items).reverse().find(item => context.contextMatchesRules(item.when));
		return itemMatchingContext ?? items[items.length - 1];
	}

When the bug happens context.contextMatchesRules() fails to match any of te bindings that are returned from this._lookupMap.get(). Which leads to a ”best guess” fallback, which does not have enough information for making an informed guess. I saw somewhere that it should go in specificity order. And when both alternatives available for the fallback are equally specific, all bets are off.
Here are the two bindings defined for the case mentioned in OP:
            {
                "command": "paredit.forwardSexp",
                "mac": "alt+right",
                "win": "ctrl+right",
                "linux": "ctrl+right",
                "when": "calva:keybindingsEnabled && editorLangId == clojure && editorTextFocus && paredit:keyMap =~ /original|strict/ && config.calva.paredit.hijackVSCodeDefaults && !calva:cursorInComment || calva:cursorAfterComment"
            },
            {
                "command": "paredit.forwardSexp",
                "mac": "ctrl+right",
                "win": "alt+right",
                "linux": "alt+right",
                "when": "calva:keybindingsEnabled && editorLangId == clojure && editorTextFocus && paredit:keyMap =~ /original|strict/ && !config.calva.paredit.hijackVSCodeDefaults && !calva:cursorInComment || calva:cursorAfterComment"
            },

They are equally specific, only differing in wether config.calva.paredit.hijackVSCodeDefaults should be true or false, giving the command palette and other call sites an arbitrary binding alternative.
However, whatever is translating the actual keyboard events successfully interprets the context and the when clauses of the alternatives. So we shouldn't have to be guessing at all here.
I notice that editorTextFocus is false in some cases where I expect it to be true. Could it be that when the command palette is rendered, editorTextFocus is no longer true, causing both when clauses to fail, and that is why we are down to guessing?

No, it is not about the editorTextFocus. I tested with a version of Calva that only checks config.calva.paredit.hijackVSCodeDefaults for the paredit.forwardSexp command.
            {
                "command": "paredit.forwardSexp",
                "mac": "alt+right",
                "win": "ctrl+right",
                "linux": "ctrl+right",
                "when": "config.calva.paredit.hijackVSCodeDefaults"
            },
            {
                "command": "paredit.forwardSexp",
                "mac": "ctrl+right",
                "win": "alt+right",
                "linux": "alt+right",
                "when": "!config.calva.paredit.hijackVSCodeDefaults"
            },

I'm on a Mac and have left the hijackVSCodeDefaults settings with its default value of true.
Expected: Command Palette shows binding ⌥→ (The active binding.)
Actual: Command Palette shows shows binding ⌃→ (A non-active binding.)

OK. So the when clause is never taken into account for this command, afaict. I can catch the call to here:
https://github.com/microsoft/vscode/blob/60ad49e4dce16291018e8f02438769ab54b5bc89/src/vs/platform/quickinput/browser/commandsQuickAccess.ts#L127
And since there is no context provided, itemMatchingContext in keybindingResolver.ts will always evaluate tp false.

I wonder if - at least for the editor provided commands - we should pass the context key service of the active editor control. somewhere here:
https://github.com/microsoft/vscode/blob/317a9388d4d09131d569bf374ac0b5c3f39e96e9/src/vs/editor/contrib/quickAccess/commandsQuickAccess.ts#L33-L33

It might not be the whole story. When using the same lookup function from developerActions I provide a context, but then the match fails.
https://github.com/PEZ/vscode/blob/9a8791ab8cd27fcbaa23588a2165a976ba63c3ca/src/vs/workbench/browser/actions/developerActions.ts#L233
But, of course, without a context it will never get a chance to fail. 😄

@bpasero, just because this one intrigues me (and that Calva is suffering quite bad from it) I spent some little more time based off of your hint about passing the context key service of the active editor control. That control does not have a context key service, afaict.  So far I only seem to find how to grab the context from the accessor, quite early in the call chain. Am I missing something obvious?

@PEZ can we isolate this to a easier repro? Here is what I try: I configure platform specific keybindings in my keybindings file:
{
    "key": "ctrl+b",
    "command": "editor.action.addSelectionToNextFindMatch",
    "when": "editorFocus && isWindows"
},
{
    "key": "cmd+b",
    "command": "editor.action.addSelectionToNextFindMatch",
    "when": "editorFocus && isLinux"
},
{
    "key": "alt+b",
    "command": "editor.action.addSelectionToNextFindMatch",
    "when": "editorFocus && isMac"
}

When I see the command palette, the keybinding actually seems to be correct for my platform (macOS):

From all the users of IKeybindingsService.lookupKeybinding none is passing in a context key service, so I doubt this would be the right fix unless I misunderstand things.
Do you have a more isolate smaller example based on user settings?

Good idea, @bpasero! Contrast these two settings:
A:
    {
        "key": "alt+b",
        "command": "editor.action.addSelectionToNextFindMatch",
        "when": "editorFocus"
    },
    {
        "key": "ctrl+b",
        "command": "editor.action.addSelectionToNextFindMatch",
        "when": "!editorFocus"
    },

B:
    {
        "key": "alt+b",
        "command": "editor.action.addSelectionToNextFindMatch",
        "when": "!editorFocus"
    },
    {
        "key": "ctrl+b",
        "command": "editor.action.addSelectionToNextFindMatch",
        "when": "editorFocus"
    },

If you summon the palette from an editor with focus, you'd expect that alt+b was displayed for setting A. And at the very least you'd expect that if you have settings B, it would change what is displayed. Instead ctrl+b is displayed both times.
I'm a bit puzzled why your example does not expose the error, even if I move the mac-binding to the beginning...

Hey, apologies for responding slowly, as I did not have a Linux machine immediately ready to test, but I cannot reproduce. I am trying with the original steps and have created an extension with the following package.json:
{
    "name": "126306",
    "publisher": "alex",
    "version": "1.0.0",
    "engines": {
        "vscode": "^1.22.0"
    },
    "contributes": {
        "commands": [{
            "command": "paredit.forwardSexp",
            "title": "My command"
        }],
        "keybindings": [{
            "command": "paredit.forwardSexp",
            "mac": "alt+right",
            "win": "ctrl+right",
            "linux": "ctrl+right",
            "when": "calva:keybindingsEnabled && editorLangId == clojure && editorTextFocus && paredit:keyMap =~ /original|strict/ && config.calva.paredit.hijackVSCodeDefaults && !calva:cursorInComment || calva:cursorAfterComment"
        }]
    }
}

On Linux, when triggering the command palette, ctrl+right is rendered as the keybinding next to the My command command:

@alexdima see my previous comment for a repro.
In Calva the users can configure how ”aggressive” the hi-jacking of ”standard” keyboard bindings should be in favour of structural editing, via the calva.paredit.hijackVSCodeDefaults setting. Some users thinks it makes perfect sense that the standard behaviour of alt+left/right (on mac) and ctrl+left/righ (on windows and linux) behave structurally in a LISP language. Others think it is super weird that those shortcuts don't behave non-structural.
Let's take the Mac as the example. The former group will leavecalva.paredit.hijackVSCodeDefaults at its default. They then use alt+right to move forward by sexpression. But in the command palette ctrl+right is displayed. Which causes major confusion and support time. And similarly for Windows users, they will see alt+right in the palette, when the real binding is ctrl+right`.

This also gets weird for my PR #126742 (displaying command titles for shortcuts) which uses the same function to get the bindings for the command. Here I have just pressed alt+right:

If you summon the palette from an editor with focus, you'd expect that alt+b was displayed for setting A. And at the very least you'd expect that if you have settings B, it would change what is displayed. Instead ctrl+b is displayed both times.

I can see that you might expect that, but that is not what we have built. Our displayed keybindings do not reflect the current context. The reverse keyboard lookup is meant to be context-free. The idea of the reverse lookup is that it is supposed to help people discover what keybindings could trigger an action, and it is not meant to be a precise indicator of what keybindings are active in the current focused dom element (in the current context).
Here is a default shortcut that VS Code ships with:
{ "key": "cmd+/",     "command": "editor.action.commentLine",
                      "when": "editorTextFocus && !editorReadonly" },

We want to display cmd+/ next to this action in all cases, even when the cursor is not blinking in the editor, even if the editor is read only. We want to display this keybinding even if there is no editor. That is because the intent is to help users discover the keybindings:

@alexdima, I see. It defeats its purpose to discover the wrong keybinding, though, wouldn't you agree? It seems to me that in this case we can both eat the cake and have it.
The way this code is written:
		const itemMatchingContext = context &&
			Array.from(items).reverse().find(item => context.contextMatchesRules(item.when));
		return itemMatchingContext ?? items[items.length - 1];

In the case the context is matched the command palette would display the right keybinding and in the case it does not match it would fall back on the current behaviour, so the bindings would always be discoverable.

This way of relating an OS to a keybinding might work for us (using the when clause): https://github.com/microsoft/vscode/issues/126306#issuecomment-865739722
That's not, however, the original issue, which is specifically about using the OS keys like "mac", etc.

It seems to me that in this case we can both eat the cake and have it.

You're absolutely correct! I'm sorry about that, I just got myself up to speed with the changes from https://github.com/microsoft/vscode/commit/450e5d164e40334d599a17ccb0e47e9cb92c5e27#diff-1bea564a53de9969cb7e8758c4a6d68e3f57fbcd6302f4761338f63cd4fc1f42 , I must have missed the notification for those.
It is possible that this would take a performance hit, but I have pushed a change to use the global IContextKeyService when a context key service is not passed in.
To verify, configure in keybindings.json:
  { "key": "cmd+shift+A", "command": "actions.find", "when": "config.specialValue == 'A'" },
  { "key": "cmd+shift+B", "command": "actions.find", "when": "config.specialValue == 'B'" },
  { "key": "cmd+shift+C", "command": "actions.find", "when": "config.specialValue == 'C'" },

And in settings.json:
  "specialValue": "B",

And then open the command pallette and search for Find. Observe how out of the 3 possible keybindings, cmd+shift+B is preferred:

cc @eamodio I remember you were asking for something similar.

Awesome! I can't wait to try this out.
Here is that other issue for reference: https://github.com/microsoft/vscode/issues/40389

@alexdima 😢 -- this doesn't help my case, since some of the context keys in the when clause are not available in the global service -- which causes the whole expression to be false.
As a hack, I tried adding a new code path that would evaluate the when and keep track of the number of items that evaluated to true before a false value  as a way of ranking them -- more true's = better match (since I always have the first item as the config value that controls the overall binding). But since we normalize and reorder the expressions, it doesn't help either, unless we evaluate all the parts individually -- which we definitely don't want to do that because of the perf impact.

You think it is the same issue that I run into here, @eamodio? #126742


github_packages: add missing root mkpath

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

https://github.com/Homebrew/homebrew-core/runs/2501632606?check_suite_focus=true#step:10:77

Review period skipped due to critical label.


Add --metadata flag to new and upload commands

Will likely be required for https://github.com/keygen-sh/keygen-api/issues/489.
https://github.com/keygen-sh/keygen-cli/blob/4a7120005ffd0ba5d2718d05a2b114aa8777d468/cmd/new.go#L62
Metadata docs are here.

/bounty $100

/attempt #13

/attempt #13

@ezekg can you provide more info into this.

/attempt #13

@syedbarimanjan feel free to ask questions. Should be pretty straight forward.

Closed in #15.


Code cleanup post to fdp command

Changed code, replace try catch blocks with if statements and put some redundant code in a generic method. I also implemented a specific push to fdp method to prevent redundancy.

Thanks for these changes. If you can look into the codacy report as a last thing (and probably skip the npath-complexity warning for now, unless you have a good grasp on how to solve it), then we can merge if afterwards.


major bug

came here. no flow chart. followed link to the official guide's section on the 'elm architecture.' no flow chart. wtf? wtf are the flow charts?

I'm afraid I do not understand what you are talking about exactly.
A flow chart of what? Where were you expecting this chart? What information will it convey to you?
It seems there are no concrete actions based on the title or original post, so I will close. We should continue discussion here though, and open a new issue if this can be refined.


Fixed import error for takeoff checks

Fixes issue #181

lgtm (tested and confirmed fix for #181)
Will be issuing a new point release.

@djnugent Thanks very much. Also works on the examples.