add GitHub org to footer

Signed-off-by: Odyssey346<EMAIL_ADDRESS>Fixes
Issue Number:

What is the current behavior?
Doesn't have a clear link to the odysee frontend/backend source code.
What is the new behavior?
Now there's a link to the OdyseeTeam github.
Other information

PR Checklist

Toggle...
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting)
[ ] Refactoring (no functional changes)
[ ] Documentation changes
[ ] Other - Please describe:

Please check all that apply to this PR using "x":

[ ] I have checked that this PR is not a duplicate of an existing PR (open, closed or merged)
[ ] I added a line describing my change to CHANGELOG.md
[ ] I have checked that this PR does not introduce a breaking change
[ ] This PR introduces breaking changes and I have provided a detailed explanation below

ok, "GitHub" could be confusing in a way. What about "Source code"?


Deployment of Dependencies via ARM Template

currently, the dependencies of ADF (e.g. for custom activities) are not part of the generated ARM-template
it has to be ensured that the dependencies are also included in the final ARM-template

Dependencies are now copied to the ARM project and a PS Script is provided to automatically upload the dependencies during deployment


Custom CSS

Hello,
I'm trying to find how to customize CSS, I have located the files and .JS I could get what I wanted. But is there another way directly into the component or the modal is called to customize it?
I could put className and add what I needed to style the modal but I do not put classes for each element type of the background, the overall modal
If you have a solution I'm interested,
Best regards,

@artsx actually you can.
Just pass style prop to ModalDialog component and this styles will be applied as well.

@artsx sorry for the late response, but you can actually just write your own version of ModalDialog to do this, then your code would look like this...
<ModalContainer>
  <MyOwnModal/>
</ModalContainer>

Is there any way for me to customise styles for ModalContainer?
I want to lower the default opacity of 0.85.

For future reference for anyone who wants to customise the background color, instead expand into a ModalPortal and ModalBackground:
<ModalPortal>
  <ModalBackground zIndex={1000} backgroundColor='#00000040'>
    <ModalDialog>...</ModalDialog>
  </ModalBackground>
</ModalPortal>


Create a provisioning script that sets a cwd for a codebase.

So that we can have an implicit variables users can use in the ui.

Useless at this point.


Flocker failed after running for some time

Currently, I am using flocker ceph and mesos together. And I use flocker and ceph as the storage solution for my mesos cluster.
But it seems that flocker does not work stable enough. The command
docker run --volume-flocker=ceph -v xxx:/xxx some-image
may get blocked and show message Timed out waiting for dataset to mount. I checked the log of flocker and I still don't know the reason. The json format log is really hard to understand.
I have multi flocker agent running. And only one of them failed to run container with flocker as volume driver. Others work fine.

any luck?  i just setup flocker ceph and the one with the flocker-control doesn't work but the other two works fine.

@arthurtsang I don't use flocker any more. I use rbd-block-plugin now. It is not as flexible as flocker but it is quite stable. No control is needed.

this? https://github.com/yp-engineering/rbd-docker-plugin

@arthurtsang  Yep, but it still have some bugs when working with multi-machines. I am trying to fix it.


Video .pauseRecording() is not working

Steps to Reproduce
When Video Capturing

(cameraState as VideoCameraState).startRecording();
User action for pausing capture
(cameraState as VideoRecordingCameraState).pauseRecording(currentCapture!);

below my code
final CameraState cameraState;

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    ref.listen(videoRecordStateProvider, (prev, next) async {
      if (next == VideoRecordState.pause) {

        final currentCapture = await cameraState.captureState$.single;
        await (cameraState as VideoRecordingCameraState)
            .pauseRecording(currentCapture!);
      } else if (next == VideoRecordState.resume) {
        if (prev == VideoRecordState.idle) {
          (cameraState as VideoCameraState).startRecording();
        } else {
          logger.d('test');
          final currentCapture = await cameraState.captureState$.last;
          (cameraState as VideoRecordingCameraState)
              .resumeRecording(currentCapture!);
        }
      } else if (next == VideoRecordState.complete) {
        if (cameraState is VideoRecordingCameraState) {
          (cameraState as VideoRecordingCameraState).stopRecording();
        }
      }
    });
}

Expected results
pause video recording
Actual results
Don't pause video record and still recording video
About your device
Android, iOS all

Hi,
There is some missing informations.

