[CO-407] Add Compatibility modules in wallet-new

Description
This is needed for Cardano.Wallet.Kernel.Migration (migrateLegacyDataLayer), which is used here
https://github.com/input-output-hk/cardano-sl/blob/304b92029fda6ace33b13f22d73c16fd2563ddd0/wallet-new/src/Cardano/Wallet/Action.hs#L68
We add the following modules to wallet-new
Cardano.Wallet.Compatibility.ClientTypes
Cardano.Wallet.Compatibility.ClientTypes.Functions
Cardano.Wallet.Compatibility.ClientTypes.Instances
Cardano.Wallet.Compatibility.ClientTypes.Types
Cardano.Wallet.Compatibility.State.State
Cardano.Wallet.Compatibility.State.Acidic
Cardano.Wallet.Compatibility.State.Storage
Cardano.Wallet.Compatibility.State.Transactions
Cardano.Wallet.Compatibility.State.Util
Cardano.Wallet.Compatibility.Pending.Types
Cardano.Wallet.Compatibility.Pending.Util

copied with minor modifications from wallet/src/Pos/Web.
Possible caveats

Location/name: Cardano.Wallet.Compatibility
Should this have been it's own package? I now opted for not, as we require little additions to the cardano-sl-wallet-new package.
Can we use existing V1 types somehow? Seems like no to me.

Linked issue
CO-407
Type of change

[~] 🐞 Bug fix (non-breaking change which fixes an issue)
[~] 🛠 New feature (non-breaking change which adds functionality)
[~] ⚠ Breaking change (fix or feature that would cause existing functionality to change)
[x] 🏭 Refactoring that does not change existing functionality but does improve things like code readability, structure etc
[~] 🔨 New or improved tests for existing code
[~] ⛑ git-flow chore (backport, hotfix, etc)

Developer checklist

[x] I have read the style guide document, and my code follows the code style of this project.
[~] If my code deals with exceptions, it follows the guidelines.
[ ] I have updated any documentation accordingly, if needed. Documentation changes can be reflected in opening a PR on cardanodocs.com, amending the inline Haddock comments, any relevant README file or one of the document listed in the docs directory.
[ ] CHANGELOG entry has been added and is linked to the correct PR on GitHub.

Testing checklist

[~] I have added tests to cover my changes.
[x] All new and existing tests passed.

QA Steps
Migration from the old legacy data layer to the new should work.
https://github.com/input-output-hk/cardano-sl/blob/304b92029fda6ace33b13f22d73c16fd2563ddd0/wallet-new/src/Cardano/Wallet/Action.hs#L68
Screenshots (if available)

Location/name: Cardano.Wallet.Compatibility
Totally fine :+1:
Should this have been it's own package? I now opted for not, as we require little additions to the cardano-sl-wallet-new package.
No. It's better to have that as part of wallet-new for now, and simply remove it once we're ready.
Can we use existing V1 types somehow? Seems like no to me.
We. must. not. This is the compatibility layer which knows nothing about the new types and shouldn't know anything about them.

Closing as @KtorZ has taken over CO-407.


Document report: [User Manual | Overview 2]

Description

The logo isn't visible anywhere.

Where will this document be findable by the users?

App Store?
On the app?
Pdf?

On GitHub, your documents are not in a folder on the user-manual branch.

Two .md
Two .pdf
UMImages folder

What are all the functionalities of the app?

The titles are not visible enough, when looking for a specific part, you can easily struggle to find it.

You are missing consistency between all the list on your document.

Severity

Medium (Should be fixed soon)

Version
430dc9b
Expected Correction

Think about adding the application logo on the footer or the header.

If in pdf, think about adding a front page, to know what the document is talking about without having to read it.

Move the files into the documents folder used for all the documents.

Add some design to your document.

Choose a syntax for your lists, and hold on this one.

Other Details
No response

05a1390543d00cef6af39899a9adc1a3bad7856b

And the folder UMImageswill be deleted for the final commit, I just need a place to save pictures while creating the file

Most of the problems of this issue have been resolved.
The only missing point is the consistency of the lists.
You need consistency between all the lists.
-> Page 6 and 8

Page 6, your list is containing ";" at each line and ends with "."
Page 8, your list isn't containing anything but the last with a "."

The issue number 2 is still in pending.

should be done here:
865d9c4112d42c525b44ae1b3d7911a9300ebfde

👍


Test failures with pyproject-metadata >= 0.8.0rc1

I know it's a bit early but Gentoo ended up needing it because of pdm-metadata (sigh). I'll submit a PR to future-proof the test suite. Hope you don't mind.

E        Regex: 'Required "project.version" field is missing'
E        Input: 'Field "project.version" missing and "version" not specified in "project.dynamic"'

/tmp/meson-python/tests/test_metadata.py:51: AssertionError
_____________________________________________________________ test_pep621 _____________________________________________________________

sdist_full_metadata = PosixPath('/tmp/pytest-of-mgorny/pytest-4/test0/mesonpy-test-rsnkxc7e/full_metadata-1.2.3.tar.gz')

    def test_pep621(sdist_full_metadata):
        with tarfile.open(sdist_full_metadata, 'r:gz') as sdist:
            sdist_pkg_info = sdist.extractfile('full_metadata-1.2.3/PKG-INFO').read().decode()

>       assert sdist_pkg_info == textwrap.dedent('''\
            Metadata-Version: 2.1
            Name: full-metadata
            Version: 1.2.3
            Summary: Some package with all of the PEP 621 metadata
            Keywords: full metadata
            Home-page: https://example.com
            Author: Jane Doe
            Author-Email: Unknown<EMAIL_ADDRESS>            Maintainer-Email: Jane Doe<EMAIL_ADDRESS>            License: some license
            Classifier: Development Status :: 4 - Beta
            Classifier: Programming Language :: Python
            Project-URL: Homepage, https://example.com
            Project-URL: Documentation, https://readthedocs.org
            Project-URL: Repository, https://github.com/mesonbuild/meson-python
            Project-URL: Changelog, https://github.com/mesonbuild/meson-python/blob/master/CHANGELOG.rst
            Requires-Python: >=3.7
            Requires-Dist: a
            Requires-Dist: b>1
            Requires-Dist: c>2; os_name != "nt"
            Requires-Dist: d<3; extra == "test"
            Requires-Dist: e[all]; extra == "test"
            Provides-Extra: test
            Description-Content-Type: text/markdown

            <!--
            SPDX-FileCopyrightText: 2021 The meson-python developers

            SPDX-License-Identifier: MIT
            -->

            # full-metadata

            An example package with all of the PEP 621 metadata!
        ''')
E       AssertionError: assert 'Metadata-Ver...1 metadata!\n' == 'Metadata-Ver...1 metadata!\n'
E
E         Skipping 116 identical leading characters in diff, use -v to show
E         Skipping 906 identical trailing characters in diff, use -v to show
E         - ords: full metadata
E         ?           ^
E         + ords: full,metadata
E         ?           ^

tests/test_sdist.py:33: AssertionError
-------------------------------------------------------- Captured stdout setup --------------------------------------------------------
Initialized empty Git repository in /tmp/meson-python/tests/packages/full-metadata/.git/
+ meson setup /tmp/meson-python/tests/packages/full-metadata /tmp/meson-python/tests/packages/full-metadata/.mesonpy-777vl431 -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md --native-file=/tmp/meson-python/tests/packages/full-metadata/.mesonpy-777vl431/meson-python-native-file.ini
The Meson build system
Version: 1.4.0
Source dir: /tmp/meson-python/tests/packages/full-metadata
Build dir: /tmp/meson-python/tests/packages/full-metadata/.mesonpy-777vl431
Build type: native build
Project name: full-metadata
Project version: 1.0.0
Host machine cpu family: x86_64
Host machine cpu: x86_64
Build targets in project: 0

full-metadata 1.0.0

  User defined options
    Native files: /tmp/meson-python/tests/packages/full-metadata/.mesonpy-777vl431/meson-python-native-file.ini
    buildtype   : release
    b_ndebug    : if-release
    b_vscrt     : md

Found ninja-1.12.0 at /usr/bin/ninja
+ meson dist --allow-dirty --no-tests --formats gztar
Created /tmp/meson-python/tests/packages/full-metadata/.mesonpy-777vl431/meson-dist/full-metadata-1.0.0.tar.gz

Ah, sorry, now I see there's #612 for it already. My bad.


Make judging rating popup less ugly

Describe the feature you'd like
The sliders for judge to rate projects don't have any CSS, so they are quite ugly. This should be fixed to match the design style more. See below.
Honestly this entire popup just needs to be improved UI-wise.
Pre-existing Issue or Justification

Additional context
See the figma for an idea of how this should look TT

Kinda related to #105

New design dropped!


added the sequence_library information

I needed to add a new specimen type to address: https://github.com/hubmapconsortium/ingest-ui/issues/259.  The new specimen type is 'sequence_library'.  I added the specimen type to the assay_types.yaml file.  @yuanzhou, @shirey asked me to have you merge this change into the devel branch after Nils approves it.  @yuanzhou feel free to delete the cborromeo/sequence-library once you do the merge.

@yuanzhou Don't delete the branch until it gets released/merged to master...  @cborromeo FYI, we only delete this type of branch after, at least, it has been merged to a release branch as it could get stuck in devel with stuff that isn't released at the same time.

@ngehlenborg You're correct, my fault- I pointed Chuck to the wrong file.  This is a "Sample" level type.
@cborromeo Please revert this change in assay_types.yaml and make it in https://github.com/hubmapconsortium-graveyard/search-schema/blob/master/data/definitions/enums/tissue_sample_types.yaml

Thanks @shirey! Was the search-schema repo prematurely archived and moved to https://github.com/hubmapconsortium-graveyard?

@ngehlenborg , no again my fault...updated my link.  @cborromeo, I'm going to just do this right now...

Thanks shirey! Was the search-schema repo prematurely archived and moved to https://github.com/hubmapconsortium-graveyard? @mccalluc did this in August: #136

@ngehlenborg : No, it used to be a separate repo which was referenced as a submodule, and making any tweak to the assay types was a multi-step process. The code that had been there was copied into this repo, the update process is much smoother, and search-schema was archived because the separate repo is no longer referenced.


Installation error

I am getting below error while installing latest image strapi/strapi:latest
Using strapi 3.0.0-beta.18.2
No project found at /srv/app. Creating a new strapi project
Creating a new Strapi application at /srv/app.

