Fix zh-Hant - PM "afternoon" handled correctly

Fixed zh-Hant PM recognition to include 'afternoon' as it alphabetically comes before 'am' - fixes issue where AM and PM were both parsing as the AM datetime because "afternoon" was not being recognized as PM and therefore not adding 12 hours.

Thank you for your contribution. Please, could you include a test case that passes after the fix, but fails without it?
Thanks

It appears that you use QUnit on this project, and my familiarity is mostly in the Jasmine world… it would take me a bit to get set up to run said tests, I’m supposing, and I’ve got my hands full with the work I’m actively doing (that required this fix).
I’ll flag this email and if I get “free time,” then certainly.
Also, it appeared additionally that no tests have been created in the project’s date tests that specifically switch locales. It seems that the best bet would be to refactor the date tests to run the full set of assertions based on every supported locale rather than just the currently hardcoded “en”.
Thoughts?
Cheers
Jim Speaker
From: Rafael Xavier de Souza<EMAIL_ADDRESS>Sent: Saturday, September 12, 2015 11:29 AM
To: jquery/globalize
Cc: Jim Speaker
Subject: Re: [globalize] Fix zh-Hant - PM "afternoon" handled correctly (#508)
Thank you for your contribution. Please, could you include a test case that passes after the fix, but fails without it?
Thanks
—
Reply to this email directly or view it on GitHub https://github.com/jquery/globalize/pull/508#issuecomment-139808400 .  https://github.com/notifications/beacon/AAyc15TuX3U8IClFvsBnS3mZECERHSGXks5oxGZlgaJpZM4F8TNc.gif

No problem. So, please could you provide me a couple of Dates where you see this problem happening for the zh-Hant locale?

Any time with the PM characters (下午), which are the same as “afternoon,” will cause this failure, as it will be evaluated as AM.
Globalize.parseDate("下午1:00", { time: "short" });
The following test fails with the original code, and passes with the updated code.
The failure is as follows:
Expected Date(Tue Sep 15 2015 01:00:00 GMT-0700 (Pacific Daylight Time)) to equal Date(Tue Sep 15 2015 13:00:00 GMT-0700 (Pacific Daylight Time)).
Original code:
  if ( hour12 && amPm === "pm" ) {

      date.setHours( date.getHours() + 12 );

  }

Updated code:
 if ( hour12 && ( amPm === "pm" || amPm === "afternoon" ) ) {

     date.setHours( date.getHours() + 12 );

 }

And, here’s the jasmine test for this zh-Hant time problem.
describe("Globalization date module as zh-Hant", function () {
var language = "zh-Hant", actual, expected = new Date(2015, 8, 15, 13, 0, 0, 0);
beforeEach(function (done) {
$.when(

    $.getJSON("/úæʒ_Scripts/globalization/cldr/main/zh-Hant/numbers.json"),

    $.getJSON("/úæʒ_Scripts/globalization/cldr/supplemental/numberingSystems.json"),

    $.getJSON("/úæʒ_Scripts/globalization/cldr/main/zh-Hant/ca-gregorian.json"),

    $.getJSON("/úæʒ_Scripts/globalization/cldr/supplemental/timeData.json"),

    $.getJSON("/úæʒ_Scripts/globalization/cldr/supplemental/likelySubtags.json")

  )

  .then(function () {

    return [].slice.apply(arguments, [0]).map(function (result) {

      return result[0];

    });

  })

  .then(Globalize.load)

  .then(

    function () {

      Globalize(language);

      Globalize.locale(language);

      done();

    }

  );

});
describe("When parsing time", function() {
beforeEach(function () {

  actual = Globalize.parseDate("下午1:00", { time: "short" });

});

it("Then it should equal todays date with the correct PM time", function () {

  expect(actual).toEqual(expected);

});

});
});
Sorry I don’t have the time to dig into QUnit. I’m sure it’s no big deal, but I need to get back to work now.
Oh, and by the way, I absolutely love the Globalize library. I’m using globalize.validate with jquery.validate, and incorporated globalize into some of my custom validators – it’s a God send for the multi-lingual web application I’m working on. The timing of the 1.0 release was right on the money with my need for it.
Thank you very much!
Jim Speaker
From: Rafael Xavier de Souza<EMAIL_ADDRESS>Sent: Tuesday, September 15, 2015 3:24 AM
To: jquery/globalize
Cc: Jim Speaker
Subject: Re: [globalize] Fix zh-Hant - PM "afternoon" handled correctly (#508)
No problem. So, please could you provide me a couple of Dates where you see this problem happening for the zh-Hant locale?
—
Reply to this email directly or view it on GitHub https://github.com/jquery/globalize/pull/508#issuecomment-140347081 .  https://github.com/notifications/beacon/AAyc1_igKf4yGZrjKkTam9JkBd1MG6Voks5ox-k6gaJpZM4F8TNc.gif

Oh, one more thing, this will also fix the same problem with zh (aka zh-Hans). The "afternoon" characters exist in both, though they are ofc different characters in zh-Hans.

Any time with the PM characters (下午), which are the same as “afternoon,” will cause this failure, as it will be evaluated as AM.

Excellent, that's what I needed. Thanks. Now I need to find time to add the unit test, so we merge this. Alternatively, if you want to give it a try, the unit tests should go here and we'll need to load data for the zh-Hant data analogous to this code and create an zhHant instance analogous to this code.

@jspeaker the implementation unfortunately isn't correct and needs considerable additions to behave correctly. Reviewing this, I found out that:

afternoon is locale-dependent, i.e., the definition changes from locale to locale;
afternoon is not the only keyword, there are also evening, midnight, night, and noon. Also they are numbered and occasionally there are two variants like afternoon1 and afternoon2.
Not all afternoonss means it's +12. For example, for uz afternoon means it's from 11am and on (link). Therefore, assuming we can always +12 when we find afternoon is wrong.

Ref: http://www.unicode.org/reports/tr35/tr35-dates.html#Day_Period_Rule_Sets


Numerous number of Advisories and Vulnerabilities do not have a title

After running the importer for csaf and cve then I hardly see Advisories/Vulnerabilities with titles, the majority do not have any title. The endpoints I hit were /api/v1/advisory and /api/v1/vulnerability

Out of curiosity I downloaded an Advisory file whose title was empty in the response. This is the file CVE-1999-0001.json . Then I opened the file and I clearly see that there is a human readable text that describes the CVE containers.cna.descriptions[0].value=ip_input.c in BSD-derived TCP/IP implementations allows remote attackers to cause a denial of service (crash or hang) via crafted packets. .

The server should be clever enough to extract the title from different fields if the main one was not available in the file.

Having that many number of advisories and vulnerabilities without titles is not acceptable for the client side (the UI). It has a negative impact on

This is the full JSON response I got from /api/v1/advisory. You see that title=null for each of the items I got:
{
    "items": [
        {
            "uuid": "urn:uuid:9c98b45e-4251-4240-af8b-f0208a483607",
            "identifier": "CVE-1999-0001",
            "hashes": [
                "sha256:4c8ca7269dca3a736f75aebf9d80a99fd24e2b17be0eaa7bc852e04631f88f73"
            ],
            "issuer": {
                "id": 2,
                "name": "mitre",
                "cpe_key": null,
                "website": null
            },
            "published": "2000-02-04T05:00:00Z",
            "modified": "2005-12-17T00:00:00Z",
            "title": null,
            "labels": {
                "importer": "cve",
                "source": "https://github.com/CVEProject/cvelistV5"
            },
            "average_severity": null,
            "average_score": null,
            "vulnerabilities": [
                {
                    "identifier": "CVE-1999-0001",
                    "published": "2000-02-04T05:00:00Z",
                    "modified": "2005-12-17T00:00:00Z",
                    "non_normative": {
                        "non_normative": true,
                        "identifier": "CVE-1999-0001",
                        "released": "2000-02-04T05:00:00Z"
                    },
                    "severity": "none",
                    "score": 0.0
                }
            ]
        },
        {
            "uuid": "urn:uuid:3809d5e2-9efc-4060-b7bb-87f0b5d3a2bb",
            "identifier": "CVE-1999-0002",
            "hashes": [
                "sha256:77b275a8740bf477cadc41a040454b6f80aa6be680d1927467901904bf4ccff8"
            ],
            "issuer": {
                "id": 2,
                "name": "mitre",
                "cpe_key": null,
                "website": null
            },
            "published": "1999-09-29T04:00:00Z",
            "modified": "2005-11-02T10:00:00Z",
            "title": null,
            "labels": {
                "source": "https://github.com/CVEProject/cvelistV5",
                "importer": "cve"
            },
            "average_severity": null,
            "average_score": null,
            "vulnerabilities": [
                {
                    "identifier": "CVE-1999-0002",
                    "published": "1999-09-29T04:00:00Z",
                    "modified": "2005-11-02T10:00:00Z",
                    "non_normative": {
                        "non_normative": true,
                        "identifier": "CVE-1999-0002",
                        "released": "1999-09-29T04:00:00Z"
                    },
                    "severity": "none",
                    "score": 0.0
                }
            ]
        },
        {
            "uuid": "urn:uuid:e92e314a-ea14-4eb6-9042-6d5f28efbe11",
            "identifier": "CVE-1999-0003",
            "hashes": [
                "sha256:1bfc7f246ff9474f9aa2f2e4093f071059777a1b186877ccd2bf6ecdf13ba09c"
            ],
            "issuer": {
                "id": 2,
                "name": "mitre",
                "cpe_key": null,
                "website": null
            },
            "published": "1999-09-29T04:00:00Z",
            "modified": "2005-11-02T10:00:00Z",
            "title": null,
            "labels": {
                "source": "https://github.com/CVEProject/cvelistV5",
                "importer": "cve"
            },
            "average_severity": null,
            "average_score": null,
            "vulnerabilities": [
                {
                    "identifier": "CVE-1999-0003",
                    "published": "1999-09-29T04:00:00Z",
                    "modified": "2005-11-02T10:00:00Z",
                    "non_normative": {
                        "non_normative": true,
                        "identifier": "CVE-1999-0003",
                        "released": "1999-09-29T04:00:00Z"
                    },
                    "severity": "none",
                    "score": 0.0
                }
            ]
        },
        {
            "uuid": "urn:uuid:be1ca24e-8557-4d15-a18f-f7804a75f64f",
            "identifier": "CVE-1999-0004",
            "hashes": [
                "sha256:22b129894b5f0a2a2f6afc6ffd5fd054c9a355ed6c0e6ff1e7ce7df1a7360966"
            ],
            "issuer": {
                "id": 2,
                "name": "mitre",
                "cpe_key": null,
                "website": null
            },
            "published": "2000-02-04T05:00:00Z",
            "modified": "2018-10-12T19:57:01Z",
            "title": null,
            "labels": {
                "importer": "cve",
                "source": "https://github.com/CVEProject/cvelistV5"
            },
            "average_severity": null,
            "average_score": null,
            "vulnerabilities": [
                {
                    "identifier": "CVE-1999-0004",
                    "published": "2000-02-04T05:00:00Z",
                    "modified": "2018-10-12T19:57:01Z",
                    "non_normative": {
                        "non_normative": true,
                        "identifier": "CVE-1999-0004",
                        "released": "2000-02-04T05:00:00Z"
                    },
                    "severity": "none",
                    "score": 0.0
                }
            ]
        },
        {
            "uuid": "urn:uuid:408af016-8502-4df7-b351-7493bde7da2e",
            "identifier": "CVE-1999-0005",
            "hashes": [
                "sha256:4d6a53d3fe93a931f0cd177638b34e7ab73043a4e05c38cd3ec1f3beabfff58c"
            ],
            "issuer": {
                "id": 2,
                "name": "mitre",
                "cpe_key": null,
                "website": null
            },
            "published": "1999-09-29T04:00:00Z",
            "modified": "2005-11-02T10:00:00Z",
            "title": null,
            "labels": {
                "importer": "cve",
                "source": "https://github.com/CVEProject/cvelistV5"
            },
            "average_severity": null,
            "average_score": null,
            "vulnerabilities": [
                {
                    "identifier": "CVE-1999-0005",
                    "published": "1999-09-29T04:00:00Z",
                    "modified": "2005-11-02T10:00:00Z",
                    "non_normative": {
                        "non_normative": true,
                        "identifier": "CVE-1999-0005",
                        "released": "1999-09-29T04:00:00Z"
                    },
                    "severity": "none",
                    "score": 0.0
                }
            ]
        },
        {
            "uuid": "urn:uuid:1ce1f41b-bfea-428b-a9d6-86c10b88a67f",
            "identifier": "CVE-1999-0006",
            "hashes": [
                "sha256:c2f104d01972fd8291092cf4cab529f7829fde66433d3c13c7c824c7da17f622"
            ],
            "issuer": {
                "id": 2,
                "name": "mitre",
                "cpe_key": null,
                "website": null
            },
            "published": "1999-09-29T04:00:00Z",
            "modified": "2005-11-02T10:00:00Z",
            "title": null,
            "labels": {
                "source": "https://github.com/CVEProject/cvelistV5",
                "importer": "cve"
            },
            "average_severity": null,
            "average_score": null,
            "vulnerabilities": [
                {
                    "identifier": "CVE-1999-0006",
                    "published": "1999-09-29T04:00:00Z",
                    "modified": "2005-11-02T10:00:00Z",
                    "non_normative": {
                        "non_normative": true,
                        "identifier": "CVE-1999-0006",
                        "released": "1999-09-29T04:00:00Z"
                    },
                    "severity": "none",
                    "score": 0.0
                }
            ]
        },
        {
            "uuid": "urn:uuid:edbe7455-93c3-423d-b464-b49841ca61b1",
            "identifier": "CVE-1999-0007",
            "hashes": [
                "sha256:92c8b211cfc1e19562d64306cff7cc3bfe187661de924878269c91e510c2d65b"
            ],
            "issuer": {
                "id": 2,
                "name": "mitre",
                "cpe_key": null,
                "website": null
            },
            "published": "1999-09-29T04:00:00Z",
            "modified": "2005-11-02T10:00:00Z",
            "title": null,
            "labels": {
                "importer": "cve",
                "source": "https://github.com/CVEProject/cvelistV5"
            },
            "average_severity": null,
            "average_score": null,
            "vulnerabilities": [
                {
                    "identifier": "CVE-1999-0007",
                    "published": "1999-09-29T04:00:00Z",
                    "modified": "2005-11-02T10:00:00Z",
                    "non_normative": {
                        "non_normative": true,
                        "identifier": "CVE-1999-0007",
                        "released": "1999-09-29T04:00:00Z"
                    },
                    "severity": "none",
                    "score": 0.0
                }
            ]
        },
        {
            "uuid": "urn:uuid:b0f6202e-ba3b-43ba-a1e4-df52a17f3f4f",
            "identifier": "CVE-1999-0008",
            "hashes": [
                "sha256:56908f75cd4d6447c0b96da2763245ff075937a9979b1356270d0c295363fd79"
            ],
            "issuer": {
                "id": 2,
                "name": "mitre",
                "cpe_key": null,
                "website": null
            },
            "published": "1999-09-29T04:00:00Z",
            "modified": "2005-11-02T10:00:00Z",
            "title": null,
            "labels": {
                "source": "https://github.com/CVEProject/cvelistV5",
                "importer": "cve"
            },
            "average_severity": null,
            "average_score": null,
            "vulnerabilities": [
                {
                    "identifier": "CVE-1999-0008",
                    "published": "1999-09-29T04:00:00Z",
                    "modified": "2005-11-02T10:00:00Z",
                    "non_normative": {
                        "non_normative": true,
                        "identifier": "CVE-1999-0008",
                        "released": "1999-09-29T04:00:00Z"
                    },
                    "severity": "none",
                    "score": 0.0
                }
            ]
        },
        {
            "uuid": "urn:uuid:4b0a6467-2f25-4a86-bff4-7278124aacad",
            "identifier": "CVE-1999-0009",
            "hashes": [
                "sha256:fa6104d5fd5e3c95316cff17b7ffacf43c372ee1a5fa8bb3dd3a1d0dc576a846"
            ],
            "issuer": {
                "id": 2,
                "name": "mitre",
                "cpe_key": null,
                "website": null
            },
            "published": "1999-09-29T04:00:00Z",
            "modified": "2009-03-02T00:00:00Z",
            "title": null,
            "labels": {
                "importer": "cve",
                "source": "https://github.com/CVEProject/cvelistV5"
            },
            "average_severity": null,
            "average_score": null,
            "vulnerabilities": [
                {
                    "identifier": "CVE-1999-0009",
                    "published": "1999-09-29T04:00:00Z",
                    "modified": "2009-03-02T00:00:00Z",
                    "non_normative": {
                        "non_normative": true,
                        "identifier": "CVE-1999-0009",
                        "released": "1999-09-29T04:00:00Z"
                    },
                    "severity": "none",
                    "score": 0.0
                }
            ]
        },
        {
            "uuid": "urn:uuid:dac02546-cfd6-47dc-9b5e-fa7a1c686fcb",
            "identifier": "CVE-1999-0010",
            "hashes": [
                "sha256:37d11b2746c1835c2c290ad1e9ce55cddfa74687abff8c7c90cb4888c47ea266"
            ],
            "issuer": {
                "id": 2,
                "name": "mitre",
                "cpe_key": null,
                "website": null
            },
            "published": "1999-09-29T04:00:00Z",
            "modified": "2009-03-02T00:00:00Z",
            "title": null,
            "labels": {
                "source": "https://github.com/CVEProject/cvelistV5",
                "importer": "cve"
            },
            "average_severity": null,
            "average_score": null,
            "vulnerabilities": [
                {
                    "identifier": "CVE-1999-0010",
                    "published": "1999-09-29T04:00:00Z",
                    "modified": "2009-03-02T00:00:00Z",
                    "non_normative": {
                        "non_normative": true,
                        "identifier": "CVE-1999-0010",
                        "released": "1999-09-29T04:00:00Z"
                    },
                    "severity": "none",
                    "score": 0.0
                }
            ]
        }
    ],
    "total": 109062
}

I think it's a good idea to use the description as an alternative for a missing title. However, I think that's something the UI should do.
Taking the description and reporting it as title on an API alters data, compared to the original/source information. Also, descriptions can get rather verbose, so it would make sense to add some ability to truncate the text.
Ideally, the UI could let the user know (via a label or something) that this content comes from the description, instead of the title field.

As of today there is no description exposed through the REST endpoints for the UI to use it. If you agree we can use this issue to track the work done for adding description to the current REST endpoints.

Ideally, the UI could let the user know (via a label or something) that this content comes from the description, instead of the title field.

I personally don't think a user cares whether the text that describes the vulnerability was taken from FieldA, FieldB, or FieldN but this is a good topic to have input from UX and PM

I agreed to both! Makes sense!

Should be closed by https://github.com/trustification/trustify/pull/485


Cor 452 recipients pwa UI

Adds form type dropdown when creating forms
Does not do client side validation on recipient forms yet
When changing to recipient form, the reference field is added automatically
Fixed some imports in  frontend/apps/native/__tests__

/lgtm


[WIP] voxel grid filter triplets

Description

This PR implements an inefficient version of the voxel grid filter.
It replaces the tensor index sorting for a triplet based sorting, which makes it slower, consumes twice the memory for the sorting structure, but allows very fine subsampling even for lidar scans or maps.
The need for this implementation comes from the fact that the standard voxel grid filter can use up to 0.1m leaf sizes for large pointclouds, which is insufficient for some applications (in this case calibration).
Related links

Tests performed
Checked that they obtain the same numerical results (as expected since we only change the way the internal sorting is performed).
Benchmark:
Pointcloud Input size = 1150089
Original implementation time = 85ms
Triplet implementation time = 143ms

Replaced the normal voxel grid implementation for this one and checked that it provided the same results (currently, in calibration applications)
Notes for reviewers

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

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

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

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

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

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

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

I asked before ohsato-san if this was ok.
Should I move it now, or from the next time?
In the same way, shouldn't we do the same with the calibration tools?


[Patch/te support 2024 08 26] Handle local_window_size

CI run to test: https://github.com/NVIDIA/JAX-Toolbox/actions/runs/10567155871

Looks good, I'll force push to the original branch


lib.strings: fix negative number handling for toInt and toIntBase10

The previous version would be unstable due to an input validation regex not expecting a - in front of the number.
Description of changes

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[X] 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

[X] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[X] Fits CONTRIBUTING.md.

Numbers with a line in front of them. Who'd have thought...
Thanks!


BREAKING CHANGE: update response definitions

Codecov Report

Merging #25 (92456cf) into master (7bb985e) will decrease coverage by 77.91%.
The diff coverage is 11.25%.

@@             Coverage Diff              @@
##            master      #25       +/-   ##
============================================
- Coverage   100.00%   22.08%   -77.92%
============================================
  Files            4        4
  Lines          340      335        -5
  Branches        42       44        +2
============================================
- Hits           340       74      -266
- Misses           0      261      +261

Impacted Files
Coverage Δ

notifications-api/v1.ts
26.98% <11.25%> (-73.02%)
:arrow_down:

findings-api/v1.ts
14.73% <0.00%> (-85.27%)
:arrow_down:

lib/common.ts
30.00% <0.00%> (-70.00%)
:arrow_down:

Continue to review full report at Codecov.

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


你好，我现在是运行项目成功了，但是我改怎么输入我的ip控制电脑呢，ios端

Found a bug? - We would like to help you and smash the bug away.

Please don't "report" questions as bugs.

We are reachable via

Matrix room : #FreeRDP:matrix.org (main)
XMPP channel<EMAIL_ADDRESS>(bridged)
IRC channel : #freerdp @ irc.oftc.net (bridged)
We are reachable via mailing list<EMAIL_ADDRESS>

Try our mailing list for discussions/questions

Before reporting a bug have a look into our issue tracker to see if the bug was already reported and you can add some additional information.
If it's a new bug - create a new issue.
For more details see https://github.com/FreeRDP/FreeRDP/wiki/BugReporting

To save time and help us identify the issue a bug report should at least contain the following:

a useful description of the bug - "It's not working" isn't good enough - you must try harder ;)
the steps to reproduce the bug
command line you have used
to what system did you connect to? (win8, 2008, ..)
what did you expect to happen?
what actually happened?
freerdp version (e.g. xfreerdp --version) or package version or git commit
freerdp configuration (e.g. xfreerdp --buildconfig)
operating System, architecture, distribution e.g. linux, amd64, debian
if you built it yourself add some notes which branch you have used, also your cmake parameters can help
extra information helping us to find the bug

Please remove this text before submitting your issue!
Thank you for reporting a bug!

If you want help, please make issues understandable. (filling out the requested information helps, so is using the language the template is created with)

楼主，我这边ios编译出错了，能否指点一下呢


chore(*) update copyright year

ref:

https://github.com/Kong/kong/pull/8240
https://github.com/Kong/kubernetes-ingress-controller/pull/2123

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

Codecov Report

Merging #112 (12474e8) into main (9d7105c) will decrease coverage by 5.64%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #112      +/-   ##
==========================================
- Coverage   43.49%   37.85%   -5.65%
==========================================
  Files          42       42
  Lines        3722     3722
==========================================
- Hits         1619     1409     -210
- Misses       1786     2050     +264
+ Partials      317      263      -54

Flag
Coverage Δ

2.0.5
?

2.1.4
37.85% <ø> (ø)

2.2.2
?

2.3.3
?

2.4.0
?

community
37.85% <ø> (-0.19%)
:arrow_down:

enterprise
?

enterprise-<IP_ADDRESS>
?

enterprise-<IP_ADDRESS>
?

enterprise-<IP_ADDRESS>
?

enterprise-<IP_ADDRESS>
?

integration
37.85% <ø> (-5.65%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

kong/mtls_auth_service.go
0.00% <0.00%> (-63.74%)
:arrow_down:

kong/workspace_service.go
0.00% <0.00%> (-53.45%)
:arrow_down:

kong/exists.go
50.00% <0.00%> (-25.00%)
:arrow_down:

kong/admin_service.go
0.00% <0.00%> (-19.12%)
:arrow_down:

kong/credentials.go
85.71% <0.00%> (-14.29%)
:arrow_down:

kong/oauth2_auth_service.go
56.04% <0.00%> (-7.70%)
:arrow_down:

kong/utils.go
75.60% <0.00%> (-3.66%)
:arrow_down:

Continue to review full report at Codecov.

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


Makie image recipe is putting the data on the wrong lat lon position

When I plot a Raster with image that gives a wrong position. I can use heatmap to properly plot the data. The mismatch depends on some properties of the dimensions.
Below is an example script and I will attach the exemplary nc file. I would have expected that the position of the rectangle in the corner would be the same for heatmap and for image.
I could not reproduce the mismatch with a simple reverse ordered Y-Axis.
julia> r = Raster("./image_vs_heatmap_corner.nc")
[ Info: No `name` or `key` keyword provided, using first valid layer with name `:unnamed`
559×561 Raster{Union{Missing, Float32},2} unnamed with dimensions:
  X Mapped{Float64} Float64[635090.3685878773,<PHONE_NUMBER>663981, …, 1.1601994887240704e6, 1.1607739741281688e6] ForwardOrdered Irregular Points crs: EPSG mappedcrs: EPSG,
  Y Mapped{Float64} Float64[6.306992429753325e6, 6.306049684474804e6, …, 5.779997819060089e6, 5.779202377731337e6] ReverseOrdered Irregular Points crs: EPSG mappedcrs: EPSG
extent: Extent(X =<PHONE_NUMBER>878773, 1.1607739741281688e6), Y = (5.779202377731337e6, 6.306992429753325e6))
missingval: missing
crs: EPSG:4326
mappedcrs: EPSG:4326
parent:
            6.30699e6  6.30605e6  6.30511e6  6.30416e6  …  5.78188e6  5.78094e6  5.78e6  5.7792e6
 6.3509e5   1.0        1.0        1.0        1.0           0.0        0.0        0.0     0.0
 6.36033e5  1.0        1.0        1.0        1.0           0.0        0.0        0.0     0.0
 ⋮                                                      ⋱
 1.1602e6   0.0        0.0        0.0        0.0        …  0.0        0.0        0.0     0.0
 1.16077e6  0.0        0.0        0.0        0.0           0.0        0.0        0.0     0.0

julia> image(r, interpolate=false)

julia> heatmap(r, interpolate=false)

julia> figim, axim, im = image(r, interpolate=false)

julia> heatmap(r, interpolate=false, colormap=:greys)

julia> display(GLMakie.Screen(), figim)
GLMakie.Screen(...)

image_vs_heatmap_corner.zip
I had to zip it because of github.

Weird that they are different, will have to look into it.
But possibly we can ignore this now as all the lower level plotting will move to
https://github.com/rafaqz/DimensionalData.jl/pull/
And just make sure they match over there

This is fixed on Rasters main with DD main.


Create view to display chat history and performance in the previous games

Performance tracking and previous chat message storage were not implemented for the application's current version.


Latest version taken from INT on 2020-12-16

Added latest API for chat + sample files
Previous version review
https://github.com/Azure/azure-rest-api-specs/pull/11716
FYI @amrElroumy  @DominikMe  lets continue the WIP on this one.
This one should address all the azure board final comments.

@amrElroumy closing this one.

@amrElroumy closing this one.


Create NodeJS program that allows user to enter in their weight for the day.

PUT: user/weight for day
GET: user - the logged weight

Will be implemented in another issue at another time.


Add owner reference to the created secrets by the operator

Fixes #51
Fixes #84
Fixes #96
Hi!
This PR adds support for owner references. The operator now will get the owner reference from the original object (Deployment or OnePasswordItem) and add it to the operator managed secret.
This way we can track the owners, apply garbage collection, and tools like Argo will know that these resources are created from others and show accordingly so they don't try to prune them.
ArgoCD example:
From this:

To this:

Thanks for the reviews and for the merge! :rocket:

@jpcoenen @jillianwilson hey guys! This is very useful but it looks like it was never released. Do you have an idea when we could get that shipped?

@jpcoenen I forgot to reply but thank you for the info! We're already using it in all our Helm charts 😄 Thank you so much!


Previous document is lost inside async callbacks

Sometimes in "after.update" hook the value of "this.previous" document is undefined. That happens when you make an update call inside a callback, wrapped with bindEnvironment.
I provided a simple example to see the issue. Just call "generateComments" method and take a look at your server console. You'll see something like this:

Previous post is undefined
Previous post is { _id: 'tKcwaidC9NCNJnSt2', title: 'post #6', commentsCount: 0 }
Previous post is undefined

The code below will work in meteor 1.0.4 only as it uses "rawCollection" method to run bulk insert.
Trust me, the same issue happens in meteor <IP_ADDRESS> when I use mongo npm to run bulk inserts.
I just did not want to bloat the example.
Example code:
posts = new Mongo.Collection('posts');
comments = new Mongo.Collection('comments');

if (Meteor.isServer) {
    Meteor.startup(function () {
        posts.remove({});

        _.each(_.range(0, 10), function (i) {
            posts.insert({title: 'post #' + i, commentsCount: 0});
        });
    });

    Meteor.methods({
        generateComments: function () {
            posts.find().forEach(function (post) {
                var data = _.map(_.range(0, 100), function (i) {
                    return {
                        _id: Random.id(),
                        postId: post._id,
                        title: 'comment #' + i
                    }
                });

                comments.rawCollection().insert(data, Meteor.bindEnvironment(function () {
                    comments.remove({_id: {$nin: _.pluck(data, '_id')}, postId: post._id});
                    posts.update(post._id, {
                        $set: {
                            commentsCount: data.length
                        }
                    });
                }));
            });
        }
    });

    posts.after.update(function (userId, post) {
        console.log('Previous post is', this.previous);
    });
}

Here is simpler example that just uses Meteor.defer and no calls to npm packages:
posts = new Mongo.Collection('posts');
comments = new Mongo.Collection('comments');

if (Meteor.isServer) {
    Meteor.startup(function () {
        posts.remove({});
        comments.remove({});

        _.each(_.range(0, 10), function (i) {
            var postId = posts.insert({title: 'post #' + i});

            _.each(_.range(0, 10), function (i) {
                comments.insert({title: 'comment #' + i, postId: postId});
            });
        });
    });

    Meteor.methods({
        triggerUpdate: function () {
            posts.find().forEach(function (post) {
                Meteor.defer(function () {
                    posts.update(post._id, {
                        $set: {
                            updatedAt: new Date()
                        }
                    });
                });
            });
        }
    });

    posts.after.update(function (userId, post) {
        if (!this.previous) console.warn('Previous post is lost');

        Meteor.defer(function () {
            comments.update({
                postId: post._id
            }, {
                $set: {
                    postUpdatedAt: post.updatedAt
                }
            }, {
                multi: true
            });
        });
    });

    comments.after.update(function (userId, comment) {
        if (!this.previous) console.warn('Previous comment is lost');
    });
}

I want confirm the bug. it's very strange, it happens irregular see output:
I20150318-10:31:29.968(1)? triggerUpdate fired
W20150318-10:31:29.984(1)? (STDERR) Previous post is lost "post #3"
W20150318-10:31:29.987(1)? (STDERR) Previous post is lost "post #3"
W20150318-10:31:29.998(1)? (STDERR) Previous post is lost "post #6"
W20150318-10:31:30.004(1)? (STDERR) Previous post is lost "post #8"
W20150318-10:31:30.016(1)? (STDERR) Previous comment is lost "comment #1"
W20150318-10:31:30.016(1)? (STDERR) Previous comment is lost "comment #0"
W20150318-10:31:30.017(1)? (STDERR) Previous comment is lost "comment #2"
W20150318-10:31:30.017(1)? (STDERR) Previous comment is lost "comment #6"
W20150318-10:31:30.017(1)? (STDERR) Previous comment is lost "comment #9"
W20150318-10:31:30.017(1)? (STDERR) Previous comment is lost "comment #4"
W20150318-10:31:30.017(1)? (STDERR) Previous comment is lost "comment #5"
W20150318-10:31:30.017(1)? (STDERR) Previous comment is lost "comment #8"
W20150318-10:31:30.018(1)? (STDERR) Previous comment is lost "comment #3"
W20150318-10:31:30.019(1)? (STDERR) Previous comment is lost "comment #7"
I20150318-10:31:34.530(1)? triggerUpdate fired
W20150318-10:31:34.541(1)? (STDERR) Previous post is lost "post #1"
W20150318-10:31:34.549(1)? (STDERR) Previous post is lost "post #4"
W20150318-10:31:34.551(1)? (STDERR) Previous post is lost "post #5"
W20150318-10:31:34.553(1)? (STDERR) Previous post is lost "post #6"
W20150318-10:31:34.556(1)? (STDERR) Previous post is lost "post #8"
W20150318-10:31:34.559(1)? (STDERR) Previous post is lost "post #7"
W20150318-10:31:34.569(1)? (STDERR) Previous post is lost "post #9"
W20150318-10:31:34.608(1)? (STDERR) Previous comment is lost "comment #0"
W20150318-10:31:34.608(1)? (STDERR) Previous comment is lost "comment #8"
W20150318-10:31:34.608(1)? (STDERR) Previous comment is lost "comment #4"
W20150318-10:31:34.609(1)? (STDERR) Previous comment is lost "comment #7"
W20150318-10:31:34.609(1)? (STDERR) Previous comment is lost "comment #2"
W20150318-10:31:34.609(1)? (STDERR) Previous comment is lost "comment #3"
W20150318-10:31:34.609(1)? (STDERR) Previous comment is lost "comment #9"
W20150318-10:31:34.609(1)? (STDERR) Previous comment is lost "comment #5"
W20150318-10:31:34.609(1)? (STDERR) Previous comment is lost "comment #1"
W20150318-10:31:34.609(1)? (STDERR) Previous comment is lost "comment #6"
I also confirm, that in normal (sync) mode it works normally

Looks like the same happens when Meteor.setInterval is used. As far as I know "Meteor.defer", "Meteor.setInterval" and "Meteor.setTimeout" use "Meteor.bindEnvironment" under the hood, so looks like previous document is lost somewhere in that "environment"

Am 18.03.15 um 16:02 schrieb atoi:

Looks like the same happens when Meteor.setInterval is used. As far as
I know "Meteor.defer", "Meteor.setInterval" and "Meteor.setTimeout"
use "Meteor.bindEnvironment" under the hood, so looks like previous
document is lost somewhere in that "environment"
—
Reply to this email directly or view it on GitHub
https://github.com/matb33/meteor-collection-hooks/issues/103#issuecomment-83011289.

yeah, definetly it is an environment variable Issue @atoi.
Looks like, "sometimes" the call is not in the same environment than the
prev.docs were created.
@matb33 do you have an idea what the issue there is, maybe we then could
help to fix it.
Or do you think, it is an Meteor internal issue with the bindEnvironment?

This really does look like a bug, and odds are it's a collection-hooks problem with bindEnvironment as you suspect. I don't have the time to look at it now but it's on the list for sure.

Two environment variables we use are for the userId in a publish function and for direct ops:
https://github.com/matb33/meteor-collection-hooks/blob/master/collection-hooks.js
Would any of those affect the operation here?

I was looking through this as this error showed up for me today today.  If I just console.log the value of this it is the entire global object.  So somehow the caller of the after update is the global object.
A non elegant solution that worked for me is to locally patch the project by just passing the previous doc into the function.  This doesn't solve the issue for the repo unfortunately because this doesn't change the issue that your caller is now global.
But for anyone who has this issue as a blocker you can clone the repo and change line 72 in update to this:
_.each(docs, function (doc) {
  o.aspect.call(_.extend({
    transform: getTransform(doc),
    previous: prev.docs && prev.docs[doc._id],
    affected: affected,
    err: err
   }, ctx), userId, doc, fields, prev.mutator, prev.options, prev.docs)
})

This really confuses me as I can see you are passing an inline object as the first arguement of call here.  I console logged the result and this is a valid object being returned in my case.
If anyone else has any theories I wouldn't mind helping but I needed a solution for the prev object atm (deadlines 😦 ).  So I didn't get to dig any deeper into the code as I'm unfamiliar with the project as a whole.

@matb33 I read from a couple other posts you are not finding much time to spend on this repo lately.  I just wanted to ask (whenever you have time) If you would consider a hotfix patch where you just passed the previous document in as a temp solution.
Or if you could guide a bit on where you would imagine the context of this is being lost in this case.  Thanks for your time.


OptionsHandlerFn is set to DeleteHandlerFn in WithDefaultOptionsHandlerFunc

https://github.com/cloudevents/sdk-go/blob/1170e89edb9b504a806f2c6a26563c3c26b68276/v2/protocol/http/options.go#L251
Can you please explain why OptionsHandlerFn is set to DeleteHandlerFn in WithDefaultOptionsHandlerFunc
Thanks in advance

It is a bug! ack!!
Want to fix?

Want to fix?
Yes definitely.

But in our code we did set it after I receive the protocol object which solves the problem indirectly....
e.g,
`p, err := cloudevents.NewHTTP(cloudevents.WithDefaultOptionsHandlerFunc([]string{"POST", "OPTIONS"}, 100, []string{"*"}, true))
p.OptionsHandlerFn = p.OptionsHandler`


Add chatbot in Login page

Related Issue
[Cite any related issue(s) this pull request addresses. If none, simply state “None”]
Fixes:  #675
Description
Added chatbot in the login page.

Type of PR

[ ] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
Before:

After:

Checklist:

[ x] I have made this change from my own.
[x ] My code follows the style guidelines of this project.
[x ] I have performed a self-review of my own code.
[x ] I have made corresponding changes to the documentation.
[x ] My changes generate no new warnings.
[x ] I have tested the changes thoroughly before submitting this pull request.
[ x] I have provided relevant issue numbers and screenshots after making the changes.

Please change this task level 1 to level 2
@PriyaGhosal


Show who tests what

Originally reported by andrea crotti (Bitbucket: andrea_crotti, GitHub: Unknown)

I was just using the awesome HTML report to see my test coverage and I had the following thought.
Wouldn't it be nice to be able to see easily what parts of the test suites are actually testing my code?
I guess that these information is collected while doing the annotation, right?
In this way we could actually see if the tests are actually good very easily, which is specially important when working with other people code.

Bitbucket: https://bitbucket.org/ned/coveragepy/issue/170

how is the status of this?

I'm currently working on switching to SQLite data storage, as part of this work: https://nedbatchelder.com/blog/201808/sqlite_data_storage_for_coveragepy.html .

@zooko @massich @schettino72 @tarpas @xcombelle @chrisbeaumont @lauwe @Pauls @sdamon @guettli @RonnyPfannschmidt @kevinjqiu This is now available in v5.0a3: https://nedbatchelder.com/blog/201810/who_tests_what_is_here.html
Please let me know what you think!

Please let me know what you think!

I think it's beyond awesome! It took me hours' to figure out how to get it working though
Would you consider a PR to expand the documentation for this, with some examples?

I will gladly take a pull request for that.  It's hard sometimes to step back and see things as a newcomer would, so you have expertise I don't.  Thanks.


load --file option does not support multiple files

Would be good if the load --file option would allow multiple file names separated by spaces so that it's easier to use in a GNU Make context. Currently the only way to do it to repeat the --file option for every individual file.

See also #210

Released a few month ago.


Write a Python program to find average of numbers

Description
Write a Python program to find average of numbers
Average of numbers is the sum of all numbers divided by the number of numbers.
Input  : 1 2 3 4 5
Output : 3

How to contribute

Save the solution in find-average-of-numbers.py file
Add find-average-of-numbers.py file in find-average-of-numbers folder

!assign


[Plugins API] Combine Plugin.register and Plugin.use?

Hi! Have you considered changing the Plugins API so it combines the functionality of Plugin.register and Plugin.use into one function?
I'm currently using matter-js in another project and importing it as a module via webpack. I recently created a plugin for the project that I would like to be able to be used both in the browser as well as imported as a module. I noticed in your three examples listed in the wiki, you define them as IIFE's that just immediately run Plugin.Register, but this isn't possible in the case where I try importing them as a module.
The way I've currently gotten around the situation is by just defining the plugins object itself, and then just attaching it to exports or window depending on whats available. In the client that uses this code, I just call register, and then use consecutively.
Here is an example where I use it in the browser.
Here is an example of how I'm importing it via ES6 modules and using it that way.
It seems like the extra use call might be unnecessary, and you could potentially just combine it into a single register(...plugins) call. Would there ever be a case where you would want to register a plugin, but not use it?
Thanks for the great work!

The Plugin.register function is used so that other plugins can reference your plugin from anywhere by name. This avoids the need for bundlers for those that don't use them.
It doesn't make sense to combine Plugin.register and Plugin.use since they are run at different times for different reasons (register happens at plugin definition by the plugin author, use happens after by the plugin consumer).
The snippet you showed:
Matter.Plugin.register(MatterCollisionEvents);
Matter.use('matter-collision-events');

Is actually just equivalent to Matter.use(MatterCollisionEvents) because you can simply just pass a plugin object if it's more appropriate. Though I'd advise using register because it allows others to more easily consume your plugin, e.g. in browser or when building their plugins on top of yours, without complex dependency resolution or bundling.
Is there a reason you can't just call Matter.Plugin.register(MatterCollisionEvents) just before line 62 in your code?

Thanks for replying!!
Ah, I think I see what you mean. Plugin.register is useful when people are directly including it in the browser, so they don't have to reference the plugin from the window object.

register happens at plugin definition by the plugin author, use happens after by the plugin consumer

My confusion is around why one would register a plugin, but then not use it. It seems like if anyone was including a plugin on their page (and thus register the plugin in your use case), they will also install (and thus use()) it. And if that were the case, I don't see why you couldn't install plugins in the same function that adds them to the registry.
I looked briefly at the Plugin code. It looks like one potential problem is that use requires the dependency graph, which is generated by using the registry, which is populated by register. I'm wondering if you could get around this by requiring plugins be registered as Matter.Plugin.register(...plugins) upfront. I'm not sure how people are currently setting up plugins, but if I were to use plugins, I would already just call a number of Matter.use() statements in the same place, anyway.

Is there a reason you can't just call Matter.Plugin.register(MatterCollisionEvents) just before line 62 in your code?

I don't call Matter.Plugin.register at line 62 because with bundled code, this would require that I import Matter.js as a dependency within what gets exported as MatterCollisionEvents. As a result, anyone using the Matter.js plugin via a bundler will end up with Matter.js duplicated for every plugin that they use (assuming this is the canonical way to do things). This could be solved if Matter plugins support some sort of dependency injection, but currently matter plugins are just objects.
I could potentially first check if Matter exists so that it will register if it's in the browser, but that would cause a discrepancy in the "API" when used from the browser vs. used with a bundler:

In the browser, you simply call Matter.use('matter-collision-events') because they are already registered
With a bundler, you have to call Matter.register(MatterCollisionEvents); Matter.use('matter-collision-events'), or Matter.use(MatterCollisionEvents), both of which differ from option 1.

My confusion is around why one would register a plugin, but then not use it.

Because registering is the actual plugin definition, which is done by the author?

I'm wondering if you could get around this by requiring plugins be registered as Matter.Plugin.register(...plugins) upfront.

Yes, this is what is supposed to happen.

I would already just call a number of Matter.use() statements in the same place, anyway.

You should only call Matter.use once otherwise you may end up with plugins being installed in the wrong order.

As a result, anyone using the Matter.js plugin via a bundler will end up with Matter.js duplicated for every plugin that they use (assuming this is the canonical way to do things).

Actually this is avoided by configuring your bundler to declare that Matter.js is an external, so it doesn't get bundled.

This could be solved if Matter plugins support some sort of dependency injection, but currently matter plugins are just objects.

I don't see how? I think you'll always need to require matter-js to be able to tell it your plugin exists, either that or you use some special global (which is ugly).
I strongly suggest you switch over to the (newly released) matter-plugin-boilerplate which demonstrates exactly what I mean :)

Ah, I was unfamiliar with externals, thanks for the enlightenment. I hope it doesn't seem like I'm stepping on your toes, I'm definitely happy to change my plugin, these were just some thoughts that I had when I was making the plugins, in case you found them interesting.

Because registering is the actual plugin definition, which is done by the author?

I guess I'm don't really understand why that's important. When the author creates the plugin, he isn't using the plugin, he's just writing out the definition. There is nothing to technically "register" to at the time of definition, because it's just a file that's will eventually be included by a plugin user.
As a plugin user, I don't care that the plugin author has "registered" his plugin, because regardless, I just know that there is a plugin, and I am going to use it.

I don't see how? I think you'll always need to require matter-js to be able to tell it your plugin exists, either that or you use some special global (which is ugly).

Currently, your plugin definitions are defined as objects, but you could potentially have them defined as a function (or an ES6 class), and inject Matter as a dependency there. You have done this with the install function that is specified on the object, but then there is a requirement to run the Matter.Plugin.register function outside that install function. If you think about it, if we're already assuming that Matter is defined, you could actually do away with passing in the base Matter into the install method, since we know that that closure will have access to the Matter outside (which we're using to call Plugin.register)
As an example, Vue.js plugins seem to follow this idea. There is only a single use function, that can be called by either the plugin author OR the plugin user, and when you use a plugin, that plugin can then be referenced or used by the plugin user. This Vue.js plugin shows a simple example. Vue is injected as a dependency into the install function itself, so that the plugin doesn't necessarily need to contain Vue.js if it doesn't want to.
On lines 52-57, it checks - if it's in the browser, immediately use it. Because use has been called, all you now have to do is just include the script, and you don't have to call use again, as a plugin user. If it's being imported as a module, though, you will still need to call Vue.use() on the plugin itself - but the plugin source doesn't actually call it.
That example has been deprecated, but the one that replaces it actually exhibits the same ideas. It includes Vue as a dependency in other files - this plugin seems to be a lot more complex, but you can see similar patterns at the end of this file.
This quote that I wrote:

I'm wondering if you could get around this by requiring plugins be registered as Matter.Plugin.register(...plugins) upfront.

is referring to the fact that my guess that you had originally separated the register from the use so that you could build the dependency graph first, before you use them. I don't know if this is accurate because I didn't study the entirety of the code, so pardon me if I was wrong here.
One example of how you might specify a plugin with dependency injection is if you instead have a model where you simply have an install function, and all your other details are simply specified on that function itself.
so instead of:
var MyPlugin = {
    name: 'matter-my-plugin',

    version: '0.1.0',

    for<EMAIL_ADDRESS>
    uses: [
<EMAIL_ADDRESS><EMAIL_ADDRESS>    ],

    options: {
        something: true
    },

    install: function(base) {
        // patch the Matter namespace here
    },

    // implement your plugin functions etc...
};

Matter.Plugin.register(MyPlugin);

you have
function MatterPlugin(Matter) {
        // patch the Matter namespace here

    // implement your plugin functions etc...
};

MatterPlugin.name = 'matter-my-plugin',
MatterPlugin.version = '0.1.0',
MatterPlugin.for =<EMAIL_ADDRESS>... etc etc

export default MatterPlugin

and then running Matter.use(...plugins) will just build the dependency graph, and then immediately load them.
again these were just thoughts I had and thought might be useful discussion. I'll change my plugin to follow the current implementation with the external bundling.

I hope it doesn't seem like I'm stepping on your toes

I'm all ears! The plugin system is still very new and it's a good idea to try iron out any kinks early.

As a plugin user, I don't care that the plugin author has "registered" his plugin, because regardless, I just know that there is a plugin, and I am going to use it.

So I should probably explain that the reason registering exists is because plugins can be required by other plugins as dependencies by name:
var MyPlugin = {
    // ...

   uses: [
<EMAIL_ADDRESS><EMAIL_ADDRESS>    ],

    // ...
};

The end user of MyPlugin here only ever calls Matter.use(MyPlugin), they don't (and shouldn't) include the two dependencies in their use call, this is done automatically. So if register and use were the same, this would no longer work because those names will not resolve to anything.

