Suppress missing javadoc warning

For some things like constructors that are well named and don't do much, its a little annoying to be forced to have to write a javadoc. I think its better to have no comment than a redundant one.
This suppresses this checkstyle check.
@aslo please take a look

LGTM!


Arduino Nano RP2040 Connect not detected

Hello!
I'm trying to connect Arduino Nano RP2040 Connect as a Raspberry Pico platform with the plugin on a Windows computer, but it can't be detected, even specifying the correct port (which in my case, was COM4).
The REPL runs flawlessly on COM4 using Arduino Lab for Micropython, but i'd like to use Pycharm for versioning purposes.

I have the same issue on RPi Pico.
Solution: Running Thonny, it detects COM port flawlessly.
Close Thonny, add the right com port to the Settings -> Languages & Frameworks -> MicroPython: Device Path: COM6

But i can see the RP2040 is connected to port COM4 from device manager; the problem is that even writing COM4 in the Device path won't work for me

See
https://github.com/JetBrains/intellij-micropython/issues/275


Cannot update a notification via Swagger UI

Describe the bug
Attempting to update a notification via Swagger UI returns 415, Unsupported Media Type.
In generated curl, content-type needs to be application/json instead of */*.
Note to implementer: when fixing, it would be good to go through all our APIs and check. It seems like these keep popping up.
To Reproduce
Steps to reproduce the behavior:

Go to ..../api/static/swagger-ui/index.html#/curation/updateNotification
Authorize with an admin token
Create a notification if one doesn't exist
Update the existing notification

Expected behavior
It should work
Screenshots

Additional context
Webservice - 1.10.2
UI - 2.7.4
Compose Setup - 1.1
Deploy - 1.10.1
┆Issue is synchronized with this Jira Story
┆Issue Number: DOCK-1856
┆Sprint: Sprint 66- Quagga shark
┆Issue Type: Story

This is working now
Webservice - 6f701da
UI - 2.8-44-g95bc00b5
Compose Setup - abf5bef
Deploy - 1.11.0-29-g9fc59c9


Removing require_equal_containers.h

The use of require_equal_containers.h has been buggy for a while, and was totally broken for modern versions of Boost. This removes that and replaces it with builtin boost test macros. The error messages take a slight hit from what used to be there*, but this makes it actually work without having to maintain an undocumented hack of Boost.Test.
I will be trying to test this with different versions of Boost using Travis, as I'm not sure how many versions of Boost this supports. As long as it works with at least Boost 1.59 I think this is a good improvement, though the requirements for the repo/docs will need to be updated (they currently require only Boost 1.55).
*Error messages in all of the 'containers of containers' will only report that the two containers are non-equal, and not what is different about them. It's a small loss to usability.

Ok, Travis has been updated to pass, and the documentation is updated as well.
I will be merging this in a week unless someone raises a problem. This is a long-standing problem for the repo that made many of the tests unusable for anyone on a recent distro.
See #110, #111, #91.

Branch works OK for me with:

OS X El Capitan 10.11.6
AppleClang <IP_ADDRESS>00038
Boost version 106300

I took another look through the documentation today, and added additional details around how to acquire Boost 1.59. I expect that after this change we may see a few people coming in who have a broken install (i.e. they've been using 1.55 and will then get a failed build once they get a new version), but it should not be that many people.
I expect that the vast majority of people are already using Boost 1.59+, as it is about 2 years old and every major Linux distro has updated by now (and the install process for Windows/Mac usually has people install the latest version). The notable exception is Ubuntu 16.04 LTS, which uses Boost 1.58. I've added explicit install instructions for that distro.

Awesomesauce!


Generate mark down branch

Created a function to generate markdown for README

Added fs package and generateMarkdown function from other folder
Added no license to choice of license
Added If statements if there is no license to return an empty string for the renderLicenseLink, renderLicenseBadge, and the renderLicenseSection function


TF 1.13.1 is not support

jupyter-tensorboard 0.1.9
tensorboard 1.13.1
tensorflow-gpu 1.13.1

When I upgraded the TensorFlow version to 1.13.1, I found that the JupyterTensorBoard didn't work.
Does the juypter-tensorboard have a plan to support TensorFlow 1.13.1 recently?
Can I help with something?

Hi @MichaelJiangPlus, I'm facing the same issue than you.
I'm getting an HTTP 404 on this URL:
https://xxxxxxxxxx.compute-1.amazonaws.com/user/eze1981/api/tensorboard?1555680638620\
Are you getting the same error?

In my scenario, because I'm running jupyter from a conda environment, I should enable tensorboard using the --sys-prefix flag:
jupyter tensorboard enable --sys-prefix

jupyter tensorboard enable --sys-prefix

The environment I use is the same as you，I tried to using the --sys-prefix flag. Great, this is very effective！Thank you very much.@eze1981
Then I tried to start the 1.13.1 TensorBoard with an earlier version of Jupyter-TensorBoard (0.1.8) with --sys-prefix flag.It works as well.This program can be used for a long time before Google makes a large-scale update to TensorBoard.


Select by ID

I may just be missing something here, but if I have the ID of a feature, is there a way to select that feature in the geojson.io UI?
My current solution is to switch to the "Table" view and use Cmd-F to find the feature. Clicking the row will bring the relevant feature into view. But this view can be slow to load for large files, and clicking the feature doesn't visibly highlight it in any way.
I'd be happy with a JS console solution here, too!

Hm, indeed, a console API for this would make sense - right now this is barely possible and very verbose in the console, but we could expose a much friendlier interface.

Now possible with window.api.mapLayer:
https://github.com/mapbox/geojson.io/blob/gh-pages/API.md#windowapimaplayer


Uncaught Error: Could not load animation before running it

Followed all the steps but, getting this log
zone.js:182 Uncaught Error: Could not load animation before running it     at RiveAnimationDirective.moveFrame (ng-rive.js:624)     at MapSubscriber.project (ng-rive.js:618)     at MapSubscriber._next (map.js:29)     at MapSubscriber.next (Subscriber.js:49)     at FilterSubscriber._next (filter.js:33)     at FilterSubscriber.next (Subscriber.js:49)     at SwitchMapSubscriber.notifyNext (switchMap.js:66)     at SimpleInnerSubscriber._next (innerSubscribe.js:10)     at SimpleInnerSubscriber.next (Subscriber.js:49)     at MapSubscriber._next (map.js:35)

We are seeing this same issue. Is it an implementation issue in our code or a bug that needs to be fixed? Or is it specific to the Rive animation being used? We haven't had a chance to dive into the source code to see what is throwing the error, but it seems to reproduce relatively easily.

Don't know, I also haven't dug deeper into the library. But it's not implementation error and also not specific for any animation either for sure.
So I would suggest to tag these down as bug. I will notify you if I find any solution.

It seems to have been related to the animation and either not specifying the artboard (on the canvas tag) or not specifying the name of the animation on the riv-animation element inside the canvas.

As far as I understand from your comment it seems you are pointing to incorrect reference to animation. If that's the case then, nope I have properly specified name of the animation.

Hello, sorry for the delay, the error might come from this line.
This can happen if the name or index of the animation you're providing in the <riv-animation> tag doesn't match any animation in your animation.
If you can provide a repo or a snippet of code I could maybe help here.
Let's take an example, if you want to use this animation: https://rive.app/preview/?filename=699-1369-simple-loader
Then the name of the name of the <riv-animation> should be "Animation 1" :
<!-- "loader" is the name of the file. By default it'll look here: asset/rive/loader.riv -->
<canvas width="500" height="500" riv="loader" fit="cover" alignment="center">
  <riv-animation name="Animation 1" play></riv-animation>
</canvas>

You need to specify the name of the animation because you can have multiple animations in the same canvas. For example this one has 9 animations: https://rive.app/preview/?filename=382-718-download-icon
You can take a look at the playground application code if you want to see more examples.
Please let me know what part of the readme wasn't clear enough so I can improve it 🙂. I'm open for pull request too 😉

Hopefully my comment above was clear, but it was a reference issue in our case. The name of the animation was not specified correctly. Thanks for the comment and thanks for the work in making this library!
I don't really have specific recommendations for improving the README (or I'd submit a PR) but the thing I thought while reading through it was that it does assume a fair amount of knowledge about the RIVE animations and structure. I know this is a bit of a helper library, so it's purpose probably isn't to teach how to use RIVE animations, but where it makes sense to expound a little, that could be helpful. Obviously I understand that anything added could become out of date and that is a maintenance challenge with a library of this nature.
In addition, it doesn't always list all of the options, for example, for the Output events, we had to dive into the source code to figure out that they both existed and then figure out when and in what scenarios each one was used and fired. Actually, this one would probably be an area I could maybe update the README as it's fairly fresh and we kept some notes locally. Let me see what I can do.

Ok, thanks for the feedback. I'll close this issue as it seems to be fixed.
I created this issue to improve devX for debugging: https://github.com/dappsnation/ng-rive/issues/23
Concerning the readme I'll try to keep it more up-to-date with all inputs & outputs. Don't hesitate to open a specific issue or a PR on that matter.

Thanks for the help guys. I saw the reference about name for animation in the README. But I wasn't clear about why it is used there, but again thanks for great support.


[improvement] [FE]side drawer can be closed by clicking anywhere outside the drawer

a/c:

all side drawers in control plane portal can be closed as well by clicking anywhere outside the drawer, right now it can only be closed by clicking "x" button

pass
works now- all side drawers in control plane portal can be closed as well by clicking anywhere outside the drawer


Updating spell ranges

Changes are not all inclusive. Notable exclusions: anything with 'see text' or  the spell 'hold monster'.
Updating  ranges are formatted consistently (ie 'medium' is not listed as a unit, instead 'ft' is listed).
Changes are all based off of aonsrd.com.  I've done a good bit of spot checking.  I am nevertheless too sensible of my defects not to think it probable that I may have committed many errors.

The ranges were done this way intentionally. I see what you're trying to do here, which is to keep the spell definitions in sync with the data from the books. That works great when you're playing at the table, but when you start considering automation from a VTT's standpoint, it's not so great. It makes more sense to mark these in terms of actual ranges so that module authors can calculate ranges easier. I appreciate the contribution, but the current system is working as intended.

I'm a touch confused as I'm hearing you say that spell entries having different entries for the same range classes makes the system easier for VTT automation.  Could you help me understand how storing a range value differently for two spells helps with VTT? I would expect we would want all 'long', 'medium', and 'short' range spells to be written consistently.
Currently spell ranges are not consistently encoded.  Two long ranged spells:

Acid Rain uses 'ft' as a unit
Clairaudience/Clairvoyance uses 'long' as a unit

Ok, in that case Clairaudience is incorrect and it would seem I need to remove some options from the drop down. It’s my intention that the ranges be fully stated in feet and not use the short, medium, or long range short hand.

For close, medium, long , and set ranges(ex: 130 ft) the proposed change would have always provided the unit 'ft'. Only in the other case of 'personal', 'touch', 'planteary', 'plane', "system-wide", and "unlimited" did I use a name in place of 'ft'.
Would it be best for me to submit another change with which only updates the 'ft' unit changes (ie short, medium, long, and standard ft unit)? If that is the case, would you prefer 'touch' or 'personal' was 0 ft?

I'll reopen the PR, and I think 'touch' or 'personal' are fine.

Per your request, the latest version should only have 'touch', 'personal', or 'ft' as the unit.

OK, looks good. Merging.


feat: adds metadata driven trigger framework

What does this PR do?
Adds Metadata driven trigger framework

Yes, but trigger.new and trigger.old cannot both be null. So capturing the null check on the trigger.new works.
On Jan 28, 2021, 8:23 PM -0500, Mohith Shrivastava<EMAIL_ADDRESS>wrote:

@msrivastav13 commented on this pull request.
In force-app/main/default/classes/Trigger Recipes/MetadataTriggerHandler.cls:

               handler.afterUndelete();

           }

       }

   }

}

/**

* @description This determines the active sObject type by describing the first

* record in the trigger New / Old list

* @return      `String`

*/