Creating a project from the database CLI arguments.
Creating files.
- Installing dependencies:
Error while installing dependencies:
warning strapi ><EMAIL_ADDRESS>This module has moved and is now available at @hapi/boom. Please update your dependencies as this version is no longer maintained an may contain bugs and security issues.
warning strapi > boom ><EMAIL_ADDRESS>This module has moved and is now available at @hapi/hoek. Please update your dependencies as this version is no longer maintained an may contain bugs and security issues.
warning strapi > strapi-utils > knex > @babel/polyfill ><EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
warning strapi-admin > react-intl ><EMAIL_ADDRESS>This package has been deprecated, please see migration guide at 'https://github.com/formatjs/formatjs/tree/master/packages/intl-relativeformat#migration-guide'
warning strapi-admin > react-virtualized > babel-runtime ><EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
warning strapi-admin > react-datetime > create-react-class > fbjs ><EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
warning strapi-plugin-users-permissions > purest > request ><EMAIL_ADDRESS>This module moved to @hapi/hawk. Please make sure to switch over as this distribution is no longer supported and may contain bugs and critical security issues.
warning strapi-plugin-users-permissions > purest > request > hawk ><EMAIL_ADDRESS>This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
warning strapi-plugin-users-permissions > purest > request > hawk ><EMAIL_ADDRESS>This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
warning strapi-plugin-users-permissions > purest > request > hawk > boom ><EMAIL_ADDRESS>This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
warning strapi-plugin-users-permissions > purest > request ><EMAIL_ADDRESS>Use uuid module instead
warning strapi-plugin-users-permissions > purest > request > hawk ><EMAIL_ADDRESS>This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
warning strapi-plugin-users-permissions > purest > request > hawk > cryptiles ><EMAIL_ADDRESS>This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
warning strapi-plugin-users-permissions > purest > request > hawk ><EMAIL_ADDRESS>This module moved to @hapi/sntp. Please make sure to switch over as this distribution is no longer supported and may contain bugs and critical security issues.
warning strapi-plugin-users-permissions > purest > request > hawk > sntp ><EMAIL_ADDRESS>This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
warning strapi-plugin-email > strapi-provider-email-sendmail > sendmail ><EMAIL_ADDRESS>This project is unmaintained
warning strapi-plugin-email > strapi-provider-email-sendmail > sendmail > mailcomposer ><EMAIL_ADDRESS>This project is unmaintained

Keep trying!

Oh, it seems that you encountered errors while installing dependencies in your project.
Don't give up, your project was created correctly.

Hi @rnkhouse,
Can you plz provide your OS, and the command you ran ?

@alexandrebodin I am running on AKS. It's a Kubernetes deployment.
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: SERVICE_NAME
spec:
  replicas: 1
  selector:
    matchLabels:
      app: SERVICE_NAME
  template:
    metadata:
      labels:
        app: SERVICE_NAME
    spec:
      terminationGracePeriodSeconds: 30
      containers:
      - name: SERVICE_NAME
        image: IMAGE_NAME
        imagePullPolicy: "IfNotPresent"
        ports:
        - containerPort: SERVICE_PORT
        resources:
          requests:
            memory: "200Mi"
            cpu: "200m"
          limits:
            memory: "200Mi"
            cpu: "200m"
        env:
        - name: DATABASE_CLIENT
          value: "mysql"
        - name: DATABASE_HOST
          value: "DATABASE_HOST_VALUE"
        - name: DATABASE_PORT
          value: "DATABASE_PORT_VALUE"
        - name: DATABASE_NAME
          value: "strapi"
        - name: DATABASE_USERNAME
          value: "DATABASE_USERNAME_VALUE"
        - name: DATABASE_PASSWORD
          value: "DATABASE_PASSWORD_VALUE"
      imagePullSecrets:
      - name: mtesacr

@rnkhouse is this sth that you can reproduice everytime ?

@alexandrebodin It worked when I increased the momory and cpu limits of the container.


[Feature Request] Daily Batch Download

Can i request an option that will let me automate downloading of multiple instagram account?

Can i request an option that will let me automate downloading of multiple instagram account?

What about running the jar on the command line with a url file?
java -jar ripme.jar -f $URLFILE where $URLFILE is a text file of the urls you want to rip, on per line

I would also like this feature, but more based on time. example. download ticked history every  x hours.

example. download ticked history every x hours.

Seems like something that the user should set up via cron or similar software rather than be built into ripme


chore: remove dublicate trait import

Removes dublicate trait import of the NonFilterable trait on files:
src/Query/ActionBuilder.php
src/Query/ImprintBuilder.php
src/Query/RegionBuilder.php
src/Query/RelationBuilder.php
src/Query/UploadBuilder.php

🚀


Wrong autoload order

I'm not sure if this is a Godot issue or a Loggie issue;
But every time I open my project, the autoload order of Loggie shifts to the middle of many of my autoloads, which makes the autoloads before it unable to use Loggie;
Every time I open the project, I have to manually adjust the order of Loggie to the front in order to run my project. (And the order will be reset when the project is opened next time)
Do you have any ideas?

I'm not able to reproduce it on Godot 4.3. I'll go into the steps below, but the obvious cause for something like this would be this:
In plugin.gd -> _enter_tree() the method add_autoload_singleton is used to add Loggie to your autoloads list.
Any time you re-run Godot and the plugin enters the tree for the first time, this will execute, however for me that doesn't seem to have any effect if I already have the plugin in my autoload list.
In _disable_plugin, there is a call to remove_autoload_singleton of course, but this will get called only if you disable the plugin, causing add_autoload_singleton on next _enter_tree() to re-add Loggie and therefore add it as the newest entry on the list.
There might be a way to enforce Loggie to always get added as the first entry in that list, but I'd have to look into it.
Here's me trying to reproduce it with a fresh installation:
https://www.youtube.com/watch?v=e-zEDLo-hHM
After closing Godot and reopening the project, Loggie still stayed in the same place in the autoload order.
Which version of Godot are you using? Maybe that could be relevant.

I found it!
This is because I used godot-global-project, and the script it injected into editor settings  somehow messed up the autoload order. Everything workings fine after I cleaned up the related script. Sorry to have taken up your time!

Ahh, I see! Makes sense.
No problem, glad you figured it out.


Adding MidiTok to models-libraries.md

Following the integration of the hub in MidiTok (v2.1.7), this PR adds it to the list of libraries integrating it. 🤗
(I also took the liberty add some spaces to aligne the Library and Description columns on some lines to improve the formatting)

(pinging @Wauplin and @osanseviero)

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

@osanseviero Thank you! 🤗
Noted, I will do. I first hesitated as there is no inference / widget integration (maybe in the future).


Added a dice game

Created  a dice game using html , css and JS.

Good Job!!

Thank you 🥰
On Sun, Oct 9, 2022, 1:10 PM Saikat Nayek @.***> wrote:

Merged #17 https://github.com/Saikat2407/DSA_Hacktoberfest/pull/17 into
main.
—
Reply to this email directly, view it on GitHub
https://github.com/Saikat2407/DSA_Hacktoberfest/pull/17#event-7549012562,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUSNLCFY3JT5DBL6YPH72BDWCJZGNANCNFSM6AAAAAARAMOKMA
.
You are receiving this because you authored the thread.Message ID:
@.***>

no worries chill :)


Debit Card - "Card declined" message displayed for the incorrect Expensify Password

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Lunch the app
Log with expensifail account and navigate to Settings > Payments > Add payment method > Debit card
Now fill in all the necessary information (enter 4242 4242 4242 4242 for credit card number), but use a wrong password.
Submit the form and verify that you see the following message: Incorrect Expensify password entered

Expected Result:
Verify that you see the following message: Incorrect Expensify password entered
Actual Result:
Card declined message displayed for incorrect Expensify Password entered
Workaround:
Unknown
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: No
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/93399543/150059668-f86b4bc7-270b-46c8-841a-f21e242e1286.mp4

Expensify/Expensify Issue URL:
Issue reported by: Applause
Slack conversation:
Issue was found when executing: https://github.com/Expensify/App/pull/6882
View all open jobs on GitHub