If you think about it, if we're already assuming that Matter is defined, you could actually do away with passing in the base Matter into the install method, since we know that that closure will have access to the Matter outside (which we're using to call Plugin.register)

In theory yes but the idea is that technically any object can have plugins installed on it, not just Matter. This may be useful in the future.

Vue is injected as a dependency into the install function itself, so that the plugin doesn't necessarily need to contain Vue.js if it doesn't want to.

The main difference is that Matter.js plugins can reference other plugins by name like I described above. Since I don't think Vue.js plugins can, so it makes sense that this works for them (it's how I initially did it too).

On lines 52-57, it checks - if it's in the browser, immediately use it.

This means that the order of install is down to the order the plugins are loaded, which may be fine for Vue.js. This won't work for Matter.js plugins because they can have dependencies which need to be resolved and installed in a specific order. I don't want to offload figuring out the correct ordering to the end user as this would suck given the recursion involved.

my guess that you had originally separated the register from the use so that you could build the dependency graph first, before you use them.

Exactly yes this is why.

One example of how you might specify a plugin with dependency injection is if you instead have a model where you simply have an install function, and all your other details are simply specified on that function itself.

Your example is almost equivalent to how it is already, except you've moved the Plugin.install to be the plugin object itself right?
I don't see how this solves any of the above issues because given you have a reference to the plugin object, there's little difference between calling MyPlugin(Matter); and MyPlugin.install(Matter);? The crux of the problem here is discovering the reference to MyPlugin when all you have is the name my-plugin.
Just so you don't get me wrong, I'm all for finding a nicer solution to register and I know it's far from convenient. But given that I want the plugin system to support:

resolution by name
recursive dependencies

I'm not sure there's going to be a better solution until all platforms natively support resolving packages by name. Either that or suggest that the end user manually goes through all of their plugins and resolves / registers all of the possible dependencies themselves (which I think sucks).

Thanks for taking the time to patiently discuss and explain! Some more thoughts:
To give context on my thoughts, just in case I'm misunderstanding the flow, this is my current understanding of the usage of a plugin. Let's say there are three plugins, PluginA, PluginB, and PluginC, between which have some sort of dependencies. They're all made by different authors. In the definitions, we call register.
There is a user that is using Matter.js, and wants to use all three plugins. For simplicity lets just assume its in the browser. When they include the scripts, they just include them in any order they please. The plugins will call register, and get put into the registry
When their application starts up, when they set up the boilerplate for their app, they also call Matter.use(PluginA, PluginC, Plugin B). Matter will generate the dependency graph, and figure out which ones to install first. If there is an issue resolving a dependency, this is where you error out and tell the user.
Here, I'm a little fuzzy on:
The dependency resolution is important, because if, for example, PluginA has a dependency on PluginB, it may want to reference PluginB in PluginA's implementation. For example, PluginA needs a way to get the reference to the plugin object of PluginB, so that PluginA can use it within its install function. Plugin A may also use any methods that PluginB adds onto the baseMatter. Is that italicized statement accurate?