provide a complete reproductible exemple so we can reproduce this error
what is your device ? (don't try this on an emulator)
how do you see the video is still recording ?

THank you


Connector for Socket Library that only reports Status through Callbacks

I am working in an environment that doesn't have access to Lua rocks and doesnt have access to luasockets.
The Library I have access to is a TcpSocket, found here.
https://q-syshelp.qsc.com/#Control_Scripting/Using_Lua_in_Q-Sys/TcpSocket.htm
The library is not blocking, and the environment does not allow me to block either.  I have access to a Timer library found here that utilizes callbacks.
https://q-syshelp.qsc.com/#Control_Scripting/Using_Lua_in_Q-Sys/Timer.htm?TocPath=Design%257CControl%2520Scripting%257CQ-SYS%2520Extensions%2520to%2520Lua%257C_____34
Can you see a way to create a connector with this?  Thank you,

That's a tough problem. This library is tightly coupling the runloop (and sockets) to the protocol implementation.
I did work on that to decouple them, see: #31 . It facilitates both blocking as well as non-blocking (== coroutine yielding) sockets. I completely rewrote the connectors there. But not sure it would be possible to handle callback based sockets.
You might want to have a look at https://luarocks.org/modules/fperrad/lua-mqtt which (afaik) only implements the protocol, not the sockets.

I was able to get it working but with some heavy lifting, and modification of the code.  I can post my fork of the project, and maybe it will spark some ideas.  Thank you!
From: Thijs Schreijer @.>
Sent: Wednesday, June 19, 2024 4:31 PM
To: xHasKx/luamqtt @.>
Cc: Schellhas, Gary @.>; Author @.>
Subject: Re: [xHasKx/luamqtt] Connector for Socket Library that only reports Status through Callbacks (Issue #47)
That's a tough problem. This library is tightly coupling the runloop (and sockets) to the protocol implementation.
I did work on that to decouple them, see: #31https://github.com/xHasKx/luamqtt/pull/31 . It facilitates both blocking as well as non-blocking (== coroutine yielding) sockets. I completely rewrote the connectors there. But not sure it would be possible to handle callback based sockets.
You might want to have a look at https://luarocks.org/modules/fperrad/lua-mqtt which (afaik) only implements the protocol, not the sockets.

Reply to this email directly, view it on GitHubhttps://github.com/xHasKx/luamqtt/issues/47#issuecomment-2179421446, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKJYLYJ5VDBBPRHVIKTHBUDZIHS6NAVCNFSM6AAAAABJSTOWHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZZGQZDCNBUGY.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>


django-cache-url deprecated notice

django-cache-url==3.0.0 is an actual dependency to control CACHES django variable anyways it has a deprecation notice
What I'm trying to achieve
Maintaining control over environment variables
Describe a proposed solution
Use simple os.environ.get function or django-environ
Other solutions I've tried and won't work
…
Screenshots or mockups

@IKarbowiak I think we can drop it in https://github.com/mirumee/saleor/pull/5043 if not already done? Can you check for me? Used by saleor.settings.CACHES and saleor.core.check_session_caching; we don't use sessions anymore–speaking of sessions, we should be able to drop django.contrib.sessions.middleware.SessionMiddleware I don't see any use anymore for it (apart... doing nothing whenever a GraphQL request is done 😉).
The CACHES were only used for sticky sessions behind load non-sticky balancers.

It's not done yet, I will drop it in #5043 :)


Add '19-'20 Santa Fe video

Add link to YouTube video for 2019-2020 Hyundai Santa Fe

Can you open your repo to pushes from PRs? I'm not able to add to the docs (hyundai/values.py)


ADD: Implement Auto-Labeling Workflow for GitHub

Is your feature request related to a problem? Please describe.
This workflow will automatically apply specific labels "gssoc-ext" and "hacktoberfest-accepted" to issues and pull requests
Additional context
Hey @notsoocool Please assign me this Task

Hey @notsoocool I have raised the PR

@samyak-aditya I will be reopening this issue if the PR doesn’t work or solve the mentioned problem. Additionally, I might revert the changes in the PR or remove the labels associated with it.


Add a repository description

I have just sent your project to the Awesome Vue list https://github.com/vuejs/awesome-vue/pull/349
so it would be good if you add a description to the repository. It will help people to find it.
My suggestion is:

A simple date picker component for Vue.js with inline mode support

I mentioned inline mode here because I did not find it in any other similar projects.

That's awesome! thanks @kkomelin
package.json description already exists but I've updated in 4ebeadc

Cool. Thanks.

@charliekassel Could you please to add the description from package.json to the repo description (at the top of the page https://github.com/charliekassel/vuejs-datepicker)?
Now it says:

No description or website provided.

Got it! OK, done.

I'am happy now ) Thanks.


Reorg FB auction. Move builder list to boost.

Reorganize FB auction folder to remove unnecessary nesting.
Moved updated builder list to under MEV-Boost  per request of @metachris

@metachris done


Add template for Node.js

Programming language
JavaScript and Typescript
Toolchains
Static Code Analysis a.k.a linter

eslint or gts or esprint (choose one)
Linting your TypeScript Codebase with ESLint

Code Formatter
prettier or gts
Update Dependencies

npm
node2nix (it's slow! both download and unpacking are not in parallel)

npm install --package-lock-only
node2nix --lock package-lock.json

https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/javascript.section.md

Security Audit
npm audit
npm audit

Others

bytenode - compile scripts into V8 bytecode
nodec - compile scripts into single executable (crosstool-ng needed for cross compilation ⚠)
tscc - as bundler and minifier

Draft
{
        javascript-node-env = {
          mkShell =
            { src ? ./.
            , lockfile ? src + "/package-lock.nix"
            , nixLock ? if hasSuffix ".nix" lockfile then lockfile else src + "/package-lock.nix"
            , yarnLock ? if hasSuffix ".lock" lockfile then lockfile else src + "/yarn.lock"
            , npmLock ? if hasSuffix ".json" lockfile then lockfile else src + "/package-lock.json"
            , pnpmLock ? if hasSuffix ".yaml" lockfile then lockfile else src + "/pnpm-lock.yaml"
            , nodejs ? pkgs.nodejs
            , ...
            }@attrs: with pkgs.lib; let
              buildNixLockCommand = lock: optionalString (isString lock) "anylock --as=nix --lockfile=${lock} --no-patch > ${nixLock}";
              mkNixLock = lock: runCommandLocal "package-lock.nix" { } (buildNixLockCommand lock);
            in
            if pathExists nixLock then
              ...
            else
              mkShell {
                packages = with pkgs.nodePackages; [ nodejs ]
                  ++ optional (hasInfix "slim" nodejs.name || lockfile == npmLock) npm
                  ++ optional (lockfile == yarnLock) yarn
                  ++ optional (lockfile == pnpmLock) pnpm
                  ++ [ anylock ];
                shellHook =
                  let
                    lockExists = lock: (lockfile == lock) && pathExists lock;
                    lockNotExists = lock: (lockfile == lock) && !(pathExists lock);
                    defaultLockfile =
                      if lockfile == npmLock then "package-lock.json" else
                      if lockfile == yarnLock then "yarn.lock" else
                      if lockfile == pnpmLock then "pnpm-lock.yaml" else
                      lockfile;
                    notExists-then = cmd: lock: optionalString (any lockNotExists (toList lock)) (cmd + "\n");
                    exists-then = cmd:
                      if isList cmd then optionalString (lockExists (last cmd)) ((concatStrings cmd) + defaultLockfile + "\n")
                      else lock: optionalString (lockExists lock) (cmd + defaultLockfile + "\n");
                  in
                  (notExists-then "npm install --package-lock-only" [ npmLock yarnLock pnpmLock ])
                    + (notExists-then "yarn import" yarnLock)
                    + (notExists-then "pnpm import" pnpmLock)
                    + (concatMapStrings (lock: exists-then [ "cp" lock ]) [ npmLock yarnLock pnpmLock ])
                    + (buildNixLockCommand defaultLockfile)
                    + (concatMapStrings (lock: exists-then "rm" lock) [ npmLock yarnLock pnpmLock ])
                    + ''git add ${lockfile}
                    echo -e "\nPlease run$(tput bold) nix develop $(tput sgr0)again."
                    exit
                  '';
              };
        };
}


Issue with Repository 'find' Method: Syntax Error Results in Unintended Data Query

Description
Using the Repository find method without providing the where keyword leads to unexpected behavior. Instead of throwing an error or returning no results, it retrieves all records of the specified entity.
My Code
const orders = await repo(Order).find({ customerId: entity.id });
await Promise.all(orders.map(async (order) => { await repo(Order).delete(order.id); }));

Note that the where keyword is missing in the find method.
The result was that all records of the Order entity were retrieved

Expected behavior
I expected the find method to either throw an error or return no results when the where keyword is omitted, rather than retrieving all records of the specified entity.
Additional context
This issue could potentially lead to unintended data deletion or manipulation (as in my tragic case..).
In this case I was using Javascript, I assume that using Typescript would point that issue when compiling the project. Anyway, I assume this is not the expected behavior.

I wouldn't change this. It's not the responsibility of the framework or orm or library to enforce how you use it. Sometimes you do need to get all records from a small dataset.

I agree - this is by design and consistent to other orm's
The use case of fetching all the rows exists

Although you can define such an error in your code:
Remult.onFind = (m, o) => {
  console.log(m, o)
  if (!o?.where)
    throw Error('no where');

}

By using the onFind handler that runs whenever anyone calls find


%%black will not format cell with magic in it

When formatting cells with magic in it, like
  [...]
  import matplotlib.pyplot as plt
  import seaborn as sns
  import pandas as pd
  %matplotlib inline

the %%black magic returns the error
cannot parse: 12:0 %matplotlib inline
This happens with any line that has a % sign to indicate magic.

Here's an alternative solution that solves this issue:
https://gist.github.com/MarvinT/a072aa992e977496974aaf492287b08c
and
https://marvint.github.io/Black-Jupyter/


Don't pass response stream directly into plugins

Temproary fix for early stream flushing. Maybe this should be done directly in got.
Fixes #67

Ahh, good idea, thanks. Might be worth opening an issue on the got repo, even though I think we should keep away from doing too much magic there.

do not flush data to plugin test is undone. https://travis-ci.org/kevva/download/jobs/70022305
==========
ava shouldn't exit with code 0 in this case.


Any Update on this Project

Hi
any update on this project ,as well can you provide camera that you test.

Yes, please provide some sample code...
client.addCamAddress({host: "ipaddress", port: 10088})
client.setCamCredentials({user:'admin', pass:'admin'})
client.openDirectCamSession({host: "ipaddress", port: 10088})
And how to get the IP address<- I use CamHi (IP address), but after that I get an undefined message (client.getStatus())


CGLS - needs clearer documentation on tolerances and potentially move tolerance stopping to a callback

Description
There is no mention of a default tolerance here: https://github.com/TomographicImaging/CIL/blob/eb254e0bae77e193f05acc03b6e94cd1c189e4ab/Wrappers/Python/cil/optimisation/algorithms/CGLS.py#L28-L47
We could also do this with a callback:
https://github.com/TomographicImaging/CIL/blob/eb254e0bae77e193f05acc03b6e94cd1c189e4ab/Wrappers/Python/cil/optimisation/algorithms/CGLS.py#L125-L135

So we can't move the tolerance check to a callback, as that is passed to the 'run' argument and not in the algorithm set-up.
The next question is: should early stopping, based on a tolerance be a default for CGLS or should it be optional and implemented with a callback, like for the rest of the algorithm class?

On one hand, I would not expect a default tolerance for an algorithm and would expect to run the number of iterations I asked it to run
On the other hand, CGLS  could converge in $n$ iterations for $A$ an $n\times n$ symmetric positive definite matrix and $b =Ax^$ for some unknown  $x^$. Running more iterations, in this case, would be a waste of computational effort.

As CGLS is the only algorithm with a default tolerance, my preference would be to remove it.
@jakobsj @paskino @epapoutsellis @gfardell - do you have any thoughts?

Good points.  The points you mention convince me that removing the tolerance is the best choice of action - to be more consistent with other algorithms, and because I think the tolerance is chosen somewhat arbitrarily in the very early days.  As a callback it will be better and more transparantly controlled by the user. We should just make sure that clear documentation is available on using callbacks and the users only seeing eg docstring is directed toward such.
If I recall the issue of converging in n iterations applies only in infinite precision computations, which we don't have, and also typically the matrix size would be so large that we wouldn't want to run as many iterations, and so the risk of wasting computational effort is negligible.


Update compatibility.rs

Update Cosmos-SDK version # for compatiblity so Hermes throws fewer errors with newer chains.

Closes:
Description
Just increases the range of supported cosmos-sdk versions.

For contributor use:

[x] Added a changelog entry, using unclog.
[ ] If applicable: Unit tests written, added test to CI.
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Updated relevant documentation (docs/) and code comments.
[x] Re-reviewed Files changed in the Github PR explorer.

Many thanks for opening a PR @faddat !

This PR overlaps with #1176. The other PR adds gaiad 5.0.5 (which uses SDK 0.42.9) in the CI and our CI passes against this version. But we can pre-emptively update the compatibility in the present PR and merge it.

many thanks for hermes!


Pixel Mode Collisions

Calculate collisions with collision-enabled entities and unwalkable tiles in pixel movement mode.

Hey @pmer would you like to take a crack at this? You wrote the code for tile mode and it turned out alright.

I am a little hesitant to pick this up since IIRC the tile mode code was thought to be complicated & I don't want to have to maintain the movement code going forward if this one comes out complicated too.

Maybe that is just motivation for me to write really good, easy to read code though, hahah.

Alright I'll try to work it while keeping the logic as similar as possible.
---- On Fri, 14 Apr 2017 19:55:29 -0700<EMAIL_ADDRESS>wrote ----
I am a little hesitant to pick this up since IIRC the tile mode code was thought to be complicated & I don't want to have to maintain the movement code going forward if this one comes out complicated too.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.

Working on by-pixel movement now in pixel_collisions branch.

@pmer I was originally going to have the edge of an entity collide with the very edge of a tile, but I realized that this makes it almost impossible for a 1-tile-wide entity to fit through a 1-tile wide area. An alternative is to collide the center of an entity with the edge of a tile, which I think is what we should do. That's what I'll develop for now.
Check out the pixel_collisions branch.

Here's some techniques other games have used:

Make players a few pixels smaller than a tile https://youtu.be/T08EidYtmT4?list=PL87EA9608EFE4BA83&t=716
Bump the player left or right a few pixels when running into a corner if that will get them unstuck https://youtu.be/OWEvtPKany0?list=PLeZSRkjynvkvkZR5MKYtouNvX_8p2SP5N&t=354

Making players a few pixels smaller than a tile can be generalized to allow entities to be arbitrarily wide, which will be useful in the future for things such as projectiles (arrows, spells, etc).

Maybe. Let's keep the current solution for the time being. This issue is almost ready to close.

Made new issues for those.

Unfortunately, it looks like we also need to overhaul tile mode collisions so they play nice with pixel mode entities.

We do a lot of calculations with the _prev_xy variable and calculations in other places that may be totally unneeded now that I added the tile.offset() function to find a tile by xy offset. We were working with pixels in tile mode to find collisions.

I was able to improve turn mode collision using the new tile.offset() function, and also fix an unnoticed collision failure bug. In order for tile mode entities to check for collisions with pixel mode entities, I need to write a function that lists which tiles the pixel mode entity is partially on. Tile mode entities will not move to a tile if any part of a pixel mode entity is occupying it.

In 5678aee739bb6dac18e81ddefd6ff8caf67bc5b4 tile mode entities can detect collisions with pixel mode entities. Now I only need to write pixel to pixel collisions.


Add graceful shutdown

In this mode Selenoid should stop serving new sessions and return after timeout.

Already stops on SIGTERM. Decided to not impement timeout feature.


Group1

Summary
A concise description of the changes being introduced. If you are submitting a PR for a
new quickstart please review the pre merge checklist section to validate this PR is ready for review.

Pre merge checklist

[ ] Did you check you NRQL syntax? - Does it work?
[ ] Did you check your dashboard image quality? -  Do they look good?
[ ] Did you check that your alerts actually work?
[ ] Did you include an InstallPlan and Documentation reference?
[ ] Did you check your descriptive content for voice, tone, spelling and grammar errors?
[ ] Did you attach images of your dashboards to the PR so we can see them working?

Screenshots
Attach images of any visual changes, such as a dashboard here.

Dashboard 1
1. Validate dashboard

[ ] Copy the *_validate.json to an account

If the accountId does not have data, find an account ID that does, replace the accountId properties with the new acountId

2. Compare against infra-dashboard

[ ] Find a infra dashboard with data, copy its providerAccountId
[ ] Add a providerAccountId to the filter on the migrated dashboard
[ ] Document differences

If changes are basic, make them directly to the template
If changes need to be applied to all dashboards: change script, re-migrate

3. Validate expected differences

[ ] All widget titles are sentence case
[ ] "Dashboard version x.y.z" is removed from markdown (if applicable)
[ ] inventory widget(s) are removed (if applicable)
[ ] event-feed widget(s) are removed (if applicable)

4. Take a screenshot

[ ] Take a screenshot of the dashboard

Make sure it does not include any PII

[ ] Add screenshot to dashboard directory as a *.png file

5. Add config.yml

[ ] Validate if a quickstarts/**/* directory/file exist

If not, move the one from the dashboard directory
If so, compare it to the one in the dashboard directory; make changes as necessary

6. Confirm contents of config.yml

[ ] Documentation link
[ ] Appropriate installPlan
[ ] Logo (Preferably a logo.svg file in the same directory)
[ ] Description (can be generic)
[ ] Reference to the dashboard(s)

7. Clean up

[ ] Remove the *_validate.json file from the dashboard directory
[ ] Remove the config.yml file from the dashboard directory
[ ] Clean up any *_validate dashboard that you created in NR1

8. Move the PR from draft

[ ] Create the actual PR, ensure all PR Pre merge checklist items are complete

Dashboard 2
1. Validate dashboard

[ ] Copy the *_validate.json to an account

If the accountId does not have data, find an account ID that does, replace the accountId properties with the new acountId

2. Compare against infra-dashboard

[ ] Find a infra dashboard with data, copy its providerAccountId
[ ] Add a providerAccountId to the filter on the migrated dashboard
[ ] Document differences

If changes are basic, make them directly to the template
If changes need to be applied to all dashboards: change script, re-migrate

3. Validate expected differences

[ ] All widget titles are sentence case
[ ] "Dashboard version x.y.z" is removed from markdown (if applicable)
[ ] inventory widget(s) are removed (if applicable)
[ ] event-feed widget(s) are removed (if applicable)

4. Take a screenshot

[ ] Take a screenshot of the dashboard

Make sure it does not include any PII

[ ] Add screenshot to dashboard directory as a *.png file

5. Add config.yml

[ ] Validate if a quickstarts/**/* directory/file exist

If not, move the one from the dashboard directory
If so, compare it to the one in the dashboard directory; make changes as necessary

6. Confirm contents of config.yml

[ ] Documentation link
[ ] Appropriate installPlan
[ ] Logo (Preferably a logo.svg file in the same directory)
[ ] Description (can be generic)
[ ] Reference to the dashboard(s)

7. Clean up

[ ] Remove the *_validate.json file from the dashboard directory
[ ] Remove the config.yml file from the dashboard directory
[ ] Clean up any *_validate dashboard that you created in NR1

8. Move the PR from draft

[ ] Create the actual PR, ensure all PR Pre merge checklist items are complete

Dashboard 3
1. Validate dashboard

[ ] Copy the *_validate.json to an account

If the accountId does not have data, find an account ID that does, replace the accountId properties with the new acountId

2. Compare against infra-dashboard

[ ] Find a infra dashboard with data, copy its providerAccountId
[ ] Add a providerAccountId to the filter on the migrated dashboard
[ ] Document differences

If changes are basic, make them directly to the template
If changes need to be applied to all dashboards: change script, re-migrate

3. Validate expected differences

[ ] All widget titles are sentence case
[ ] "Dashboard version x.y.z" is removed from markdown (if applicable)
[ ] inventory widget(s) are removed (if applicable)
[ ] event-feed widget(s) are removed (if applicable)

4. Take a screenshot

[ ] Take a screenshot of the dashboard

Make sure it does not include any PII

[ ] Add screenshot to dashboard directory as a *.png file

5. Add config.yml

[ ] Validate if a quickstarts/**/* directory/file exist

If not, move the one from the dashboard directory
If so, compare it to the one in the dashboard directory; make changes as necessary

6. Confirm contents of config.yml

[ ] Documentation link
[ ] Appropriate installPlan
[ ] Logo (Preferably a logo.svg file in the same directory)
[ ] Description (can be generic)
[ ] Reference to the dashboard(s)

7. Clean up

[ ] Remove the *_validate.json file from the dashboard directory
[ ] Remove the config.yml file from the dashboard directory
[ ] Clean up any *_validate dashboard that you created in NR1

8. Move the PR from draft

[ ] Create the actual PR, ensure all PR Pre merge checklist items are complete

Dashboard 4
1. Validate dashboard

[ ] Copy the *_validate.json to an account

If the accountId does not have data, find an account ID that does, replace the accountId properties with the new acountId

2. Compare against infra-dashboard

[ ] Find a infra dashboard with data, copy its providerAccountId
[ ] Add a providerAccountId to the filter on the migrated dashboard
[ ] Document differences

If changes are basic, make them directly to the template
If changes need to be applied to all dashboards: change script, re-migrate

3. Validate expected differences

[ ] All widget titles are sentence case
[ ] "Dashboard version x.y.z" is removed from markdown (if applicable)
[ ] inventory widget(s) are removed (if applicable)
[ ] event-feed widget(s) are removed (if applicable)

4. Take a screenshot

[ ] Take a screenshot of the dashboard

Make sure it does not include any PII

[ ] Add screenshot to dashboard directory as a *.png file

5. Add config.yml

[ ] Validate if a quickstarts/**/* directory/file exist

If not, move the one from the dashboard directory
If so, compare it to the one in the dashboard directory; make changes as necessary

6. Confirm contents of config.yml

[ ] Documentation link
[ ] Appropriate installPlan
[ ] Logo (Preferably a logo.svg file in the same directory)
[ ] Description (can be generic)
[ ] Reference to the dashboard(s)

7. Clean up

[ ] Remove the *_validate.json file from the dashboard directory
[ ] Remove the config.yml file from the dashboard directory
[ ] Clean up any *_validate dashboard that you created in NR1

8. Move the PR from draft

[ ] Create the actual PR, ensure all PR Pre merge checklist items are complete

Dashboard 5
1. Validate dashboard

[ ] Copy the *_validate.json to an account

If the accountId does not have data, find an account ID that does, replace the accountId properties with the new acountId

2. Compare against infra-dashboard

[ ] Find a infra dashboard with data, copy its providerAccountId
[ ] Add a providerAccountId to the filter on the migrated dashboard
[ ] Document differences

If changes are basic, make them directly to the template
If changes need to be applied to all dashboards: change script, re-migrate

3. Validate expected differences

[ ] All widget titles are sentence case
[ ] "Dashboard version x.y.z" is removed from markdown (if applicable)
[ ] inventory widget(s) are removed (if applicable)
[ ] event-feed widget(s) are removed (if applicable)

4. Take a screenshot

[ ] Take a screenshot of the dashboard

Make sure it does not include any PII

[ ] Add screenshot to dashboard directory as a *.png file

5. Add config.yml

[ ] Validate if a quickstarts/**/* directory/file exist

If not, move the one from the dashboard directory
If so, compare it to the one in the dashboard directory; make changes as necessary

6. Confirm contents of config.yml

[ ] Documentation link
[ ] Appropriate installPlan
[ ] Logo (Preferably a logo.svg file in the same directory)
[ ] Description (can be generic)
[ ] Reference to the dashboard(s)

7. Clean up

[ ] Remove the *_validate.json file from the dashboard directory
[ ] Remove the config.yml file from the dashboard directory
[ ] Clean up any *_validate dashboard that you created in NR1

8. Move the PR from draft

[ ] Create the actual PR, ensure all PR Pre merge checklist items are complete

Dashboard 6
1. Validate dashboard

[ ] Copy the *_validate.json to an account

If the accountId does not have data, find an account ID that does, replace the accountId properties with the new acountId

2. Compare against infra-dashboard

[ ] Find a infra dashboard with data, copy its providerAccountId
[ ] Add a providerAccountId to the filter on the migrated dashboard
[ ] Document differences

If changes are basic, make them directly to the template
If changes need to be applied to all dashboards: change script, re-migrate

3. Validate expected differences

[ ] All widget titles are sentence case
[ ] "Dashboard version x.y.z" is removed from markdown (if applicable)
[ ] inventory widget(s) are removed (if applicable)
[ ] event-feed widget(s) are removed (if applicable)

4. Take a screenshot

[ ] Take a screenshot of the dashboard

Make sure it does not include any PII

[ ] Add screenshot to dashboard directory as a *.png file

5. Add config.yml

[ ] Validate if a quickstarts/**/* directory/file exist

If not, move the one from the dashboard directory
If so, compare it to the one in the dashboard directory; make changes as necessary

6. Confirm contents of config.yml

[ ] Documentation link
[ ] Appropriate installPlan
[ ] Logo (Preferably a logo.svg file in the same directory)
[ ] Description (can be generic)
[ ] Reference to the dashboard(s)

7. Clean up

[ ] Remove the *_validate.json file from the dashboard directory
[ ] Remove the config.yml file from the dashboard directory
[ ] Clean up any *_validate dashboard that you created in NR1

8. Move the PR from draft

[ ] Create the actual PR, ensure all PR Pre merge checklist items are complete

Dashboard 7
1. Validate dashboard

[ ] Copy the *_validate.json to an account

If the accountId does not have data, find an account ID that does, replace the accountId properties with the new acountId

2. Compare against infra-dashboard

[ ] Find a infra dashboard with data, copy its providerAccountId
[ ] Add a providerAccountId to the filter on the migrated dashboard
[ ] Document differences

If changes are basic, make them directly to the template
If changes need to be applied to all dashboards: change script, re-migrate

3. Validate expected differences

[ ] All widget titles are sentence case
[ ] "Dashboard version x.y.z" is removed from markdown (if applicable)
[ ] inventory widget(s) are removed (if applicable)
[ ] event-feed widget(s) are removed (if applicable)

4. Take a screenshot

[ ] Take a screenshot of the dashboard

Make sure it does not include any PII

[ ] Add screenshot to dashboard directory as a *.png file

5. Add config.yml

[ ] Validate if a quickstarts/**/* directory/file exist

If not, move the one from the dashboard directory
If so, compare it to the one in the dashboard directory; make changes as necessary

6. Confirm contents of config.yml

[ ] Documentation link
[ ] Appropriate installPlan
[ ] Logo (Preferably a logo.svg file in the same directory)
[ ] Description (can be generic)
[ ] Reference to the dashboard(s)

7. Clean up

[ ] Remove the *_validate.json file from the dashboard directory
[ ] Remove the config.yml file from the dashboard directory
[ ] Clean up any *_validate dashboard that you created in NR1

8. Move the PR from draft

[ ] Create the actual PR, ensure all PR Pre merge checklist items are complete

Dashboard 8
1. Validate dashboard

[ ] Copy the *_validate.json to an account

If the accountId does not have data, find an account ID that does, replace the accountId properties with the new acountId

2. Compare against infra-dashboard

[ ] Find a infra dashboard with data, copy its providerAccountId
[ ] Add a providerAccountId to the filter on the migrated dashboard
[ ] Document differences

If changes are basic, make them directly to the template
If changes need to be applied to all dashboards: change script, re-migrate

3. Validate expected differences

[ ] All widget titles are sentence case
[ ] "Dashboard version x.y.z" is removed from markdown (if applicable)
[ ] inventory widget(s) are removed (if applicable)
[ ] event-feed widget(s) are removed (if applicable)

4. Take a screenshot

[ ] Take a screenshot of the dashboard

Make sure it does not include any PII

[ ] Add screenshot to dashboard directory as a *.png file

5. Add config.yml

[ ] Validate if a quickstarts/**/* directory/file exist

If not, move the one from the dashboard directory
If so, compare it to the one in the dashboard directory; make changes as necessary

6. Confirm contents of config.yml

[ ] Documentation link
[ ] Appropriate installPlan
[ ] Logo (Preferably a logo.svg file in the same directory)
[ ] Description (can be generic)
[ ] Reference to the dashboard(s)

7. Clean up

[ ] Remove the *_validate.json file from the dashboard directory
[ ] Remove the config.yml file from the dashboard directory
[ ] Clean up any *_validate dashboard that you created in NR1

8. Move the PR from draft

[ ] Create the actual PR, ensure all PR Pre merge checklist items are complete

Dashboard 9
1. Validate dashboard

[ ] Copy the *_validate.json to an account

If the accountId does not have data, find an account ID that does, replace the accountId properties with the new acountId

2. Compare against infra-dashboard

[ ] Find a infra dashboard with data, copy its providerAccountId
[ ] Add a providerAccountId to the filter on the migrated dashboard
[ ] Document differences

If changes are basic, make them directly to the template
If changes need to be applied to all dashboards: change script, re-migrate

3. Validate expected differences

[ ] All widget titles are sentence case
[ ] "Dashboard version x.y.z" is removed from markdown (if applicable)
[ ] inventory widget(s) are removed (if applicable)
[ ] event-feed widget(s) are removed (if applicable)

4. Take a screenshot

[ ] Take a screenshot of the dashboard

Make sure it does not include any PII

[ ] Add screenshot to dashboard directory as a *.png file

5. Add config.yml

[ ] Validate if a quickstarts/**/* directory/file exist

If not, move the one from the dashboard directory
If so, compare it to the one in the dashboard directory; make changes as necessary

6. Confirm contents of config.yml

[ ] Documentation link
[ ] Appropriate installPlan
[ ] Logo (Preferably a logo.svg file in the same directory)
[ ] Description (can be generic)
[ ] Reference to the dashboard(s)

7. Clean up

[ ] Remove the *_validate.json file from the dashboard directory
[ ] Remove the config.yml file from the dashboard directory
[ ] Clean up any *_validate dashboard that you created in NR1

8. Move the PR from draft

[ ] Create the actual PR, ensure all PR Pre merge checklist items are complete

Dashboard 10
1. Validate dashboard

[ ] Copy the *_validate.json to an account

If the accountId does not have data, find an account ID that does, replace the accountId properties with the new acountId

2. Compare against infra-dashboard

[ ] Find a infra dashboard with data, copy its providerAccountId
[ ] Add a providerAccountId to the filter on the migrated dashboard
[ ] Document differences

If changes are basic, make them directly to the template
If changes need to be applied to all dashboards: change script, re-migrate

3. Validate expected differences

[ ] All widget titles are sentence case
[ ] "Dashboard version x.y.z" is removed from markdown (if applicable)
[ ] inventory widget(s) are removed (if applicable)
[ ] event-feed widget(s) are removed (if applicable)

4. Take a screenshot

[ ] Take a screenshot of the dashboard

Make sure it does not include any PII

[ ] Add screenshot to dashboard directory as a *.png file

5. Add config.yml

[ ] Validate if a quickstarts/**/* directory/file exist

If not, move the one from the dashboard directory
If so, compare it to the one in the dashboard directory; make changes as necessary

6. Confirm contents of config.yml

[ ] Documentation link
[ ] Appropriate installPlan
[ ] Logo (Preferably a logo.svg file in the same directory)
[ ] Description (can be generic)
[ ] Reference to the dashboard(s)

7. Clean up

[ ] Remove the *_validate.json file from the dashboard directory
[ ] Remove the config.yml file from the dashboard directory
[ ] Clean up any *_validate dashboard that you created in NR1

8. Move the PR from draft

[ ] Create the actual PR, ensure all PR Pre merge checklist items are complete

Dashboard 2 - aws-api-gateway-apis
Dashboard
There was not a previous existing newrelic-quickstart for api-gateway. I had to modify the json template as the migration script did not include the limit property in nrqlQueries which was required to render a vizco bullet widget.
Quickstart
There was a newrelic-quickstart subdir already: newrelic-quickstart/quickstarts/aws/aws-api-gateway/. Because of that, I created a separate subdirectory newrelic-quickstart/quickstarts/aws/aws-api-gateway-apis/ which is more correct as we have two dashboard templates for api-gateway.
I made sure the config.yml for api-gateway-apis and api-gateway-stages called out the specific differences between the 2 dashboards.

Dashboard 3 - aws-api-gateway-stages
Dashboard
There was not a previous existing newrelic-quickstart for api-gateway-stages so I created that.
Quickstart
There was a newrelic-quickstart subdir already at newrelic-quickstart/quickstarts/aws/aws-api-gateway/. Because of that, I created a separate subdirectory newrelic-quickstart/quickstarts/aws/aws-api-gateway-stages/ which is more correct as we have two dashboard templates for api-gateway.
I made sure the config.yml for api-gateway-apis and api-gateway-stages called out the specific differences between the 2 dashboards.

Dashboard 4 - aws-autoscaling
Dashboard
There was no previously existing subdir for api-autoscaling so I created a subdir for the migrated template at newrelic-quickstart/dashboards/aws-autoscaling/.
I did have to modify 2 queries of the migrated json template as the migration script had removed 'and' from GroupStandbyInstances.
Quickstart
There was a newrelic-quickstart subdir already: newrelic-quickstart/quickstarts/aws/aws-auto-scaling/. Because of that, I created a separate subdirectory newrelic-quickstart/quickstarts/aws/aws-autoscaling/.
One difference between the two config.ymls is that the installPlans for the existing aws auto scaling was for aws-infrastructure-monitoring. According to the docs, it does say that aws-cloudwatch-metric-streams can and should be used.

Dashboard 5 - aws-billing-budgets
Dashboard
There was is a previous existing aws-billing subdir with json template
Quickstart
There was a newrelic-quickstart subdir already: newrelic-quickstart/quickstarts/aws/aws-billing/. Because of that, I created a separate subdirectory newrelic-quickstart/quickstarts/aws/aws-billing-budgets-costs/. The config.yml I added to this subdir points to both aws-billing-budgets and aws-billing-costs

Dashboard 6 - aws-billing-costs
Dashboard
There was is a previous existing aws-billing subdir with json template, the existing template aws-billing.json does have the 2 queries that are separated out on the migrated aws-billings-cost.json
Differences between existing and migrated template:
There was no previously existing aws-billing-costs specific json. Though the the queries included on this template were on the aws-billing template that already existed in quickstarts.
Quickstart
There was a newrelic-quickstart subdir already: newrelic-quickstart/quickstarts/aws/aws-billing/. Because of that, I created a separate subdirectory newrelic-quickstart/quickstarts/aws/aws-billing-budgets-costs/. The config.yml I added to this subdir points to both aws-billing-budgets and aws-billing-costs

Dashboard 6 - aws-appsync
Dashboard
There was no previous existing quickstart template. So subdir dashboards/aws-appsync/ is now home to appsync json.
This template does NOT have a markdown informational widget. We may want to add that.
Quickstart
There was a newrelic-quickstart/aws/aws-appsync subdir already. So I created a separate subdirectory until we can compare and decide which one will remain: newrelic-quickstart/quickstarts/aws/aws-appsync-migrated/.
Differences between existing and migrated config.yml:
The config.yml installPlans was updated to aws-cloudwatch-metric-streams

Dashboard 8 - aws-athena
Dashboard
There was a previously existing quickstart template at dashboards/athena/. The migrated subdir dashboards/aws-athena/ is home to aws-athena json.
This template does NOT have a markdown informational widget. We may want to add that.
Differences between existing and migrated templates:
All the queries in both templates are different. We will need to compare between existing and migrated templates.
Quickstart
There was a newrelic-quickstart/aws/amazon-athena subdir already. So I created a separate subdirectory at newrelic-quickstart/aws/aws-athena until we can compare and decide which one will remain.
Differences between existing and migrated config.yml:
The config.yml installPlans was updated to aws-cloudwatch-metric-streams

Dashboard 8 - aws-cloudfront
There were a number of issues with this migration - the migration script failed and somehow overwrote the file already in place within newrelic-quickstarts/aws-cloudfront, I replaced this file and created a new dashboard subdirectory.
Another issue is that I could not find an account using the infra-dashboard-templates json to compare against.
Dashboard
There was a previously existing quickstart template at dashboards/aws-cloudfront/. The migrated subdir dashboards/aws-cloudfront-migrated/ is home to aws-cloudfront json.
Quickstart
There was a previously existing quickstart config at newrelic-quickstart/aws/aws-cloudfront. I created a separate subdirectory at newrelic-quickstart/aws/aws-cloudfront-migrated until we can compare and decide which one will remain.
Differences between existing and migrated config.yml:
The migrated config.yml installPlans was updated to aws-cloudwatch-metric-streams. The description was on a single line, i separated it out so it follows the formatting in other config.ymls.

aws-cloudtrail
Was not included as the template is not migrated to dimensional metrics yet.


TimeoutError when fetching records in build action

The earliest know case can be found in the "Run tests" step here.

This was fixed in #308


Reintrodcute python 3.5 compatibility with attr package

Change attr.dataclass to attr.s
Add test for previously untested  ModelParams

This fixes the build as well :)


Generate native image for engine-runner

Pull Request Description
This PR adds a possibility to generate native-image for engine-runner.
Note that due to on-demand loading of stdlib, programs that make use of it are currently not yet supported
(that will be resolved at a later point).
The purpose of this PR is only to make sure that we can generate a bare minimum runner because due to lack TruffleBoundaries or misconfiguration in reflection config, this can get broken very easily.
To generate a native image simply execute:
sbt> engine-runner-native/buildNativeImage
... (wait a few minutes)

The executable is called runner and can be tested via a simple test that is in the resources. To illustrate the benefits
see the timings difference between the non-native and native one:
>time built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/bin/enso --no-ir-caches --in-project test/Tests/ --run engine/runner-native/src/test/resources/Factorial.enso
720

real	0m4.503s
user	0m9.248s
sys	0m1.494s
> time ./runner --run engine/runner-native/src/test/resources/Factorial.enso
720

real	0m0.176s
user	0m0.042s
sys	0m0.038s

Important Notes
Notice that due to a bug in GraalVM, which is already fixed in 22.x, and us still being on 21.x for the time being, I had to add a workaround to our sbt build to build a different fat jar for native image. To workaround it I had to exclude sqlite jar. Hence native image task is on engine-runner-native and not on engine-runner.
Will need to add the above command to CI.
Checklist
Please include the following checklist in your PR:

[ ] The documentation has been updated if necessary.
[x] All code conforms to the
Scala,
Java,
and
Rust
style guides.
All code has been tested:

[x] Unit tests have been written where possible.
[ ] If GUI codebase was changed: Enso GUI was tested when built using BOTH
./run ide dist and ./run ide watch.

What's the sbt command to invoke the build?

The build says:
Use the option --initialize-at-run-time=io.methvin.watchservice.jna.CarbonAPI to explicitly request delayed initialization of this class.

where shall I put the option?

If the b4292d3 commit is combined with  #3696 then the native image compiled runtime can execute:
fac n =
    facacc n v = if n <= 1 then v else @Tail_Call facacc n-1 n*v

    res = facacc n 1
    res

main =
    fac 6

and print result. Useful when testing the final runner executable in CI, I think.

Updated description and it's ready for final review. Will ping @mwu-tow separately to get that into our CI

All the added @TruffleBoundary annotations are great to have. With them placed at proper places we can start measuring the performance for real. Btw. did you try to compare benchmarks? @TruffleBoundary may have some effect (negative as well as positive).

I will be checking that today

Run benchmarks - results were good, if not better


Add tests for latest regressions

Description
Add two test cases to account for the regressions that were fixed in https://github.com/onflow/flow-emulator/pull/398.

Tests for coverage reporting
Tests for deployment of common contracts

For contributor use:

[x] Targeted PR against master branch
[x] Linked to GitHub issue with discussion and accepted design OR link to spec that describes this work
[x] Code follows the standards mentioned here
[x] Updated relevant documentation
[x] Re-reviewed Files changed in the GitHub PR explorer
[x] Added appropriate labels

Codecov Report

Merging #416 (a99f877) into master (b85f4ab) will increase coverage by 1.12%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #416      +/-   ##
==========================================
+ Coverage   51.77%   52.90%   +1.12%
==========================================
  Files          27       27
  Lines        3372     3372
==========================================
+ Hits         1746     1784      +38
+ Misses       1481     1435      -46
- Partials      145      153       +8

Flag
Coverage Δ

unittests
52.90% <ø> (+1.12%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 3 files with indirect coverage changes


bug: sgmv_shrink does not support CUDA graph tracing

When attempting to run the sgmv_shrink kernel as part of a CUDA graph, an error will occur. Digging into it further, it seems that some of the operations performed in the kernel are not supported by CUDA graphs. I haven't dug too deeply into it, but going through the code, I wonder if it might be related to memcpy or other (presumably) blocking calls.
Example:
torch.cuda.synchronize(device)

graph = torch.cuda.CUDAGraph()
with torch.cuda.graph(graph, pool=None):
    sgmv_shrink(...)

torch.cuda.synchronize(device)

Thanks for the great work on this project! We're huge fans at LoRAX.

Thanks! We'll investigate.

I think the issue (or at least a part of it) stems from the fact that the current Torch stream is not used. This would prevent graph capture.

Thanks for the suggestion, @Yard1! I'm also running into this issue with the legacy cutlass kernel (still needed for expand). I tried specifying the kernel to use the current stream from PyTorch, but that doesn't seem to have resolved the issue. Let me know if I'm missing something:
diff --git a/server/punica_kernels/punica_kernels/sgmv/sgmv_cutlass.cuh b/server/punica_kernels/punica_kernels/sgmv/sgmv_cutlass.cuh
index 69e180c..1747ce6 100644
--- a/server/punica_kernels/punica_kernels/sgmv/sgmv_cutlass.cuh
+++ b/server/punica_kernels/punica_kernels/sgmv/sgmv_cutlass.cuh
@@ -1,4 +1,5 @@
 #pragma once
+#include <ATen/cuda/CUDAContext.h>
 #include <cuda_bf16.h>
 #include <cuda_fp16.h>
 #include <cuda_runtime.h>
@@ -63,6 +64,7 @@ template <typename DType>
 bool sgmv(DType *y, DType *x, DType **w, int32_t *s_start, int32_t *s_end,
           void *tmp_d, int num_problems, int d_in, int d_out, int layer_idx) {
   using cutlass_t = typename cutlass_dtype<DType>::type;
+  const cudaStream_t stream = at::cuda::getCurrentCUDAStream();

   auto ptr_Y = alloc_from_buf<cutlass_t *>(&tmp_d, num_problems);
   auto ptr_X = alloc_from_buf<cutlass_t *>(&tmp_d, num_problems);
@@ -73,7 +75,7 @@ bool sgmv(DType *y, DType *x, DType **w, int32_t *s_start, int32_t *s_end,
   auto all_problems =
       alloc_from_buf<cutlass::gemm::GemmCoord>(&tmp_d, num_problems);

-  precompute_sgmv_args<<<num_problems, 1>>>(
+  precompute_sgmv_args<<<num_problems, 1, 0, stream>>>(
       all_problems, ptr_Y, ptr_X, ptr_W, ld_Y, ld_X, ld_W, (cutlass_t *)y,
       (cutlass_t *)x, (cutlass_t **)w, s_start, s_end, d_in, d_out, layer_idx);

@@ -112,7 +114,7 @@ bool sgmv(DType *y, DType *x, DType **w, int32_t *s_start, int32_t *s_end,
                                          ptr_Y, ld_X, ld_W, ld_Y, ld_Y);

     GemmGrouped gemm;
-    auto status = gemm.initialize(args);
+    auto status = gemm.initialize(args, nullptr, stream);
     if (status != cutlass::Status::kSuccess) {
       fprintf(stderr, "sgmv_cutlass gemm.initialize failed: %s\n",
               cutlassGetStatusString(status));
@@ -157,7 +159,7 @@ bool sgmv(DType *y, DType *x, DType **w, int32_t *s_start, int32_t *s_end,
                                          ptr_Y, ld_X, ld_W, ld_Y, ld_Y);

     GemmGrouped gemm;
-    auto status = gemm.initialize(args);
+    auto status = gemm.initialize(args, nullptr, stream);
     if (status != cutlass::Status::kSuccess) {
       fprintf(stderr, "sgmv_cutlass gemm.initialize failed: %s\n",
               cutlassGetStatusString(status));

Really nice catch @Yard1 .
@tgaddair Can you try https://github.com/punica-ai/punica/commit/b5f5e1a3aa46702c843e8815acf8f654a242e109 ? pytest -v -k cuda_graph. This commit fixes the stream issue. But I think we need more work to make cuda graph run smoothly on SGMV, because the input is very dynamic. Maybe related: https://pytorch.org/docs/master/notes/cuda.html#partial-network-capture

Thanks for the quick fix, @abcdabcd987! I can verify that the changes in your commit appears to have resolved the issue (graph can trace and replay) for both the shrink and cutlass sgmv kernels. One thing to note, though, is that the cutlass kernel still raises an error for me if run with CUDA_LAUNCH_BLOCKING=1 (though shrink no longer fails). I was setting this for debugging, but since I don't use it in production, this should hopefully not be an issue, but worth calling out.
Regarding the dynamic input: my plan there was to set the segment index tensor to have shape [batch_size + 1] instead of [num_segments + 1], and pad the tensor with -1. Then make a small change within the kernel to short-circuit if the segment value is -1. That way we always run with a fixed batch size, but potentially variable number of segments. Let me know if you see any obvious issues with that approach.

Hey @abcdabcd987, through further testing, the shrink kernel holds up well, but it looks like there are in fact some issues with the cutlass sgmv kernel. I'm trying to put together a minimal repro of the issue, but it looks like under certain situations the sgmv cutlass kernel will be a no-op when running during graph replay, while the same inputs run outside the graph will work as expected. This seems to have something to do with interaction between other operations in the graph, as I haven't been able to repro it using a graph that only consists of the sgmv ops.

I can confirm that CUDA_LAUNCH_BLOCKING=1 pytest -v -k cuda_graph can trigger the issue. The problem comes from that we have a kernel, precompute_sgmv_args, that computes input arguments for cutlass. And sadly I forgot to add stream to it in my previous commit.
Can you try https://github.com/punica-ai/punica/commit/07a40b9d30e98d88963e8a7e140120a25ac0d518 ? CUDA_LAUNCH_BLOCKING=1 pytest -v -k cuda_graph looks good this time.

Ah, that fixed it! Thanks @abcdabcd987. I can confirm that both CUDA_LAUNCH_BLOCKING=1 and replay issues are resolved with these changes. I'll close out this issue!

Awesome!


Optimize build options per RPi model

We currently have a one size fits all default build option  in easyinstall.sh  (clang++-11 with one thread) which always works on any RPi, but isn't optimized for build time.
For instance, on RPi 3 or 4, using 2 or 3 threads cuts build time by 1/2 or 2/3. But on a Zero 2 W, we can only use one thread because otherwise the system runs out of memory.
Another example, the Zero W, gcc is notably faster than clang. Building with clang takes 4h at the time of writing, while gcc takes 3.5h.
This ticket is for exploring the potential of detecting particular models or capabilities and dynamically choose the default options.

One solution would be to inspect /proc/cpuinfo
$ cat /proc/cpuinfo
processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2835
Revision        : 9000c1
Serial          : 00000000f14495c9
Model           : Raspberry Pi Zero W Rev 1.1

We already had a simple solution (only) taking the number of processors into account. It used the cpuinfocommand in order to determine the number of CPU cores. Directly using(parsing /proc/* is not the best choice if there are regular commands providing the desired information.
If there are platforms where clang is slower than gcc it is very likely due to swapping because of not enough physical memory.
Just adding a note to the Wiki may be best. One can simple configure the MAKEFLAGS environment variable with the number of course to use. On my Pi 4 I just set in my profile:
export MAKEFLAGS=-j4

This is a very simple approach. Spending time on more complicated solutions, which can never yield better results than just setting MAKEFLAGS once for the respective platform. may not be such a good idea, considering that there are still several open (bug) tickets.

The problem with using all available CPU cores, is that there are devices with multiple cores but too little memory to compile multi-threaded. The currently known example is the Zero 2 W, which has 4 cores but only 512MB RAM. Use any more than one thread and the system freezes up with both gcc and clang. Other such models may be manufactured or discovered in the future.
Long compile times when updating is continuously reported as a pain point by our users. I want to do something to improve the situation for them.

@rdmark Any chance to resolve this issue? If you want to add a not too complicated rule of how many cores to use when compiling I suggest to set -j to the availabile physical RAM in MB divided by 512, but never to set it higher than the actual number of cores. This results in one more parallel process for each 512 MB of physical memory, as long as there are enough cores.

@uweseimet I like this idea. It seems scalable and safe. I don't have access to any RPis right now to test on real devices (being shipped across the Pacific ocean) but I can do the theoretical update to easyinstall.sh

PR in https://github.com/PiSCSI/piscsi/pull/1239


Operability with other Cordova plugins which handle push notifications

I am one of the maintainers of Intercom's Cordova plugin. By far the most common issue that our users encounter is that when they install phonegap-plugin-push, push notifications don't work correctly. On Android this leads to duplicate notifications and on iOS it can lead to Intercom not opening notifications.
Our solution to date (which is not idea) has been to provide a fork of phonegap-plugin-push that works around these issues (Available here: https://github.com/intercom/phonegap-plugin-push).
However, I believe that it would be in the interest of the community for phonegap-plugin-push to be capable of existing alongside other plugins that use push notifications without interference. This issue is not exclusive to Intercom but applies to all other plugins that handle push notifications.
Expected Behaviour
Push plugin should co-exist with other plugins which use push notifications.
Actual Behaviour
Installing phonegap-plugin-push alongside other plugins that use push leads to duplicate push notifications and other unexpected behaviour.
Reproduce Scenario (including but not limited to)
Steps to Reproduce

Install phonegap-plugin-push.
Install cordova-plugin-intercom.
Receive an Android push notification from Intercom. It will be displayed twice (built by both plugins).

Platform and Version (eg. Android 5.0 or iOS 9.2.1)
Any
(Android) What device vendor (e.g. Samsung, HTC, Sony...)
Any
Cordova CLI version and cordova platform version
Any
Plugin version
Any
Sample Push Data Payload
Sample Code that illustrates the problem
The changes that were necessary to make in order to work around the issue can be seen here.
Logs taken while reproducing problem
N/A
Please let me know if I can provide any more detail on the issue described here.

Just to add a little more context here: The underlying issue is that phonegap-plugin-push assumes it is responsible for handling all push notifications received by the app.

@jtreanor yeah, I'd be happy to have interoperability between the two plugins and since you know your plugin better than I do pull requests are always welcome.
One recent change which was released as part of 1.10.0 was for the push plugin to only show the notification if the sender ID matched the one set at init time. See: https://github.com/phonegap/phonegap-plugin-push/commit/a0d51e54aac39b8c58e4c67080f174c0228947c9
Does this help work around your issue?

Thanks @macdonst,
That is certainly a good start, though I suspect it will not solve the full issue. I will dig a little deeper into this to see what solutions I can come up with and open a PR with some changes.

@jtreanor what is the root cause of the double notifications in the shade? I feel if the push plugin and the intercom plugin are using different sender ID's we should be most of the way there.

@macdonst The duplicate push notifications were caused by onMessageReceived in GCMIntentService as you have suggested. However, due to the fact that there can only be one GcmLisenterService in an app, it must be passed to Intercom from there rather than just ignored.
Additionally, it is quite common for our customers to use the same sender ID for Intercom and the push plugin. We could recommend against this but the problem would resurface when using FCM (since its only possible to use one google-services.json file).
I will ask my colleague who is more familiar with this to clarify the detail tomorrow. There is some detail about how Intercom interacts with other push providers on Android here.
My current thought is that phonegap-plugin-push could be extended so that other plugins could provide some sort of callback to it for handling their notifications.

@jtreanor the simplest and hackiest thing to do would be to implement 'intercomPushClient.isIntercomPush(message)inside ofonMessageReceivedofGCMIntentService`. There is probably some key we can depend on in the message object to identify the incoming push as an Intercom one.
The way that you suggest leaves us open for expansion as we could add a way for other plugins to register push handlers with the push plugin. Then let the handler determine if the message should be acted upon or passed on to the default push handling.
Regardless, we should talk more about supporting your use case.

@macdonst Yeah, that certainly would be the most straightforward. It is easy to identify an Intercom push.
I experiment with a few options and loop you in on what I come up with.

@jtreanor sounds good, happy to add it to the plugin.

I've done quite a bit of digging here and have managed to work around the conflict on our side. For you interest, the changes are here.
Thanks for being welcoming and helpful in this issue.

@jtreanor alright cool. Glad you worked around it but happy to make changes on this side if you change your mind. I saw in the commit you are using reflection on Android which is too bad you had to go that route.

@macdonst We are not using reflection in the solution (though we do use Class.forName()). I will continue to keep the plugin in mind in future to see if there are any desirable changes to be made.

@jtreanor my mistake, I only looked quickly while on vacation last week 😎


python_submit

Good Job!!!   @gravityrb
Python homework:

Total questions: 108
Correct answers: 1
Score: 0%

Good Job!!!   @gravityrb
Python homework:

Total questions: 108
Correct answers: 0
Score: 0%

Good Job!!!   @gravityrb
Python homework:

Total questions: 108
Correct answers: 0
Score: 0%

Good Job!!!   @gravityrb
Python homework:

Total questions: 108
Correct answers: 0
Score: 0%


Foreign Keys are not created for 1:1 associations

PHP Version
PHP 8
Shopware Version
<IP_ADDRESS>
Expected behaviour
When creating an entity with a 1:1 relation, i would expect the command dal:create:schema to create this association. Given this snippet:
`
return new FieldCollection([
(new IdField('id', 'id'))->addFlags(new PrimaryKey(), new Required()),
(new LongTextField('comment', 'name'))->addFlags(new Required()),

(new FkField('order_id', 'orderId', OrderDefinition::class))->addFlags(new Required()),
new OneToOneAssociationField('order', 'order_id', 'id', OrderDefinition::class, false),

        new CreatedAtField(),
        new UpdatedAtField()
    ]);

`
Actual behaviour
This will be created instead:
CREATE TABLEorder_refund(    idBINARY(16) NOT NULL,    commentLONGTEXT NOT NULL,    order_idBINARY(16) NOT NULL,    created_atDATETIME(3) NOT NULL,    updated_at DATETIME(3) NULL,     PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
How to reproduce
Create an entity with a 1:1 relation.

This ticket has been created upon this SO-Question: https://stackoverflow.com/questions/70287163/the-command-dalcreateschema-does-not-create-foreign-keys/71005337#71005337

Duplicate of #2222


Notify user of second device using SA F9.

From j1939-84 created by battjt: battjt/j1939-84#928
Provide notice for extraneous queries from SA F9,
When extraneous queries, not sent by the SAE J1939-84 software are observed:

Print a time stamped message in the log:
HH:MM:SS.SSSS ccccccF9 [n] XX XX XX XX XX XX XX
WARN: Unexpected Service Tool Message from SA F9 observed. Test results uncertain. False failures are possible.
Add a pop up message for the UI
Unexpected Service Tool Query from SA F9 observed. Test results uncertain. False failures are possible.
Should a 2nd Query appear while this Pop-up is displayed, a 2nd Popup will not be displayed.
This popup shall not interfere with the user interface pop ups, and allow the user to respond to them.

After II.B add the following footnote.
[xx] Implementors are encouraged to detect overlapping queries created by on-board devices using the test tool’s F9h address. Notices to the user through the implementor’s user interface, and messages in the test log of these occurrences are recommended.

I suggest that we word this as an invalid test, not a warning.  A second tool makes the test invalid; all DS transport protocol will be effected.  It's not just overlapping queries.


Add ability to exclude messages by regex

This adds the ability to exclude console messages by regex on a plugin config level and per-test level.
The implementation is pretty hacky since it uses a global variable global.PROTRACTOR_CONSOLE_EXCLUDE_REGEX to store per-test regexes. The only other alternative I could think of is to patch jasmine and protractor to propagate test-specific metadata. Any thoughts on this? 💬
Fixes #5

Thanks for taking a stab at this @chrismwendt! Protractor allows for plugins to pass options: https://github.com/angular/protractor/blob/master/docs/plugins.md#using-plugins. Perhaps that would work better than the global variable?

Protractor plugin options are evaluated once at the beginning of an entire run, right? That could work if a massive dictionary (test name -> regex) is provided up front, but has the downside of requiring the regex for a test to be specified far from the test definition. That would still have the downside of requiring the test name to be specified twice (once in the test definition and once in the dictionary).
Another hacky approach could be to embed the regex (if there is one) in the test name itself (e.g. it('should emit a console error /some error to be ignored/', function() { ... })) and extract what's between the /s in the plugin.

Maybe a more generic "filter" option to pass a function is more appropriate then. It would essentially give you the power to do whatever you want.


spelling mistake in example ReadMe

https://github.com/alibaba/Pai-Megatron-Patch/blob/main/examples/qwen1_5/README.md#数据集和模型下载
wgt->wget

Thank you very much. Already fixed, please review: https://github.com/alibaba/Pai-Megatron-Patch/pull/231


List org/group users

What is currently missing?
List group members.
https://api.aiven.io/doc/#tag/Groups/operation/UserGroupMemberList
List organization users
https://api.aiven.io/doc/#tag/Users/operation/OrganizationUserList
Then a user login via IDP, i can specify to put users in a group, or the team option.  lets say group name is IDP-USERS.
With terraform i would like to list members of IDP-USERS, and match if user is in a Azure Ad admin group.
If they are, i would put this user in an Aiven group that had admin privileges on specific projects.
I have now solved this with two IDP setups. however, this is not ideal since it will require the users to pick form
list of urls for account registration.
How could this be improved?
enable listing users and put them in groups based on permissions
Is this a feature you would work on yourself?
no

sorry for late response. I solved with by manually adding SSO users to Aiven Org groups as a cronjob.
if user creates an account, within 1h the user will be added to a group that has any of read/developer/operator permissions on all projects. Target Aiven Org group is decided on IAM on my end.


Named parameters/arguments in function call

C# allows adding names of arguments in a function call:
CalculateBMI(weight: 123, height: 64);

See http://msdn.microsoft.com/en-us/library/dd264739.aspx
In TypeScript's source this is also done, but with comments:
emitLinesStartingAt(nodes, /*startIndex*/ 0);

Can we have named arguments in TypeScript like this:
emitLinesStartingAt(nodes, startIndex: 0);

This can add some compile time checking, for instance when you type count: 0 you will get an error.
I think we should add a restriction that the order of the arguments cannot be changed. Example:
function foo(first: number, second: number) {}
var z = 3;
foo(second: z++, first: z);

An error should be thrown on the last line, because changing the order of the arguments (to foo(z, z++)) in the generated javascript would cause unexpected behavior.
Also this can be useful for functions with lots of optional arguments:
function foo(a?, b?, c?, d?, e?) {}
foo(e: 4);
foo(d: 8, 5); // e will be 5

Generates
function foo(a, b, c, d, e) {}
foo(void 0, void 0, void 0, void 0, 4);
foo(void 0, void 0, void 0, 8, 5);

@basarat in Typescript, interfaces are "free" - there is no run-time footprint at all, which is why I prefer this approach:
interface StartParams {
    isFoo?: boolean;
    isBar?: boolean;
    isBaz?: boolean;
}

function start(p: StartParams) {
    // ...
}

start({ isFoo:true, isBaz:false });

It's almost like having named arguments, though not quite, since you still have to unpack the arguments inside the function. I often find this approach to be safer and easier to refactor over time though. YMMV.

(Said originally this on #5857)
Personal opinion... it is anti-TypeScript design goals:

Avoid adding expression-level syntax.

Non-goal:

Exactly mimic the design of existing languages. Instead, use the behavior of JavaScript and the intentions of program authors as a guide for what makes the most sense in the language.

Object destructuring in ES6 with the combination of the terse object literal declarations in ES6 (both downward emittable) are more than sufficient to cover this type of functionality.  TypeScript isn't trying to be a new language, it is trying to be a superset of JavaScript.  This sounds a lot like a new language.

@RyanCavanaugh Parameter destructuring mostly does cover this but the syntax with TS can be pretty bad if you want to support 0 arguments.  Let's say you want a function that logs two booleans, taking 0, 1, or 2 parameters:
function log({a = true, b = true} = { a: true, b: true }) {
	console.log(a, b);
}

log();
log({a: false});
log({b: false});
log({a: false, b: false});

In ES6 without TS you could just do this:
function log({a = true, b = true} = {}) { ... }
But that doesn't work for TS because the types won't be equivalent and you get an error, so you have to repeat the structure twice.
Is there a better way of doing this in TS?

Hmm, I'm actually not seeing an error for this on TS Playground.  Perhaps this didn't work in TS 1.5 but has been fixed in 1.6 or 1.7?  This is the error I'm getting in 1.5 when I use just {} for the default argument:
error TS2459: Build: Type '{}' has no property 'refreshGrid' and no string index signature.

@alanouri, that was an TS 1.7 enhancement, you can read more about it in https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#improved-checking-for-destructuring-object-literal

Oh, yes that's exactly this issue.  Perfect, thanks for the enhancement, I think this works perfectly now.

@mhegazy - I have something similar throwing the same error...
export function httpGet(path?: string, ...middlewares : Function[]) { };

and is used like:
class Controller {
  @httpGet('/:id')
  async get(ctx: Context) { .... }
}

which throws ....
30   @httpGet('/:id')
     ~~~~~~~~~~~~~~~~

src/api/Controller.ts(30,3): error TS1241: Unable to resolve signature of method decorator when called as an expression.

@alanouri gives a great example of a default case above, but I just wanted to give a non-default example. I know this issue is closed, but it's the first hit on google and I wanted to explicitly show another example using destructuring for others like me who don't understand what this means.
function log({a = true, b = true} = { }) {
    console.log(a, b);
}

is basically syntactic sugar for
function log({a = true, b = true}: {a?: boolean, b?: boolean} = { }) {
    console.log(a, b);
}

But this does several things and this may not be obvious to others (like me) who are relatively new to TS. It gives defaults to individual values, as well as a default to the entire value.
Here is another example without some of the defaults:
                // params    // shape
function logNum({num, a, b}: {num: number, a?: boolean, b?: boolean}) {

    console.log(num, a, b); // << uses destructuring
}

It can be called using:
logNum({num: 123});
logNum({num: 123, a: false});

A default could then be added:
                                                                          // default
function logNum2({num, a, b}: {num: number, a?: boolean, b?: boolean} = { num: 123 }) {
    console.log(num, a, b);
}
logNum2();

There are many more possibilities, but the important part is that you are defining a single parameter object, the shape of that object, and sometimes defining optional/default values. Destructuring is then pulling out the individual args inside the implementation, as in the line console.log(num, a, b);.
For me, this is immensely useful for readability and refactorability especially with large-ish method signatures like in some factory functions.

I wanted named arguemnts for a while, and I changed my mind.
Javascript already has idiomatic named arguments, in the form of parameter objects.
In Typescript, these are even more useful, because you can declare an interface, defining all the possible parameter types.
Thanks to declaration merging, decorators/plugins/etc can even decorate such an interface with new possible parameters.
It's quite flexible - more so than named arguments would be. But more importantly, it's idiomatic - there is myriad JS code in the wild using the parameter object pattern for just about anything.
As for defaults, the typical JS approach is not to do it at the moment when you receive the parameters, but rather to do in when you consume one of the parameters - so rather than establishing defaults up front, typically we specify the default when we look up the parameter, e.g. something like $.post(options.url || DEFAULT_URL).
In other words, JS developers are used to seeing the default specified at the point where you consume an optional parameter, not where you received it. This also has the advantage of being able to very the default in each case, e.g. options.url || DEFAULT_URL in one case, and options.url || ANOTHER_URL in another case.
I think this feature is unnecessary, and in recent years, in other languages, I find myself leaning towards the parameter object pattern, for any large-ish method signature, such as factory functions, as it tends to refactor more easily without BC breaks.
Having optional arguments in a signature, tends to indicate that those arguments aren't directly or closely related, and often then a parameter object is preferable to me.
Anyways, just putting that out there for anyone to ponder, if you're still obsessing about the lack of named arguments. I rarely miss them anymore :-)

Is there a way to automatically assign destructured constructor parameters to the class instance,
like it is possible adding the private/public/protected keyword in front of the parameter name?

is there a way to automatically assign destructured constructor parameters to the class instance,
like it is possible adding the private/public/protected keyword in front of the parameter name

Nope :rose:

I'm using the  example of @bill-mybiz , but i don'get the default value for 'name' variable. is this the right way to use  destructuring object literal?
import { Component } from '@angular/core';
export class Hero {
id: number;
name: string;
constructor( {id  , name }: {id: number, name?: string } = { id:3, name: 'defaulthero'} ) {
console.log( id, name);
this.id = id;
this.name = name;
}
}
@Component({
selector: 'my-app',
template:
{{title}}

Hero {{hero3.id}} {{hero3.name}}
,
})
export class AppComponent    {
title = 'Tour of Heros';
public hero3: Hero;
ngOnInit() {
//this.hero3  = new Hero (  ) ;  // work
//this.hero3  = new Hero (  {} ) ; // does not work
this.hero3  = new Hero ( {id: 0} ) ;  // does not work, default value 'defaulthero' not assign, just i get 'undefined'

}
}

In my experience, the primary utility of named parameters is to increase readability at call sites by providing a sort of inline documentation -- a sort of "here's what this argument is, so you (the developer) don't have to look it up".
Yes, JS provides idiomatic named arguments already, in the form of parameter objects. However, a very large number of libraries have functions/methods with multiple formal parameters.
Since TypeScript is meant as ES + type annotations/checking, I don't think named parameters makes any sense as an output transformer. However, I think they would be very useful as an optional, syntax-only, semantic no-op --- a sort of cleaner alternative to inline comments that could improve readability.
A setTimeout example:
setTimeout(() => {
  console.log("Print this after a while");
}, waitTime: 1000);

Here the waitTime annotation is nice and reduces cognitive load by a small amount (in my opinion).
Somewhat orthogonally, I imagine named parameters might also be useful for verifying arguments against other TypeScript (or JS+types) code, with errors thrown when the names don't match. But I haven't thought enough about that case to say much more...

@RoyTinker that seems like something which should be proposed for standardization into ECMAScript. Adding it on the TypeScript side introduces a massive likelihood for collisions with the subset.

@aluanhaddad Good point, thanks. Although I imagine they'd have a similar concern about collisions with potential future features 🤷♂

Named parameters are handy when you need to add a new argument to a legacy API. In this scenario, destructuring isn't an option because it would break existing function calls.
Without named parameters:
login(Model.Email, Model.Password, undefined, undefined, undefined, Model.invitationID)

Notice the 3 nasty undefineds for unused optional arguments.
With named parameters:
login(email: Model.Email, password: Model.Password, invitationID: Model.invitationID)

@RyanCavanaugh
can we at least allow named arguments in the same order as parameters go?
point is the names help a lot when it comes to reading the code
since the order of arguments and parameters always the same there is no problem with matching
with that said the emit can just drop these names (for the sake of transpile to js scenario)
if the type information is available the argument names are forced to match the parameter names
please consider reopening this issue

It's pretty risky to add expression syntax in that position; I don't think what is essentially documentation meets the bar for that.
In TS we just use fn(/* paramName */ arg) when the meaning is not obvious from context. We had a lint rule to enforce the matching as well (though this turns out to be expensive)

can we at least allow named arguments in the same order as parameters go?

Just a thought, but - given the example above...
setTimeout(
    () => console.log("Print this after a while"),
    1000 // waitTime
);

And the other one...
login(
    Model.Email,
    Model.Password,
    undefined, // no first name
    undefined, // no last name
    undefined, // dob (not available on this form)
    Model.invitationID
)

Looks better to me: you didn't need to repeat the words "email" and "password", since those words figure in the arguments you're passing, and it makes room to explain why you're omitting certain values.
The upshot of this is that you're not at risk of the actual argument names changing... I mean, normally, changing an argument name is not a breaking change - call sites aren't affected.
Also, arguments in JS functions obtain names for positional arguments only at call-time inside the function scope - if you create dependency on argument names, arguably (hah!) that might actually be considered a change to the semantics of the language?

@mindplay-dk  The callee parameters are not always so close on levels of abstraction as the arguments of the call, and the arguments can also be ambiguous. If that's the case, the argument names don't really help in understanding the call.
Consider the contrived example of:
transferCredits(from: AppInfo.AppOwnerCompanyAccount, to: Model.LoggedInUserAccount)
vs
transferCredits(AppInfo.AppOwnerCompanyAccount, Model.LoggedInUserAccount).
In all cases, this was about introducing an optional feature. It can be only applied where needed. Also if anyone really prefers any other way, like comments above, they could still rather use that.

@zlamma the main problem with this idea as a compile-time feature, is the semantic mismatch: if somebody renames a positional argument, that's not traditionally a breaking change at any call-site - if we allow named arguments at call-sites for positional arguments, renaming a positional argument is now a breaking change; but you can't reasonably expect neither JS or TS library vendors to version their packages as major releases every time they rename an argument, because, according to how JS works, positional arguments are assigned names only within the local scope of the function, at call-time.
So the whole discussion is kind of a non-starter: it's simply not how JS works. No matter how much I like (and would like to have) this feature, even if you took this to the TC39, I think they would reject it more or less outright, because it would be a breaking change to the language.
I think you're going to have to resign yourself to using parameter objects in your own code - and, when you need to use third-party library code, and positional arguments cause serious readability problems for you, you will have to either PR and help improve those libraries, or, proxy third-party functions in custom wrapper-functions that do use parameter objects.
I simply don't see any other ways to approach this - even the vestigial naming feature (as you or someone else proposed) where you can name parameters only when also supplied in positional argument order, doesn't make sense, since, again, changing the names of positional arguments isn't supposed to be a breaking change.

@mindplay-dk Great points - it seems clear that named positional parameters as a check and/or an output transformer are inadvisable in both TS and JS.
However, please see my (comment above) [https://github.com/Microsoft/TypeScript/issues/467#issuecomment-320798866] - that isn't supposed to be capable of causing breaking changes. It would only be a nicer alternative to using inline /* parameterName */ comments.

@mindplay-dk I just had a thought. What if named parameters were added as a semantic no-op (call site documentation) as I mentioned above, but also an "experimental" TS compiler feature that would throw errors for mismatched TS-to-TS parameter names? In my mind, this could cause breaking changes (when library APIs or type annotations change, etc.), but only when someone wants that behavior.

@RoyTinker fwiw, when (only) implemented as a semantic no-op this starts to look a lot more like an IDE feature, than a language construct. https://www.youtube.com/watch?v=ZfYOddEmaRw

@mindplay-dk  - whether this is a breaking change is rather subtle. It certainly is not a breaking change for any existent code, both libraries as well as their callers, the syntax is not used in it as it is unavailable. The behavior is breaking just to 'expectations about new code', which is much much milder.
Whether renaming an argument should be a breaking change also depends on context. Machines can only care about position for optimization, but human intentions in the program are certainly to provide an argument that means 'this and that' - it's quite likely that when the name changes, it no longer means 'this and that', so it's reasonable to notify human that he should re-think it. I, for one, would rather appreciate this and not make much fuss even if it turned out that I just need to do the trivial chore of changing the name.
As to refactoring the problem away, using a {} object Is not merely a syntactic difference. Function arguments may be preferred for ease of currying or performance (new object in memory and extra garbage collection burden).
In all cases, all of the points you are making about breakiness applied to any language that introduced the feature mid-life. Notably, C# did this in 4.0 and did not cause a revolution.

@zlamma Good points -- it's good to know details on other languages. There's one important difference b/t TypeScript and those languages: TypeScript is transpiled to ES, and one of its stated goals (#8) is to "avoid adding expression-level syntax" -- of course, excluding type annotations. Goal #9 is to "use a consistent, fully erasable, structural type system".
Since this feature would contribute to compile-time checks, would be fully erasable, and would not affect compiler output, I think it's arguable that it falls under goal #9 instead of #8.

Related: https://github.com/Microsoft/vscode/issues/16221

@RyanCavanaugh would it be possible to reconsider only a case where parameter order is as original? Whenever I have multiple parameters of same type (like string) it's a mess trying to figure out which of them is for which value.

No, because the concern of syntactic conflict with a future version of ECMAScript still stands.
We use the /*name*/ syntax when this occurs

Just for those who wanted this feature, you can actually emulate it using object-destructuring since ES6.  For example,
// Definition
function send({message, to}) {
    if(to === "console") { console.log(message) }
    else if(to === "window") { window.alert(message) }
    else { console.log("Unknown channel : " + to); }
}

// Example of usage
send({message: "Hello world", to: "console"})
send({message: "Hello world", to: "window"})

// Tested in Google Chrome

What if I wish to do something like this?
constructor({
  private id: string,
  private name: string,
  private email: string,
}) { }

What TypeScript requires me to do to achieve that is not very nice:
constructor({ id, name, email }: {
  id: string,
  name: string,
  email: string,
}) {
  this.id = id
  this.name = name
  this.email = email
}

@qoh This is what I do. Not super pretty, with two issues

Shape doesn't work very well with methods
When strict is enabled, all the properties will have to have !

type Shape<T> = { [P in keyof T]: T[P] }

class X {
  public id!: string
  public name!: string
  public email!: string

  constructor(obj: Shape<X>) {
    Object.assign(this, obj);
  }
}

@wongjiahau's example with ES6 object destructuring is probably the closest we can realistically get to named arguments in TS without departing from JS semantics?
That pattern is already idiomatic to JS, and engines likely already optimize for it.
Perhaps we should start asking how to better enable that pattern in TS instead?
So how do we improve on this:
function send({message = "Hello", to}: {message: string; to: string}) {
  // ...
}

Repeating every argument (property) name is a bit clunky, but it's also the only real problem - call sites are perfectly readable with an object literal, and such calls are completely idiomatic to JS since the dawn of time, so no real problem there IMO.
Here's an idea for a simple sugar to abbreviate the example above:
function send(${ message = "Hello", to: string }) {
  // ...
}

This syntax would work in argument lists only - it just declares a single argument that desugars to an ES6 object spread, with an anonymous type assembled from the argument-names/types, which can be either declared with : or inferred from a default const initialization with =.
The syntax would be more or less exactly that of property-declarations in a class.
I believe this approach has a few advantages over actual named arguments:

You can have more than one set of named arguments:
function foo(${ a: string, b: string }, ${ c: string, d: string })

You can dynamically define named arguments at call sites:
bar({ ...defaults, ...overrides, some: value })

Named arguments are properly grouped - so mixing positional and named arguments is clear:
function baz(a: number, ${ b: string, c: string }, d = "default")

I think there's a bunch of advantages to building on establishes semantics and well-known patterns, rather than inventing an entirely new language feature.
Thoughts?

@mindplay-dk I actually like this proposal quite a lot. Do we need the $ tho? I guess the parser could know what we want even without it

Do we need the $ tho? I guess the parser could know what we want even without it

@DominikDitoIvosevic No, I don't think it works without some sort of operator?
function foo({ a: string }) {}

The parser would see this as destructuring of the arguments, I think?
It can't know if string is type or a variable-name, so it's ambiguous with destructuring the property a into a variable named string, isn't it?

Hi everyone, I'm a bit confused. I can use object destruct to force the input object approach on my function's customers only if I have the luxury to change the function signature. For functions requiring backward compatibility or functions I consume but not own, this is not a solution.

I must say that, to me, all the suggestions to refactor the problem away using a {} object are not satisfactory as a 'language-wide' solution to the problem, no matter the syntactic sugar.
It's important to note that refactorings to an object parameter bring a difference to the programs that isn't merely syntactic. Multiple function arguments are not only more performant (no new heap object allocation/garbage collection) but also make for simple partial application using bind (which will also be more performant than any object-based alternative). Given that, even if {} is professed as "the JavaScript's natural way of passing named arguments", the convention will never reach full adoption within the language. A convention that is opinionated against the language's own features of some unique value will never become a language-level good practice. As an example, Google's JS style guide does recognize that it can be 'infeasible' to refactor functions' multiple parameters away.
I still stand by the conviction that this is a safe-to-introduce and a positive feature, and it is so even in the event of 'plain JS libraries changing their param name but not changing their SemVer'. See this previous comment of mine which I now updated, adding some more efforts to demonstrate that making the compilation break even in this case is an added value to the users of TypeScript in what seems to be pretty much any real-life development setups.

@mindplay-dk
You mention that

changing the names of positional arguments isn't supposed to be a breaking change.

This reminds me of that argument for C++ named arguments, according to proposal N4172:

Objection #3: Named arguments make parameter names part of a function's interface, so that changing the parameter names can affect call sites
We were initially concerned about this as well. To get an idea about the magnitude of this problem, we surveyed some large open-source libraries to see how often parameter names change in the declarations of the public API functions (i.e., the names that users would use when making calls to these functions).
For each library, we chose a recent release and a release from several years ago, examined the diff between the two versions, and recorded the number of parameter name changes. Only name changes that preserved the types of the parameters were considered, as a change to the type of a parameter typically breaks a function's interface already. The table below summarizes our findings. For more details, please see [1].

Given the low number of parameter name changes relative to the sizes of these libraries over periods of several years, we believe that code breakage due to parameter name changes would not be a significant problem in practice.

I am sure that little popular libraries tend to frequently rename parameters within their development flow from stable version to another -- as this generally indicates poor coding practices. Clearly, if the function signature is replaced because of a semantic change, then it is only natural that this change breaks compatibility to some extent.
If code clarity and quality is in mind, well-planned projects should almost never refactor their parameters, and the cases where this would be so can also apply to any other user-defined identifier within the language.
Regarding your point about parameter scope, as TypeScript transpiles to JavaScript, this is not a problem. This only affects function call sites, so named parameters could be syntactic sugar that requires the function signature type to be present at compile time, and replace the named call with a positional call.

On another note, I don't think that adding this feature would be almost like "a new language", while it is true that object destructuring could be enough to solve this. However, currently the way it is it makes duplicating the object attributes, making it quite unreadable. It was one of the things that I disliked the most when I started learning TypeScript. When functions are annotated in-place, code formatters break the one-liners and split the signature into many many lines, making it super ugly. So this ends up making the type be extracted to an interface.
Solving this in a nice way would require adding another syntactic feature significantly different to current object type annotation principles.
The most obvious way that someone would expect to avoid duplication:
function foo({firstParameter, anotherParameter}: {firstParameter: string, anotherParameter: number}) {}

would imply, as suggested, removing the destructuring and just leaving the interface
function foo({firstParameter: string, anotherParameter: number}) {}

But in order for this to work, the interpreter would have to either (a) not consider the declaration an interface, or (b) inject the interface attributes to the scope, and this would not be very beautiful, as it would be inconsistent with current behaviour. So the most natural solution is dropping the braces and adding syntactic sugar to function calls, which is not incompatible with type annotation as this feature is not currently allowed in call site.

On another note

function test1 ({a:: string}) {}
function test2 ({a: b: string}) {}
function test3 ({a: b: number | string = 1}) {}


error values need to be modernized

Short version:
This codebase predates Go 1.13.
All the features added to Go's standard errors since; should be used instead of the various things we do right now.
Long version:
Throughout the project there are a few ways errors are handled.
The bulk of this code was written in 2017-2018 which predates Go 1.13.
(This is true too for some of our dependencies as well)
As such, things like error wrapping, comparison, joining, etc. were less standardized and relied on per-project conventions instead.

The most common pattern in the current codebase is almost a direct copy of how errors are handled within upspin, with minor deviations and extensions.
(ref: https://commandcenter.blogspot.com/2017/12/error-handling-in-upspin.html)
Although other patterns exist at various layers too.
These afforded many benefits, most important of which was the ability to add additional information to errors without losing comparison, as well as extending them to contain data which could be interpreted for multiple systems.
E.g. our fserrors.IO can be returned from common code, and at edges, be translated into things like FUSE's errorno, 9P error strings, 9P2000.L's errorno, native syscall errors, etc.
The types and values of which all differ, despite being the same kind of error, derived from the same cause/fault.
While these were great then, you wouldn't do this today.
The standard errors pkg has evolved significantly and errors.{Is|As|Join} along with fmt.Errorf's %w (and in 1.20 the ability to use multiple %w tokens), satisfy the same requirements we have, but in a standard way.

We should try to migrate away from this older style somehow.
Either gradually, or all in one shot.
And favour the standard library style instead.
Utilizing constant errors formatted with fmt.Errorf, and errors.Is to compare and translate Go errors to API specific errors where needed.
If possible we should extend this effort into our dependencies so that things are consistent the whole way through.

Reminder to update any tests when we tackle this: https://github.com/djdv/go-filesystem-utils/pull/25/commits/63d7b5650c6190a3e8e2b637fc2efe21929dfec6#r1037622423