Triggered auto assignment to @pecanoro (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

@kavimuru exported already, closing https://github.com/Expensify/App/issues/7310


accounts: verification email is not being sent fix

Corrects conditions on when to sent an email. (addresses
zenodo/zenodo#275)

Signed-off-by: Adrian Pawel Baran<EMAIL_ADDRESS>

\cc @lnielsen

@bouzlibop can you also include a simple test case to cover this issue? Thanks

I've just added simple test case for note field. I've overwritten existing (but empty) test suit file - I'm not sure if I'm not breaking anything?

build is failing, but the error is not connected with this PR - @hachreak already created an issue in https://github.com/kvesteri/sqlalchemy-utils to resolve the problem

lastest is passing, release, devel need fixes mentioned by @hachreak


Do nothing when the activity is null

Fixes #5257

@Danieladu, this was reviewed by the SDK team. There are some questions. Why the response would be empty? Can this be fixed by adding constraints to the schema?

@Danieladu, this was reviewed by the SDK team. There are some questions. Why the response would be empty? Can this be fixed by adding constraints to the schema?

The response is evaluated at runtime. The schema could only check the dialog file staticly.


Implement customizable sorting

In the first commit, I implemented sorting by oldest or newest. The implementation is very simple and would fix #265 and #319. I then extended the sorting algorithm in the second commit to support multiple sorting methods and added the "upvote" sorter. With this, #4 is also fixed.
To see how it works, the updated part of the documentation:

A comma-separated list of thread sorting methods that are applied in the
specified order.
Possible sorting methods:

newest: Bring newest comments to the top
oldest: Bring oldest comments to the top
upvotes: Bring most liked comments to the top

You can combine sorting methods. If you specify upvotes,newest, then comments
will be sorted by upvotes, and comments with the same number of upvotes will be
sorted by date (newest first).
Note that only the top level threads are sorted according to this
configuration. The thread replies are still sorted in chronological order
(oldest first), so that they can be read from top to bottom.
Default sorting is oldest.

I kept the default sorting at oldest, but you might want to change it to upvotes,newest.

Can this PR be merged? I'd really love to have this feature personally and the work is already done!

Actually, this doesn't work with auto-hiding of overflow comments, since the sorting happens on the client. Let's say I have 500 comments on one post, and I limit the display to 10 top-level comments, and I want to display NEWEST first: the embed.min.js script grabs the 10 oldest comments from the Isso server, then sorts those by newest. So I guess the sorting needs to happen on the Isso server, rather than the client, to work with hiding overflow comments.

@dkmooers you're right about that issue. I don't use hiding, so that's a non-issue for me so far.
@jelmer @posativ what would be your preferred approach? can this PR be saved somehow, or would everything need to be done on the server side?

Yes, I believe we should push this logic into the server. :-/

Then I'll close this :slightly_smiling_face:


[BUG] The <IP_ADDRESS> JS jar in wrong maven coordinates.

What is the bug?
JS and JS-SPI are 2 plugins part of the JS repo.
JS-SPI works fine as it only outputs the jars, it goes under https://aws.oss.sonatype.org/content/repositories/releases/org/opensearch/opensearch-job-scheduler-spi/<IP_ADDRESS>/ ---> Valid Scenario
JS has both jar and zip, the jar should be under this URL (missing for <IP_ADDRESS>) and zips under this URL, but with some change it broke and now both jars and zip are under the zips URL (groupID: org.opensearch.plugin)
How can one reproduce the bug?
Steps to reproduce the behavior:

clone https://github.com/opensearch-project/opensearch-build
Run ./build.sh manifests/3.0.0/opensearch-3.0.0.yml --component OpenSearch
Run ./build.sh manifests/3.0.0/opensearch-3.0.0.yml --component job-scheduler
cd tar/builds/opensearch/maven/org/opensearch/plugin/opensearch-job-scheduler/<IP_ADDRESS>
ls -ltr | awk '{print $9}'

opensearch-job-scheduler-<IP_ADDRESS>-sources.jar.sha1
opensearch-job-scheduler-<IP_ADDRESS>.pom.sha512
opensearch-job-scheduler-<IP_ADDRESS>.module
opensearch-job-scheduler-<IP_ADDRESS>-javadoc.jar.sha512
opensearch-job-scheduler-<IP_ADDRESS>.zip.sha1
opensearch-job-scheduler-<IP_ADDRESS>.zip.md5
opensearch-job-scheduler-<IP_ADDRESS>-sources.jar.sha512
opensearch-job-scheduler-<IP_ADDRESS>-sources.jar.md5
opensearch-job-scheduler-<IP_ADDRESS>-sources.jar
opensearch-job-scheduler-<IP_ADDRESS>.pom.sha1
opensearch-job-scheduler-<IP_ADDRESS>.pom.md5
opensearch-job-scheduler-<IP_ADDRESS>.module.sha512
opensearch-job-scheduler-<IP_ADDRESS>.module.sha256
opensearch-job-scheduler-<IP_ADDRESS>.module.sha1
opensearch-job-scheduler-<IP_ADDRESS>-javadoc.jar.sha1
opensearch-job-scheduler-<IP_ADDRESS>.jar.md5
opensearch-job-scheduler-<IP_ADDRESS>.zip
opensearch-job-scheduler-<IP_ADDRESS>.jar
opensearch-job-scheduler-<IP_ADDRESS>.zip.sha512
opensearch-job-scheduler-<IP_ADDRESS>.zip.sha256
opensearch-job-scheduler-<IP_ADDRESS>-sources.jar.sha256
opensearch-job-scheduler-<IP_ADDRESS>.pom.sha256
opensearch-job-scheduler-<IP_ADDRESS>.pom
opensearch-job-scheduler-<IP_ADDRESS>.module.md5
opensearch-job-scheduler-<IP_ADDRESS>-javadoc.jar.md5
opensearch-job-scheduler-<IP_ADDRESS>-javadoc.jar
opensearch-job-scheduler-<IP_ADDRESS>.jar.sha256
opensearch-job-scheduler-<IP_ADDRESS>.jar.sha1
opensearch-job-scheduler-<IP_ADDRESS>-javadoc.jar.sha256
opensearch-job-scheduler-<IP_ADDRESS>.jar.sha512

Notice both jars and zips under the same location.

What is the expected behavior?
The Jars of JS should be under /org/opensearch/opensearch-job-scheduler (similar to JS-SPI).
NOTE:  This used to work fine with job-scheduler <IP_ADDRESS>,
JS-jars
JS-zips

From what I understand each location can only support one packaging type which is either zip or jars.
So to continue publishing jars for JS we need to publish them under org.opensearch.opensearch-job-scheduler
This should help in resolving zips.
So JS will have 3 maven co-ordinates:

https://aws.oss.sonatype.org/content/repositories/releases/org/opensearch/opensearch-job-scheduler-spi/ - SPI Jars
https://aws.oss.sonatype.org/content/repositories/releases/org/opensearch/opensearch-job-scheduler/ - JS Jars (to be fixed)
https://aws.oss.sonatype.org/content/repositories/releases/org/opensearch/plugin/opensearch-job-scheduler/ - JS Zips

That is correct @saratvemulapalli.

@cwperks and I looking are into this

Steps to publish to maven central:

Check out this repository in local and check out 2.7 branch
Verify that 2.7 branch commit is same as <IP_ADDRESS> tag and backport commit for https://github.com/opensearch-project/job-scheduler/pull/379
Run build.sh script from 2.7 branch which will publish all maven artifacts to artifacts/maven/org/opensearch
Sign the artifacts using OpenSearch signing system
Run maven publish script  using dir as artifacts/maven/org/opensearch

Missing artifacts were released using above steps:
https://aws.oss.sonatype.org/content/repositories/releases/org/opensearch/opensearch-job-scheduler/<IP_ADDRESS>/
Closing the issue!

Just to mention that this issue needs to be added to verify before auto publishing:

https://github.com/opensearch-project/opensearch-build/issues/2928


[New] Monitor changes to layer view state

Description
This PR implements Monitor changes to layer view state in Maps category.
URL to README: Monitor changes to layer view state
Linked Issue(s)

swift/issues/5262

How To Test

Interact with the sample and watch the status at the top of the screen change.

Toggle the layer to see "Active" and "Not Visible".
Scale the map outside of the layer's scale range to see "Out of Scale".
Turn of your mac's network to see "Warning".

Screenshots

Thank you guys!


std::move() and std::forward() cannot be used as constexpr in C++11 (build failing in clang 3.8 and in clang 3.9 )

Clang 3.8 will not be supported. Clang 3.9 works but with C++ standard 14 and higher.


Various improvement

Issue
n/a
Description

small fix on icon inside badge
missing export component
change CODEOWNER

Additional context

🧪  Gravitee.io Automatic Prerelease @gravitee/ui-particles-angular
npm install<EMAIL_ADDRESS>
yarn add<EMAIL_ADDRESS>

🧪  Gravitee.io Automatic Prerelease @gravitee/ui-policy-studio-angular
npm install<EMAIL_ADDRESS>
yarn add<EMAIL_ADDRESS>

📚  View the storybook of this branch here

:tada: This PR is included in version 7.40.0 :tada:
The release is available on:

npm package (@latest dist-tag)
npm package (@latest dist-tag)
npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Custom schema doesn't parse numbers properly

console.log(yaml.safeLoad('test: 1'));
console.log(yaml.safeLoad('test: 1', {schema: yaml.Schema.create(yaml.Schema.DEFAULT_SAFE_SCHEMA, [])}));

result:
{ asdf: 1 }
{ asdf: '1' }

Why would creating a custom schema based on the DEFAULT_SAFE_SCHEMA and the empty array result in a string instead of an integer?

NVM, it should be
yaml.DEFAULT_SAFE_SCHEMA

instead of
yaml.Schema.DEFAULT_SAFE_SCHEMA


Upload Question - resolve field references

This addresses #292 and adds XPath insertion to upload type questions.

Codecov Report

Merging #293 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #293      +/-   ##
==========================================
+ Coverage   81.19%   81.21%   +0.01%
==========================================
  Files          23       23
  Lines        3106     3109       +3
  Branches      729      730       +1
==========================================
+ Hits         2522     2525       +3
  Misses        450      450
  Partials      134      134

Impacted Files
Coverage Δ

pyxform/question.py
92.26% <100%> (+0.13%)
:arrow_up:

Continue to review full report at Codecov.

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

@ukanga - I've updated the attribute column test (as this is adding an attribute) to check for the intended output (this also had the side effect of testing external namespace addition as well)

@tedrick It is expected that any new test addition should use the markdown approach, I was expecting this change in tests_v1 rather than an updated excel XLSForm file.

@tedrick making sure you saw @ukanga's ask to put the test in the tests_v1 format! Please ask if you have any questions.

Yes, it's in my backlog - it's been a busy summer :)

Thanks for the status update, @tedrick! 🎉 Here's to a less busy fall for all of us!

Closing in favor of #386


fast/short array creation syntax

any ideas of making fast array creation/fill syntax?
here is the target javascript code:
Array(n).fill(x)

where n is the number of elements, and x is the fill value. maybe:
[n of x]

Possible complications of introducing a new syntax might be upheld by "you may ignore it if you find it unhandy" claim, but eventually it will concern every one of us because we eventually will have to read someone else's code.
The richest "language" regarding to the "shorthand" is possibly the RegEx. It's considered as a "write-only language".
So, I prefer not to have it at all. That's of course only my idea.

Isn’t that just [x] * n?

@vendethiel
works well, when n is given straight and small, but:
repeatArray$([x], n);
function repeatArray$(arr, n){
  for (var r = []; n > 0; (n >>= 1) && (arr = arr.concat(arr)))
    if (n & 1) r.push.apply(r, arr);
  return r;
}

Isn't it way too arcane? :]

In a version of LiveScript that assumed (or was instructed to have) an ES6 target, I think it could make sense to optimize specifically [x] * n to Array(n).fill(x). I wouldn't want there to be another syntax that overlaps with the existing one in functionality.
Absent such a version of LiveScript, this doesn't seem that important to do; writing Array n .fill x yourself isn't bad, if you care enough about the efficiency of your code to want that. It has the advantage of being crystal clear both about what it's doing and about what it requires from the runtime; the only cost is eight more characters.

@rhendric
So you mean that LiveScript should be upgraded to have some compile option that enables higher JS/ES runtime versions first?

I'm not saying such a compile option would necessarily be a good idea. (A while back there was some talk about integrating LiveScript with Babel (#821), which I think would be a better approach for targeting more modern runtimes.)
But to take a compilation that targets ES5 (or is this even ES3?) and change it to only run on ES6 is more breaking than I want to do without some sort of a bigger plan for ES6+ support in general. If such a plan ever comes into play, I think I'd be happy for this optimization to be a part of it.


ENH utils module available from civis namespace

Import utils into civis so that users can access civis.utils.run_job after an import civis import. Many users expect this and are surprised when it's not available.

Anything else you're planning to add to this PR? I'm happy to review.

No, that was it. I was trying to avoid asking for review on too many PRs at once.


DST-890 - Fix KeyError "locality" bug

Codecov Report
Attention: Patch coverage is 50.00000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 81.55%. Comparing base (80ee387) to head (2fd622d).

Files with missing lines
Patch %
Lines

django_app/utils/address_formatter.py
50.00%
2 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #272      +/-   ##
==========================================
- Coverage   81.61%   81.55%   -0.07%
==========================================
  Files          77       77
  Lines        2350     2353       +3
==========================================
+ Hits         1918     1919       +1
- Misses        432      434       +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Make _Config in runner.py class a dataclass so we can remove the whole lot of type: ignore-s from later parts of cli.py

This not being a dataclass causes a lots of confusion for mypy, and rightfully so. This is not the nicest. Make it a dataclass or replace everything with click :)

@deathowl Hi, I'd like to work on this. To double-check, do you mean _Config class in cli.py? We can make it dataclass to that we can refactor _get_config_from_parsed_args. And what does it mean "ignore-s from later parts of cli.py"?