So if register and use were the same, this would no longer work because those names will not resolve to anything

It looks like in the docs, you already suggest that people call Matter.use(...plugins) once, and with all plugins. Wouldn't you be able to just, within the Matter.use function, call Plugin.register on each of the plugins, and then call Plugin.use on them afterwards? This disallows people to call Matter.use() in the order they wish, but I don't know if that's actually useful, because like you mentioned people probably don't want to manually resolve dependencies, similar to any package manager.

This means that the order of install is down to the order the plugins are loaded, which may be fine for Vue.js. This won't work for Matter.js plugins because they can have dependencies which need to be resolved and installed in a specific order

Yeah, you're right, the browser case shouldn't actually be applied to Matter. In this case, as a plugin author, you would simply just not call use. The base idea that I was trying to outline was that they don't require you to "static engine setup step" (register), and then run a "dynamic step" (use).

actually no, the dependency graph gets built inside Matter.use, whereas Matter.register only pairs a plugin name to a plugin object.

Oops!! You're right, sorry about that. I should've looked at the code more carefully.

there's little difference between calling MyPlugin(Matter); and MyPlugin.install(Matter);? The crux of the problem here is discovering the reference to MyPlugin when all you have is the name my-plugin, on any platform.

The primary difference is that the author of MyPlugin now no longer needs to include Matter.js in the MyPlugin definition. Instead, in Matter.js itself, you pass Matter directly into the plugin in your generic "load plugin" step (in this case, I believe it is within Plugin.use. Within this step as well, you can also set up the registry, or the map of string -> Plugin, and plugin users can just know to be able to directly call (something along the lines of) Matter.registry['matter-js-plugin']

I'm not sure there's going to be a better solution until all platforms natively support resolving packages by name

To clarify, what do you mean by platform? Like node (or bundlers) vs browser?
I'm also wondering if there is another issue that might come up if plugin developers start using dependencies.
Here's a scenario I'm thinking about:
There is<EMAIL_ADDRESS>and then<EMAIL_ADDRESS>but it has a dependency on<EMAIL_ADDRESS>because the developer hasn't updated dependencies, and then there is<EMAIL_ADDRESS>that depends on<EMAIL_ADDRESS>And for the sake of discussion, each of the 0.x.0 updates on MyPluginB are breaking API changes (missing methods, etc)
The user wants to use all three plugins, and is in the browser, so he goes and downloads each of the three files. The dependency resolution will go through fine, because the dependency graph just includes 3 different versions of MyPluginB. However, the user has actually only downloaded the latest, 0.3.0 version of MyPluginB! When MyPluginA and MyPluginC try to run or try to get used, they try to reference methods that were supposed to be added on by MyPluginB, but were not included.
An easy solution is to just throw warnings or errors that there were multiple versions of MyPluginB that were included, but only one plugin instance. However, this ends up forcing the user of Matter.js to go and download each of the individual releases to include themselves.
Have you thought about somehow relegating the dependency resolution and plugin management work at build-time, i.e, just have plugin developers include modules via npm or yarn. I don't know if it's even possible since the plugins modify Matter at run-time, but it might be interesting.
I'm thinking something where, for example: I am developing MyPlugin, I will import any dependencies I need as npm modules, import these npm modules, and then specify my dependencies: [] array with the npm modules I import (instead of the names). In Matter.js, you can just build a tree and run a post-order traversal and call the install functions on each of the plugins (post-order, so that you start with the dependencies first, before calling install on the plugins themselves).

When their application starts up, when they set up the boilerplate for their app, they also call Matter.use(PluginA, PluginC, Plugin B)

Well, only if all three of those are 'top level'. If plugin B and C are only dependencies of A, then the user should only call Matter.use(PluginA) (this is why registering the others is important).

For example, PluginA needs a way to get the reference to the plugin object of PluginB, so that PluginA can use it within its install function. Plugin A may also use any methods that PluginB adds onto the baseMatter. Is that italicized statement accurate?

No not really, it's not (usually) the case that plugins directly reference functions from other plugins (though, it is possible and acceptable, it's not the problem that the plugin system is solving). The actual reason for dependencies inside plugins is that they usually build on some feature that another plugin will patch on Matter. So in other words, they're not usually 'hard' dependencies, they're implicit, an expectation of some new 'built-in' functionality.