private String getSObjectType() {

   if (Trigger.new != null) {

       return Trigger.new[0].getSObjectType().getDescribe().getName();

   } else {

       return Trigger.old[0].getSObjectType().getDescribe().getName();

Trigger.old can be null in a few contexts (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Yes, but trigger.new and trigger.old cannot both be null. So capturing the null check on the trigger.new works.
On Jan 28, 2021, 8:23 PM -0500, Mohith Shrivastava<EMAIL_ADDRESS>wrote:

@msrivastav13 commented on this pull request.
In force-app/main/default/classes/Trigger Recipes/MetadataTriggerHandler.cls:

               handler.afterUndelete();

           }

       }

   }

}

/**

* @description This determines the active sObject type by describing the first

* record in the trigger New / Old list

* @return      `String`

*/

private String getSObjectType() {

   if (Trigger.new != null) {

       return Trigger.new[0].getSObjectType().getDescribe().getName();

   } else {

       return Trigger.old[0].getSObjectType().getDescribe().getName();

Trigger.old can be null in a few contexts (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

@pozil Github is trying to convince me to resolve one of your requested edits, but there's nothing I see that's outstanding. mind giving a re-review?

Adds the Metadata Driven Trigger recipe(s) and their Stub provider driven tests.


Adding Group to appear in the Quick Launch of the site's People and Groups Page

This might be a logical page on which to detail how to use PowerShell to add a SharePoint Group to the site's People and Groups page; i.e. to specify which SharePoint Groups to list in the left pane of the People and Groups page for a Web site.
Not sure if/how it is possible with SharePoint Online PowerShell, although after days of scouring the internet, I was eventually able to work it out using PnP PowerShell.
Is referring to PnP cmdlets out of scope for this page?
Is there a way to do this with SPO cmdlets?
For PnP this involves:-

to retrieve the existing ID's of the associate(d) groups: Get-PnPPropertyBag -key vti_associategroups
and
Set-PnPPropertyBagValue -key vti_associategroups -value GroupAID;GroupBID;GroupCID (etc.) e.g. Set-PnPPropertyBagValue -key vti_associategroups -value "112;118;712;101;504"

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

ID: 0096189e-b3e3-e26e-2d55-711323ab2a5f
Version Independent ID: 50d5393d-2dac-869a-8ade-dc2fc3d7a4cf
Content: Manage SharePoint Online users and groups with Office 365 PowerShell
Content Source: Enterprise/powershell/manage-sharepoint-users-and-groups-with-powershell.md
Service: o365-administration
GitHub Login: @JoeDavies-MSFT
Microsoft Alias: josephd

@John471  - Thank you for submitting feedback.
I will get this issue over to the Enterprise writing team for investigation.
Thank you for reporting and making the docs better. Much appreciated.
I made a note to request the team to update this when the work is complete.

@John471 This is an interesting idea for PowerShell. However, the best I can do right now is add it to the list of documentation requests for future consideration. Thanks for letting us know.


[CT-2594]  Fix serialization of warn_error_options on Contexts

resolves #7694
Problem
In core 1.5 thewarn_error_options property within the invocation_args_dict began simply stringifying the WarnErrorOptions python object as described in #7694. This is problematic because that makes it harder to deserialize. This PR ensures that the WarnErrorOptions get dict-ified for the invocation_args_dict
Solution
Specifically dict-iying the WarnErrorOptions in args_to_dict
Checklist

[X] I have read the contributing guide and understand what's expected of me
[X] I have run this code in development and it appears to resolve the stated issue
[X] This PR includes tests, or tests are not required/relevant for this PR
[ ] This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX

I believe this incurs a change to logging. @jtcohen6 is there someone specific I should tag for review as specified by the PR checklist?

Codecov Report

Merging #8180 (7f87cb4) into main (fb6c349) will decrease coverage by 21.13%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##             main    #8180       +/-   ##
===========================================
- Coverage   86.17%   65.05%   -21.13%
===========================================
  Files         174      174
  Lines       25498    25501        +3
===========================================
- Hits        21973    16589     -5384
- Misses       3525     8912     +5387

Impacted Files 	Coverage Δ
core/dbt/utils.py 74.46% <100.00%> (-6.77%) 	⬇
... and 117 files with indirect coverage changes

I'm unsure how my changes could have that big of a code coverage effect...

Rebasing off main to see if the differences in code coverage are caused by that? 😬


Adding cleanup steps to kuttl tests

Though it's ok to delete resources explicitly after every test, as I mentioned in the earlier PR the resources are indeed cleaned up. Below is a full kuttl run and resources at different times (note: we're not running tests in parallel)
--- PASS: kuttl (808.89s)
--- PASS: kuttl/harness (0.00s)
--- PASS: kuttl/harness/dataplane-create-test (1.07s)
--- PASS: kuttl/harness/dataplane-extramounts (15.16s)
--- PASS: kuttl/harness/dataplane-with-ipam-create-test (11.23s)
--- PASS: kuttl/harness/dataplane-service-custom-image (15.20s)
--- PASS: kuttl/harness/dataplane-service-config (16.13s)
--- PASS: kuttl/harness/dataplane-deploy-no-nodes-test (420.45s)
--- PASS: kuttl/harness/dataplane-deploy-global-service-test (226.31s)
--- PASS: kuttl/harness/dataplane-deploy-tls-test (102.64s)
PASS
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanenodeset -n openstack
NAME                    STATUS   MESSAGE
edpm-compute-no-nodes   False    Deployment in progress
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanedeployment -n openstack
NAME                    NODESETS                    STATUS   MESSAGE
edpm-compute-no-nodes   ["edpm-compute-no-nodes"]   False    Deployment in progress
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanedeployment -n openstack
NAME                         NODESETS                    STATUS   MESSAGE
edpm-compute-no-nodes        ["edpm-compute-no-nodes"]   True     Setup complete
edpm-compute-no-nodes-ovrd   ["edpm-compute-no-nodes"]   True     Setup complete
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanenodeset -n openstack
NAME                    STATUS   MESSAGE
edpm-compute-no-nodes   True     NodeSet Ready
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanenodeset -n openstack
NAME                    STATUS   MESSAGE
edpm-compute-no-nodes   False    Deployment in progress
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanedeployment -n openstack
NAME                  NODESETS                  STATUS   MESSAGE
edpm-compute-global   ["edpm-compute-global"]
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanenodeset -n openstack
NAME                  STATUS   MESSAGE
edpm-compute-global   False    Deployment in progress
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanenodeset -n openstack
NAME                  STATUS   MESSAGE
edpm-compute-global   False    Deployment in progress
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanenodeset -n openstack
NAME                 STATUS   MESSAGE
openstack-edpm-tls   False    Deployment not started
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanedeployment -n openstack
No resources found in openstack namespace.
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanedeployment -n openstack
NAME                 NODESETS                 STATUS   MESSAGE
openstack-edpm-tls   ["openstack-edpm-tls"]   False    Deployment in progress
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanedeployment -n openstack
NAME                      NODESETS                 STATUS   MESSAGE
openstack-edpm-tls        ["openstack-edpm-tls"]   True     Setup complete
openstack-edpm-tls-ovrd   ["openstack-edpm-tls"]   False    Deployment in progress
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanenodeset -n openstack
NAME                 STATUS   MESSAGE
openstack-edpm-tls   True     NodeSet Ready
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanenodeset -n openstack
No resources found in openstack namespace.
[stack@osp-df-2 install_yamls]$ oc get openstackdataplanedeployment -n openstack
No resources found in openstack namespace.
[stack@osp-df-2 install_yamls]$ oc get openstackansibleee -n openstack
No resources found in openstack namespace.

/retest

recheck - retry limit

I don't understand why this is needed. Unless you pass --skip-delete, anything created in the tests will be automatically deleted.
What this would do is delete any of these other resources that exist and were created outside the test, but only after the test. So, this doesn't make sense to me, and it would actually make it harder to debug why a test may have failed...
1. fail the first time due to existence of unrelated resources that pollute the test

2. unrelated resources are deleted by 99-cleanup.yml

3. test now passes

very hard to tell why it failed the first time.

If I understand the kuttl docs[1] correctly. The automated cleanup does not happen, when the tests are executed in the same namespace. In our case that would be the openstack. We could add cleanup tests as test before each test.
[1] https://kuttl.dev/docs/testing/test-environments.html#single-namespace-testing

I don't understand why this is needed. Unless you pass --skip-delete, anything created in the tests will be automatically deleted.
What this would do is delete any of these other resources that exist and were created outside the test, but only after the test. So, this doesn't make sense to me, and it would actually make it harder to debug why a test may have failed...
1. fail the first time due to existence of unrelated resources that pollute the test

2. unrelated resources are deleted by 99-cleanup.yml

3. test now passes

very hard to tell why it failed the first time.

If I understand the kuttl docs[1] correctly. The automated cleanup does not happen, when the tests are executed in the same namespace. In our case that would be the openstack. We could add cleanup tests as test before each test.
[1] https://kuttl.dev/docs/testing/test-environments.html#single-namespace-testing

That's not the observed behavior. That can be checked in our kuttl test logs. No resources are left behind. Are you seeing differently or is something else already cleaning them up? What issue is this trying to fix?

I don't understand why this is needed. Unless you pass --skip-delete, anything created in the tests will be automatically deleted.
What this would do is delete any of these other resources that exist and were created outside the test, but only after the test. So, this doesn't make sense to me, and it would actually make it harder to debug why a test may have failed...
1. fail the first time due to existence of unrelated resources that pollute the test

2. unrelated resources are deleted by 99-cleanup.yml

3. test now passes

very hard to tell why it failed the first time.

If I understand the kuttl docs[1] correctly. The automated cleanup does not happen, when the tests are executed in the same namespace. In our case that would be the openstack. We could add cleanup tests as test before each test.
[1] https://kuttl.dev/docs/testing/test-environments.html#single-namespace-testing

That's not the observed behavior. That can be checked in our kuttl test logs. No resources are left behind. Are you seeing differently or is something else already cleaning them up? What issue is this trying to fix?

With our tests still being a bit flaky I thought that explicitly removing leftovers from previous test cases could help. Especially since the documentation seemed to indicate that it's necessary if we are defining our own namespace.
But, I understand that the current behavior differs from what would be expected if that was the case.


Create log console

Open a window that shows the Winch logs as they are written
Make it optional from the Settings tab
Include a search feature, severity filter, and mod source filter

Instead this was implemented as a log console directly in Winch 0.3.1


WMF\Reader\WMF\Magic : Backends sorted by priority

Pull Request Test Coverage Report for Build<PHONE_NUMBER>0
Details

28 of 29 (96.55%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+3.4%) to 89.316%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/WMF/Reader/WMF/GD.php
2
3
66.67%

Totals

Change from base Build<PHONE_NUMBER>8:
3.4%

Covered Lines:
209

Relevant Lines:
234

💛  - Coveralls


python311Packages.scipy: attmpt to fix Darwin build

Description of changes
cc @vcunat .
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This builds for me on aarch64-darwin.  With both pythons; BTW 3.12 is the default now.

BTW what do you think about the time out pytest failure reported by ofborg?
FAILED lib/python3.12/site-packages/scipy/optimize/tests/test_milp.py::test_milp_timeout_16545[options0-Time limit reached. (HiGHS Status 13:] - assert None is not None

It's not present on Hydra right?

Probably a transient issue, maybe the CI machine was more loaded at that point.  Scipy on linux seems OK on Hydra's last eval: https://hydra.nixos.org/eval/1807322?filter=scipy#tabs-still-succeed


Enable the casper-mainnet feature by default in manifests

This adds the casper-mainnet feature to the set of default features in the node and the client. This feature is responsible for keeping the software on the legacy hashing scheme in protocol versions up to the one where we will switch to fast sync, and should be enabled in all builds intended for use in the mainnet.

bors merge


There's something funky in the coast of South America

Hello again. I've noticed something weird is going on around the south america's south and east routing. The routes become unnecessary long for no particular reason:
latFrom  	  lonFrom  	  latTo  	  lonTo
-26.8895517092518	-48.6897540649155	-54.812105803446045	-68.29988218200157
-37.09185465569397	-73.1540339191571	-50.37664399331081	-75.33395584925265

Also, i can't find the exact coordinates, but i tried to route something short out of Argentina coast (
-30	-50	=> -45	-32
):
and it makes a weird turn

It's usually worse for short voyages for some reason.

Hi @siggemannen, the issue was caused by uncomplete LineString connections between them on this specific geo area. Fixed this, will be visible on the next published version.
Please note that on this specific area, the network is not very sensible to short distances, this can be fixed by adding more LineStrings on the network.

Hi @siggemannen, can you try on the latest realse https://github.com/genthalili/searoute-py/releases/tag/1.0.9?
Let me know if that fixed your issue.


MWPW-152952 Allow message for Marketo form success

Fixes issue that was preventing "message" success type for Marketo forms
FYI there's also a fix needed on the MCZ side for the message to fully work

Resolves: MWPW-152952
Test URLs:

Before: https://main--milo--adobecom.hlx.page/drafts/methomas/marketo-message?martech=off
After: https://methomas-marketo-message--milo--adobecom.hlx.page/drafts/methomas/marketo-message?martech=off

To verify:

Note that the form doesn't redirect
Also, look in the console under "Form Type & Version" -> "success"
The content should be a thank you message: "Thank you. Your request has been..."
The type should be "message"

Regression:
(Should redirect)

https://main--bacom--adobecom.hlx.live/?milolibs=methomas-marketo-message

@overmyheadandbody This waiting on work from the MCZ team which has had some delays.

FYI @Brandon32 will be taking over this PR while I'm on sabbatical


Upgrade maven-install-plugin 2.5.2 -> 3.1.2

This PR contains the following updates:

Package
Type
Update
Change

maven-install-plugin
build
major
2.5.2 -> 3.1.2

[ ] If you want to rebase/retry this PR, check this box

Warning
Renovate's suggested commit message is being replaced with improved initial commits to enable automerging. As a side effect, these suggested commit messages might have changed. Consider comparing the initial commit message and this message to determine the most suitable one. Please leave feedback in #sys-renovate.

Suggested commit message:
Upgrade maven-install-plugin 2.5.2 -> 3.1.1

See:
- https://github.com/apache/maven-install-plugin/releases/tag/maven-install-plugin-3.0.0-M1
- https://github.com/apache/maven-install-plugin/releases/tag/maven-install-plugin-3.0.0
- https://github.com/apache/maven-install-plugin/releases/tag/maven-install-plugin-3.0.1
- https://github.com/apache/maven-install-plugin/releases/tag/maven-install-plugin-3.1.0
- https://github.com/apache/maven-install-plugin/releases/tag/maven-install-plugin-3.1.1
- https://github.com/apache/maven-install-plugin/compare/maven-install-plugin-2.5.2...maven-install-plugin-3.1.1

Edited/Blocked Notification
Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.
You can manually request rebase by checking the rebase/retry box above.
⚠ Warning: custom changes will be lost.


Updated UI elements in the docs page

Why:
Closes #20426

What's being changed (if available, include any code snippets, screenshots, or gifs):

Updated the screenshots and placeholder images in the https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews page.
Check off the following:

[x] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

Thanks so much for taking the time to submit this PR. :sparkles: We have a few issues that could use some extra help this Hacktoberfest. If you’re up for working on another help wanted issue, look for the pumpkin-spice label.


Use /etc/os-release to determine linux distro #204

Fixes #204
When determine linux distribution use the new configuration file /etc/os-release instead of per-distribution release files /etc/*-release. The majority of the big distributions adopted /etc/os-release.

Hi @havoron, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

Thanks for digging into the installation problem on Linux Mint and submitting this PR. Much appreciated!

@havoron, as much as I'd like to take this into master, we're locked down at the moment. Could you rebase this against the dev branch?

Closing in favor of https://github.com/OmniSharp/omnisharp-vscode/pull/232


Information about supported Java versions

I've noticed that you used the new lambda expression in Java (e.g. https://github.com/ifedapoolarewaju/transloadit-java-sdk/blob/master/src/com/transloadit/sdk/Steps.java#L73). However, they are only available as of Java 8 and this version is not widely supported, yet. Compilers will probably be able to compile in a way so the Java7 runtimes can still deal with it but not all people use a Java 8-compatible compiler. So you may want to reconsider using these features for supporting more Java version. Setting up Travis tests will help you there (compare https://github.com/tus/tus-java-client/blob/master/.travis.yml)

@Acconut I have addressed this issue here


Voting system and threshold required to accept a proposal

Currently we are considering two approaches to identify an accepted proposal

A proposal has at least the 51% of the preferences (where 51% refers to the active stake)
A proposal has at least 90-95% of the preferences.

The proposal 1) has the advantage that an adversary controlling only the minority of the stake cannot stop an update, if the honest parties want update the system according to some proposal.
The disadvantage of 1) is that the "sentiments" of the parties participating to the blockchain could  change given that the system could be updated even with such a low threshold.
The proposal 2) has the advantage that a proposal is accepted only if almost all the participants are happy about that proposal. The disadvantage is that an adversarial party could always prevent the system to update (which means that critical security fix might not be applied).
In any case, it seems to be that we want to use a voting system that is different from the current one (where the preferences for the proposals are written inside the blocks issued by the miners). In this case we should decide whether to use an approach based on a committee (that is decided in such a way that the majority of the committee is honest), or an approach that allows all the parties to vote.
In both cases we should consider the problem of adaptive/static corruptions of the voters (maybe this is critical only if we use the committee approach).

See FC20 submitted paper.


[ECO-451] Bootstrap node with an environment when set in first-boot.json

Adds the ability to bootstrap a node with an environment when one is set in first-boot.json. Order of environment preference: -E ENV, -j JSON, config file.
@chef/client-core

@mcquin I put that requirement in originally, but now I think I was wrong. I think I brainfarted on the "Chef-solo totally supports environments" thing. I've removed the requirement from the original card.

@alexpop

Additionally, does not set an environment value in /etc/chef/client.rb:
> bundle exec knife environment create production
> bundle exec knife bootstrap localhost -p 2200 -x vagrant -P vagrant -N test00 -j "{\"environment\": \"production\"}" --sudo
> vagrant ssh
$ cat /etc/chef/client.rb
log_location     STDOUT
chef_server_url  "https://api.opscode.com/organizations/****"
validation_client_name "****-validator"
node_name "test00"

:+1:

:+1:

Most notable update to this PR is here. Does this seem sane @chef/client-core ?

LGTM!  Does anyone else have opinions on how this should work?

Ping @chef/client-core

LGTM - one definitely does not want one's environment to wind up in the node's client.rb because that way lies sadness and confusion. :+1:

It is worth noting this may introduce confusion as a lot of people are already fuzzy on node.chef_environment vs. node['chef_environment']. Normally the latter is nil so at least errors are caught early, with this in place I think it would mean that the latter would always return the env the node was bootstrapped with, while future changes might make it different from node.chef_environment. Still :+1: on the feature, but we should bump up the priority of resolving this other issue. Probably would be good to always set node['chef_environment'] to the current value at the start of a run. That doesn't resolve the issue of setting it inside recipe code though, or how to handle something like a role that overrides the attribute (which would have no effect on node.chef_environment).

Correct, node['chef_environment'] and node.chef_environment at the start of a run are now the environment the node was bootstrapped with.
@coderanger

we should bump up the priority of resolving this other issue

What exactly is "this other issue"? That node.chef_environment and node['chef_environment'] may disagree at the start of a run?

I think you are scrubbing the actual attribute values, so more of a user expectation issue. They might think they could use node['chef_environment'] because it was set in an attributes JSON file, but it isn't an attribute value.

Taking a step back to what's confusing me...
What exactly is the purpose of first boot attributes? Are they meant to be used /only/ during bootstrap/the first time chef-client runs, or do they persist (see: https://github.com/chef/chef/pull/3595#discussion_r33633076)? Should the environment a node is bootstrapped with only be applied to the node during bootstrap (i.e., running chef-client again on the node will use _default if no other environment is specified)?

Attribute passed in via -j are persistent, they are set as the value of node.normal and will last indefinitely. Separately from that we have the issue that node.chef_environment is not attribute data, normally node['chef_environment'] will be unset (nil) because Chef::Node#chef_environment is a real attr_accessor, not a use of the old method_missing fallback for attributes. I'm unclear we are trying to add a way to set the environment via attribute data when the environment of a node is not kept as an attribute, and I'm worried it will increase the confusion around this issue.

I'm unclear we are trying to add a way to set the environment via attribute data when the environment of a node is not kept as an attribute, and I'm worried it will increase the confusion around this issue.

Maybe @charlesjohnson and @alexpop can help answer this question.

The underlying pain, along with @alexpop's original proposal for this fix, is outlined here: https://feedback.chef.io/forums/301644-chef-product-feedback/suggestions/8278449-support-specifying-node-environment-in-first-boot:

I've seen users having difficulties figuring out how to specify the chef environment while implementing an unattended chef-client bootstrap:
https://docs.chef.io/install_bootstrap.html#unattended-installs

Right now, the --environment option needs to be used for chef-client to place the node in a specific environment.

First instinct was to add the chef_environment to 'first-boot.json' along with the run_list and normal attributes. From an automation perspective, it makes more sense to generate a client.rb, a json file and run chef-client. So, this enhancement request is to allow the chef_environment to be specified in the json attributes and just call this on the first chef-client run:
chef-client -j /etc/chef/first-boot.json

On failure, it's a simple command to run without having to remember how to specify the environment.

So if we need to re-state, then how about: "As a Chef User I want to bootstrap nodes from a single configuration file without additional command-line flags, so that unattended installs no longer require humans to track additional metadata when interacting with the unattended install process. This single configuration file should contain all of the data currently stored in first-boot.json, as well as the node environment if specified."

Hmm, so this won't allow setting a run list, which would probably be a hard requirement for that story. Perhaps we should rewind a whole bunch and make a new option which accepts an actual node JSON file? That would cover attributes, environment, run list, and anything else that gets added to nodes later (eg. the attributes 2.0 data split). That still wouldn't handle the forthcoming Ohai config data or chef_server_url/encrypted_data_bag_secret which are read from knife's config and are never part of a node object.
If we combine all that, I'm not sure how great this looks as a feature anymore, would end up looking a lot like spiceweasel maybe? Would be :+1: on have a --json-node to cover at least all data stored in the node object itself.

Also "unattended installs" usually doesn't mean knife bootstrap, which is all this covers (and the cloud plugins that use knife bootstrap under the hood). If you mean "unattended" in terms of things like autoscaling or self-healing systems, this is not going to help there. Can you clarify that piece of the use case a bit?

That's way too big. YAGNI.
Again: Instead of chef-client -j first-boot.json -E chef_environment, we want: chef-client --some-flag unattended-config-file-that-has-everything-you-would-put-in-first-boot-json-and-also-the-node-environment.
If piggybacking the unattended install data into first-boot.json isn't the right solution then okay, but that's the requirement.

@charlesjohnson Okay, then we can close out, this change is about adding this feature to knife bootstrap, not to chef-client. I think there was just a miscommunication on the goals here. -j on the client has a different meaning vs. knife :-)

Nope, this isn't about knife bootstrap. This is about chef-client --some-flag unattended-config-file-that-has-everything-you-would-put-in-first-boot-json-and-also-the-node-environment.

@charlesjohnson I think @coderanger means this PR is about bootstrap.

Yes, I mean that this PR is not what you want.

I will be tackling this in another PR that addresses the core issue.

:+1: @mcquin https://github.com/chef/chef/blob/master/lib/chef/node.rb#L316-L322 is probably the right place to add this.

@coderanger Looks likely. Thanks! :)


Helm release details page is stale after upgrade

https://user-images.githubusercontent.com/40840436/188977419-0757fd40-be9e-4b2a-b9a4-ba20dd73b866.mov
Observed on 6.0.1-latest

the details are also stale when transitioning from one helm release to another. It seems to keep the yaml of the first viewed helm release.


added CLI flag to choose custom CA CommonName

CLI flag -ca-cn to override the default common name in the generated CA.
Even internal CAs used with domestic microservices can have a personal touch!

@jsha no luv for personal touch? :)


Prepare website for internationalization content in diffrent languages

Hi @cjyabraham,
May I ask if you could take a look at this PR to ensure it fits with the site design to support i18n.
Many thanks for this


chore: fix datalist e2e

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Refactoring
[ ] Build or CI related changes
[x] Tests related changes
[ ] Documentation content changes

What is the current behaviour?
Closes #
What is the new behaviour?

@nsbarsukov ping


Update free-programming-books-subjects.md

What does this PR do?
Add resource(s)
For resources
Description
A book about OOP in JAVA
Why is this valuable (or not)?
It teaches the fundamentals of OOP.
How do we know it's really free?
The BAOU is an organization which provides free resources.
For book lists, is it a book? For course lists, is it a course? etc.
It's a book.
Checklist:

[x] Read our contributing guidelines.
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction).
[x] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

Thanks, and welcome to free-programming-books!


the error of freeze model

OS Platform:  Ubuntu 16.04
TensorFlow installed from:  anaconda
TensorFlow version: GPU-1.8
Python version: 3.6.6
CUDA/cuDNN version: 9.0 / 7.1.2
GPU model and memory:16G

The model is mobilenetV2 + LSTM + attention.
MobilenetV2 is restored from the model zoo in https://github.com/tensorflow/models/tree/master/research/slim. It is not trained during the training of the whole model.
LSTM and attention is trained.
The code about model is shown as following.
    def mobilenet_v2_rnn_attention(self, X, num_classes, dropout_keep_prob=0.8, is_train=False):
        rnn_size = 4096
        num_layers = 8
        attention_size = 1024
        arg_scope = training_scope()
        with slim.arg_scope(arg_scope):
            net_vis, end_points = mobilenet_base(X, num_classes=num_classes)
        with slim.arg_scope([slim.conv2d, slim.max_pool2d, slim.avg_pool2d], stride=1, padding='SAME'):
            with tf.variable_scope('Logits_out'):
                orig_shape = net_vis.get_shape().as_list()
                net = tf.reshape(net_vis, [-1, orig_shape[1] * orig_shape[2], orig_shape[3]])

                def lstm_cell():
                    return tf.contrib.rnn.LSTMCell(rnn_size)

                stack = tf.contrib.rnn.MultiRNNCell([lstm_cell() for _ in range(0, num_layers)], state_is_tuple=True)
                net, _ = tf.nn.dynamic_rnn(stack, net, dtype=tf.float32)
                # (B, T, D) => (T, B, D)
                net = tf.transpose(net, (1, 0, 2))
                net = attention(net, attention_size, True)
                net = slim.fully_connected(net, num_classes, activation_fn=None, scope='Logits_out1')
        return net, net_vis

At the first, I export the graph as following.
    X = tf.placeholder(tf.float32, [None, height, width, 3], name="inputs_placeholder")
    net, net_vis = build_model(X, num_classes, 1.0, False, arch_model)
    net = tf.nn.sigmoid(net)
    predict = tf.reshape(net, [-1, num_classes], name='predictions')

    graph_def = graph.as_graph_def()

    with gfile.GFile(FLAGS.output_file, 'wb') as f:
      f.write(graph_def.SerializeToString())

Then, freeze the model using the api
python /root/anaconda3/pkgs/tensorflow-base-1.8.0-py36hc1a7637_0/lib/python3.6/site-
    packages/tensorflow/python/tools/freeze_graph.py \
      --input_graph=${INFERENCE_GRAPH_PATH}/${TMP_GRAPH} \
      --input_checkpoint=${CHECKPOINT_PATH}/model.ckpt-3800 \
      --input_binary=true \
      --output_graph=${CHECKPOINT_PATH}/${EXPORT_INF_GRAPH} \
      --output_node_names=${OUTPUT_NODE_NAME}

The error is shown as following.
[libprotobuf FATAL google/protobuf/wire_format.cc:830] CHECK failed: (output->ByteCount()) == (expected_endpoint): : Protocol message serialized to a size different from what was originally expected.  Perhaps it was modified by another thread during serialization?

Thank you for your post. We noticed you have not filled out the following field in the issue template. Could you update them if they are relevant in your case, or leave them as N/A? Thanks.
Have I written custom code
OS Platform and Distribution
Bazel version
Exact command to reproduce
Mobile device


Simulate peer disconnection when resync is required

However is reviewing this, add ?w=1 at the end of the url in order to ommit the whitespaces from the review. Note: you won't be able to comment in this mode.
This is the full url: https://github.com/stratisproject/StratisBitcoinFullNode/pull/1636/files?w=1


Security

make sure individual needs physical access to device in order to get plaintext password.
SSH should be disabled
FPT
any other random procs.

I disabled ssh and added it to setup file, should be good.


Showcase sites need to be updated; one w/ redirects.

The following sites don't work:

https://explore.visitsarasota.org
http://www.roboterwelt.de

The following site seems to have been eaten by malware and is giving redirects:

http://webonise.co.uk/

A few of the other sites have also been updated, so the thumbnails might be do well with an update.

Hello, I think this one needs to be in Pull Request. Please do fork this project, and make changes from your forked project. Then propose your changes to the main repository/project. Glad this would help you since a lot of issues are not being checked or likely being ignored due to rules are not followed.


Restructure Deployment for Dev & Production Servers

This PR has a few small changes

Removes the VolumeClaim from the helm chart. This is now managed by the cluster administrator (over at k8s-cluster).
Creates a single PersistentVolumeClaim and shares is across all pods

This is currently deployed on the development kubernetes server and all pods are stable.
Fixes #31

Looks good after a quick scan, thanks @ThomasThelen.


Could not find a JSTalk connection to com.bohemiancoding.sketch3.JSTalk

Where is your Sketch installed?

Is it in a directory other than /Applications?
Is it called soemthing other than Sketch (maybe Sketch beta?)


make cluster-up fails

Steps to reproduce

Install kind following this doc

[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.20.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind
kind version
kind v0.20.0 go1.20.4 linux/amd64

git clone https://github.com/sustainable-computing-io/kepler-operator.git

Output of make cluster-up attached in the issue

make cluster-up output.txt

Are you using podman or docker?

podman

@husky-parul does kind create cluster work for you?
I also feel we should move this to https://github.com/sustainable-computing-io/local-dev-cluster

Found somewhat similar issue with creating kind cluster using podman

@sthaha kind create cluster works. I ended up creating the cluster using these steps

Found somewhat similar issue with creating kind cluster using podman

@vprashar2929 @sthaha when I followed the steps in the docs for Local cluster setup it worked with podman
podman ps
CONTAINER ID  IMAGE                                                                                COMMAND     CREATED     STATUS      PORTS                      NAMES
e2b5b620c0a7  docker.io/kindest/node@sha256:3966ac761ae0136263ffdb6cfd4db23ef8a83cba8a463690e98317add2c9ba72              6 days ago  Up 6 days   <IP_ADDRESS>:41873->6443/tcp  kind-control-plane

docker ps
bash: docker: command not found...
Packages providing this file are:
'moby-engine'
'podman-docker'


Add setuptools to requirements for pkg_resources

I just saw a failure when using uproot with the traceback:
+ python -c 'import uproot; assert len(uproot.open("root://eospublic.cern.ch//eos/root-eos/cms_opendata_2012_nanoaod/Run2012B_DoubleMuParked.root")["Events"]["PV_x"].array()) == 29308627'
Traceback (most recent call last):
  File "/home/conda/feedstock_root/build_artifacts/uproot_1608368458292/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.9/site-packages/uproot/extras.py", line 21, in awkward
    import awkward
  File "/home/conda/feedstock_root/build_artifacts/uproot_1608368458292/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.9/site-packages/awkward/__init__.py", line 29, in <module>
    import awkward._cpu_kernels
  File "/home/conda/feedstock_root/build_artifacts/uproot_1608368458292/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.9/site-packages/awkward/_cpu_kernels.py", line 7, in <module>
    import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/conda/feedstock_root/build_artifacts/uproot_1608368458292/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.9/site-packages/uproot/behaviors/TBranch.py", line 2059, in array
    _ranges_or_baskets_to_arrays(
  File "/home/conda/feedstock_root/build_artifacts/uproot_1608368458292/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.9/site-packages/uproot/behaviors/TBranch.py", line 3430, in _ranges_or_baskets_to_arrays
    uproot.source.futures.delayed_raise(*obj)
  File "/home/conda/feedstock_root/build_artifacts/uproot_1608368458292/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.9/site-packages/uproot/source/futures.py", line 46, in delayed_raise
    raise exception_value.with_traceback(traceback)
  File "/home/conda/feedstock_root/build_artifacts/uproot_1608368458292/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.9/site-packages/uproot/behaviors/TBranch.py", line 3401, in basket_to_array
    arrays[branch.cache_key] = interpretation.final_array(
  File "/home/conda/feedstock_root/build_artifacts/uproot_1608368458292/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.9/site-packages/uproot/interpretation/numerical.py", line 115, in final_array
    output = library.finalize(output, branch, self, entry_start, entry_stop)
  File "/home/conda/feedstock_root/build_artifacts/uproot_1608368458292/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.9/site-packages/uproot/interpretation/library.py", line 481, in finalize
    awkward = self.imported
  File "/home/conda/feedstock_root/build_artifacts/uproot_1608368458292/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.9/site-packages/uproot/interpretation/library.py", line 478, in imported
    return uproot.extras.awkward()
  File "/home/conda/feedstock_root/build_artifacts/uproot_1608368458292/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.9/site-packages/uproot/extras.py", line 23, in awkward
    raise ImportError(
ImportError: install the 'awkward' package with:

    pip install awkward

Alternatively, you can use ``library="np"`` or globally set ``uproot.default_library``
to output as NumPy arrays, rather than Awkward arrays.

Tests failed for uproot-4.0.0-pyhd8ed1ab_0.tar.bz2 - moving package to /home/conda/feedstock_root/build_artifacts/broken

The issue is that pkg_resources is part of setuptools and this isn't declared in the awkward install_requires. As it's a dependency of pip it's rare to be running on a system without it installed so it's often missed as a dependency.

Thanks! I think what happened here is that all my testing systems already had this installed.


Configure Azure Pipelines

This pipeline configuration builds the application and produces a build for the Release configuration.

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


Feature/chessboard

task #81

From playGame.js, all of the changes that prevented errors on the display of not running games have vanished; and some errors gave even been re-introduced. @wiilee, I guess you simply copied your whole local state over the state of develop. Please do a proper merging instead, otherwise this pull request can not be approved.

ok is fixed

Looks good to me now. Next time, please use the pull request template though.


Adding F16 GEMM variants

Hi @alheinecke May I know when libxsmm will support such case :   io_generated_code->arch >= LIBXSMM_X86_AVX512_SPR ) &&               (LIBXSMM_GEMM_GETENUM_AB_COMMON_PREC( l_xgemm_desc_mod.datatype ) == LIBXSMM_DATATYPE_F16) &&               (LIBXSMM_GEMM_GETENUM_C_PREC( l_xgemm_desc_mod.datatype ) == LIBXSMM_DATATYPE_F16 || LIBXSMM_GEMM_GETENUM_C_PREC( l_xgemm_desc_mod.datatype ) == LIBXSMM_DATATYPE_F32) ?

Not sure what you mean, there is GNR and SPR support for F16 GEMM. Can you please be add more details to your question? @egeor  just in case.

@alheinecke I mean it seems F16 GEMM in VNNI layout hasn't been supported yet. https://github.com/libxsmm/libxsmm/pull/769/files#diff-13c297ba78236d6ab7f88f9fd9f883c9bd27fcaf4fa2b8fb79ea836e617cf183R293 Will it be supported in the future ？

This is supported for GNR already in the codebase. For SPR we do not support it and it is not in the plans to do so... Since this would not be performance on SPR anyway, most likely the best option is to have the application deal with the reformats/relayouts upfront and call existing high-performance gemm kernels.

@egeor Sorry for not describing it clearly. It seems that there is no support for such gemm with VNNI layout on GNR:  takes fp16 inputs and generates fp32/fp16 output ? https://github.com/libxsmm/libxsmm/blob/main/src/generator_gemm.c#L361

I still don't understand...  see here:
https://github.com/libxsmm/libxsmm/blob/main/src/generator_gemm.c#L324
and here
https://github.com/libxsmm/libxsmm/blob/main/src/generator_gemm.c#L637

@egeor  Oh, I understand. I missed io_generated_code->arch >= LIBXSMM_X86_AVX512_GNR. Thank you very much for your patient answer.


Issue with NominalMetadataType.genericArguments()

Hi,
I've been trying to get the GraphQL related https://github.com/GraphQLSwift/Graphiti project upgraded to Swift5 using the latest version of this library and came across a crash running the tests. The crash occurs in NominalMetadataType.genericArguments() when trying to get the TypeInfo for a simple Struct. I noticed that the Struct was declared nested within a closure.
It appears that NominalMetadataType.genericArguments() is coming back with a non-zero size results when it ought to be zero, and sometimes crashes.
To try and reproduce the problem within this project directly I've added a new test to MetadataTests.swift called testNestedStruct.
Please see this branch on my fork https://github.com/SportlabsTechnology/Runtime/tree/investigateCrash
Weirdly the addition of this new test causes the existing testStruct test to detect a non-zero amount of genericArguments and fail.
Any ideas ands help appreciated.
Thanks,
Mike.

Not to sure whats going on off the top of my head. Ill take a look soon. Thanks for the test case!

@sportlabsMike Not too sure why it being nested within a function is messing it up. If the nested struct was generic it would work.
Ended up getting it to work by checking the metadata flags to make sure the type is generic before trying to read the arguments.
I have a branch if you wouldn't mind testing it out: nested-struct-crash. If that fixes your issue Ill merge it.

@wickwirew that nested-struct-crash branch looks good. Thanks!

Awesome thanks! Its been merged and 2.1.0 has been released


Inline field styling in live preview mode

Is your feature request related to a problem? Please describe.
I virtually never use Reading View, preferring Live Preview. Except quick references like MOCs, I don't often open a note without wanting to edit it. It's therefore important to me that styling features work in Live Preview. Without styling, inline fields don't call much attention to themselves, and I find their readability impeded.
Describe the solution you'd like
Styling of inline fields in Live Preview similar to what we get with Reading View.
Describe alternatives you've considered
I've considered making heavier use of Reading View, but I haven't found a way to switch between reading and editing in an ergonomic way. I typically use vim bindings to move around, which doesn't work in Reading View.

Fellow vimmer! I've wanted a vimium-like for reading view but no dice.
Anyhow, you could potentially reuse DV's CSS snippets as a custom snippet but I think that depends on how the codemirror processor handles inline DV fields. I'll let blacksmithgu comment on this.

Yeah, I may wind up looking into custom CSS snippets, but I find those a bit painful to work with, so I thought it would be reasonable as a feature request.

As far as I am aware, this has to be done as a CodeMirror extension. I haven't tried doing it yet because it seems quite complicated! The reference documentation is here (https://codemirror.net/6/docs/ref/#view.Decoration^replace)... if anyone has even a vague clue about how to do this in Obsidian it would be greatly appreciated.

I came here for kind of a +1 message but it seems there is already some progress on this issue.
Looks to be rather complex which is a pity as this would be an extremely nice change.
Unfortunately I am no programmer but if ever gets somewhere and testers are needed I will be available.

It's finally here in v0.5.60!
So I assume this issue can now be closed.

Also date time fields are not formatted according to the settings.
Live Preview:

Reading Mode:

@vruyr Fixed in 0.5.61.


Fix SELinux issues with gsi-openssh tests

On EL7, SELinux forbids sshd (and gsisshd) from opening unregistered ports (e.g. 2222). This fix allows gsisshd to use port 2222 for the duration of the osg-test run. Some contortions were necessary so that the tests OkSkip if we need policycoreutils-python and can't find it.

Test results: http://vdt.cs.wisc.edu/tests/20170706-1718/results.html


Remove isInPrototypeChain

%IsInPrototypeChain has been removed in new versions of V8.
This PR could fix #8 .

Actually the name has changed to HasInPrototypeChain in v8 5.0   -- the pull request actually should detect the version of the engine and use the correct call..

Oops, I don't know the rename. But I could argue that InPrototypeChain is not very useful and do not need native test (just use Object.getPrototypeOf and Object.prototype.isPrototypeOf) 😄
What do you think?


Matter Binding between ESP32-S3 and other Manufacturer board (CON-585)

Hello,
I have a bit of doubt that right now I have one Matter Enabled board of ESP32-S3. And I have one more Matter Enabled board from Different Manufacturer so If I want to Communication between that board or I would say Matter binding between that board so can ESP32 Support it?

Binding is a feature in Matter Specification, and ESP32 does support it.

Okay Thank you @shubhamdp


Refresh to reload preset store

slide down on preset store should refresh preset store.

actually it refreshes on every swipe, so idk if this is needed

ok that makes that unnecessary. And i guess the presets are not that quickly updated...

after changing network connections after can't connect to the preset store

reopen this when problem related to this issue occurs


hermit install should warn but not fail without network if all packages are already installed

Currently it just completely fails, making the IJ plugin unusable. There is no real reason for this to be the case if all of the packages are already installed.
See also #258 which if fixed would probably solve this issue somewhat.
Error while running ./hermit
error:https://github.com/cashapp/hermit-packages.git: Cloning into '/Users/aat/Library/Caches/hermit/sources/6682e3c492bdd27fac0db80685cb1df7bd13fda32bb9765ca15e895df13eb3cc-2486539884'...
fatal: unable to access 'https://github.com/cashapp/hermit-packages.git/': Could not resolve host: github.com

fatal:hermit: git sync failed: git clone --depth=1 https://github.com/cashapp/hermit-packages.git /Users/aat/Library/Caches/hermit/sources/6682e3c492bdd27fac0db80685cb1df7bd13fda32bb9765ca15e895df13eb3cc-2486539884 failed: exit status 128

I cannot seem to reproduce this. When all packages are installed, hermit install just exits immediately with exit code 0 whether I am connected to the network or not.

Excellent! It must have been fixed in the interim!


Upgrade Ruby to 2.3.0

Upgrading Ruby to 2.3.0 as it's the latest stable.
But really, I want to test the new Docker image building!
(Also updating it since the Docker image building is now using the same
version as the Ruby version instead of the super crazy MoJ specific Ruby
versioning)

Looks good, merge at will.


List all tests/suites

Feature Request
It does not seem that I can find a way to list all suites/tests without running them, is there something that I am not aware of or it lacks such functionality?

Please note this issue tracker is not a help forum (as stated in issue template)
We recommend using our discord channel or StackOverflow where there is an active jestjs tag for questions


bump version to 1.1.1beta

noticed that .xml config files still said 1.0

@jgravois - I noticed you use the dashed string for the comment 1.1.1-beta but a non-dashed for the string variable 1.1.1beta. Is that on purpose? I looked at http://semver.org/ which seems to favor the dashed version, but maybe I missed something.

no.  you're right.  fixed (and squashed).

Looks nice and clean - merged :)


Local integration

Hello,
It's possible to do a local integration? Now when server down HA don't get data from server. Maybe somebody tryied to look into local controller integration?

Unfortunately TECH Controllers producer doesn't give any support so it would be hard to revers engineer local RF communication. This integration never aimed to do so.


Multiline text in UI

Currently it's not possible to make a text adjust its number of lines to the size of its parents. You have to explicitly add line breaks with \n
The whole point of using flexbox was to have the UI adjust dynamically to different screens and contents. Without this feature, any text with more than 6 words is a pain to handle.
It also makes it more complicated to do libraries that handle any prompt or NPC text.
In SDK6 this was not something creators needed to think about, the text just adapted to the size of the container.

@nearnshaw I can't remember if I worked on this or not, do you know if this is done and we can close this issue?

Yes, this is already fixed :)
closing it


nixos/mediawiki: allow using default extensions

It appears the MediaWiki module "hides" the extensions that are shipped in the package. Please consider whether this PR improves the module by allowing them to be easily used, or whether it just makes it confusing.
cc @aanderse @redvers
Motivation for this change
Mostly convenience - MediaWiki ships with bunch of extensions and these often require particular MediaWiki version. Using the ones bundled with the wiki source, one does not have to manually update them whenever the wiki is updated.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg test mediawiki

@aanderse can you please elaborate, or point to an example of such package? I'm struggling to imagine how this works and would like to write better modules too:)
Also, I'm wondering whether this PR should use true instead of null as that would result in slightly more self-descriptive configuration.

@mmilata anything with plugins that uses symlinkJoin is probably a good example. I'll circle back to this when I have some time.

@mmilata unfortunately this hasn't hit the top of my priority list yet. I also forgot to come back and merge this... sorry.
@GrahamcOfBorg test mediawiki

Thanks @mmilata :tada:


Using SQLite.swift with SQLCipher

I get the following error when try to add SQLCipher subspec on Xcode 8 in a Swift 3 project:
dyld: lazy symbol binding failed: Symbol not found: _sqlite3_key
Referenced from: /Users/USER/Library/Developer/Xcode/DerivedData/myproject/Build/Products/Debug/myproject.app/Contents/MacOS/../Frameworks/SQLite.framework/Versions/A/SQLite
Expected in: /usr/lib/libsqlite3.dylib
dyld: Symbol not found: _sqlite3_key
Referenced from: /Users/USER/Library/Developer/Xcode/DerivedData/myproject/Build/Products/Debug/myproject.app/Contents/MacOS/../Frameworks/SQLite.framework/Versions/A/SQLite
Expected in: /usr/lib/libsqlite3.dylib
I tried the solution from zetetic to no avail.

Looks like it's trying to link against the system libsqlite3.dylib. Have you done any other modifications in your project (manual linking for example?) Check 'Build Phases / Link Binary with Libraries'.
A simple  pod 'SQLite.swift/SQLCipher', '~> 0.11.1' should just work.
Interesting though that zetetic categorically is against the use of CocoaPods.

Thank you @jberkel. I only have Pods_projectname.framework under 'Build Phases / Link Binary with Libraries'. I am building a MacOS (not an iOS) app, would that make a difference when it comes to how _sqlite3_key is bound?

Should not make a difference. I've just tested it with a new OSX project from scratch and it compiled and linked without problems there.
Maybe you reference another pod which has a dependency to libsqlite3?

I can connect to the sqlite3 database without a problem. It is only when I try to key or rekey the db that I get the error.
        let db = try Connection("/path/db.sqlite3") // works
        try db.key("secret") // fails
        try db.rekey("mysecret") // fails

I got the following in my Podfile. Please lemme know if I am doing anything wrong because I am new to Cocoapods.
use_frameworks!
target 'SQLCipherTest' do
use_frameworks!
Pods for SQLCipherTest
pod 'SQLite.swift', '~> 0.11.1'
pod 'SQLite.swift/SQLCipher', '~> 0.11.1'
target 'SQLCipherTestTests' do
inherit! :search_paths
# Pods for testing
end
target 'SQLCipherTestUITests' do
inherit! :search_paths
# Pods for testing
end
end
I tried the same thing in a different computer. Same error! Both using Xcode 8

get rid of the first pod 'SQLite.swift', '> 0.11.1', you only need to include it once, with subspec

That was it! Thank you @jberkel


Monorepo setup

Notes on scope of PR
The following are considered in scope in this PR:

[x] Set up maintenance and development of all Enketo packages intended for either standalone or embedded deployment, or Enketo-maintained dependencies thereof.

[x] Minimal monorepo setup to facilitate said maintenance and development. Minimal as in:

Tooling (Yarn for package management and running commands)
CI (preserve pertinent CI functionality from each respective package, limit runtime and number of jobs where reasonable)
Simple and idiomatic package/directory structure:

Root README and requisite tooling configs
All releasable packages under /packages
Any extant or future demonstration packages under /examples

[x] Upgrade to currently supported versions of Node (18 and 20; this task had recently been deferred in anticipation of this monorepo migration)

[x] Upgrade direct (package.json) dependencies where either required for said Node upgrades, or appropriately unblocked by related tooling changes. This has mostly been limited to dev dependencies, with a few exceptions (most notably for runtime dependencies, upgrading jQuery was unblocked).
One particular pain point worth calling out was handling changes to test snapshots in enketo-transformer. These changes were necessary because of changes in vitest's snapshot format, prettier's move to asynchronous-by-default formatting, and whitespace changes in @prettier/plugin-xml. Addressing the latter was the most important, without which there would be an absurd amount of false positive updates to the snapshot file. And as a future note, if we continue to maintain or expand snapshot tests we'll want to consider ways we can break them up to limit false positives in the future.

[x] Move management of dev dependencies to the monorepo root, as much as possible.
Some exceptions were made for unshared dependencies which were fussy about their place in the file system relative to their respective dependent package.

[x] Consolidate code formatting (Prettier, ESLint) across all packages, now run as a single task at the monorepo root. There are of course quite a few formatting exceptions (none new, just consolidated under .eslintrc.json).
Note: code in the openrosa-xpath-evaluator package has been reformatted in this process. We had done a previous unification pass on the other packages, but deferred that one at the time because it was already fairly divergent in code style from the rest. But it made sense now to reconcile.
This change, like the previous formatting pass, was mostly automated. The remaining manual changes were almost entirely so uncontroversial they're not really worth elaborating. The only real exception would be the changes from isNaN to Number.isNaN. The former coerces its argument to a number before checking its NaN-ness, which can have surprising behaviors (which, in turn, is why it's a lint error). I tried to be as conservative in addressing these errors as possible, but they're worth a close eye.

[x] Correct, and in some cases improve, module references between packages. Most notably, Sass imports should be much more clear.

[x] Any fixes necessary to build and dev for each package. Many of these were minor and should hopefully be obvious, significant changes in enketo-express's Gruntfile.js are worth a close look.

[x] All packages are built on install. In some cases this ensures inter-package dependencies work as expected without additional steps. In other cases a stub build step was introduced for consistency. (The latter wasn't strictly necessary, but helped to ensure correct top-level behavior.)

[x] Consolidate GitHub issue/PR templates. (Note: I assume this worked, but it won't be testable until they land in main)

[x] Oh yeah, the main branch is now main

The following may be considered in scope for this PR (or a later change):

[ ] Remove now-unused Git history migration scripts. They have served their purpose, we can leave some breadcrumbs back to them in the new Git commit history as appropriate.
[ ] Remove any temporary TODOs and notes as we see fit
[ ] Rebase as desired
[ ] Reduce redundancies in CI config. There's quite a lot of stuff repeated almost-or-totally-verbatim in ci.yml. In theory some of it can be broken out into separate actions which might be triggered explicitly by the main config. This sounds nice, but a word of caution: in past experience, I've found attempts to apply more than the minimal necessary abstraction in these sorts of configs (and in YAML broadly) can and even tend to do more harm than good.

The following are in scope for one or more future PRs:

[ ] Updated release automation and procedures. The current release processes are currently copied from their respective packages into .github/workflows/ci.yml, and commented out as stubs.
[ ] Update other packaging/deployment considerations (i.e. Dockerfile)
[ ] Additional revisions to package-level READMEs and documentation revisions

The following will be done when we determine the monorepo migration is sufficiently ready for switchover:

[ ] Migrate existing issues from their individual repos
[ ] Archive those repos

The following may be in scope for future work:

[ ] Migrate any VSCode launch.json/tasks.json as we see fit. (I suspect I was the only one using these, and I haven't used them much for quite a while. I'm inclined to reconsider the approach if/when we find a need.)
[ ] Consolidate top level tsconfig.json and jsconfig.json if/where possible. Some cases must remain broken out in separate configs (generally test-specifics, and cases like those in enketo-transformer with conditional access to DOM APIs). I would like to have spent some time addressing this in the initial setup PR, but there's some inherent complexity (i.e. composite projects) that should probably be addressed, and a bunch of incidental complexity related to our intended gradual adoption.
[ ] Improve consistency of scripts and task management (i.e. package.json scripts entries, remaining usage of grunt). I'd like to have done more on this here too, but it felt increasingly like a separate scope as the rest progressed.
[ ] We should eventually address issues with enketo-transformer's release-related portions of package.json found by Are the types wrong?.
[ ] TODOs extracted from .gitignore:

[ ] Allow *.code-workspace if we ever want that
[ ] Naming and path consistency of build artifacts, don't mix build output in source paths
[ ] Naming and path consistency of fixtures
[ ] Consolidate configs
[ ] Revisit Docker/etc related ignores

Notes on other Enketo repositories
There are quite a few other Enketo repositories, some of which may be considered for inclusion in this monrepo. It's taken as read that any archived repository would not be under consideration. Some quick thoughts on the rest:

enketo-core-performance-monitor: I'd like to bring this in, and address some other issues with it in the process.
vex-dialog-enketo: this is an explicit dependency of enketo-express (and a fork of vex-dialog). It could make sense to include as long as we continue using it. But it's also been remarkably stable (i.e. last commit was in 2018), so I'm currently inclined to leave it that way.
merge-xml: also a fork, and presently involved in at least one known bug (restoring non-relevant subtrees of repeat instances in submissions). It very probably makes sense to bring in, or revisit its usage.
Leaflet.draw: also a fork, also remarkably stable. Inclined to leave out as well.
blog, enketo-website, enketo-roadmap, enketo-api-docs: these would potentially make sense to include, but we should evaluate their maintenance generally.
enketo-validate, enketo-validate-webapp, (maybe) centro: I wasn't even aware these were being actively maintained until I looked today! To the extent they are a going concern, it seems a case could be made for their inclusion.
enketo-iframe-demo: could be reasonably migrated into /examples.

Breaking changes

All packages: Dropped support for Node 12, 14, 16. Versions now supported: 18 and 20.
enketo-express: Removed support for request-filtering-agent and related configs (ip filtering). We believe this support is no longer necessary following previous changes to how manifest media is served.

Risks
Overall this should be relatively low risk. Some specific risks and considerations are discussed above. Beyond those:

Yarn does not have an equivalent to npm audit fix [--production], and the corresponding release instructions have been removed from packages' respective READMEs. Yarn does provide an audit command which we will continue to use, so really the risk here is an increased emphasis on manually resolving dependency vulnerabilities. On the other hand, Yarn's resolutions feature gives us a much freer hand to address said vulnerabilities. In past experience, I haven't found the lack of a fix command to be an issue at all.

Quite a lot of the version updates are potential risk factors. I've taken care to read through release notes to evaluate all explicit breaking changes, and believe each upgrade was safe according to the information available to me.
It'll be particularly worth double checking that the Sass upgrades haven't introduced meaningful changes to built stylesheets.

Changing development process can be disruptive and might trip up contributors. In my experience, the expectation of working from a monorepo's root can be especially surprising.

I tried to pay close attention to these changes in general, and particularly whenever anything package-local was consolidated at the top level. One area of risk in that vein I think is worth pointing out is the possibility that any safeguards have been mistakenly relaxed, e.g. unintentional loosening of lint rules. I don't think we can categorically rule out that possibility, though I think the changes generally demonstrate tightening of rules if anything.

I felt some mild irritation when doing yarn install that there seems to be less feedback about what's going on than there was with npm i. In particular, I got no console output while libxslt was building which made me think things were broken.

That tripped me up at first too. I think node-sass might even take longer than libxslt and libxmljs too, but you wouldn't necessarily notice it from the output. If you do want the output, you can run yarn install --verbose. Personally I came to appreciate the lack of output once I got used to the wait without it... but yeah I can see why it might seem broken.

Do you want to consider any changes for the .gitignore before we merge? Or maybe there's some rebasing you want to do? I don't see any particular need.

I've removed the TODOs from there and added in the PR notes (for now). Up to you on whether you want to rebase any of that.


[Mathematical Functions] Support factorial function

Description:
Added support for factorial function to age

PR updated (resolved all comments)


fix: Use Scroll API instead of findAll

to avoid ES index max_result_window excess error

SonarQube is reporting a bug in the implementation of the RestHighLevelClient


Update NOTICE.txt

@enahum Please help merge when you can 🙏 (I don't have permission)

Cherry pick is scheduled.


welcome view content layout is broken?

welcome view layout is handled by the ViewPane parent  class
https://github.com/microsoft/vscode/blob/7fa1bef37f8f42cd92f76b1a8d7bcd6d30855ee6/src/vs/workbench/browser/parts/views/viewPaneContainer.ts#L335-L340
None of the sub classes (views) are calling super.layoutBody(). Does it mean that if any of these views has welcome view content then welcome view is not layout correctly?

I actually went through all the subclasses and added super.renderBody() to all renderBody() methods. Forgot to do the same for layoutBody...

Verified by code review


Use constants instead of functions

Using constants instead of methods saves some OPCode steps 💪
PHP_OS_FAMILY has a smaller, predefined set of possible values
:octocat:

Can you also enable the function_to_constant rule here?

Good call! Done!


[Snyk] Upgrade core-js from 3.22.8 to 3.23.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade core-js from 3.22.8 to 3.23.0.

:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released 21 days ago, on 2022-06-13.

Release notes

Package name: core-js

3.23.0 - 2022-06-13
Array find from last moved to the stable ES, according to June 2022 TC39 meeting:

Array.prototype.findLast
Array.prototype.findLastIndex
%TypedArray%.prototype.findLast
%TypedArray%.prototype.findLastIndex

Methods from the Array grouping proposal renamed, according to June 2022 TC39 meeting:

Array.prototype.groupBy -> Array.prototype.group
Array.prototype.groupByToMap -> Array.prototype.groupToMap

Changed the order of operations in %TypedArray%.prototype.with following proposal-change-array-by-copy/86, according to June 2022 TC39 meeting
Decorator Metadata proposal extracted from Decorators proposal as a separate stage 2 proposal, according to March 2022 TC39 meeting, Symbol.metadataKey replaces Symbol.metadata
Added Array.prototype.push polyfill with some fixes for modern engines
Added Array.prototype.unshift polyfill with some fixes for modern engines
Fixed a bug in the order of getting flags in RegExp.prototype.flags in the actual version of V8
Fixed property descriptors of some Math and Number constants
Added a workaround of V8 ArrayBufferDetaching protector cell invalidation and performance degradation on structuredClone feature detection, one more case of #679
Added detection of NodeJS bug in structuredClone that can not clone DOMException (just in case for future versions that will fix other issues)
Compat data:

Added NodeJS 18.3 compat data mapping
Added and fixed Deno 1.22 and 1.21 compat data mapping
Added Opera Android 69 compat data mapping
Updated Electron 20.0 compat data mapping

3.22.8 - 2022-06-01
Fixed possible multiple call of ToBigInt / ToNumber conversion of the argument passed to %TypedArray%.prototype.fill in V8 ~ Chrome < 59, Safari < 14.1, FF < 55, Edge <=18
Fixed some cases of DeletePropertyOrThrow in IE9-
Fixed the kind of error (TypeError instead of Error) on incorrect exec result in RegExp.prototype.test polyfill
Fixed dependencies of { actual, full, features }/typed-array/at entries
Added Electron 20.0 compat data mapping
Added iOS Safari 15.5 compat data mapping
Refactoring

    from core-js GitHub release notes

Commit messages

Package name: core-js

54fcdb8 3.23.0
b509d83 Merge pull request #1082 from zloirock/group
af0903f update the changelog
26e0577 update docs
a936c35 update the `README`
73c837a rename methods from the `Array` grouping proposal
23fef36 update dependencies
d75860d improve docs
062ec17 update dependencies
fa10599 improve docs
e1a0d39 prevent V8 ArrayBufferDetaching protector cell invalidation and performance degradation
6338c5f add v8 protectors invalidation check
188a315 improve the changelog
94f69a4 Merge pull request #1077 from zloirock/array-push
19f126a disable some test262 tests
408971e make it properly work in some old engines
77dcc86 add some tests
e3b9d7e update docs
f719025 add new entries
56aac57 some improvements
53fb222 add `Array.prototype.unshift` polyfill
d80a05e use `doesNotExceedSafeInteger` helper
0d7d897 it's still not fixed in Safari 15.4 - only in TP
c31c3e4 add a link

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Snyk opened this in my name, this is not my action :disappointed:  .


Overhaul of FormGroup + new components to better support mock ups

Proposed Changes
I had a look at some implementations that tried to use Form and FormGroup and it did not quite support what was required by the mock-ups.
The original premise of using only two levels (Form > FormGroup) is not consistent with what UX has in mind. For instance, they start from the bottom input and define levels to represent those inputs as groups.
I still wanted to provide some "structure" components that would provide props for most of UXs use cases, so here is the new design:
<Form>
  <FormGroup title="" description="">
     <LabeledInput title="" description="">
           <Any Input />
     </LabeledInput>
  </FormGroup>
  <FormGroup>
       <FormGroup level={2}>
           ...
       </FormGroup>
  </FormGroup>
</Form>

FormGroup is used to add a header and delimits a section. It provides an optional title and description with the appropriate styling. level is introduced to properly output h2/h3/h4 depending on the level.
LabeledInput is introduced to wrap inputs with a label and/or description.
For instance:

Input already provides its own label, so you don't need to put one. But description might still be useful.
SingleSelectConnected does not have a label, so wrap it and define title and/or description

So in theory, using those two components together will ensure that you have consistent:

Font color and size
Spacing
Content location

The FormExample has been updated with two real-life mock-ups, and they pretty much look the same :)
Let me know if you have any ideas to improve this, and if there should be changes in the styling
Potential Breaking Changes
All of the changed attributes are still supported
Acceptance Criteria

[ ] The proposed changes are covered by unit tests
[ ] The potential breaking changes are clearly identified
[ ] README.md is adjusted to reflect the proposed changes (if relevant)

Is there something we can do about the accumulated spacing top?

Bon ça a brassé pas mal avec les quelques dernières recommandations de UX :D
On attends la prochaine démo et ils vont regarder ce que ça donne

It looks like some very very nice stuff!!!
GG
I love it :D

In my opinion, permitting everything in title and label goes against the purpose of this component.
<FormGroup title={<Input/>} makes no sense, nor <FormGroup title={<Description />}.
I would rather add props for missing features, fronted with an intent. (For instance, helpText and helpLink instead of tooltip.
I understand the concern for flexibility, but I would rather limit the options to ensure that everyone using those components are in-line with UX's recommendations

Codecov Report

Merging #1289 into master will decrease coverage by 0.29%.
The diff coverage is 26.31%.

@@            Coverage Diff            @@
##           master    #1289     +/-   ##
=========================================
- Coverage   99.42%   99.12%   -0.3%
=========================================
  Files         359      361      +2
  Lines        9044     9080     +36
  Branches     2135     2145     +10
=========================================
+ Hits         8992     9001      +9
- Misses         52       79     +27

Impacted Files
Coverage Δ

...ct-vapor/src/components/input/InputDescription.tsx
100% <100%> (ø)

.../react-vapor/src/components/input/LabeledInput.tsx
30.43% <30.43%> (ø)

...ages/react-vapor/src/components/form/FormGroup.tsx
20% <7.69%> (-55%)
:arrow_down:

...act-vapor/src/components/headers/HeaderWrapper.tsx
100% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Coverage is now increased 🎉 :discoball:

I think it would be ready for another round of review (or a merge) :)

Very nice! GG!
Eventually, I'd see a couple of improvements:

Like discussed earlier, call this SECTION to apply it to non-form contents
Change the props name for
Title (no change)
Help text (instead of description, since people might think they don't have to add a description, since the label already describes the input. Calling it "Help text" makes it more obvious that it is meant to help user enter their value)
Option information (instead of information, because we should not use tooltips for non-optional info.)

@Charles-ErickBG I applied your proposed changes. Since the component had to be renamed, I opted to revert back the original FormGroup component to its original behavior and remove the example so that it doesn't appear in the documentation

@Charles-ErickBG I applied your proposed changes. Since the component had to be renamed, I opted to revert back the original FormGroup component to its original behavior and remove the example so that it doesn't appear in the documentation

That is just amazing stuff to me! I love it!!! GG.


Attempt to run explicit v0.6 and v0.7 tests.

This is still a draft, it says.

did you miss click?


⚠ Turnos 24x7 has degraded performance

In 0ee14fd, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 4235 ms

Resolved: Turnos 24x7 performance has improved in 45fb7ed.


Use chronus for publish and publish github releases

All changed packages have been documented.

You can try these changes at https://cadlplayground.z22.web.core.windows.net/prs/2985/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/prs/2985/


macOS Window Conventions

On macOS, the close, minimise, and maximise buttons appear on the left side of a window's title bar, and menu items appear within the system menu bar rather than within the application's window. It'd be great if NetPad could be made to feel more at-home on macOS by following these conventions.

Image: NetPad above and VS Code below
Thanks for making this though, it's a very useful utility :)

Yeah I agree. This is definitely something I'm planning to address. The plan is to keep the native window chrome and window controls but also integrate the menu bar with the title bar on Windows and Linux to utilize as much vertical space towards editing. On macOS, the menu will be moved to the native menu on the very top.
I gave it a quick attempt a while back but I quickly realized its something that I'll need to be a bit careful with for it to work properly in a cross-platform way. Keeping vertical real-estate as a priority, I settled on having a uniform title bar on all platforms in the meantime.
In the short term, or maybe as an alternate solution, I could introduce a couple settings:

Use native title bar: Which would remove the integrated, uniform, title bar, and replace it with the native title bar as in your VS Code snapshot, and move the menu to:

the native menu bar, at the very top, on macOS
the native menu bar, below the titlebar, on Windows/Linux

Keep the integrated titlebar but move window controls to the left: side for users that are used to them being on the left (ie. macOS and Linux that have configured their WM as such)

#107 introduces a number of settings now:

Titlebar

Integrated: the titlebar NetPad has had so far, merges the main menu and the titlebar (default for Windows/Linux).
Native: Uses the OS-native window chrome and titlebar (default for macOS).

Window Controls Position: position the minimize, maximize, close..etc to the right or left. This does not apply when using the Native titlebar.

Right (default)
Left

Main Menu Auto-Hide: does not apply when using Native titlebar on macOS

Always Show (default)
Auto-Hide

This will go out with the next release.

Closing with publish of new v0.6.0 release.


default group

how can I set a user's default group membership?

Sorry for replying almost 5 years late, you can use the key default_group_id upon use creation: https://developer.zendesk.com/rest_api/docs/support/users#json-format-for-agent-or-admin-requests


[ISV-5191] Release pipeline can be triggered by label only when PR is merged

Tested in personal OC playground on top of this PR - intercepted event evaluated as False and release pipeline was not triggered.
Event listener test log:
{
  "severity": "info",
  "timestamp": "2024-09-06T08:22:31.987Z",
  "logger": "eventlistener",
  "caller": "sink/sink.go:420",
  "message": "interceptor stopped trigger processing: rpc error: code = FailedPrecondition desc = expression (\n  body.action == \"labeled\"\n  && body.label.name == \"pipeline/trigger-release\"\n  && body.pull_request.base.ref == \"tman-test\"\n  && body.pull_request.merged == true\n) did not return true",
  "commit": "80de3d1",
  "eventlistener": "community-operator-pipeline-github-listener",
  "namespace": "tman-playground",
  "/triggers-eventid": "4e7da982-ebdb-40d4-962e-756e37033d83",
  "eventlistenerUID": "fb05bb4f-0ad7-4c95-9231-2972cea3a237",
  "/trigger": "github-community-label-listener-release"
}

Closes ISV-5191

@johnbe11 @kosciCZ Hey guys, any update to your reviews? It has been a couple of days since @mantomas tagged you here and we should merge this bugfix asap.

@Allda sorry, missed this in my inbox, I'll get on this ASAP