Hey! Thanks for reaching out . Yeah, it makes https://github.com/facebookincubator/TestSlide/blob/master/testslide/cli.py#L332 really not nice to have so many type: ignore-s. The easier way could be to turn _Config into a dataclass that holds configuration.
The harder but nicer way would be to move cli.py to use click so we wouldn't need to worry about this at all. Ping the thread if you need any help :)

Yeah, maybe I can think about moving to click directly. Do we have test for cli.py so that my refactor won't break?

Click <3
There should be thorough test coverage for the CLI: make tests/cli_unittest.py V=1. Those work by spawning the binary and asserting on output, so, click / no click, they should work the same for the most part.


The text box is visible after clicking any one node

Repro Steps:

Right click one subscription and select 'Create New Web App' then select one subscription.
Make sure the text box is displayed to enter a globally unique name for the new Web App.
Right click one node and make sure the context menu are displayed.
Check whether the text box disappears or not.

Expect:
The text box disappears.
Actual:
The text box doesn't disappear for Azure App Service extension like below.

More Info:
The text box disappears for Azure Storage Extension.

@v-dantch This behavior is by design. Since the user has to go through several menus one-by-one in VS Code, it would be annoying if a stray click made you lose all your progress
We've actually had a few issues to this effect:
https://github.com/Microsoft/vscode-azureappservice/issues/42
https://github.com/Microsoft/vscode-azurefunctions/issues/154


os: RemoveAll fails to remove deeply nested directory tree, triggers OOM Killer

What version of Go are you using (go version)?

$ go version go1.16.5 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
    $ go env
    GO111MODULE=""
    GOARCH="amd64"
    GOBIN=""
    GOCACHE="/home/test/.cache/go-build"
    GOENV="/home/test/.config/go/env"
    GOEXE=""
    GOFLAGS=""
    GOHOSTARCH="amd64"
    GOHOSTOS="linux"
    GOINSECURE=""
    GOMODCACHE="/home/test/go/pkg/mod"
    GONOPROXY=""
    GONOSUMDB=""
    GOOS="linux"
    GOPATH="/home/test/go"
    GOPRIVATE=""
    GOPROXY="direct"
    GOROOT="/usr/lib/golang"
    GOSUMDB="off"
    GOTMPDIR=""
    GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
    GOVCS=""
    GOVERSION="go1.16.5"
    GCCGO="gccgo"
    AR="ar"
    CC="gcc"
    CXX="g++"
    CGO_ENABLED="1"
    GOMOD=""
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    PKG_CONFIG="pkg-config"
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1485272220=/tmp/go-build -gno-record-gcc-switches"

What did you do?
create.go:
package main

import (
	"fmt"
	"log"
	"os"
	"strings"
)

func main() {
	path := os.Args[1]
	os.Mkdir(path, 0755)
	os.Chdir(path)

	// 2^30 is big enough that the process will run out of memory before completing on most machines
	// 2^10 (1024) is a good value to use for profiling memory usage
	// n := 10
	n := 30
	for i := 0; i < (1 << n); i++ {
		dirname := strings.Repeat("x", 255)

		if i%128 == 0 {
			fmt.Println(i)
		}

		err := os.Mkdir(dirname, 0755)
		if err != nil {
			log.Fatal(err)
		}
		os.Chdir(dirname)
	}
}

remove.go:
package main

import (
	"log"
	"os"
)

func main() {
	dir := os.Args[1]
	err := os.RemoveAll(dir)
	if err != nil {
		log.Fatal(err)
	}
}

Create a very deep directory tree (~2.5 million subdirectories)
$ go run create.go /tmp/deep
0
128
...
2473472
Killed

Attempt to remove them with os.RemoveAll()
$ go run remove.go /tmp/deep
Killed

Observe exhaustion of system memory, causing oom-killer to kill the process. Directory tree still remains:
$ ls -d /tmp/deep
/tmp/deep

What did you expect to see?
remove.go successfully remove the target deep directory tree, without exhausting system memory
What did you see instead?
remove.go causes a sharp increase in memory usage, causing OOM killer to kill remove.go before it can complete

Profile of os.RemoveAll() with this patch:  patch
diff --git a/src/os/removeall_at.go b/src/os/removeall_at.go
index c1a1b726af..31fb746d56 100644
--- a/src/os/removeall_at.go
+++ b/src/os/removeall_at.go
@@ -9,9 +9,30 @@ package os
 import (
	"internal/syscall/unix"
	"io"
+	"runtime"
+	"strconv"
	"syscall"
 )