It looks like in the docs, you already suggest that people call Matter.use(...plugins) once, and with all plugins.

Again, not all the plugins. Only the ones the user is interested in (the user does not pass the lower level dependencies into use).

Wouldn't you be able to just, within the Matter.use function, call Plugin.register on each of the plugins, and then call Plugin.use on them afterwards? This disallows people to call Matter.use() in the order they wish, but I don't know if that's actually useful

It's not just useful but sometimes required for things to work. The user must figure out the order for the top level plugins themselves because there's no automatic way to do it. Usually though, this order shouldn't be too complicated (often it may even be arbitrary) due to the dependency resolver doing the hard parts.
Now, if the order of Matter.use was guaranteed to be arbitrary, then everything you're saying makes sense, because then like you say we can get rid of Matter.register.
To be fair, it may actually be the case that the top level order is always arbitrary iff plugins correctly specify all of their dependencies... hmm. I need to think of a solid counter case.

The primary difference is that the author of MyPlugin now no longer needs to include Matter.js in the MyPlugin definition.

But the only reason they do though right now is because of needing to call Matter.Plugin.register, the plugin format itself makes no requirement of Matter.
Aside from that, I did think about using the format you suggest, but the current format is more inline with the style of the codebase. Also, the function-as-the-plugin-object format makes it look like it's some sort of JS constructor which is a little confusing, attaching static functions to it also feels a little weird. I prefer the plugin-as-a-namespace style.