+var iterations = 0
+
+func PrintMemUsage() {
+	var m runtime.MemStats
+	runtime.ReadMemStats(&m)
+
+	f, _ := OpenFile("/tmp/golang_stats", O_APPEND|O_CREATE|O_WRONLY, 0644)
+
+	f.WriteString("Iterations: " + strconv.Itoa(iterations) + "\n")
+	f.WriteString("StackInUse = " + strconv.FormatUint(m.StackInuse, 10))
+	f.WriteString("\tStackSys = " + strconv.FormatUint(m.StackSys, 10))
+	f.WriteString("\tAlloc = " + strconv.FormatUint(m.Alloc, 10))
+	f.WriteString("\tTotalAlloc = " + strconv.FormatUint(m.TotalAlloc, 10))
+	f.WriteString("\tSys = " + strconv.FormatUint(m.Sys, 10))
+	f.WriteString("\tNumGC = " + strconv.FormatUint(uint64(m.NumGC), 10) + "\n")
+
+	f.Close()
+}
+
 func removeAll(path string) error {
	if path == "" {
		 // fail silently to retain compatibility with previous behavior
@@ -45,6 +66,8 @@ func removeAll(path string) error {
	}
	defer parent.Close()

+	PrintMemUsage()
+	iterations = 0
	if err := removeAllFrom(parent, base); err != nil {
		 if pathErr, ok := err.(*PathError); ok {
			  pathErr.Path = parentDir + string(PathSeparator) + pathErr.Path
@@ -52,11 +75,13 @@ func removeAll(path string) error {
		 }
		 return err
	}
+	PrintMemUsage()
	return nil
 }

 func removeAllFrom(parent *File, base string) error {
	parentFd := int(parent.Fd())
+	iterations += 1
	// Simple case: if Unlink (aka remove) works, we're done.
	err := unix.Unlinkat(parentFd, base, 0)
	if err == nil || IsNotExist(err) {

$ cat /tmp/golang_stats
Iterations: 0
StackInUse = 294912 StackSys = 294912 Alloc = 908920 TotalAlloc = 908920 Sys = 71388176 NumGC = 0
Iterations: 1025
StackInUse = 884736 StackSys = 884736 Alloc = 9492424 TotalAlloc = 10795872 Sys = 74269704 NumGC = 2

After 1K iterations of removeAllFrom, i.e. for 1000 directories deep, around 10MB of allocations were used. This increased in proportion to the depth of directory tree so that one million iterations used  a thousand times more memory, several GB. On a system with 8GB of RAM, OOM Killer was therefore triggered well before the removal of the directory tree could be completed.
In comparison, coreutils’ rm uses significantly less memory and eventually succeeds in removing the deep directory (though a small amount of swap space was needed).

Here's a standalone test case (go test rm_test.go):
package rm

import (
	"os"
	"strings"
	"testing"
)

func TestRm(t *testing.T) {
	path := "/dev/shm/deep"
	dirname := strings.Repeat("x", 1)
	os.Mkdir(path, 0777)
	os.Chdir(path)
	n := 1<<11
	for i := 0; i < n; i++ {
		err := os.Mkdir(dirname, 0777)
		if err != nil {
			t.Fatalf("mkdir #%d: %v", i, err)
		}
		os.Chdir(dirname)
	}
	os.Chdir("/")

	err := os.RemoveAll(path)
	if err != nil {
		t.Fatal(err)
	}
}

Interestingly, that test case takes time O(n²) on my Mac, but all the time is in syscall (calling into Mac libc), which suggests that perhaps Mac libc implements openat/unlinkat by reconstructing the original paths instead of actually using the fds directly. Oops.

On my Linux workstation, getconf PATH_MAX says 4096, but every file system I've tried rejects mkdir after 31 255-long directory elements, or just under 8kB. If I change 255 to 1, then I can make more directories: 1<<11 works fine. I'm not sure what sysctl etc needs to be frobbed to get access to million-element path names.

As for the actual bug, the implementation of os.RemoveAll already uses openat(2) and unlinkat(2), so there's no concern with the long paths directly (at least on Linux).
The problem appears to be that the implementation keeps the parent directory open while it removes the children, and each open directory has a directory-entry-reading bufferin its dirInfo.buf, of size 8kB. If you are removing a tree a million entries deep with an 8kB buffer per depth level, that's going to be 8 GB.
Presumably the kernel also has some state related to each open directory. If that was 1kB then you're still looking at 1 GB of kernel state for a million open file descriptors.
An obvious answer is to close the parent while removing its children. But you need the parent's fd for the openat of each child. Closing the fd between children would (recursively) require rewalking the entire path to get the fd for the next child, which leads to exactly the quadratic behavior that opnat(2)/unlinkat(2) was introduced to, well, remove.
We can't make the per-directory buffer appreciably smaller, because we get lost directory entries if it is too small - see #24015.
It does look like we can adjust directory reading to drop the buffers between reads most of the time, though. I've sent CL 337449 to do that. Even that CL is not perfect, though: each level of the walk is holding all the strings from that directory read, which could be up to 8 kB or so of data. So you could still provoke 8 GB of memory usage, though not in the test case. I don't see any way to avoid having those strings, since we need to read at least 5760 bytes per #24015, and we can't throw away all but the first entry that is returned.
Those strings are already in memory, so dropping the directory-reading buffers is at least a factor of two improvement in that worst case. Of course, then there is the problem of a two-million-deep directory tree.
I tried to look at what coreutils rm does, and the answer appears to be “use some library that is not in the coreutils repo,” so I stopped there.
Generally speaking, cleaning up an arbitrarily deep directory tree is going to be arbitrarily expensive. I'm not convinced this is a battle that the implementation of os.RemoveAll can win, although the memory factor of at least 2 (more in common cases) is probably worth claiming.
We could submit my change for Go 1.18, but I think it's a bit too risky, with hardly any real benefit, for Go 1.17.

The GNU rm program uses the fts library that is part of gnulib.  The source code is at https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/fts.c;h=e6603f40e76fe86707ddf600ab7f818e3f63ccc1;hb=HEAD.  The code is pretty complicated.  As far as I can tell, as invoked by the rm command, it keeps a small cache of parent directories open as it descends.  If the cache fills up, it closes and later reopens the parent directory for use with fstatat.  Separately, when it gets to a new directory, it reads up to 100000 entries from that directory.  If the directory has more entries than that, it also keeps it open apart from the cache.  So in the typical case where there are fewer than 100000 entries, it just does a simple file walk with only a few parent directories open at any one time.  When there are more entries in one directory, it keeps that directory open.  So it will run out of resources with a deep tree if each level of the tree has many entries.  Assuming I understand the code; it is quite possible that I don't.


Rencommended way to get SVG support

Hello, thank you for this repo!
I was wondering how to add SVG load support inside of the VM, because I'm getting these errors at the moment:

I tried the following, but installing with apt-get doesn't seem to work:
image: barichello/godot-ci:3.2

stages:
  - export

before_script:
  - mkdir -v -p build/windows

windows:
  stage: export
  script:
    - apt-get update -y
    - apt-get install -y gwenview
    - cd GodotProject
    - godot -v --export-debug "Windows Desktop" ../build/windows/$EXPORT_NAME.exe
    - test -e ../build/windows/$EXPORT_NAME.exe
  artifacts:
    name: $EXPORT_NAME-$CI_JOB_NAME
    paths:
      - build/windows
  only:
      - master

Any idea how I should do this?

To clarify, this is the error in Gitlab:

I think you're missing apt-get upgrade to install what you need, try with: apt-get update && apt-get upgrade && apt-get install -y --no-install-recoends gwenview

Hello @aBARICHELLO ! Thank you for your time!
Unfortunately, this doesn't work either 😢

(Also, if gwenview is not a good program for making these SVG import/load errors disappear please tell me)

Just to elaborate a bit: The problem becomes even more dire when using 3D models and other more "exotic" formats. For this year's Global Game Jam, I tried to use the godot-ci tools to automatically publish my game to itch.io.
This works great with our test repositories 😄
But when trying to use it with formats like *.fbx, *.mesh, *.ogg and *.wav as seen here:

So there should be some way to install the correct dependencies that support these files...
Unfortunately I can't get the apt-get to work.

I'm not sure how to help you, I think there's a problem with your project configuration.
Godot documentation does not mention any specific runtime dependencies to export projects with those file extensions you mentioned and I don't know how installing gwenview would help.

Hello, I made a small mock-up project that demonstrates the issue.
It seems that (in this case) the autoload editor_plugin "Test.tscn" has issues loading the icon.png
when building this project in Gitlab you get errors. This example is extremely as my actual problem (except for the fact that that project uses an .svg instead)
ci-warning-test.zip
When running/exporting Powershell:

When running in Gitlab:

Could this problem be related to the fact the CI uses a headless build of Godot to export?

This is likely solved by https://github.com/godotengine/godot/pull/36083, which hasn't been merged yet. By the way, you don't need to install any system libraries to use SVG in Godot (it bundles nanosvg).

Sweet! Thanks @Calinou ! I'll test it out once that commit is merged and see if that fixes it 😄
BTW I didnt see .mesh or .fbx files in that list? Does that mean that does files will still spawn errors?

@2shady4u I only looked at image formats, not mesh formats. That said, I don't know why mesh importers would differ between a non-headless version and a headless version.

This should probably be closed given this isn't an issue with this CI script.


Port GOV-35 fix to dev branch.

Ports https://github.com/casper-network/casper-node/pull/1757 fix to dev branch.

bors merge


got enzyme test working with redux connected components

Fixed the enzyme issue, by:

using jsdom test environment instead of default node test environment.
when doing a shallow render use .children().dive() to render and wrap components

Still having issues simulating an onClick in redux connected component:

Mocking and Spying on the useState function call doesn't seem to work, maybe I can try reading the prop directly

Updated port to be 3068 to avoid potential conflicts with user apps. Converted to decimals
K:75
u:117
r:114
+_____
306
8 should be 56 but I just added the 8 to the end for that 4 number look.
Partially completed custom metrics page with enzyme:

I still need to test the form, drag n drop, and hydrating from local storage


Presentation for Consideration

Hello,
I wondered whether my talk on Adversarial Threat Modelling — A Practical Approach to Purple Teaming in the Enterprise (using VECTR) can be included in your list please?
The talk contains practical guidance on how to orchestrate an intelligence led process within the Enterprise, as well as lots of tips on organising tests within VECTR. Thanks for your consideration!

Hi @ssnkhan Thank you very much for sharing your talk resources! You put a lot of work into it! I added it as a resource under VECTR!!! =)


Add layer of Goa plateaus

Is your feature request related to a problem? Please describe.
Laterite capped table lands/plateaus are a unique geological feature of Goa and the Konkani belt. The plateaus play a vital role in water table recharge and supporting life in the settlements around it.
Adding a layer that demarcates the various plateaus will be an important reference for various conservation efforts. There is only one map available online that marks them:

https://www.researchgate.net/figure/Map-of-distribution-of-key-laterite-capped-table-land-plateaux-regions-of-Goa-1_fig1_42800308
Describe the solution you'd like
Polygons of the plateaus do not exist and will have to be created. One way to do it would be to use the terrain map for reference and roughly demarcate them. We can use the research gate map for some of the names, but might have to do further research for more detailed shapes and attributes.

Describe alternatives you've considered
Look online for sources of open data for plateau polygons but none was found

I think the polygons are here - https://bhukosh.gsi.gov.in/arcgis/rest/services/Geomorphology250K/Geomorphology_250K/MapServer/0

@ramSeraph tried via QGIS but not able to get any vectors from the map server. Does it work for you?

@planemad Haven't attempting pulling.. But I was able to see the preview on this page - https://www.arcgis.com/home/webmap/viewer.html?featurecollection=https%3A%2F%2Fbhukosh.gsi.gov.in%3A443%2Farcgis%2Frest%2Fservices%2FGeomorphology250K%2FGeomorphology_250K%2FMapServer%3Ff%3Djson%26option%3Dfootprints&supportsProjection=true&supportsJSONP=true ( You will need to click on the pin and add to map ).

I tried downloading and found that the vector data is not accessible from here.
I see it at a different source. I will see if it is downloadable from there.

geomorphology_GA_GM50K_0506.geojsonl.txt Source is Bhuvan

Looking through the geomorphology data, its likely not directly useful for demarcating the plateau lands which is more closely related with the terrain elevation and slope.
Using DEM generated slope, the outlines of the plateau lands are more clearly visible.

@ramSeraph we do not need to bother with the geomorphology vector for now, although its probably a useful dataset to have in future for other purposes.


Narrowing a union from generic fails when union is not the first generic

TypeScript Version:

2.9.0-dev.20180330
2.8.1
2.7.2

Search Terms:

generic order
map index generic

Code
type Tags  = { foo: ''; bar: ''; baz: ''; }
type Tag = keyof Tags

type GetTag<UsedTag extends keyof Tags> = keyof { [tag in UsedTag]: any }

type DoThingVersionOne =
  <UsedTag extends Tag = Tag, Props = {}>(tag: UsedTag) => GetTag<UsedTag>

const doThingVersionOne: DoThingVersionOne = {} as any

const fooOne = doThingVersionOne('foo')                       // expected | type = "foo"
const fooOneITag = doThingVersionOne<'foo'>('foo')            // expected | type = "foo"
const fooBarITagIProps = doThingVersionOne<'foo', {}>('foo')  // expected | type = "foo"

type DoThingVersionTwo =
    <Props = {}, UsedTag extends Tag = Tag>(tag: UsedTag) => GetTag<UsedTag>

const doThingVersionTwo: DoThingVersionTwo = {} as any

const fooTwo = doThingVersionTwo('foo')                       // expected | type = "foo"
const fooTwoITag = doThingVersionTwo<{}>('foo')               // unexpected | type "foo" | "bar" | "baz"
const fooTwoITagIProps = doThingVersionTwo<{}, 'foo'>('foo')  // expected | type "foo"

Expected behavior:
The order of a generic does not effect it's behaviour when narrowing from a union.
Actual behavior:
The order of a generic does effect it's behaviour when narrowing from a union.
Playground Link:
Playground Reproduction
Related Issues:
https://github.com/Microsoft/TypeScript/issues/17713
https://github.com/Microsoft/TypeScript/issues/21631
https://github.com/Microsoft/TypeScript/issues/12424

The order matters because of the default values you have and in the unexpected case you're partially instantiating the generics. The following two are equivalent and give the same result.
const fooTwoITagWithDefault = doThingVersionTwo<{}>('foo') //  "foo" | "bar" | "baz"
const fooTwoITag = doThingVersionTwo<{}, Tag>('foo') //  "foo" | "bar" | "baz"

I believe partial application of generics turns off inference for those that are omitted (they fall back to their default value).

Ahh, right. I was thinking when providing generics, only the ones passed would be instantiated.
Happy to close this, thanks for your quick response and explanation.


page.SetContent could accept a URL to set page.url

Could this be possible?
var expectedContent = '
Test div
';
var expectedLocation = 'http://www.teste.org/';
page.setContent(expectedContent, {url: expectedLocation});
page.url() would then be equal to expectedLocation.

Couldn't you just do:
const browser = await puppeteer.launch();
const page = await browser.newPage();

const expectedLocation = 'http://www.teste.org/';
await page.goto(expectedLocation);

const expectedContent = '
Test div
';
await page.setContent(expectedContent);

console.log(await page.url() === expectedLocation);

await browser.close();

@rafagsiqueira Eric's workaround would work. You can even speed it up with request interception's respond method (available in v0.13.0-alpha, current tip-of-tree):
await page.setRequestInterception(true);
page.once('request', req => {
  req.respond({
    body: '
Test div
'
  });
});
await page.goto('http://www.teste.org/');

But if I do page.goto(expectedLocation) wouldn't I be loading the whole content of this page?
The request interception solution is more efficient I believe. Thank you for both solutions!
Still, I think it makes sense, if you can set the page content you should be able to set the url of that page.

I would love to see this request reopened. HTML you set as content may have external links, so full code would look something like the following:
        await page.setRequestInterception(true);
        page.on('request', (request) => {
          if ( request.url() === data.base_url || request.url() === data.base_url + '/') {
            request.respond({
              body: data.content
            });
          } else {
            request.continue();
          }
          return;
        });
        await page.goto(data.base_url);

+1 to reopen this issue

@ruz
Just for anybody else trying this.
I had to set the content type in the request.respond to actually make it render my html:
request.respond({
          contentType: 'text/html',
          body: screenshotSettings.htmlString
        })

+1 to reopen this.


[WIP] [AutoTVM][TOPI] NHWC conv2d templates for ARM

Per https://github.com/dmlc/tvm/pull/3754 and https://github.com/dmlc/tvm/pull/3141#issuecomment-526434398 , we are enabling NHWC conv2d templates for ARM as a nearly final solution. The benefits include:

Enable NHWC schedule directly. Previously, we need to transpose between NCHW and NHWC.
AutoTVM now can tune NHWC directly. Previously, we need to build a NCHW network to tune.
Potential performance advantage in NHWC which known to community.

Cowork with @FrozenGene and @etaf .
This is a draft to loop people who may have interest, @anijain2305 @tmoreau89 . Will loop more when the PR is ready, thank you. :)

@jackwish Very glad to see this :)
Does this also support int8 computation?

Hi Animesh, thanks for the interest, INT8 support will be added later, we'd
like to improve the draft schedule first :)
Animesh Jain<EMAIL_ADDRESS>于2019年8月30日周五 上午11:53写道：

@jackwish https://github.com/jackwish Very glad to see this :)
Does this also support int8 computation?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dmlc/tvm/pull/3859?email_source=notifications&email_token=ABFVHDOERZTSK5EJS6QMLPTQHCKTDA5CNFSM4ISI3UL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5QOYMI#issuecomment-526445617,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABFVHDIYDR5DUG6FR2RTVSLQHCKTDANCNFSM4ISI3ULQ
.

Great to see this draft @jackwish ! A question I have regarding code maintainability: should we consider reusing some common infrastructure between x86 and ARM?

@jackwish Glad to see this!
As we discussed in https://github.com/dmlc/tvm/pull/3754, NWHC layout can further boost conv2d on arm_cpu. In this case, we can use NHWC by default as backend schedule for arm_cpu. Combining with enhanced alter op layout pass
, we can boost models, such as MXNet model, which have NCHW as data layout.

@tmoreau89 yes, I agree. we could consider opening a RFC to discuss. Many code / schedule can be unified between x86 with arm. However, There is some different places we will have. Especially tensorize for producing special instruction.

Great to see this draft @jackwish ! A question I have regarding code maintainability: should we consider reusing some common infrastructure between x86 and ARM?

Yes @tmoreau89 , that is really a great idea to share code between x86 and ARM (or any other CPU ISA). And, we have some internal discussions previously. Personally, I am thinking that have a module which handles generic CPU schedules, topi.cpu for example, and let the arch-dependent code lies in topi.{isa}. We can further discuss this, I was planning to draft a RPC next week, what you say :)

@jackwish Glad to see this!
As we discussed in #3754, NWHC layout can further boost conv2d on arm_cpu. In this case, we can use NHWC by default as backend schedule for arm_cpu. Combining with enhanced alter op layout pass , we can boost models, such as MXNet model, which have NCHW as data layout.

Yes @kevinthesun , we are working on this to improve performance.

@jackwish an RFC sounds like a great idea. I agree, there will be differences between different backends (tensorization for ARM 8bit, and bitserial; vectorize for AVX etc.) but overall the schedules shouldn't diverge too much. It will make maintaining the code bases more tenable; and minimize technical debt in the long run

Hi guys, I am a bit busy this week, will come back to this (for the RFC part) later :)

Is NHWC generally faster than NCHW on ARM CPUs? should we transform NCHW to NHWC in alter_layout?

Hi Yizhi, thank you for ask. NHWC is not generally faster than NCHW, it
depends on the schedule still. I guess we can use AutoTVM to decide which
layout is preferred for specific workloads :)
Regards
Yizhi Liu<EMAIL_ADDRESS>于2019年9月9日周一 上午11:06写道：

Is NHWC generally faster than NCHW on ARM CPUs? should we transform NCHW
to NHWC in alter_layout?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dmlc/tvm/pull/3859?email_source=notifications&email_token=ABFVHDLC4TLTHHU5EC7HGS3QIW4PXA5CNFSM4ISI3UL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6GDQLQ#issuecomment-529283118,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABFVHDMJLO5ADM64PTGGDULQIW4PXANCNFSM4ISI3ULQ
.

@jackwish, are you sure NHWC isn't faster than NCHW on ARM? In my experience I've consistently observed speeds up to 5X faster and haven't found any cases where NCHW is preferable. I'm definitely on in support of automatically altering to NHWC for arm_cpu workloads.

@jackwish, are you sure NHWC isn't faster than NCHW on ARM? In my experience I've consistently observed speeds up to 5X faster and haven't found any cases where NCHW is preferable. I'm definitely in support of automatically altering to NHWC for arm_cpu workloads.

Hi @jwfromm , sorry if I made any confusing comments, but I was saying that NHWC is not always faster than NCHW. To achieve better performance, sound schedule is needed.
It's really impressive to obtain 5X performance for NHWC over NCHW, which I think this PR cannot make it happen (sad story)... Would you please share more your design if that's is possible? I am sure it must be inspiring and insightful!

I've been using the NHWC schedule written by @cowanmeg, which can be found in the quantized_end2end branch of her TVM fork (https://github.com/cowanmeg/tvm/tree/quantized_end2end). Maybe she can chime in on what works well for NHWC.

I've been using the NHWC schedule written by @cowanmeg, which can be found in the quantized_end2end branch of her TVM fork (https://github.com/cowanmeg/tvm/tree/quantized_end2end). Maybe she can chime in on what works well for NHWC.

Thank you @jwfromm. I have taken a look at the code, which is very similar to this PR. Still, I am very curious about the 5X performance, would you please share the detail of getting the performance (I will try @cowanmeg 's schedule too)? As mobilenet1 with NCHW can get 121 ms on Raspberry Pi 3B, 5X means ~25 ms, which outperforms many fast quantization optimization approaches I think.

Hi Jack,
I haven't tried benchmarking mobilenet. Because it uses separable convolutions instead of the more typical convolution layers in the models I've worked with it's very reasonable that data layout format might have a much smaller impact. Most recently I found that SqueezeNet in NCHW format takes 780ms to run in NCHW format and 182ms to run in NHWC format. It might be worth checking out your schedules on a squeezenet or vggnet (lots of standard convolutions).

Hey @jackwish , nice work for supporting NHWC data layout. It would be great if you could give some performance number of common models on ARM CPUs.

Hi Jack,
I haven't tried benchmarking mobilenet. Because it uses separable convolutions instead of the more typical convolution layers in the models I've worked with it's very reasonable that data layout format might have a much smaller impact. Most recently I found that SqueezeNet takes 780ms to run in NCHW format and 182ms to run in NHWC format. It might be worth checking out your schedules on a squeezenet or vggnet (lots of standard convolutions).

Hi @jwfromm , thanks for you data. I have tried that schedule with MobileNetV1, but didn't get performance advantage like 5X. I think the performance gain depends on the network architecture also :)

Hey @jackwish , nice work for supporting NHWC data layout. It would be great if you could give some performance number of common models on ARM CPUs.

Thanks for the reminder @ZihengJiang , we will share some performance data when this is ready for review. :) We have been working on internal project, so the progress of this PR could be last for days :(

Hi @jackwish , any idea when this PR can be in good shape :)

Hi @anijain2305 , thank you for asking. This PR was pending due to NHWC building failure on ARM targets (w/o this patch). I didn't look into it in detail as I have been busy with Quantization and OpenCL backends. Will re-check later this week :)

Rebased now. Collecting benchmarking data.
PS. Though we expected NHWC have a potential of better performance on CPU than NCHW, however, the result depends on how the schedule is designed. Say, a naive NHWC cannot outperform a carefully designed NCHW schedule.
We (AliOS team in Alibaba) have not observed better NHWC performance in spatial pack before, as not paying much effort in this. We was focusing on other schedules. So, this patch may not outperform the original NCHW spatial pack schedule. But still a good try :)

Thanks @jackwish for the update. Makes sense. So, are we planning to close this PR?
I am starting to look into Conv2D schedules for ARM. I can make a alter-layout change for NHWC network to use NCHW spatial schedule. I will do it in a manner that there are as few layout transforms as possible in the whole network (hopefully just 2) to amortize the cost of layout transforms.

Thanks @jackwish for the update. Makes sense. So, are we planning to close this PR?

I agree to close this - data layout doesn't impact spatial pack convolution very much. And people interesting in this can still try @cowanmeg 's branch or mine.

I am starting to look into Conv2D schedules for ARM. I can make a alter-layout change for NHWC network to use NCHW spatial schedule. I will do it in a manner that there are as few layout transforms as possible in the whole network (hopefully just 2) to amortize the cost of layout transforms.

That sounds good! We have already considered this solution internally before.
Thanks everyone, this is now closing as we are not going to putting extra effort to improve the performance of Spatial Pack convolution schedule for NHWC.

Given how far we have landed the code, it will still be great to bring it into the collection. @jackwish if you like, please feel free to re-open the thread and get some reviews.

I agree @tqchen's comment. I think we could bring this in, which doesn't hurt anything.

Per @tqchen and @FrozenGene suggestion, reopening.
As I didn't observe significant performance advantage of this NHWC spatial pack schedule, this is much like a functionality patch rather than something to outperform NCHW.
@tmoreau89 Would like to look into this code structure? I will add some benchmark results next week.