Instead, in Matter.js itself, you pass Matter directly into the plugin in your generic "load plugin" step (in this case, I believe it is within Plugin.use

This is already the case though? The first argument of MyPlugin.install is the Matter namespace, which is what should be patched (dependency injection, as you say).

Within this step as well, you can also set up the registry, or the map of string -> Plugin

Yeah it could, but only if all plugins were passed by the user (not currently the case, like I discussed). It's an interesting thought though, if only I could guarantee that order didn't matter.

To clarify, what do you mean by platform? Like node (or bundlers) vs browser?

Yes, node vs browser vs what ever else can run JS.

An easy solution is to just throw warnings or errors that there were multiple versions of MyPluginB that were included, but only one plugin instance. However, this ends up forcing the user of Matter.js to go and download each of the individual releases to include themselves.

It's already handled and warnings will be thrown. Note that the system only installs the single latest version of a plugin that the user has loaded (as multiple versions of a single plugin are impossible to support simultaneously).

Have you thought about somehow relegating the dependency resolution and plugin management work at build-time, i.e, just have plugin developers include modules via npm or yarn. I don't know if it's even possible since the plugins modify Matter at run-time, but it might be interesting.

Nope because the system is designed to work on any platform. I don't want to tie anyone into using a bundler or package manger. Otherwise closer integration with npm would have been a neat idea :)

It's not just useful but sometimes required for things to work. The user must figure out the order for the top level plugins themselves because there's no automatic way to do it.

Sorry I didn't quite follow this. If we are assuming top level plugins don't have dependencies on each other, why does order matter?

But the only reason they do though right now is because of needing to call Matter.Plugin.register, the plugin format itself makes no requirement of Matter.

Yeah, the Matter requirement is only needed for Matter.Plugin.register.

Aside from that, I did think about using the format you suggest, but the current format is more inline with the style of the codebase. Also, the function-as-the-plugin-object format makes it look like it's some sort of JS constructor which is a little confusing, attaching static functions to it also feels a little weird. I prefer the plugin-as-a-namespace style.

That's fair, I won't belabor that point.

This is already the case though? The first argument of MyPlugin.install is the Matter namespace, which is what should be patched (dependency injection, as you say).

Yeah, I am referring to the requirement of Matter in the plugin definition to call Matter.register

It's already handled and warnings will be thrown. Note that the system only installs the single latest version of a plugin that the user has loaded (as multiple versions of a single plugin are impossible to support simultaneously).

That's a good point, now that I think about it, multiple versions are indeed impossible since they all modify Matter. I think you can still reuse this run-time check while also utilizing npm for the dependencies though.

Nope because the system is designed to work on any platform. I don't want to tie anyone into using a bundler or package manger. Otherwise closer integration with npm would have been a neat idea :)

Aren't you already tying plugin development to node/bundlers, though, since there is the need to require Matter for Matter.register? Otherwise, plugins developed specifically for the browser that don't use bundlers would have to assume there is a global Matter reference, which in turn would not be able to be used by bundlers.

I don't want to break up the discussion, but in case it's helpful, I just converted matter-collision-events to use Plugin.register, but am running into issues when trying to use it in another project. I've specified Matter.js as an external in the plugin itself, and the example runs fine in the browser.
For my other project, I'm building all my front-end code with bundles via webpack. This is my entry file. I'm importing both Matter and MatterCollisionEvents as a bundle, and I think because I import Matter as a bundle instead of including it as a script file, it is never set on window, so when MatterCollisionEvents runs, it throws errors saying that Matter isn't defined. Any thoughts on how I can get around this? I may change it so that it checks existence on the plugin side as a temporary fix, and just call register from my project's file.

Sorry I didn't quite follow this. If we are assuming top level plugins don't have dependencies on each other, why does order matter?

There are cases where it does matter. For example imagine a plugin that patches Matter.Render and renders some sort of HUD onto the canvas (HudPlugin). Now imagine another plugin that also patches Matter.Render and does some kind of post-processing effect, for example a bloom filter (BloomPlugin). The user must always use HudPlugin last, otherwise BloomPlugin will apply the bloom filter to the HUD which will make it blurry. Notice that there's no dependency here, so it's down to the user to order them correctly.
Another example. Imagine a plugin that patches Body.create and adds an option to generate vertices in some way, let's say TrianglePlugin. Now another that patches Body.create and makes the corners of the body's vertices rounded, ChamfterPlugin. For these two plugins to work together, the order must be TrianglePlugin before ChamfterPlugin otherwise the result will just be a triangle rather than a rounded one.
Hope those make sense?

Aren't you already tying plugin development to node/bundlers, though, since there is the need to require Matter for Matter.register?

Not at all. In the browser, Matter is global so there's no need to require anything.

Otherwise, plugins developed specifically for the browser that don't use bundlers would have to assume there is a global Matter reference, which in turn would not be able to be used by bundlers.

For this project the browser is first class and therefore I have avoided any requirement for using bundlers because they are not standardised. I do strongly suggest that production plugins should be  compatible with bundlers (which is why matter-plugin-boilerplate exists to make it easy), but it isn't a requirement due to this.
I'll put this another way: Matter and the plugin system are completely agnostic to what ever dependency resolution (as in, require etc) system you'd like to use.  There are many of them and none are standard. You're left to your own devices, as is standard practice for any browser based library.
If the author didn't bundle their plugin (and I strongly suggest they do for compatibility, it's just common sense), then it's ultimately down to the person using the bundler to handle resolving missing globals. This is usually a built in feature of bundlers too, for example see webpack's shimming modules feature.