conv2d.py:625
why insert this new_weight below to overlay the previous new_weight? @jackwish
new_weight = tvm.placeholder((KH + tile_size - 1, KH + tile_size -1, CO // VC, CI, VC),
kernel.dtype)

conv2d.py:625
Another problem, the second KH should be KW!! @jackwish
new_weight = tvm.placeholder((KH + tile_size - 1, KH + tile_size -1, CO // VC, CI, VC),
kernel.dtype)

Thank you for the review @snowolfhawk ! I will update later (I have been working on some other thing on parallel).
Btw, would you please to leave review comments by clicking the floating button below, that is pretty efficient :)

@jackwish
Do you still use winograd for NHWC?

Do you still use winograd for NHWC?

Hi @snowolfhawk , this Spatial Pack schedule seems to be the first NHWC layout support for ARM CPU. May I know more detail of your question?

Rewritten schedule. For Mobilenet on Rasp 3B+ w/ AArch64 image, NCHW gets 134.26 ms while NHWC gets 132.50 ms. People may still finetune this schedule to improve.
Before this is merged, the NHWC->NCHW layout transform #4249 may need to revert, so please hold a second.

Do you still use winograd for NHWC?

Hi @snowolfhawk , this Spatial Pack schedule seems to be the first NHWC layout support for ARM CPU. May I know more detail of your question?

I think @snowolfhawk 's question is we could use Winograd algo. on NCHW layout, For NCHW, could we use Winograd for NHWC layout too?

@jackwish I saw your comment regarding reverting https://github.com/apache/incubator-tvm/pull/4249
Sounds good to me. Lets ensure that we can work with both Conv and Depthwise. Let me know. If you want, I can send a PR for reverting.

Hi @anijain2305 , actually that was an accident :(. I have mixed the data of different layouts... Will tune this when I have time...

Oh I see. No worries. I think AlterOpLayout code converted to NCHW under the hood, causing confusion.
It's ok. Take your time. I am willing to revert my PR if we see comparable performance with NHWC schedule. That will be the right thing to do.

Rewritten schedule. For workload (input/output HW 64, input/output channel 64, kernel size 1), we now have comparable performance on Rasp 3B+ w/ AArch64 Ubuntu (~5ms). Tuning a larger workload currently.
So basically this is ready for review, please have a look at @tmoreau89 @ZihengJiang .
Notes:

Kernel prepack not enabled yet. We'd like to hold that until depthwise NHWC were done, and the AlterOpLayout were simplified.
Won't be used unless disable NHWC-NCHW layout transformation in AlterOpLayout. To try out this, put return None in AlterOpLayout.
AlterOpLayout will be updated when we can run whole MobileNet in NHWC.

For the CI sanity check , I failed to reproduce it locally :(. And, I think the warning (as below) should be ignored because we are really using cfg['compat'].val as integer rather than bool.
python3 -m pylint topi/python/topi --rcfile=/workspace/tests/lint/pylintrc

Using config file /workspace/tests/lint/pylintrc

************* Module topi.arm_cpu.conv2d_spatial_pack

topi/python/topi/arm_cpu/conv2d_spatial_pack.py:314: [R1706(consider-using-ternary), schedule_conv2d_spatial_pack_nhwc] Consider using ternary (oco if cfg['compat'].val else owo)

topi/python/topi/arm_cpu/conv2d_spatial_pack.py:331: [R1706(consider-using-ternary), schedule_conv2d_spatial_pack_nhwc] Consider using ternary (oco if cfg['compat'].val else owo)

--------------------------------------------------------------------

Your code has been rated at 10.00/10 (previous run: 10.00/10, -0.00)

@jackwish disable in current file is acceptable

Thanks @FrozenGene for your quick review, comments addressed.

@jackwish great work, thank you for pushing this PR through since it was opened. I'm glad the performance is on par on a small kernel. Do you mind checking tuned performance for e2e resnet18 and/or mobilenet? One thing to keep track of is the schedule space. If the schedule space for your implementation turns out to be very large, it might make tuning quite expensive. One thing to get around this is to use xgboost tuner, and limit the number of trials to something like 1000.

Other than that, I'd recommend adding more comments in the schedule code. Particularly in terms of decisions that affect compute declaration/schedule space definition. For instance, why did you list the different dimension reorderings etc. This will help future maintainers, or folks who'd want to write future schedule templates for ARM.

Hi @tmoreau89 , thanks for your comments!

Do you mind checking tuned performance for e2e resnet18 and/or mobilenet?

I'd like to provide e2e performance too, though it seems pretty hard before we have a dedicated depthwise NHWC schedule. I will tune some workloads from MobileNet.

One thing to keep track of is the schedule space.

The tuning space is a bit larger than NCHW, but still manageable. When evaluating the performance, I have a trail of 1000 and early stop of 500 for both NCHW and NHWC. The best result is obtained at about 500th iteration even with a sufficient large workload (image size 128 with input/output channel 128).

I'd recommend adding more comments in the schedule code.

For sure I agree with this. Most of the TVM schedule primitives are straightforward (to people who have experience), while the recording are basically for locality in general regarding different workloads.

@jackwish any updates on the e2e mobilenet tuning results? thanks!

@jackwish any updates on the e2e mobilenet tuning results? thanks!

@tmoreau89 I am very sorry for the delay, we have been working on enabling some models internally. I will update the data as soon as possible when available.

What is the status of the PR, is it ready to be merged?

@jackwish do you have spare time to continue to handle this? If we could support NHWC layout of depthwise convolution in this pr, it will be nice, because this will help users tune whole mobilenet when to use TFLite. I wish we could make it in ASAP.

@jackwish If you don't have time to benchmark end2end results compared with NCHW, I think it doesn't matter, we could support this functionality and continue to evolve. @tqchen how about your opinion of this?

Given the PR stands complete, i will merge it in for now, would be great if we can followup with a thread for benchmarks :) Thanks @jackwish @FrozenGene @tmoreau89 @snowolfhawk

Thanks @tqchen for your help of merging this PR. The long progress have been interrupted many times due to busy internal work, I am sorry for that and related todo things. Currently, I lose access to the development environment as I have left the position, but I may still be available to help to improve related schedules. One this to for this PR is that, the NHWC->NCHW layout transform needs to be disabled to tune with this NHWC schedule. But please don't rush for it as I have not tested it with latest code.
Thank you everyone.
Best regards


Add support for old-style -option options

Some commands– including many older programs, and most programs using Golang's builtin argument parser– use a single dash for long arguments, instead of two. I propose adding a new command special flag, _single, which would allow these commands to be supported. For example:
sh.echo(_single=True, test=True)  # prints "-test"

I think you're looking for the _long_prefix option http://amoffat.github.io/sh/sections/special_arguments.html#long-prefix

Ah, indeed! Ty. Does sh not do any collapsing of single letter options?
Like, does it turn -a -b -c into -abc?
On Jan 27, 2017 6:50 PM, "Andrew Moffat"<EMAIL_ADDRESS>wrote:

I think you're looking for the _long_prefix option
http://amoffat.github.io/sh/sections/special_arguments.html#long-prefix
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/amoffat/sh/issues/354#issuecomment-275805370, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvSraXnXgHijQbXgCFR76hO0l4ldEBvks5rWoLCgaJpZM4LvX5s
.

No, you'll have to handle that in your program


[Event Request] Codeunit 80 "Sales-Post" - OnBeforeInvoiceRoundingAmount

Hi, would it be possible to modify the OnBeforeInvoiceRoundingAmount event in codeunit 80 (Sales-Post) by adding the Currency parameter, like this:
    local procedure InvoiceRounding(SalesHeader: Record "Sales Header"; var SalesLine: Record "Sales Line"; UseTempData: Boolean; BiggestLineNo: Integer)
    var
        CustPostingGr: Record "Customer Posting Group";
        InvoiceRoundingAmount: Decimal;
    begin
        Currency.TestField("Invoice Rounding Precision");
        InvoiceRoundingAmount :=
          -Round(
            TotalSalesLine."Amount Including VAT" -
            Round(
              TotalSalesLine."Amount Including VAT", Currency."Invoice Rounding Precision", Currency.InvoiceRoundingDirection),
            Currency."Amount Rounding Precision");

        // Modified Event begin
        // OnBeforeInvoiceRoundingAmount(
        //   SalesHeader, TotalSalesLine."Amount Including VAT", UseTempData, InvoiceRoundingAmount, SuppressCommit, TotalSalesLine);
        OnBeforeInvoiceRoundingAmount(
            SalesHeader, TotalSalesLine."Amount Including VAT", UseTempData, InvoiceRoundingAmount, SuppressCommit, TotalSalesLine, Currency);
        // Modified Event end
        if InvoiceRoundingAmount <> 0 then begin
            CustPostingGr.Get(SalesHeader."Customer Posting Group");
            with SalesLine do begin
                Init;
                BiggestLineNo := BiggestLineNo + 10000;
                "System-Created Entry" := true;
                if UseTempData then begin
                    "Line No." := 0;
                    Type := Type::"G/L Account";
                    SetHideValidationDialog(true);
                end else begin
                    "Line No." := BiggestLineNo;
                    Validate(Type, Type::"G/L Account");
                end;
                Validate("No.", CustPostingGr.GetInvRoundingAccount());
                Validate(Quantity, 1);
                if IsCreditDocType then
                    Validate("Return Qty. to Receive", Quantity)
                else
                    Validate("Qty. to Ship", Quantity);
                if SalesHeader."Prices Including VAT" then
                    Validate("Unit Price", InvoiceRoundingAmount)
                else
                    Validate(
                      "Unit Price",
                      Round(
                        InvoiceRoundingAmount /
                        (1 + (1 - SalesHeader."VAT Base Discount %" / 100) * "VAT %" / 100),
                        Currency."Amount Rounding Precision"));
                Validate("Amount Including VAT", InvoiceRoundingAmount);
                "Line No." := BiggestLineNo;
                LastLineRetrieved := false;
                RoundingLineInserted := true;
                RoundingLineNo := "Line No.";
            end;
        end;

        OnAfterInvoiceRoundingAmount(SalesHeader, SalesLine, TotalSalesLine, UseTempData, InvoiceRoundingAmount, SuppressCommit);
    end;

    [IntegrationEvent(false, false)]
    local procedure OnBeforeInvoiceRoundingAmount(SalesHeader: Record "Sales Header"; TotalAmountIncludingVAT: Decimal; UseTempData: Boolean; var InvoiceRoundingAmount: Decimal; CommitIsSuppressed: Boolean; var TotalSalesLine: Record "Sales Line"; var Currency: Record Currency)
    begin
    end;

Thanks!

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 40862.


ironic: Use ironic setup from qa_crowbarsetup instead of batch

The batches were needed in the initial phase as there was no ironic specific
setup code in mkcloud/qa_crowbarsetup. Now it should be safe to drop the
batches and use the scripts to configure the environment for ironic.
this requires https://github.com/SUSE-Cloud/automation/pull/3227

This works for cloud 7 too?

@cmurphy I hope so :o) [but it was not tested there (yet)]


[SPARK-44282][CONNECT] Prepare DataType parsing for use in Spark Connect Scala Client

What changes were proposed in this pull request?
This PR prepares moving DataType parsing to sql/api. Basically it puts all DataType parsing functionality in a super class of regular parsing. We cannot move the parser just yet because that need to happen at the same time as DataType.
Why are the changes needed?
We want the Spark Connect Scala Client to use a restricted class path. DataType will be one of the shared classes, to move DataType we need to move DataType parsing.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Modified existing tests.

cc @amaliujia

Per my understanding, this PR creates a new interface for DataType parsing and also extract the parsing code. I guess the ultimate goal is we only move Datatype parsing (so not entire SQL grammar) to sql/api.
The idea LGTM. This is the best we can achieve for the parser relocation.
For the detailed interfaces, I am ok with the splitting so also LGTM. However I may not be the best person to comment the current way of constructing the new interface in this PR.

Merging for now.

late LGTM


Ensure toolbar buttons toggle widgets, and turn off when widgets are closed.

Objective
To design a scalable system to make it easy to implement new toolbar items that clean themselves up when closed or un-toggled.
Implementation

Added a new decorator that wraps toggle button callbacks that will automatically take care of constructing and deconstructing the widget when the respective toggle is pressed. It also ensures that when the "close" button is clicked on the respective widgets, the toolbar toggle is turned off automatically.
It works by ensuring that the decorated callback returns the control widget that has a cleanup property that is a method that safely removes it from the map and clean up any state. Then, the decorator modifies the cleanup property to also call the toggle_off method which turns off the respective toggle in the toolbar. Then, when the "close" button is clicked, the callback uses the modified version of the cleanup so that cleanup and toggle off both occur.

Backwards Incompatibility Notes

Two widgets can't be added at the same time. I think this is done for safety as the map.tool_control property is shared amongst widgets.
The whitebox toolbox doesn't turn off its own toggle when closed since that tool is implemented in a different repository.

Tested
Added unit tests to test cleanup behaviors and tested in Jupyter-Lab and Colab: https://colab.research.google.com/drive/1HHQomXhy-vS68qiMu6AOhDmrsLq6OZwe#scrollTo=6-4Mn2sAFNrO

@sufyanAbbasi Thanks a lot for the great improvement. I am on travel today. I might not be able to review this until tonight or tomorrow. If @naschmitz or @bengalin has time, please feel free to review and merge it.

@sufyanAbbasi – Currently reviewing the PR. How difficult would it be to update this PR to support multiple widgets being open at the same time? It's a common use case.

Currently reviewing the PR. How difficult would it be to update this PR to support multiple widgets being open at the same time? It's a common use case.

Very easy, just removed two lines in curry_callback to make it work! The only thing is that it may be unclear how certain widgets interact with each other while both are open, since some state is shared between components, however, I expect those interactions to be worked out later!


os: add func UserCacheDir() string

I've seen a dozen or so implementations of looking up the user's cache directory.
The latest is from @rsc in:
https://go-review.googlesource.com/c/go/+/68116/3/src/cmd/go/internal/cache/default.go
Which says:
// TODO(rsc): This code belongs somewhere else,
// like maybe ioutil.CacheDir or os.CacheDir.

Some examples of other implementations:
https://godoc.org/go4.org/xdgdir
https://godoc.org/camlistore.org/pkg/osutil#CacheDir
https://github.com/golang/crypto/blob/bd6f299fb381e4c3393d1c4b1f0b94f5e77650c8/acme/autocert/listener.go#L142
Consolidate into std?

Yes, I think we should do this. The windows docs I found said to use %localappdata% for caches, which none of those do. And I know of other copies in the dashboard scraper that (incorrectly) use $HOME/.cache on macOS, and so on. This definitely seems worth putting into the standard library.
Reading the actual definitions of ioutil.TempDir and os.TempDir, this looks closer to os.TempDir (return $TMPDIR) than ioutil.TempDir (make and return a fresh dir under $TMPDIR), so it should probably be os.CacheDir.
Probably should leave for Go 1.11 at this point.

What about a config/data variant? It's similarly tricky to get right.

The os/user package might be a good place for this, since it os/user would likely be a dependency anyway, to find the current user and their $HOME.

If we put it in os/user then it's harder for cmd/go to use it (it cannot depend on cgo for bootstrap). I don't believe os/user is necessary for XDG anyway - the spec very clear says $HOME not "the user's home directory".

Perhaps a silly question, but wouldn't this be a bit limited then? If a Go program is run outside a shell, $HOME would likely not be set.

@mvdan that's not very specific. What execution environment do you have in mind that does not set $HOME?

I was thinking anything that doesn't get run under a shell. I was hoping to demonstrate this with an empty docker container just running a Go program printing $HOME, but it seems like docker has a fallback of HOME=/ in that case.
Systemd also came to mind, but it seems to also take care of the variable on its own. And, on Linux, login programs apparently set it too, so opening a terminal without a shell still has $HOME present.
I thought that relying on this variable was more fragile than it actually is - my bad. Still curious if any reasonable execution environment wouldn't have it set.

It sounds like we should do this, as os.UserCacheDir. Per discussion with @bradfitz, let's run with $HOME (not using os/user) until we know a compelling reason to need the fallback.

It sounds like we should do this, as os.UserCacheDir. Per discussion with @bradfitz, let's run with $HOME (not using os/user) until we know a compelling reason to need the fallback.

If this goes in as os.UserCacheDir, then isn't it true that it can never fall back on os/user because os cannot depend on os/user?

If this goes in as os.UserCacheDir, then isn't it true that it can never fall back on os/user because os cannot depend on os/user?

There are shenanigans we can do with internal packages to make it work later if we wanted.

There are shenanigans we can do with internal packages to make it work later if we wanted.

I assume you mean something like creating an internal/os/user package that both os and os/user depend on.
Suppose you did that. On unix, os/user can get the user data one of two ways

Using a C standard library call. Russ objected to cgo earlier, so i assume this is out.
Reading /etc/password. This requires opening a file, which requires... os. So os still can't depend on internal/os/user because it creates a dependency loop. Now you either need to pull os.File into an internal package, or rewrite os/user using raw syscalls, or something else.

You're also basically pulling most of the os/user functionality into os, and I assume that there was a good reason to keep them separate in the first place.
It's probably not impossible to work around all these issues, but it seems like an awful lot of effort for something very small.
I don't really care either way whether UserCacheDir falls back on os/user or not (and Russ makes a good point that the spec doesn't say it has to). I just don't think you can defer the decision if you put it in os.