Fix invalid file path handling in windows when there is dot in the file name

This basically re-adds the dot-removal removed by the previous commit (PR https://github.com/godotengine/godot/pull/88129). It looks like get_basename() (that was meant to replace the old "dot-removal" part?) doesn't actually remove the dot from the filename. Therefore "con.png" etc. becomes "con." and this still froze the editor.
Not sure if the dot-removal should be actually done in get_basename() instead(?) If so, feel free to discard this PR.
@bruvzg

This is exactly what the get_basename method does:
https://github.com/godotengine/godot/blob/94dbf69f5d6b7d2fd9561692df2e71557607fddc/core/string/ustring.cpp#L4800-L4807
Are you sure there's nothing else missing here? This shouldn't be needed

In addition to being redundant, this logic is wrong since it's searching for the dot from the left instead of doing it from the right (like get_basename do), so it will reject a completely valid con.con.con file for example.

Actually, according to the Windows docs, con.con.con should not be valid, so searching from the lest might be more correct. But names like this seems to work in practice (at least on Windows 11).

Also avoid these names followed immediately by an extension; for example, NUL.txt and NUL.tar.gz are both equivalent to NUL.

So you commented faster than me, but I will post this anyway... :)
Did some more testing with debug-prints:
bool FileAccessWindows::is_path_invalid(const String &p_path) {
	// Check for invalid operating system file.

	WARN_PRINT("p_path: " + p_path);

	String fname = p_path.get_file().get_basename().to_lower();

	WARN_PRINT("fname after get_basename(): " + fname);

	int dot = fname.find(".");
	if (dot != -1) {
		fname = fname.substr(0, dot);
	}

	WARN_PRINT("fname after manual dot removal: " + fname);

	return invalid_files.has(fname);
}

Output with BBCode "[img]con.[/img]"
drivers\windows\file_access_windows.cpp:64 - p_path: res://con..remap
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con.
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
drivers\windows\file_access_windows.cpp:64 - p_path: res://con..import
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con.
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
drivers\windows\file_access_windows.cpp:64 - p_path: res://con.
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
Resource file not found: res://con. (expected type: Texture2D)
BBCode "[img]res://con.png[/img]":
drivers\windows\file_access_windows.cpp:64 - p_path: res://con.png.remap
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con.png
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
drivers\windows\file_access_windows.cpp:64 - p_path: res://con.png.import
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con.png
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
drivers\windows\file_access_windows.cpp:64 - p_path: res://con.png
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
Resource file not found: res://con.png (expected type: Texture2D)
BBCode "[img]res://con.png.tmp[/img]":
drivers\windows\file_access_windows.cpp:64 - p_path: res://con.png.tmp.remap
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con.png.tmp
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
drivers\windows\file_access_windows.cpp:64 - p_path: res://con.png.tmp.import
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con.png.tmp
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
drivers\windows\file_access_windows.cpp:64 - p_path: res://con.png.tmp
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con.png
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
Resource file not found: res://con.png.tmp (expected type: Texture2D)
BBCode "[img]con.png[/img]":
drivers\windows\file_access_windows.cpp:64 - p_path: res://con.png.remap
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con.png
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
drivers\windows\file_access_windows.cpp:64 - p_path: res://con.png.import
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con.png
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
drivers\windows\file_access_windows.cpp:64 - p_path: res://con.png
drivers\windows\file_access_windows.cpp:68 - fname after get_basename(): con
drivers\windows\file_access_windows.cpp:75 - fname after manual dot removal: con
Resource file not found: res://con.png (expected type: Texture2D)
Those ".remap" and ".import" extensions confure me a bit. And I was wrong about ""con.png" etc. becomes "con."". Not sure why I came to that conclusion...
Reverted my changes and tried with some strings (same as above + "bare" con):
"[img]res://con.[/img]" -> Freeze
"[img]res://con.png[/img]" -> Freeze
"[img]res://con.png.tmp[/img]" -> Freeze
"[img]con.png[/img]" -> Freeze
"[img]con[/img]" -> Works
None of these freeze the editor with this PR. PC has windows 10.

Looks good! Could you squash the commits? See PR workflow for instructions.

Thanks!


using the extension with the gradle-avro-plugin

I didn't see anything maven specific in the code so expected this to also work with the gradle-avro-plugin.
I have a config like:
apply plugin: "com.github.davidmc24.gradle.plugin.avro-base"

avro {
    dependencies {
        compileOnly 'com.github.sabomichal:avro-compiler-extension:0.1'
    }
}
...

tasks.register("generate", GenerateAvroJavaTask) {
    dependsOn generateSchema
    source file("../dist")
    include("**/*.avsc")
    outputCharacterEncoding = 'UTF-8'
    additionalVelocityToolClasses = ['com.github.sabomichal.avroextensions.AvroGeneratorExtensions']
    optionalGettersForNullableFieldsOnly = true

    outputDir = file("build/generated/java")
}

but I get the following error:
unable to load velocity tool class com.github.sabomichal.avroextensions.AvroGeneratorExtensions
It's probably that I'm not adding avro-compiler-extension to the build.gradle correctly. Any idea how to get this working in a gradle build?

I haven't tried it, but this might work

plugins {
    id "com.github.davidmc24.gradle.plugin.avro" version "1.7.1"
}

dependencies {
    avro 'com.github.sabomichal:avro-compiler-extension:0.1'
}
...

But just looking at the plugin implementation, it probably won't, since the plugin do not define custom configuration set as described here https://docs.gradle.org/current/userguide/implementing_gradle_plugins.html#providing_default_dependencies_for_plugins
You need to find a way to workaround it.


Rethink object selection model

The way selection of objects is currently handled is crappy and has many drawbacks. We need to think about it.

Now we have a selection model from a very good user interface library :p


HTTP protocol: enable POST for update/delete

Not all servers use PUT/DELETE. Fusion Tables, for one, uses POST for all transactions.
It's comparatively simple to add this ability by adding new properties updateWithPost and deleteWithPost similar to readWithPOST, and changing update() and delete() to use them. With Fusion Tables, the data with the delete POST is the SQL delete statement.
These new properties should both be APIPropertys and, as it seems to me that readWithPost should also be an APIProperty which developers can set in the options, I've changed this too.
All tests continue to pass after this change.

@probins Thanks for the explanation. The last thing I'm wondering is whether the way we derive the update/delete URL makes sense when update/deleteWithPOST is set.
var url = options.url ||
             feature.url ||
             this.options.url + "/" + feature.fid;

When withPOST is set using
var url = options.url || this.options.url;

may make more sense. What do you think?

So I think we can merge this pull request's commits and tackle the DELETE/PUT URL issue in a separate pull resuest. Do you agree?

yes


added to ServerProvider extra logic found in delta-importer-2 ServerPro...

...vider which was originally used. The logic concerned the addition of a class FailedCause which added an extra dimension on managing the retry logic.
Merge Note: Delta importer 2 originally used the ServerProvider contained within, that was changed to the Thirdparty-Utils' ServerProvider but we wish to maintain the extra logic found in the former case and support backwards compatibility with those classes that used the extra functionality before the change.

socrata-thirdparty-utils #92 SUCCESS
This pull request looks good

socrata-thirdparty-utils #93 SUCCESS
This pull request looks good

socrata-thirdparty-utils #95 SUCCESS
This pull request looks good

socrata-thirdparty-utils #96 SUCCESS
This pull request looks good


How to use Helm 3

Description
I'm unable to use Helm3.
When I try the following:

microk8s enable helm3
helm list

I get Error: Kubernetes cluster unreachable.
I then try:

microk8s.config view > /home/anton/.kube/config as suggested in https://github.com/ubuntu/microk8s/issues/833
helm list

And get the same
Doesnt Work
kubectl cluster-info
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Unable to connect to the server: x509: certificate signed by unknown authority

Works
kubectl cluster-info --insecure-skip-tls-verify=true
Kubernetes master is running at https://<IP_ADDRESS>:16443
Heapster is running at https://<IP_ADDRESS>:16443/api/v1/namespaces/kube-system/services/heapster/proxy
CoreDNS is running at https://<IP_ADDRESS>:16443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Grafana is running at https://<IP_ADDRESS>:16443/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
InfluxDB is running at https://<IP_ADDRESS>:16443/api/v1/namespaces/kube-system/services/monitoring-influxdb:http/proxy

So I assume the issue is something to do with certificates, however, from my understanding Helm3 doesnt use Tiller.

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

From run microk8s inspect:
inspection-report-20200410_123916.tar.gz
We appreciate your feedback. Thank you for using microk8s.

This helped - https://worklifenotes.com/2020/01/22/how-to-make-microk8s-work-with-helm/

I believe you could have used the addon comming with MicroK8s (microk8s enable helm3) and then use microk8s helm3.

I don't understand why this helm/helm3 addon is needed. Helm can be obtained separately via snap, so why is this an addon in microk8s? Any advantages?

Hi @giddyhut
The helm3 addon is there for mainly two reasons: first is simplicity, microk8s comes with it out of the box so no extra binaries are needed to get started. the second is that some addons (e.g. GPU) are using it to deploy the necessary manifests. that would be a lot more complex if helm was not built-in.
By the way, there is nothing that stops you from using any helm binary (or version) you might prefer with a microk8s cluster, as long as you point it to the cluster kubeconfig.
Hope this gives some more context around it.


[Request] Allow referencing user in bar.json

To allow a kind of universal "logout", I tried setting this in bar.json:
{
  "label": "Logout",
  "exec": "loginctl terminate-user $USER",
  "icon": "/usr/share/nwg-bar/images/system-log-out.svg"
}

but as expected environment variables aren't parsed. I also tried moving that code into a script and calling the executable using "exec", but that didn't work either when using Sway.
This isn't really a request to add environment variable parsing, but I believe being able to reference the current user would be helpful for this situation and others, potentially.

I also tried moving that code into a script and calling the executable using "exec", but that didn't work either when using Sway.

This works well for me:
bar.json:
[
  {
    "label": "Lock",
    "exec": "swaylock -f -c 000000",
    "icon": "/usr/share/nwg-bar/images/system-lock-screen.svg"
  },
  {
    "label": "Logout",
    "exec": "tu.sh",
    "icon": "/usr/share/nwg-bar/images/system-log-out.svg"
  },
  {
    "label": "Reboot",
    "exec": "systemctl reboot",
    "icon": "/usr/share/nwg-bar/images/system-reboot.svg"
  },
  {
    "label": "Shutdown",
    "exec": "systemctl -i poweroff",
    "icon": "/usr/share/nwg-bar/images/system-shutdown.svg"
  }
]

tu.sh:
#!/usr/bin/env bash

loginctl terminate-user $USER

Yes, that's what I did in the initial post and it works when calling nwg-bar from the terminal, but when calling it using
bindsym $mod+Escape exec nwg-bar                 # in sway
riverctl map normal $mod Escape spawn 'nwg-bar'  # in river

it doesn't work, which was something I should've made more clear earlier. I'm not too sure on if there's a way to pass variables to the program when called this way, so forgive me if it's already possible.

I'd like to request to reopen this issue, as I think - parsing $USER  is an important feature. wlogout, which is also based on GTK and uses JSON format, does this but, it seems, the project is abandoned and it has its own cons.


Add --separate-weights flags to cog debug and other subcommands

Following up on #1151, we should add this flag for any other subcommands that have to do with building images, including cog debug.
(Thanks to @philandstuff for reporting)

Let me handle it :)

Thanks both ❤


Error When Importing The BrachioGraph Library, and Error When Putting in Arm Lengths

Sorry if this is a strange question (python beginner), but when I'm importing
from brachiograph import BrachioGraph
it says:
>>> from brachiograph import BrachioGraph Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/home/pi/BrachioGraph/brachiograph.py", line 4, in <module>     import readchar ModuleNotFoundError: No module named 'readchar'
And this is very confusing, as I don't know what this means, and I can't find anything answering it.
My second question might be fixed if the first question is resolved, I don't know, but when I put in
bg = BrachioGraph(inner_arm=<8>, outer_arm=<8>)
it gives me an 'invalid syntax' error, pointing to the beginning of '<8>'
Please help!

Did you follow the steps at https://www.brachiograph.art/get-started/install.html#other-python-packages ? There you need to install readchar
Don't put <> around the numbers:
 bg = BrachioGraph(inner_arm=8, outer_arm=8)

Did you follow the steps at https://www.brachiograph.art/get-started/install.html#other-python-packages ? There you need to install readchar
Don't put <> around the numbers:
 bg = BrachioGraph(inner_arm=8, outer_arm=8)

Ok, so that worked, but I'm still having issues when testing a box, it says this:
>>> bg.box() Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/home/pi/BrachioGraph/brachiograph.py", line 406, in box     self.xy(bounds[0], bounds[1], wait, interpolate)   File "/home/pi/BrachioGraph/brachiograph.py", line 439, in xy     (angle_1, angle_2) = self.xy_to_angles(x, y)   File "/home/pi/BrachioGraph/brachiograph.py", line 610, in xy_to_angles     hypotenuse_angle = math.asin(x/hypotenuse) ZeroDivisionError: float division by zero
Why is it doing this?

I have the same issue with readchar even though I've installed it.  The project uses Python3 but readchar seems to be associated with Python2.7.
Did you get it working Declan?

I have the same issue with readchar even though I've installed it.  The project uses Python3 but readchar seems to be associated with Python2.7.
Did you get it working Declan?

I have the same issue with readchar even though I've installed it.  The project uses Python3 but readchar seems to be associated with Python2.7.
Did you get it working Declan?

No, sadly. I still dont know what is wrong, so I've just given up on it.

I have the same issue with readchar even though I've installed it.  The project uses Python3 but readchar seems to be associated with Python2.7.
Did you get it working Declan?

No, sadly. I still dont know what is wrong, so I've just given up on it.

Hello Declan, that's a shame!  I have written simple programs in Python but I'm no expert!  What I have discovered is that you get syntax errors when running in the wrong version of Python for the program you're trying to execute.
To get readchar and tqdm to run I had to do the following:
sudo apt install python3-pip
sudo pip3 install readchar
sudo pip3 install tqdm
So that solved that problem!  pip3 installs for Python 3 and pip for Python 2.  I discovered that on the Raspberry Pi website.
I'll keep you informed as I go along!
John

Hello Declan, that's a shame!  I have written simple programs in Python but I'm no expert!  What I have discovered is that you get syntax errors when running in the wrong version of Python for the program you're trying to execute.
To get readchar and tqdm to run I had to do the following:
sudo apt install python3-pip
sudo pip3 install readchar
sudo pip3 install tqdm
So that solved that problem!  pip3 installs for Python 3 and pip for Python 2.  I discovered that on the Raspberry Pi website.
I'll keep you informed as I go along!
John

So I've started off with a fresh OS.  Followed all the instructions to the letter and checked that readchar is actually present in:
usr/local/lib/python3.7/dist-packages
As soon as I run 'from brachiograph import BrachioGraph' I get this

from brachiograph import BrachioGraph
Traceback (most recent call last):
File "", line 1, in
File "/home/pi/BrachioGraph/brachiograph.py", line 4, in
import readchar
ModuleNotFoundError: No module named 'readchar'

Does anyone know why?

So I've started off with a fresh OS.  Followed all the instructions to the letter and checked that readchar is actually present in:
usr/local/lib/python3.7/dist-packages
As soon as I run 'from brachiograph import BrachioGraph' I get this

from brachiograph import BrachioGraph
Traceback (most recent call last):
File "", line 1, in
File "/home/pi/BrachioGraph/brachiograph.py", line 4, in
import readchar
ModuleNotFoundError: No module named 'readchar'

Does anyone know why?

I think I've found it now.  In home/pi/env/pyenv.cfg
I changed the line include-system-site-packages = false to true
home = /usr/bin
include-system-site-packages = true
version = 3.7.3
Now I've progressed!

I think I've found it now.  In home/pi/env/pyenv.cfg
I changed the line include-system-site-packages = false to true
home = /usr/bin
include-system-site-packages = true
version = 3.7.3
Now I've progressed!

Hello Declan, Hope you're still interested!
All the problems and errors I had were all solved by changing that one line indicated above from false to true.
Now I have it working.  Haven't drawn anything with it yet but the servos are all moving so now I'll calibrate it.
At one point I typed bg = BrachioGraph and got all sorts of errors.
I should have typed bg = BrachioGraph()  and then the errors went.
John

Hello Declan, Hope you're still interested!
All the problems and errors I had were all solved by changing that one line indicated above from false to true.
Now I have it working.  Haven't drawn anything with it yet but the servos are all moving so now I'll calibrate it.
At one point I typed bg = BrachioGraph and got all sorts of errors.
I should have typed bg = BrachioGraph()  and then the errors went.
John

I have the same issue in a different place (trying to use linedraw).
I've followed all the steps and when doing opencv-python-headless, I get:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
 NameError: name 'opencv' is not defined
Is there something wrong?


Arabic character is shown separated in wpf version

Hi, Arabic/Persian characters is shown separated in wpf version of html rendered, for more details please see:
http://stackoverflow.com/questions/41242388/arabic-character-is-shown-separated-in-c-sharp-html-renderer

There is no any solution for this bug since 2017 !!!!