Well, cgo could be done if needed. And regarding 2), we could e.g. have the os package tell the internal package how to open files, passing an implementation of func (name string) (io.ReadCloser, error) in some init block. And then the os/user and/or internal package would use that to read /etc/password.
So while I'm not too worried about the trickery we could play to make it work later if we needed the current user, I'm also not worried where this function lives. I'll defer to Russ who seems content with package os.

As you will.

Why is it implemented now without returning an error?
Chaining is impossible anyway, since the return value must be checked for the in-band error condition of empty string. So might as well return a real error value where error conditions for not being able to reduce a cache directory can be communicated, so the user/developer/admin can fix them.
With the currently implemented API the caller needs to re-implement the same functionality again with error handling when he receives an empty string to be able to tell the user how he can fix the situation.

@nightlyone what about non-empty dir path, but the actual dir does not exist? Would the func also return an error in that case?

@bradfitz @rsc did you see @nightlyone's comment above? If we want to change the signature of this function, we should do that before the final 1.11 release.

Scratch my comment above; I just realised the error return parameter was added later in 50bd1c4d4eb4fac8ddeb5f063c099daccfb71b26.


Flying sprinting in creative mode on blocks can cause to slow down

Happens in latest version
https://github.com/Wilyicaro/Legacy-Minecraft/assets/39068731/7c294281-5685-4fca-b354-498a393fd65c

This has already been corrected, this slowness is caused by the "impact" when you descend, then it returns to normal flight speed, it is impossible to have greater precision due to the delta movement, which maintains this impact for a while, and which is not present in LE probably (I didn't look at the source code, so I can't say)


handbrake: add mainProgram

Description of changes
Add mainProgram in handbrake's meta, so that we can run it with nix run
CC maintainers @Anton-Latukha @wmertens

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Arguably, the fact that both the GUI and CLI programs are packaged means there isn't really a "main" program (one could argue either one should be the "main" one).
I'm not sure what the usual stance is on which one is "more canonical", if any.

I just think it's not friendly for users to rummage in /nix/store/xxx-handbrake/bin/ to find out how to run it, but I agree with that we need to discuss which is the main.


Intermittent test failure on systems::test::correct_transforms_when_no_children in bevy_transform

Bevy version
Any recent commit, like https://github.com/bevyengine/bevy/commit/fb74ca3d4644cf31afefe62ecd5e566794211290 or https://github.com/bevyengine/bevy/commit/a09dd034a2695dec504fbe45c4441cc459c9b08d
Relevant system information
Windows 11, stable 1.64.0
What you did
cargo run -p ci on my machine
What went wrong
     Running unittests src\lib.rs (target\debug\deps\bevy_transform-15b5c6f3f18cfb6b.exe)

running 5 tests
test systems::test::did_propagate_command_buffer ... ok
test systems::test::did_propagate ... ok
test systems::test::correct_children ... ok
test systems::test::correct_transforms_when_no_children ... FAILED
test systems::test::panic_when_hierarchy_cycle - should panic ... ok

failures:

---- systems::test::correct_transforms_when_no_children stdout ----
thread 'systems::test::correct_transforms_when_no_children' panicked at 'assertion failed: `(left == right)`
  left: `0v0`,
 right: `2v0`: Malformed hierarchy. This probably means that your hierarchy has been improperly maintained, or contains a cycle', crates\bevy_transform\src\systems.rs:69:9
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\std\src\panicking.rs:584
   1: core::panicking::panic_fmt
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\core\src\panicking.rs:142
   2: core::fmt::Arguments::new_v1
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\core\src\fmt\mod.rs:394
   3: core::panicking::assert_failed_inner
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\core\src\panicking.rs:218
   4: core::panicking::assert_failed<bevy_ecs::entity::Entity,bevy_ecs::entity::Entity>
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\core\src\panicking.rs:181
   5: bevy_transform::systems::propagate_recursive
             at .\src\systems.rs:69
   6: bevy_transform::systems::transform_propagate_system
             at .\src\systems.rs:38
   7: core::ops::function::FnMut::call_mut<void (*)(bevy_ecs::system::query::Query<tuple$<enum$<core::option::Option<tuple$<ref$<bevy_hierarchy::components::children::Children>,bevy_ecs::query::filter::Changed<bevy_hierarchy::components::children::Children> > >
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\core\src\ops\function.rs:164
   8: core::ops::function::impls::impl$3::call_mut<tuple$<bevy_ecs::system::query::Query<tuple$<enum$<core::option::Option<tuple$<ref$<bevy_hierarchy::components::children::Children>,bevy_ecs::query::filter::Changed<bevy_hierarchy::components::children::Childre
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\core\src\ops\function.rs:290
  ...
  29: bevy_transform::systems::test::correct_transforms_when_no_children
             at .\src\systems.rs:303
  30: bevy_transform::systems::test::correct_transforms_when_no_children::closure$0
             at .\src\systems.rs:278
  31: core::ops::function::FnOnce::call_once<bevy_transform::systems::test::correct_transforms_when_no_children::closure_env$0,tuple$<> >
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\core\src\ops\function.rs:248
  32: core::ops::function::FnOnce::call_once
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\core\src\ops\function.rs:248
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

failures:
    systems::test::correct_transforms_when_no_children

test result: FAILED. 4 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s

error: test failed, to rerun pass '-p bevy_transform --lib'
thread 'main' panicked at 'Please fix failing tests in output above.: command exited with non-zero code `cargo test --workspace --lib --bins --tests --benches`: 101', tools\ci\src\main.rs:103:14
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\std\src\panicking.rs:584
   1: core::panicking::panic_fmt
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\core\src\panicking.rs:142
   2: core::result::unwrap_failed
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\core\src\result.rs:1814
   3: enum$<core::result::Result<tuple$<>,xshell::error::Error>, 1,<PHONE_NUMBER>3709551615, Err>::expect<tuple$<>,xshell::error::Error>
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\core\src\result.rs:1064
   4: ci::main
             at .\tools\ci\src\main.rs:101
   5: core::ops::function::FnOnce::call_once<void (*)(),tuple$<> >
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\core\src\ops\function.rs:248
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: process didn't exit successfully: `target\debug\ci.exe` (exit code: 101)

Additional information
The same command almost always works ok (i.e., the test passes) if I run it immediately afterwards.

I think this is the same issue as https://github.com/bevyengine/bevy/issues/6036.

Interesting.  I've never had a failure in the did_propagate test, always in this one.  But the commonality of the assert, Malformed hierarchy. This probably means that your hierarchy has been improperly maintained, is a gun producing some smoke.

it's an issue with the panicking test. When the test panics it causes other test's systems not to run if they're on the thread that panics.

i think this may also affect systems::test::correct_children as i'm getting an intermittent failure there too.

closing for #5285


Improve router performance

Reduce allocation?
Try different route search methods.

Allocation reduced. Not to zero, but performance improved significantly.