[BUG] Deleting virtual machine restore CR makes restoring VM can't restart

Describe the bug
Directly deleting virtualmachinerestore CR makes resotring VM can't restart
To Reproduce
Steps to reproduce the behavior:

Creating backup for a VM
Restoring backup to a new VM
Deleting the related virtualmachinerestore CR with kubectl
Restarting the restored VM
The restarting will be rejected with Error start virtual machine <restored VM> failed, persistentvolumeclaims "<restored PVC>" not found

Environment

Harvester ISO version: master-head (8b80f821f9da22a678ecef018a01d0fe241715a4)

Additional context
The restoring VM's pvc has ownerReferences points to the matched CR virtualmahcinerestore, for example:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  ....
  name: restore-vm-b1-434fd2c1-fd7a-4c0f-bda7-9ac31becef13-disk-0
  namespace: default
  ownerReferences:
  - apiVersion: harvesterhci.io/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: VirtualMachineRestore
    name: restore-vm-b1-5xcnx
    uid: 434fd2c1-fd7a-4c0f-bda7-9ac31becef13
  resourceVersion: "100298"
  uid: c7db72ed-d9c9-4fee-a424-14a3cefbb0bb
spec:
  accessModes:
  - ReadWriteMany
  ....
  storageClassName: longhorn-image-l8mlc
  volumeMode: Block
  volumeName: pvc-c7db72ed-d9c9-4fee-a424-14a3cefbb0bb

so once the virtualmachinerestore CR is deleted, the PVC will turn into Terminating status. If the restoring VM is stopped, the PVC will be completely deleted.

set priority to 2 because the virtualmachinerestore resources are not available in the GUI.

Test OK on v1.4.0-dev-20240918, close as fixed.
Environment

v1.4.0-dev-20240918

Profile: 2 nodes QEMU/KVM (8C/16G/250G per node)
ui-source: Auto

Test Steps

Creating backup for a VM
Restoring backup to a new VM test2
Deleting the related VirtualMachineRestore CR by kubectl, and deletion operation was rejected, console print error The request is invalid: spec.target.name: The restore can't be removed because the restored VM test2 exists, work as expected.

After deleted VM test2, related VirtualMachineRestore CR was removed either.


Typescript compilation error SyntaxError: Unexpected token '.' (yaml: "^2.0.1")

Describe the bug
Hi guys! I was contributing to Pulumi GitHub action, when found this bug. I've developed a new feature in the middle of the April and all was okay. But the owner of the repo checked my code only a 2 months later, and we got this error. When I got back from ^2.0.1 to 2.0.1 trouble is disappeared. Could you check this?
To Reproduce
Steps to reproduce the behaviour.

Add yaml ^2.0.1 to package.json
Build with yarn
Profit
https://github.com/pulumi/actions/tree/982ee41fcc25609042a89cf6043af498a30146e8
https://github.com/Moon1706/actions/runs/6825643139?check_suite_focus=true

Expected behaviour
A clear and concise description of what you expected to happen.
I expected this behavior.
Versions (please complete the following information):
yaml: 2.1.1
node-version: 14.x

Environment: [e.g. Node.js 14.7.0 or Chrome 87.0]
https://github.com/Moon1706/actions/blob/master/package.json

Additional context
Add any other context about the problem here.

Encountered the same problem

This is pretty much the same thing as #394, which I've now pinned to hopefully guide others who encounter this. This is not a problem with yaml, but with other tools that need to be updated.
In this particular case, it looks like @pulumi/pulumi is using<EMAIL_ADDRESS>which does not support optional chaining (the syntax with which you encountered this error). You should get that updated to at least v3.8, which was released two years ago.

@evilaliv3 I haven't encountered any problems with yaml v2.x myself, so I am not sure. It does not appear to be affecting other npm-check-updates users.

That was fast, thank you @raineorshine for your feedback!
Actually updating to node 16.15.1 and npm 8.1.0 solved the issue.

Closing this, as there's no action on the yaml side and it looks like the upstream fixes have been merged as well.


Add useUpsert hook

Motivation
Created a hook that will use the functionality exposed by supabase-js for doing insert or update queries via upsert() method.
Related

Discussion https://github.com/tmm/react-supabase/discussions/5
Docs https://supabase.io/docs/reference/javascript/upsert

Docs
/docs/pages/documentation/data/use-upsert.md

Not sure why, but the docs title is not well rendered as useUpsert, but Use-Upsert instead.

It will be nice to fix that prior a merge


Stop letting Milkdrop talk to Redux

Ideally Milkdrop would not know about the Redux state.

We've decided to actually go in the opposite direction and move the Butterchurn integration into the core.


Chore: Define pyblish targets on install host

Changelog Description
It is possible to define pyblish targets in install_host which are used instead of auto-detected targets.
Additional information
This may be necessary for automations which should run very specific target and none of the auto-detected. We've discovered the need with automated cli publishing of csv editorial via traypublisher. There we have to deregister all targets to register only specified targets.
Testing notes:

All hosts should be installed without any changes as did before.
It should be possible to use custom targets without using the auto-detected.

I'm personally not too sure about this change.
If there's a specific need to run a pyblish with very specific targets, why not use pyblish.util.publish(targets=targets_override) argument?
Aside of that single publish process in CLI - what else does it influence for the install_host that it requires the actual override to occur for the host installation itself? Why can't we only influence the singular publish call we're doing in that CLI?

I'm personally not too sure about this change. It feels like a customization in the wrong place - it's not relevant as much to the host install. Right?

There is no way how to call install_host without registering "local" or "remote" target. The condition for is_in_tests is also questionable, "automated" target is different publish logic from "local" and "remote" in a way that they should not be combined.

Aside of that single publish process in CLI - what else does it influence for the install_host that it requires the actual override to occur for the host installation itself? Why can't we only influence the singular publish call we're doing in that CLI?

To be honest I wanted to add this option long time ago regardless of the PR. I would say that the logic for "remote" could be removed with this change, and the logic for testing should be replaced too (if possible).

There is no way how to call install_host without registering "local" or "remote" target. The condition for is_in_tests is also questionable, "automated" target is different publish logic from "local" and "remote" in a way that they should not be combined.

I understand, but for the CSV case as my example shows it doesn't matter since it's a specific publish case where the publish must have a specific target, so we pass it to the publisher.

EDITED:
The "remote" logic is defined only for maya, but as I'm going throught the code, it just can't work. There is so much missing pieces, the submit plugin is half done and the remote publish script is not implemented at all.

I'm pretty sure this is 'half-copied' at some point from our Colorbleed codebase during Avalon. We used the remote target to allow any host to publish to the farm with close to no tweaks to the plugins. Basically the target defined where publishes would go to, local or remote. OpenPype decided to go down a different direction with encapsulating all that "is this going to farm or not?" logic per plug-in in the process methods just so that one instance could go to the farm and another could run local. More complex code, but does allow that extra flexibility.
I believe the copied code from our original codebase was never used in OpenPype and likely never worked but was just blindly copied at the time?

Closing for now


Permission for Real-Time C++ Book Excerpts

Hi Chris - Good to chat with you again!  After a one semester break, I should be teaching my course at the University of Puerto Rico - Mayaguez again in August.   I've had two successful classes using your book and I was happy to see that the 2nd Edition is out now!  I've order two books - one for me and one for UPRM.
Question for you (or the publisher).  I would like to take snapshot copies from certain pages from your book to add to my Prezi presentations.  For the first two semesters, I only referenced your book and had the students turn to those pages when needed.  Very awkward especially since I'm teaching live virtually using zoom.us service.  How do I get permission to use your book in this way?  My presentations are not publicly available and limited to the students who are in my course and who have also purchased the book.
I want to ensure that I'm meeting all copyright restrictions with your book and any restrictions that the publisher my have.
Please let me know what I am able to do with your book during class time.
Thanks!
Ken Vaughan
Profesor
Departamento de Ingeniería Eléctrica y Computadoras
Recinto Universitario de Mayagüez
Universidad de Puerto Rico
<EMAIL_ADDRESS>

Hi Ken,
It is good to hear about your successful use of the book. Thank you.
In my opinion, you must adhere to all copyright restrictions from the publisher, Springer Verlag. As far as I know, these are printed in the front matter of the book.
Best regards, Chris


fix yaml blocks in ASM content

Fixed broken yaml blocks

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

azuresmps-3.7.0/Azure/New-AzureVMSqlServerAutoBackupConfig.md
:white_check_mark:Succeeded

azuresmps-3.7.0/Azure/Set-AzureVMChefExtension.md
:white_check_mark:Succeeded

azuresmps-4.0.0/Azure/New-AzureVMSqlServerAutoBackupConfig.md
:white_check_mark:Succeeded

azuresmps-4.0.0/Azure/Restart-AzureVM.md
:white_check_mark:Succeeded

azuresmps-4.0.0/Azure/Set-AzureVMChefExtension.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


suzuka-full-node-local (ubuntu-22.04, x86_64, buildjet-16vcpu-ubuntu-2204 failing for multiple branches

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
See these CI jobs for the following PRs:

https://github.com/movementlabsxyz/movement/pull/372
https://github.com/movementlabsxyz/movement/pull/399
https://github.com/movementlabsxyz/movement/pull/400
https://github.com/movementlabsxyz/movement/pull/436
https://github.com/movementlabsxyz/movement/pull/391

and more. Various PRs by different authors.
Expected behavior
Screenshots
Additional context
The check passes for some branches, e.g. this PR which I was able to merge:

https://github.com/movementlabsxyz/movement/pull/434

In the failing PRs, output looks like this before the check fails:
[m1-da-light-node	] 2024-08-27T02:45:26.323828Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:27.325270Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:28.325530Z  INFO movement_timing: read_blocks block_count=0
[celestia-bridge	] 2024-08-27T02:45:29.101Z	ERROR	rpc	go-jsonrpc@v0.3.1/server.go:108	RPC Error: Invalid request
[celestia-bridge	] 2024-08-27T02:45:29.101Z	ERROR	rpc	go-jsonrpc@v0.3.1/server.go:108	RPC Error: Invalid request
[m1-da-light-node	] 2024-08-27T02:45:29.326828Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:30.328032Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:31.329271Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:32.330355Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:33.331636Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:34.332884Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:35.334125Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:36.335135Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:37.336281Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:38.337489Z  INFO movement_timing: read_blocks block_count=0
[celestia-bridge	] 2024-08-27T02:45:39.100Z	ERROR	rpc	go-jsonrpc@v0.3.1/server.go:108	RPC Error: Invalid request
[celestia-bridge	] 2024-08-27T02:45:39.101Z	ERROR	rpc	go-jsonrpc@v0.3.1/server.go:108	RPC Error: Invalid request
[m1-da-light-node	] 2024-08-27T02:45:39.338728Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:40.340036Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:41.341036Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:42.341520Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:43.342795Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:44.344121Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:45.345406Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:46.347631Z  INFO movement_timing: read_blocks block_count=0
[m1-da-light-node	] 2024-08-27T02:45:47.349048Z  INFO movement_timing: read_blocks block_count=0
Error: The operation was canceled.

Closing this as it appears to have been due to flaky runners.


Upgrade to SQLAlchemy 2

This turned out to be very easy.
Closes #100

Haha, yes very simple. As this passes the CI tests, I'm happy to approve.


Detected blocking call to sleep inside the event loop by custom integration

Saw this message in the Home Assistant logs... Need to change the time.sleep() calls to await asyncio.sleep()

Not as straightforward and minimal benefit.
Closing for now.

This is going to be embarrassing when added to home assistant...
Consider adding async_* alternative methods similar to how home-assistant has alternative async_ methods


[LevelDB] Update to latest Level DB code

What is the purpose of this pull request (PR)?
Updates the Level DB version to match latest used by Bitcoin.  Needed to build the Windows binaries.
Any background context to help the reviewer?
Needed to build the Windows binaries.
Was this PR tested and how?
Tested with Windows.  Still needs testing on Linux and Mac.

Travis failing due to attempting build with Qt4.

I am not done with this PR.  Please don't delete my working branches.


Fix effect priority caching

In this PR, fixes for: https://github.com/hammerlab/cohorts/issues/253 and https://github.com/hammerlab/cohorts/issues/252
Instead of an "all_effects" cache, we now remove priority filtering from the small nonsyn. cache and the larger effects cache. If all_effects is true, we don't do priority filtering after generating our collections or pulling from the cache; otherwise, we do.
Tried to test this pretty aggressively.

Note that we need to clear our effects caches to make use of this PR. Should also result in a non-trivial version bump.

Coverage increased (+0.2%) to 52.714% when pulling e01fd5812c3a7a1f33f84a74aa6619e2e210c47c on fix_effects_caching into ea31881381e592cd26f6125a4723ccd74796ec0e on master.

Coverage increased (+0.2%) to 52.714% when pulling b2e01a8b8371a1caa4d5a8cd9f356c0623370326 on fix_effects_caching into ea31881381e592cd26f6125a4723ccd74796ec0e on master.

@jburos great idea! Just moved top_priority_maybe. Good to merge on green?

Coverage increased (+0.2%) to 52.714% when pulling 84d059f7c8138d52ba09fa90b94087dfb71dedf4 on fix_effects_caching into ea31881381e592cd26f6125a4723ccd74796ec0e on master.

@tavinathanson sorry if you didn't see my 👍  -- but yep good to go whenever you are ready. Once this has been merged I will update my pending PRs to be consistent with these changes.


What books you follow (or followed)[Tech books]

Have answered this multiple times through social media channels. Please follow along or check the archives.


Pub build crashes with too many entrypoints

This is a tracking bug for the hotfix for #14730. That bug will stay open until a cleaner solution is in place. This bug is just for doing something to alleviate the problem.

This issue has been moved to dart-lang/pub#702.


Lgtm: part6

Issue being fixed or feature implemented

What was done?

How Has This Been Tested?

Breaking Changes

Checklist:

[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or updated relevant unit/integration/functional/e2e tests
[ ] I have made corresponding changes to the documentation

For repository code-owners and collaborators only

[ ] I have assigned this pull request to a milestone

Codecov Report

Merging #161 (1b2b349) into master (d1f5e41) will increase coverage by 0.02%.
The diff coverage is 16.66%.

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


"Coșeri" is listed in the drop-down menu

Description:
"Coșeri" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Coșeri" in the search bar.

Expected results
The location is listed in the drop-down menu as "Coșeri, Argeș (Căteasca)".


undefined symbol: injector_attach

System is  Debian GNU/Linux 10 (buster) running Python 3.7.3
Installed debugger as
apt install  --no-install-recommends python3-pip python3-setuptools python3-wheel python3-dev build-essential
python3 -m pip install madbg

I have this trace trying to attach:
# python3 -m madbg attach 18964
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 183, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.7/runpy.py", line 142, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.7/runpy.py", line 109, in _get_module_details
    __import__(pkg_name)
  File "/usr/local/lib/python3.7/dist-packages/madbg/__init__.py", line 1, in <module>
    from .api import set_trace, set_trace_on_connect, post_mortem, run_with_debugging, attach_to_process
  File "/usr/local/lib/python3.7/dist-packages/madbg/api.py", line 10, in <module>
    from hypno import inject_py
  File "/usr/local/lib/python3.7/dist-packages/hypno/__init__.py", line 1, in <module>
    from .hypno import inject_py
  File "/usr/local/lib/python3.7/dist-packages/hypno/hypno.py", line 4, in <module>
    from pyinjector import inject
  File "/usr/local/lib/python3.7/dist-packages/pyinjector/__init__.py", line 1, in <module>
    from .pyinjector import inject, LibraryNotFoundException
  File "/usr/local/lib/python3.7/dist-packages/pyinjector/pyinjector.py", line 13, in <module>
    libinjector.injector_attach.argtypes = POINTER(injector_pointer_t), pid_t
  File "/usr/lib/python3.7/ctypes/__init__.py", line 369, in __getattr__
    func = self.__getitem__(name)
  File "/usr/lib/python3.7/ctypes/__init__.py", line 374, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/local/lib/python3.7/dist-packages/pyinjector/libinjector.cpython-37m-x86_64-linux-gnu.so: undefined symbol: injector_attach

Thank you, fixed in pyinjector==1.0.5


Make sure tests don't run in bake+deploy test.

Make sure tests don't run in bake+deploy test if the proper flags are set/not set. @lwander PTAL. @ewiseblatt FYI.

1 comment then good to go


Error "InvalidOperationException: Collection was modified; enumeration operation may not execute." in NetworkRoomManager

Describe the bug
Sometimes when changing scene when Mirror is up an running we face the following error:
"**InvalidOperationException: Collection was modified; enumeration operation may not execute.**"
Full stack
InvalidOperationException: Collection was modified; enumeration operation may not execute.
System.Collections.Generic.List`1+Enumerator[T].MoveNextRare () (at <a3b02d6f9b494355b946095ea1f25c54>:0)
System.Collections.Generic.List`1+Enumerator[T].MoveNext () (at <a3b02d6f9b494355b946095ea1f25c54>:0)
Mirror.NetworkRoomManager.OnServerSceneChanged (System.String sceneName) (at Assets/Mirror/Components/NetworkRoomManager.cs:366)
Mirror.NetworkManager.FinishLoadSceneHost () (at Assets/Mirror/Core/NetworkManager.cs:1077)
Mirror.NetworkManager.FinishLoadScene () (at Assets/Mirror/Core/NetworkManager.cs:1020)
Mirror.NetworkManager.UpdateScene () (at Assets/Mirror/Core/NetworkManager.cs:998)
Mirror.NetworkManager.LateUpdate () (at Assets/Mirror/Core/NetworkManager.cs:288)

[IMPORTANT] How can we reproduce the issue, step by step:
Please tell us how to reproduce your issue, STEP BY STEP, with one of our built in examples.
-> Connect to online game scene, single player (host) is enough
-> Change scene to another (keeping the connectivity)
-> Go back to first online opened scene: the error occurs
Any bug that can be reproduced, can be fixed.
If we can't reproduce it, we can't fix.
Expected behavior
No error at all.
Code quick review
the method public override void OnServerSceneChanged(string sceneName) from NetworkRoomManager.cs (line 366) is doing this:
foreach (PendingPlayer pending in pendingPlayers)     SceneLoadedForPlayer(pending.conn, pending.roomPlayer);
But in the method called during this foreach iteration we have (same source, line 131):
if (Utils.IsSceneActive(RoomScene))
{
    // cant be ready in room, add to ready list
    PendingPlayer pending;
    pending.conn = conn;
    pending.roomPlayer = roomPlayer;
    pendingPlayers.Add(pending);
    return;
}

Screenshots
N/A
Desktop (please complete the following information):

OS: Windows 11 Pro
Build target: Windows
Unity version: 2022.3.14f1
Mirror branch: official 86.13.4

Additional context
Maybe replacing foreach by a for should be considered ?

Can't reproduce with the Room example that ships with Mirror...what step am I missing?

Hi, as you may know, it's not allowed in C# to add/remove/change order a list within a foreach iteration. The code we have here do this in certain case (did you test a NetworkRoomManager, this one produces the error).
Since I reproduce this every time, I've adapted the code in this way:

Add "protected virtual" to method "void SceneLoadedForPlayer(NetworkConnectionToClient conn, GameObject roomPlayer)" (NetworkRoomManager, line 121)
Add an override in my own NetworkManager to bypass the code present in "public override void OnServerSceneChanged(string sceneName)" (NetworkRoomManager line 361) doing this:

public override void OnServerSceneChanged(string sceneName)
{
    if (sceneName != RoomScene)
    {
        // call SceneLoadedForPlayer on any players that become ready while we were loading the scene.
        for (int index = pendingPlayers.Count - 1; index >= 0; index--)
        {
            PendingPlayer pending = pendingPlayers[index];
            SceneLoadedForPlayer(pending.conn, pending.roomPlayer);
        }

        pendingPlayers.Clear();
    }

    OnRoomServerSceneChanged(sceneName);
}

Hi, as you may know, it's not allowed in C# to add/remove/change order a list within a foreach iteration. The code we have here do this in certain case (did you test a NetworkRoomManager, this one produces the error).

The Room example uses NetworkRoomManager, and doesn't produce this error.  Try it yourself.
I know about not changing a collection from within a foreach...I'm asking how you're getting into the condition to produce the error.

Hey @joshuameurey this can happen if your game script accidentally modifies the collection while mirror is using it.
I recently helped another project to reproduce this and build 'SafeCollections' for C#:
https://github.com/miwarnec/CSharp-SafeCollections
Swap the List/Dictionary/etc. with SafeList/Dictionary/etc. and try again.
It will tell you the two places where the list is modified, which then helps debug.

Hi, thanks for this feedback @miwarnec, I'll give it a try ! Again, many thanks.

If you manage to reproduce it and think it's a mirror bug, then please reopen the issue!


DRILL-6970: fix issue with logregex format plugin where drillbuf was overflowing

@jcmcote is there any update?

I did not have time to add a test case yet. However I know the fix is good,
using it in production.
On Tue, Feb 5, 2019 at 7:21 AM Arina Ielchiieva<EMAIL_ADDRESS>wrote:

@jcmcote https://github.com/jcmcote is there any update?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/drill/pull/1612#issuecomment-460618283, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJoEwuMni3Va6kU8-erPICVuBTf-JKnWks5vKXdYgaJpZM4Z8ren
.

@jcmcote
Could you just modify one of the existing unit tests with a long string?

Is there a JIRA for this?. I am getting an IndexOutofBoundsException, and am wondering if it's the same issue.  (Drill 1.14, I am trying to see if this would fix the plugin)
SYSTEM ERROR: IndexOutOfBoundsException: index: 32760, length: 9 (expected: range(0, 32768))

yes that's the issue. 32k seems to be the buffer size and is never
recycled. I think that's what the safe methods do.
On Wed, Feb 13, 2019 at 10:16 AM John Omernik<EMAIL_ADDRESS>wrote:

Is there a JIRA for this?. I am getting an IndexOutofBoundsException, and
am wondering if it's the same issue. (Drill 1.14, I am trying to see if
this would fix the plugin)
SYSTEM ERROR: IndexOutOfBoundsException: index: 32760, length: 9
(expected: range(0, 32768))
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/drill/pull/1612#issuecomment-463237104, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJoEwhhKm3lVudX5Sco3wuau7wbyDKlmks5vNCxIgaJpZM4Z8ren
.

I think I fixed the build issue but it does not look like it is picking it up...


The version of used PyTorch

It seems that this project RoboFlamingo, the dataset API calvin_agent and the 3rd library open_flamingo have used three different versions (torch==1.12.1+cu113, torch==1.13.1, and torch==2.0.1) of the PyTorch. So what should I do to choose a suitable one?

Hi I think the latest version should work fine.

Hi I think the latest version should work fine.

Ok. I have already launched my running script. However, I can only use one A100 GPU, with unfixed bugs when using multi-GPUs. Hope the final training results will be fine.


Implement 'breaking change' alerting in Ingestion API

Done in https://github.com/opendatadiscovery/odd-platform/pull/138


Cannot run install.sh as non-root, non-root cannot open js_shell

Installation information

jumpscale version: 9.6.0
operating system: Ubuntu 18.04

Detailed description
Installation was only possible when adding "sudo bash -c" to the installation command, however after installation the js_shell is only available to the root user. Doesnt seem like desired behaviour
Steps to reproduce
Install using sudo on Ubuntu 18
Relevant stacktraces

this is expect behavior


Create a new sub-folder for IDE setup files of general interest

IDE-specific files of general interest, in particular formatting rules, should be added to the repository. A new top-level folder "ide_setup" should be used. The "cpp/.vscode" folder and launch_sudo script should also be moved there, in order not to force local preferences/setups onto other users with different needs. Actually, local settings like these should not be in the repository at all, but only files of general interest.
A README should be added to this folder, explaining the meaning/usage of these files.

[x] Add Eclipse formatting rules
[x] Remove user-specific files
[x] Add README

@rdmark I suggest to remove the recently created .clang-format file, because it cannot be used for IDE configurations and also does not cover all the settings required.

@rdmark I suggest to remove the recently created .clang-format file, because it cannot be used for IDE configurations and also does not cover all the settings required.

Yes, please go ahead. Let's avoid multiple sets of files with overlapping purpose.

Just removed it.


Show both a message creation date and a date of its latest update

In a Timeline AndStatus shows a date of creation, not a date of update or reblog/retweet. But it sorts tweets by dates of updates/retweets.
This is why old tweet, which was retweeted or updated recently, appears above tweets, which were created earlier than creation, but later than retweet of this tweet.
This confuses sometimes: you don't understand, if you are looking at old part of a timeline, or at a new but with old messages updated...
We need an option to show both dates. Presumably, showing both dates is not needed, when they are the same / close to each other.
Another aspect of this problem: if we need / can SHOW the same message in two places of a Timeline: when it was created, and when it was last updated/retweeted etc...
So, we need to discuss, what to do and how exactly a User should see this.

The problem was mostly solved, when AndStatus started showing Activities, and not "Notes/Tweets" only. so e.g. for Reblog activities we see both dates: the date of the reblog and the date of the reblogged note.

Is it possible to (optionally) change the sort order, so that the posts are sorted by post date rather than the date on which they got "liked" (or otherwise updated)?

Hi @vaschw! This thread ("issue") is many years old. Since that time AndStatus changed its internal data model largely. Mostly following ideas of Activity Streams and appeared later ActivityPub protocol.
Now "likes" or "retweets" DON'T UPDATE original message (called a "Note" in the modern terminology, see https://www.w3.org/TR/activitypub/ ).
Now most of timelines show Activities (actions), not "Notes". Thus sorting by a date of an Activity.
In this context your wish means an option to "Show Notes instead of Activities" in current timeline. With natural sorting by a date of a Note.
?!

Yes, I think you have described the option I am asking for.  In some cases it may be nice to view things in the order that the Activities happened (as the AndStatus Home Timeline currently does).  In other cases, I may want the option to see the order that Notes were written in -- so that the date of a "like" does not change the ordering.
Is this a feature that already exists?  I cannot find it.

No such a feature yet. I will need to add it. I created a separate issue for that.


Fix missing param.

This PR fixes a required name typo.
cc @xavijam

Pass local tests and if they are working, merge it without waiting tests.

Already did 🚀


Integrate the Microsoft mvvm Toolkit

See https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Mvvm

[ ] Add comment to https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3428 re lack of zero param overloads.
[ ] Submit PR to the community toolkit master branch.

Hey @SimonGeering - it's great folks trying out the new MVVM Toolkit, hope it's going well so far! 😄
Just a couple notes:

Keep in mind the API surface might change a bit in a couple places when the next preview drops (just a heads up). I'm keeping an updated list of all changes in https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3428, and you can also browse through the various commits in the two linked PRs if you're interested. That's to say, the master branch in the toolkit does not reflect the actual current state of the MVVM Toolkit, as that doesn't account for all the pending changes there.
Regarding that "lack of zero param overloads", curious to hear more about that, what your use case scenario is, etc. Please feel free to share feedbacks in the linked issue so we can discuss this (if we do settle on a new API to add, I'll just include it in one of my two tracking PRs, so that we'll have all pending changes for the toolkit in a single place, which makes things easier) 😊

Hi @Sergio0694 - very kind of you to take the time and trouble to reach out on here 😃 👍
The Xamarin app is a placeholder project for now but I am actively working on both a Desktop (WPF) and Web (Blazor Webasm) UI with a shared view model using CleanArchitecture.
The app is very "early days" as it stands with BankAccountEditDialogViewModel being the only VM anywhere near functional and integrated with the corresponding BankAccountEditDialog.xaml WPF dialog and the BankAccountEditDialogComponent.razor blazor component.
re you points above:

Yep, I had already come to that deduction but I appreciate the heads up. So far the deployed package has done just fine.

This was the area I was looking to raise a feature request / PR for. The issue is that blazor webasm doesn't have a command binding analogous to that found in the various XAML dialects. Instead getting MVVM to work in blazor requires a fair bit of liberal use of lambdas to hook the events to the corresponding VM command as in the OnClick handler for save and cancel buttons shown here:

  <DialogButtons>
    <DialogButton OnClick="@(_ => this.vm.Cancel.ExecuteAsync(null))" Disabled="@(!this.vm.Cancel.CanExecute(null))" Content="Discard" IconCss="fa fa-lg fa-trash-o" />
    <DialogButton OnClick="@(_ => this.vm.Save.ExecuteAsync(null))" Disabled="@(!this.vm.Save.CanExecute(null))" Content="Save" IconCss="fa fa-lg fa-floppy-o" IsPrimary="true" />
  </DialogButtons>

by comparison, the same WPF XAML would be
    <StackPanel Grid.Row="7" Grid.Column="1" Grid.ColumnSpan="10" Orientation="Horizontal" HorizontalAlignment="Right">
      <Button Command="{Binding Cancel}" Content="Cancel" Margin="0,0,8,0" Padding="8,4,8,4" />
      <Button Command="{Binding Save}" Padding="8,4,8,4">
        <StackPanel Orientation="Horizontal">
          <iconPacks:PackIconFontAwesome Kind="SaveRegular"/>
          <TextBlock Padding="4,0,0,0" VerticalAlignment="Center">Save</TextBlock>
        </StackPanel>
      </Button>
    </StackPanel>

So as you can see the option of another overload to make the nullable parameter argument entirely optional would remove the need to pass it in on the blazor side and clean the code up nicely. Something that is particularly important when trying to keep the amount of 'script' code mixed into the razor markup to a minimum.


Added support for build event

- What I did
It's an attempt at porting PR #15216 over which will finally close #15211
- How I did it
I copied what I could, then compiled it with tests.
- How to verify it
make test
- Description for the changelog
Triggers an event log when a build is made, allowing for listeners to know a build was started
- A picture of a cute animal (not mandatory but encouraged)

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "event-build" git@github.com:FrenchBen/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

ping @FrenchBen tests are failing;
21:14:29 ----------------------------------------------------------------------
21:14:29 FAIL: docker_cli_events_test.go:304: DockerSuite.TestEventsBuild
21:14:29
21:14:29 docker_cli_events_test.go:325:
21:14:29     c.Fatalf("build should be build, not %#v", buildEvent)
21:14:29 ... Error: build should be build, not []string{"2016-09-13T21:14:28.861798526Z", "container", "kill", "fe3587a0763e017bd9114f004d9192763222a1cd1f66d7689be00ff964edc622", "(image=busybox,", "name=foo,", "signal=9)"}
21:14:29
21:14:30
21:14:30 ----------------------------------------------------------------------

@thaJeztah I'll check to see where I failed 🍂

Needs a rebase now.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "event-build" git@github.com:FrenchBen/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

03:06:19
03:06:19 ----------------------------------------------------------------------
03:06:19 FAIL: docker_cli_events_test.go:273: DockerSuite.TestEventsBuild
03:06:19
03:06:19 docker_cli_events_test.go:287:
03:06:19     c.Assert(parseEventAction(c, events[nEvents-5]), checker.Equals, "build")
03:06:19 ... obtained string = ""
03:06:19 ... expected string = "build"
03:06:19

ping @FrenchBen I'll close this for now, but let us know when you're ready to work on this again

thanks @thaJeztah I'll make sure to follow up when bandwidth permits!


Model taking lip video as input

Hi! Thank you for your excellent work in the paper!
As is said in you paper, your model takes lip video as input, while this repo however only provides a model  taking face video as input. Could you please provide a pre-trained model which takes the lip video as input? It will be very helpful for me!

Or could you please make it clearer how I can train the model by myself with lip videos as input?


[LinearProgress] High frequency updates

Updated progress.md according to update suggested in issue [LinearProgress] High frequency updates. Closes #21411

[X] I have followed (at least) the PR section of the contributing guide.

Still missing that this is only confirmed in chromium (on ubuntu)

@eps1lon I believe that you have provided a reproduction of the delay in https://github.com/mui-org/material-ui/issues/21411#issuecomment-643771029 for Ubuntu 18.04 Firefox 77.0.1 as I could reproduce it for all the env I tested.

@eps1lon I believe that you have provided a reproduction of the delay in #21411 (comment) for Ubuntu 18.04 Firefox 77.0.1 as I could reproduce it for all the env I tested.

The video shows to me that firefox does not have this issue. At least chrome and firefox have different behaviors which is why I asked for clarification. The current explanation tells me firefox is working correctly.

@eps1lon I had this delay in mind, notice the white area:

I had this delay in mind, notice the white area:

But in the issue you talked about the switch from scale to translate being the reason which is obviously not the case from the firefox behavior. This is why I asked for clarification since you assume a lot of information in your statements. From the information included in the GitHub issue and PR it's not clear what is going on.

The lag you're describing can be observed prior to #21411: https://codesandbox.io/s/material-progress-scale-9rcwo?file=/package.json
Again, I'm cautioning against handwaving this issue for a smart sounding, technical description.
There are at least 2 different issues mixed together here and it's not clear which of those are browser, React or Material-UI issues.

the switch from scale to translate being the reason which is obviously not the case from the firefox behavior

@eps1lon Agree, I think that you proved me wrong on this end. I was on the wrong track. It seems that it has more to do with how Blink handles the rendering internally.

And you're still using "Hz". This is a generic term. Frames/s, commits/s, renders/s?

Sorry, I was referring to renders/s. Agree, clearing potential confusion is important.

The lag you're describing can be observed prior to #21411

Agree, let's leave this issue outside of the equation. It explains the observed behavior at a superficial level, it doesn't tall much about what's really going on.

There are at least 2 different issues mixed together here and it's not clear which of those are browser, React or Material-UI issues.

Agree, the pull request is now covering a related but not directly linked problem. I have updated the description:

@dnicerio Thanks for the help

@dnicerio Thanks for the help

happy to help


Reading input data from HDF5 file

Is it possible to read input data from hdf5 file?

The main reason being that there is currently no support for reading HDF5 AMR data in AMReX.

Closing this as implementation is not planned and would be dependent on AMReX development


moved "write a connector" content from  connector sample to doc

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

This is the first step in revising the docs, right Json?

This is the first step in revising the docs, right Jason?

Yes, Sam.  Just the first edit.

I defer to @scsewall, @swwilson-bsi, and/or @kabentley on the content. My only suggestion is to add a note explaining that "bridge" in names like BridgeRunner is a synonym for "connector" - I expect that discrepancy will confuse users.

Paul did you see line 2? "Note: iTwin Connectors were also known as iModel Bridges.  Though the term "iModel Bridge" has been deprecated in fovor of "iTwin Connector", for legacy and backward compatibility reasons, you may find the older terminology used in this documentation.  You can consider them the same."

Paul did you see line 2?

Nope. Thanks.

@abeesh is the original author of this doc, and so I defer to him on the changes and the plan to change the bridge terminology.
One comment: I think we should make a clearer that the the developer who writes a connector does not have to write the change-detection logic. The BridgeRunner(?) class does that. I would therefore shorten or remove the section that describes change-detection. Could we add some scraps of sample code to this doc, to make it more concrete?

@abeesh is the original author of this doc, and so I defer to him on the changes and the plan to change the bridge terminology.
One comment: I think we should make a clearer that the the developer who writes a connector does not have to write the change-detection logic. The BridgeRunner(?) class does that. I would therefore shorten or remove the section that describes change-detection. Could we add some scraps of sample code to this doc, to make it more concrete?

BridgeRunner

@scsewall BridgeRunner is a class which I assume I can't rename.  I can point out that the class named has been retained for legacy and backward compatibility purposes, but, will be referred to as a ConnectorRunner.  I supposed we can introduce a new class ConnectorRunner which inherits from BridgeRunner.

BridgeRunner

@scsewall BridgeRunner is a class which I assume I can't rename.  I can point out that the class named has been retained for legacy and backward compatibility purposes, but, will be referred to as a ConnectorRunner.  I supposed we can introduce a new class ConnectorRunner which inherits from BridgeRunner.

I supposed we can introduce a new class ConnectorRunner which inherits from BridgeRunner.
If we want to make ConnectorRunner the official name, we should rename BridgeRunner. If we are concerned about breaking APIs by doing so, we can add export type BridgeRunner = ConnectorRunner and deprecate it.

I supposed we can introduce a new class ConnectorRunner which inherits from BridgeRunner.
If we want to make ConnectorRunner the official name, we should rename BridgeRunner. If we are concerned about breaking APIs by doing so, we can add export type BridgeRunner = ConnectorRunner and deprecate it.

@jchick-bentley can this be abandoned in favor of the changes in #701 ?

@jchick-bentley can this be abandoned in favor of the changes in #701 ?

@calebmshafer I'll have to discuss w/ @timlawrence-bentley looks like we were both assigned overlapping tasks.  My task, this pull request was to replace parts of the "write a bridge" documentation with some more current documentation.  Looks like he was updating the "write a bridge" documentation that's already there.  I suppose if you abandon this PR, I'll still have my fork so that I'll be able to recover the work that was already done.  Please abandon the PR if that's in the best interest of imodeljs.

@jchick-bentley sounds good. I'm going to close it out for now until you get a chance to get back to it.


Follow logs from service

One feature that at the moment we don't have but could be good is
a command to follow logs for a particular service.
With this PR I am trying to implement this feature and also grab some
information about this feature.
This is my first contribution and plese let me know if this idea is
completly wrong.
If someone has feedback for my this is a checklist about my next steps

[x] Bootstrap new command swarmctl service logs <service-name>
[x] Grab containerId for each task running
[ ] obtain logs from this list of containers
[ ] Print something of good to see
[ ] Implement flags like -f to follow or not a stream

Signed-off-by: Gianluca Arbezzano<EMAIL_ADDRESS>

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "feature/service-logs" git@github.com:gianarb/swarmkit.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

[Current coverage][cc-pull] is 53.83%

Merging [#1050][cc-pull] into [master][cc-base-branch] will increase coverage by 0.16%

@@             master      #1050   diff @@
==========================================
  Files            75         75
  Lines         11659      11660     +1
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           6257       6277    +20
+ Misses         4501       4484    -17
+ Partials        901        899     -2

[][cc-pull]

Powered by Codecov. Last updated by [5f1106a...b96fdd1][cc-compare]
[cc-base-branch]: https://codecov.io/gh/docker/swarmkit/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/docker/swarmkit/compare/5f1106a1fd8ba2688b6ebb0a9f0625b3fb622e41...b96fdd15d9809faee79345798fc57e14ced262af
[cc-pull]: https://codecov.io/gh/docker/swarmkit/pull/1050?src=pr

There are a log of complexities in collecting logs in cluster. There are simple approaches that work for a small number of containers or a small cluster. However, when the volume of logs goes way up, these approaches fall over.
For the most part, swarmkit's cli tools are just for testing out cluster orchestration primitives. Typically, I just grab logs directly from docker if I really need to dig in, so having it built in here doesn't provide much.
For docker swarm mode, log drivers are being implemented in https://github.com/docker/swarmkit/pull/1111. They can be used for larger clusters, but they will still have the same limitations of log drivers in Docker.

Thanks

Thank you for contributing!

@thaJeztah please let me know if I can help :) I am spending time to understand how.. but it's not easy :D bye


Data race between worker threads sharing a buffer

What happened?
Recently a patch is revered: https://github.com/iree-org/iree/commit/ab8f6680e20b2dbc3cb497656321302732ea0c19 as it caused intermittent test failures on ARM64 builds.
Further investigation shows that on arm64, threadsanitizer complains data race in memset, however the tsan stack trace does not give much insight into which part exactly caused it. ASan did not complain on failed test runs.
The reproduce rate is <10%, MacOS and Arm64 Linux are reproducible. The TSan log is attached.
LastTest.log
Steps to reproduce your issue

revert the revert patch: https://github.com/iree-org/iree/commit/ab8f6680e20b2dbc3cb497656321302732ea0c19
compile with option -DIREE_ENABLE_TSAN=ON on an ARM machine
run with ctest -R narrow_n_matmul and see the error.

What component(s) does this issue relate to?
Runtime
Version information
commit ab8f6680e20b2dbc3cb497656321302732ea0c19
Additional context
No response

Interpreting the TSan log:
Two worker threads, Thread T57 'iree-worker-0' and Thread T64 'iree-worker-7', are accessing a shared memory buffer without adequate ordering.
T57 is trying to map the buffer, which thanks to the IREE_HAL_MEMORY_ACCESS_DISCARD flag + assertions enable, is a memory write, helping making this reproduce consistently in TSan:
  Write of size 8 at 0xffffee603b80 by thread T57:
    #0 memset <null> (iree-check-module+0x15511c) (BuildId: d50e3fb55e5361f2)
    #1 iree_hal_heap_buffer_map_range /Users/lialan/workspace/iree/runtime/src/iree/hal/buffer_heap.c:270:5 (iree-check-module+0x24be8c) (BuildId: d50e3fb55e5361f2)

Note: the buffer_heap.c code in above frame #1 writing those 0xCD bytes:
https://github.com/iree-org/iree/blob/4fddac063bf413945fbde6b55ebcf392e0901717/runtime/src/iree/hal/buffer_heap.c#L268-L272
T64 had previously written to the buffer inside of dispatch function code:
  Previous write of size 8 at 0xffffee603b80 by thread T64:
    #0 <null> <null> (iree_dylib_CtHR1K_mem_.so+0x12ee8)
    #1 iree_hal_system_executable_issue_call /Users/lialan/workspace/iree/runtime/src/iree/hal/local/loaders/system_library_loader.c:331:13 (iree-check-module+0x4a90a8) (BuildId: d50e3fb55e5361f2)

A question for @benvanik - when two worker threads cooperate on a buffer, where is the synchronization code that is meant to prevent a data race? Is there code meant to ensure that no two tasks sharing a buffer can be scheduled concurrently?

There's nothing that implicitly synchronizes access. If two concurrently executing operations access the same locations in memory they must use atomics to do their work.
I don't know what the above is, but that looks like a miscompile in codegen or a TSAN misidentification: a command buffer copy and a dispatch should not be accessing the same memory concurrently.

That's what I'm asking about: when you say "a command buffer copy and a dispatch should not be accessing the same memory concurrently", what specific piece of code implements that "should not" ?

The compiler must insert barriers - the lack of barriers implies no synchronization is required. The barriers show as structured statements in the stream IR with any sibling operations within a stream.async.concurrent/stream.cmd.concurrent having no barriers between them and all peer operations to the concurrent having barriers. In HAL the barriers are hal.command_buffer.execution_barrier, and at runtime they are recorded as iree_hal_command_buffer_execution_barrier. On the task execution system the barriers become links between the tasks. If the compiler has an execution barrier between a dispatch and a copy then at runtime the task issuing the last workgroup of a dispatch will be what queues up the tasks for the copies and no copy task will run before any of the dispatch workgroup tasks have completed.

Oh i see, it's in the compiler generated code. I was mistakenly looking for barriers in the runtime. OK, so that means we should be looking at IR. Can you suggest where to look?
@lialan can you edit the source of that narrow_n_matmul test to keep only the failing testcase module.batch_matmul_narrow_n_2 and then compile it with -mlir-disable-threading -mlir-print-ir-after-all and upload the resulting log?

--compile-to=stream will show you the stream level and you'll be able to see if the operations are expected to be run concurrently (if they're in a stream.cmd.concurrent together)

ah ok. that's going to be much lighter than -mlir-print-ir-after-all, thanks.

@benvanik @bjacob Attaching the dumps:
This one generated by: ./tools/iree-compile --iree-hal-target-backends=llvm-cpu --iree-global-opt-enable-early-materialization=false --compile-to=stream -mlir-disable-threading:
stream_out.txt
This one is just print-after-all:
print_after_all.txt

lol your print ir after all dump is truncated because TSAN is catching a signal:
iree-compile: iree/compiler/src/iree/compiler/Codegen/Common/CPU/CPUMaterializeEncodingPass.cpp:339: mlir::iree_compiler::TileMxNxK mlir::iree_compiler::chooseMatmulTile(ArrayRef<mlir::iree_compiler::TileMxNxK>, int64_t, int64_t, ArrayRef<int64_t>): Assertion `(hostDefinedUpperBound.empty() || hostDefinedUpperBound.size() == 3) && "expected hostDefinedUpperBound is empty or has upper bound for {M, " "N, K}"' failed.

that may be the root cause of the issue here and you should check on that.
The IR as it pertains to runtime scheduling seems fine to me.
This reads as 3 dispatches doing set_encoding concurrently reading and writing independent buffer ranges (I don't know why you're encoding the result - seems silly, but whatever :), a matmul consuming those results, and then an unset_encoding and copy concurrently operating independent buffer ranges.
    %11 = stream.cmd.execute await(%10) => with(%2 as %arg0: !stream.resource<constant>{%7}, %4 as %arg1: !stream.resource<constant>{%8}, %6 as %arg2: !stream.resource<constant>{%9}, %__constant_tensor_2x3x2xi32 as %arg3: !stream.resource<constant>{%c256}, %result as %arg4: !stream.resource<external>{%c128}, %result_0 as %arg5: !stream.resource<transient>{%c3072}) {
      stream.cmd.concurrent {
        stream.cmd.dispatch @_batch_matmul_narrow_n_2_dispatch_0::@_batch_matmul_narrow_n_2_dispatch_0_set_encoding_LHS_2x3x4 {
          ro %arg0[%c0 for %7] : !stream.resource<constant>{%7},
          wo %arg5[%c0 for %c512] : !stream.resource<transient>{%c3072}
        }
        stream.cmd.dispatch @_batch_matmul_narrow_n_2_dispatch_1::@_batch_matmul_narrow_n_2_dispatch_1_set_encoding_RHS_2x4x2 {
          ro %arg1[%c0 for %8] : !stream.resource<constant>{%8},
          wo %arg5[%c512 for %c512] : !stream.resource<transient>{%c3072}
        }
        stream.cmd.dispatch @_batch_matmul_narrow_n_2_dispatch_2::@_batch_matmul_narrow_n_2_dispatch_2_set_encoding_RESULT_2x3x2 {
          ro %arg2[%c0 for %9] : !stream.resource<constant>{%9},
          wo %arg5[%c1024 for %c2048] : !stream.resource<transient>{%c3072}
        }
      }
      stream.cmd.dispatch @_batch_matmul_narrow_n_2_dispatch_3::@_batch_matmul_narrow_n_2_dispatch_3_batch_matmul_2x3x2x4_i8xi8xi32 {
        ro %arg5[%c0 for %c512] : !stream.resource<transient>{%c3072},
        ro %arg5[%c512 for %c512] : !stream.resource<transient>{%c3072},
        rw %arg5[%c1024 for %c2048] : !stream.resource<transient>{%c3072}
      }
      stream.cmd.concurrent {
        stream.cmd.dispatch @_batch_matmul_narrow_n_2_dispatch_4::@_batch_matmul_narrow_n_2_dispatch_4_unset_encoding_RESULT_2x3x2 {
          ro %arg5[%c1024 for %c2048] : !stream.resource<transient>{%c3072},
          wo %arg4[%c0 for %c48] : !stream.resource<external>{%c128}
        }
        stream.cmd.copy %arg3[%c0], %arg4[%c64], %c48 : !stream.resource<constant>{%c256} -> !stream.resource<external>{%c128}
      }
    } => !stream.timepoint

Since there's no reuse here there's really not anything within the two concurrent regions that could have TSAN conflicts unless the dispatches are incorrectly touching memory. For example, if the unset_encoding is touching %arg4 outside of the range of [0,48) bytes then it will stomp on the copy touching [64,112).
The address at fault in the TSAN report is 256B into the allocation but we slab allocate so that doesn't mean 256B into the buffer (as there's the buffer header in there). The HAL IR or a runtime --trace_execution dump would show what the HAL is doing with its copy buffer (I'm guessing it'll be offset 64 for length 48 as in the IR above), in which case the unset_encoding may be the culprit.

(I do suspect that assertion is guarding correct behavior, and we really should not be relying on assertions for things like that - if analysis fails then we need to error out properly)

lol your print ir after all dump is truncated because TSAN is catching a signal:
iree-compile: iree/compiler/src/iree/compiler/Codegen/Common/CPU/CPUMaterializeEncodingPass.cpp:339: mlir::iree_compiler::TileMxNxK mlir::iree_compiler::chooseMatmulTile(ArrayRefmlir::iree_compiler::TileMxNxK, int64_t, int64_t, ArrayRef<int64_t>): Assertion `(hostDefinedUpperBound.empty() || hostDefinedUpperBound.size() == 3) && "expected hostDefinedUpperBound is empty or has upper bound for {M, " "N, K}"' failed.

Darn, thanks, that is indeed related to the PR that triggers this. Looking into this.

(I don't know why you're encoding the result - seems silly, but whatever :)

it's just a misnomer - we're encoding the input accumulator here; encodings don't care about input vs output though, so it's really just the accumulator encoding, which got named the result encoding, which is fair when we're talking about the output accumulator, which is the result, but is confusing when talking about the input accumulator.

I see, the assert failure reproduces only with --iree-global-opt-enable-early-materialization=false.

It's actually a red herring / unrelated issue. In particular, --iree-global-opt-enable-early-materialization=false is only passed in the e2e matmul tests but not in that narrow_n_matmul test that is also failing. The assert only fails for batch cases because the 4th dimension causes that array to have size 4, defeating the assertion that it has to be 0 or 3. The fix is trivial but doesn't change the race condition we're observing at runtime.
Fix:
diff --git a/compiler/src/iree/compiler/Codegen/Common/CPU/CPUMaterializeEncodingPass.cpp b/compiler/src/iree/compiler/Codegen/Common/CPU/CPUMaterializeEncodingPass.cpp
index c1948b9418..64e9ad3216 100644
--- a/compiler/src/iree/compiler/Codegen/Common/CPU/CPUMaterializeEncodingPass.cpp
+++ b/compiler/src/iree/compiler/Codegen/Common/CPU/CPUMaterializeEncodingPass.cpp
@@ -334,7 +334,7 @@ static TileMxNxK
 chooseMatmulTile(ArrayRef<TileMxNxK> enumeratedTiles, int64_t matmulNarrowM,
                  int64_t matmulNarrowN,
                  ArrayRef<int64_t> hostDefinedUpperBound = {}) {
-  assert((hostDefinedUpperBound.empty() || hostDefinedUpperBound.size() == 3) &&
+  assert((hostDefinedUpperBound.empty() || hostDefinedUpperBound.size() >= 3) &&
          "expected hostDefinedUpperBound is empty or has upper bound for {M, "
          "N, K}");
   // Handle narrow-N by transposing to reduce to narrow-M. Note: the
diff --git a/compiler/src/iree/compiler/Codegen/Common/EncodingUtils.cpp b/compiler/src/iree/compiler/Codegen/Common/EncodingUtils.cpp
index 83874316f8..cfb11c36f0 100644
--- a/compiler/src/iree/compiler/Codegen/Common/EncodingUtils.cpp
+++ b/compiler/src/iree/compiler/Codegen/Common/EncodingUtils.cpp
@@ -65,10 +65,10 @@ static RankedTensorType transposeIfNarrowNResult(RankedTensorType tensorType) {

   // auto newRoundDimsTo = encoding.getRoundDimsToArray();
   SmallVector<int64_t> newRoundDimsTo(encoding.getRoundDimsToArray());
-  assert(newRoundDimsTo.size() == 0 || newRoundDimsTo.size() == 3);
-  if (newRoundDimsTo.size() != 0)
-    std::swap(newRoundDimsTo[0], newRoundDimsTo[1]);
-
+  assert(newRoundDimsTo.size() == 0 || newRoundDimsTo.size() >= 3);
+  if (newRoundDimsTo.size() != 0) {
+    std::swap(newRoundDimsTo[newRoundDimsTo.size() - 3], newRoundDimsTo[newRoundDimsTo.size() - 2]);
+  }
   auto context = tensorType.getContext();
   AffineMap permutation = AffineMap::getPermutationMap(permIndices, context);
   for (auto &map : maps) {

However: that is a lot of gratuitous complexity here from the fact that RoundDimsTo is an array... while in practice all entries in it are initialized as 16 in SetEncoding. We should make RoundDimsTo a single scalar for all dimensions that this rounding may apply to, which would simplify a lot of code @hanhanW  (also, we would never want to apply that to the batch dimension, so the 16 there was meaningless).
Here is the print-ir-after-all regenerated with that so that we get past this assertion:
https://gist.githubusercontent.com/bjacob/d88eed55cb9b57771f1ddbe1b9cbaa05/raw/7efc2fb97173603a9e8bd86cbc53f96b6be9d544/log.mlir
@benvanik  PTAL?

@benvanik , for this to manifest only on arm64, this must be almost correct and only incorrect in some lower-level detail. So it's not surprising that looking at Stream above, everything was OK. I'm curious how these things get lowered down to synchronization primitives later on (HAL?) hopefully something we can see now with the print-ir-after-all in the previous comment (getting past that assertion).
Can you pinpoint the ops implementing both sides of the synchronization that should be happening, and point to their C implementations, so we can start to reason about what they are doing?

There's no difference across targets on the runtime side. If this is only showing with arm64 you'll definitely need to look at your dispatches. Perhaps it's something that TSAN on other targets is not catching that arm64 is though that's doubtful that there's target-specific functionality in TSAN - though maybe it's target-specific rules that only apply there. AFAIK the only variances in sanitizers have been around aligned/unaligned accesses and such, but sanitizers work in mysterious ways (sometimes AFAICT not even known to the creators :).
Nearly all times there's been an issue with clobbering data/races it's been in the dispatches. The only thing the host-side compiler/runtime does is provide appropriate buffer ranges to the dispatches and here they look correct. Assuming it's the dispatch_4 unset_encoding overlapping with the copy the dispatch_4 should only be writing bytes 0 to 48 (given %1 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c0) : !flow.dispatch.tensor<writeonly:tensor<2x3x2xi32>>) and the copy is scheduled to write 64 to 112 (given hal.command_buffer.copy_buffer<%cmd : !hal.command_buffer> source(%__constant_tensor_2x3x2xi32 : !hal.buffer)[%c0] target(%transient_buffer : !hal.buffer)[%c64] length(%c48)). I doubt there's a bug (but would gladly buy someone a beer if there was!) in the copy_buffer, so if the two are writing the same ranges concurrently then it's got to be in the dispatch. You can printf in iree_hal_command_buffer_copy_buffer or the iree_hal_heap_buffer_map_range to verify the range.

(if you can tell me 100% that the dispatch is never possibly accessing a range the copy is and the copy is writing to the correct range we can talk about how tasks are scheduled - I don't really think it's useful to go down that route until confident, though)

There's no difference across targets on the runtime side. If this is only showing with arm64 you'll definitely need to look at your dispatches.

(if you can tell me 100% that the dispatch is never possibly accessing a range the copy is and the copy is writing to the correct range we can talk about how tasks are scheduled - I don't really think it's useful to go down that route until confident, though)

Well it is true that this issue occurred on ARM64 CI. However given the fact that this is intermittent and recurrence rate is not 100%, we cannot rule out the possibility that it can be reproduced on other platforms as well.
@bjacob given the same configuration, is it true that we will reach a same/similar execution path on x86? Worth trying out?

Sure, worth retrying. The last time I tried on x86, I didn't retry enough times to be 100% sure.
I have pushed my fixes to the above assertion failure, on top of your transpose_rebase branch, to this branch on origin:
https://github.com/iree-org/iree/tree/bjacob-transpose-rebase-repro
Also sharing the small reproducer with just the failing testcase:
https://gist.github.com/bjacob/f248a132c0a9af929047b898936fa8c0
And my command line to build and run this with retrying until failure:
ninja iree-compile && tools/iree-compile --iree-hal-target-backends=llvm-cpu /tmp/a.mlir -o /tmp/a.vmfb
&& for i in `seq 1 100`; do tools/iree-check-module --module=/tmp/a.vmfb --device=local-task || break; done; echo; ec
ho "Failed after retrying $i times."

Here are my observations on Mac/arm64:

This reproduces only with --iree-hal-target-backends=llvm-cpu, not vmvx, not even with vmvx microkernels.
On llvm-cpu:

This reproduces with data-tiling (default). This does not reproduce when data-tiling is disabled.
This reproduces the same with or without early-materialization.
This reproduces with or without ukernels. However:

Without ukernels, only the first batch is incorrectly zero, the second batch is correct.
With ukernels, both batches are incorrectly zero.

Also, since we are considering the possibility of dispatches writing out of bounds, we should check ASan.

Here is the trace from --trace_execution: https://gist.github.com/bjacob/2e4146426d3d9af06ef6e4a3b4873e94

Tried >10000 runs with @bjacob 's branch and the script, 0 failure on x86.

From the trace, we see that the data race is between a dispatch that is the unpack of the matmul output, and a copy_buffer that is copying the golden test results that are passed as the RHS to check.expect_eq.
Notice that in the error message, the erroneous side is the RHS --- which is, the golden results:
  check.expect_eq_const(%result, dense<[
    [[0, 11], [7, -1], [-17, 14]],
    [[-11, -1], [-29, -15], [-24, -18]]
  ]> : tensor<2x3x2xi32>) : tensor<2x3x2xi32>

so the dispatch 4, which does the unpack, is overwriting the golden results with zeros.
Looking at the trace, this makes sense as both the dispatch 4 and the copy_buffer are scheduled concurrently writing to the same destination buffer. They are writing with different offsets that should be safe, but all is consistent with a bug in dispatch 4 writing zeros past the end of its normal output span.
[module.batch_matmul_narrow_n_2+000003AD]    vm.call.varadic @hal.command_buffer.push_descriptor_set(%r10(!hal.command_buffer/0x0x13f00a800), %r2(!hal.pipeline_layout/0x0x13e904e90), %i9(0), %i9(0), %i9(0), %r0(!hal.buffer/0x0x13e9053c0), %i16(0), %i28(256), %i6(1), %i9(0), %r9(!hal.buffer/0x0x13e905200), %i16(0), %i22(128))
[module.batch_matmul_narrow_n_2+000003DA]    vm.call @hal.command_buffer.dispatch(%r10(!hal.command_buffer/0x0x13f00a800), %r3(!hal.executable/0x0x13e904f30), %i4(4), %i3(2), %i6(1), %i6(1))
[module.batch_matmul_narrow_n_2+000003F0]    vm.br ^000003F8()
[module.batch_matmul_narrow_n_2+000003F9]    vm.call @hal.command_buffer.copy_buffer(%r10(!hal.command_buffer/0x0x13f00a800), %r1(!hal.buffer/0x0x13e904980), %i16(0), %r9(!hal.buffer/0x0x13e905200), %i26(64), %i20(48))

Here we see that both are writing to the buffer at 0x0x13e905200, which has size 128.

dispatch 4 should be writing 48 bytes at offset 0.
copy_buffer is writing 48 bytes at offset 64.

So this looks like dispatch 4 is writing zeros past the end of its normal output span.
Specifically:

With default codegent, it overwrites the first 24 bytes of the golden values, meaning offsets 64--88, meaning it's writing 40 bytes of zeros past its normal end at offset 48.
With ukernels, it overwrites the whole 48 bytes of golden values, meaning offsets 64--112, meaning it's writing 64 bytes past its normal end at offset 48.

(So this is exactly what Ben was saying, and our next step is to look closely at arm64 codegen.)

Here is the disassembly of the actual arm64 module code when it reproduced, for that dispatch. Assuming that nothing outside of the target library call function would be writing zeros to buffers, the faulty zeros writes have to be done by this code?
0000000000003898 <__batch_matmul_narrow_n_2_dispatch_4_unpack_i32>:
    3898: b9400048     	ldr	w8, [x2]
    389c: 7100051f     	cmp	w8, #0x1
    38a0: 540003a8     	b.hi	0x3914 <__batch_matmul_narrow_n_2_dispatch_4_unpack_i32+0x7c>
    38a4: a9bf7bfd     	stp	x29, x30, [sp, #-0x10]!
    38a8: 910003fd     	mov	x29, sp
    38ac: f940102a     	ldr	x10, [x1, #0x20]
    38b0: b9400c29     	ldr	w9, [x1, #0xc]
    38b4: 5280030b     	mov	w11, #0x18              ; =24
    38b8: a940294c     	ldp	x12, x10, [x10]
    38bc: 9bab290d     	umaddl	x13, w8, w11, x10
    38c0: 8b09052b     	add	x11, x9, x9, lsl #1
    38c4: d37ae52a     	lsl	x10, x9, #6
    38c8: 8b08198c     	add	x12, x12, x8, lsl #6
    38cc: d37df16b     	lsl	x11, x11, #3
    38d0: 910081ad     	add	x13, x13, #0x20
    38d4: 9102818c     	add	x12, x12, #0xa0
    38d8: ad7f8182     	ldp	q2, q0, [x12, #-0x10]
    38dc: 8b090108     	add	x8, x8, x9
    38e0: 3cde0181     	ldur	q1, [x12, #-0x20]
    38e4: 3dc00583     	ldr	q3, [x12, #0x10]
    38e8: f100091f     	cmp	x8, #0x2
    38ec: 8b0a018c     	add	x12, x12, x10
    38f0: 4e803824     	zip1.4s	v4, v1, v0
    38f4: 4e807820     	zip2.4s	v0, v1, v0
    38f8: 4e833841     	zip1.4s	v1, v2, v3
    38fc: 4e837842     	zip2.4s	v2, v2, v3
    3900: ad3f01a4     	stp	q4, q0, [x13, #-0x20]
    3904: ad0009a1     	stp	q1, q2, [x13]
    3908: 8b0b01ad     	add	x13, x13, x11
    390c: 54fffe63     	b.lo	0x38d8 <__batch_matmul_narrow_n_2_dispatch_4_unpack_i32+0x40>
    3910: a8c17bfd     	ldp	x29, x30, [sp], #0x10
    3914: 2a1f03e0     	mov	w0, wzr
    3918: d65f03c0     	ret

Given the dispatch is 2x1x1 you know it's called twice and there should be two iree_hal_cmd_dispatch_tile calls.
that function is what sets up the args:
https://github.com/iree-org/iree/blob/main/runtime/src/iree/hal/drivers/local_task/task_command_buffer.c#L842-L879
The dispatch functions take 3 args: environment, dispatch state, and workgroup state:
https://github.com/iree-org/iree/blob/main/runtime/src/iree/hal/local/loaders/embedded_elf_loader.c#L210-L212
on arm64 that should be (I believe) x0, x1, x2.
    3898: b9400048     	ldr	w8, [x2]   // workgroup_id_x
    38ac: f940102a     	ldr	x10, [x1, #0x20]  // binding_ptrs[]
    38b0: b9400c29     	ldr	w9, [x1, #0xc]  // workgroup_count_x
    38b8: a940294c     	ldp	x12, x10, [x10]  // binding_ptrs[0]

... I can't immediately find where binding_ptrs[1] gets retrieved (hooray compilers)?
    3900: ad3f01a4     	stp	q4, q0, [x13, #-0x20]
    3904: ad0009a1     	stp	q1, q2, [x13]

looks a bit suspicious though for a function expected to write only 48 bytes? I don't know arm64, but that reads like two 256bit stores as -32 and 0 meaning 64 bytes per loop iteration, and we know the function is dispatched twice? (maybe only one loop each, but that's always more than 48?)
(haven't had coffee yet, hopefully that's not all wrong :)

looks a bit suspicious though for a function expected to write only 48 bytes? I don't know arm64, but that reads like two 256bit stores at -32 and 0 meaning 64 bytes per loop iteration, and we know the function is dispatched twice? (maybe only one loop each, but that's always more than 48?)

Yes, sorry, that is caused by a local patch that I have in the above-referenced branch that sets the TileMxNxK tile size to 8, 8, 4 to remove one of the ways that things differ based on target details. Funny, this doesn't really change the symptoms, but I'll now try without it / with other values.

So, here is where the specific padding sizes are coming from. This is a i8 x i8 -> i32 matmul on baseline arm64, so our logic in CPUMaterializeEncodingPass returns these possible tile sizes:
    return {
        TileMxNxK{4, 16, 2},
        TileMxNxK{2, 16, 2},
        TileMxNxK{1, 16, 2},
    };

Now, the result shape in the source program is 2(batch) x 3(M) x 2 (N) x i32.
This has both narrow M and narrow N, but N is smaller, so it triggers our transpose-narrow-N logic (the PR that triggers the whole thing here) and the result shape becomes:
2(batch) x 2(M) x 3(N) x i32
Looking at the above TileMxNxK, we have one for M==2, it's TileMxNxK{2, 16, 2}, meaning M=2, N=16, K=2, so we select that one, and in terms of padding our result matrix, that becomes:
2(batch) x 2(M) x 16(N) x i32
So each tile is 2x16xi32 = 128 bytes.
    38d8: ad7f8182     	ldp	q2, q0, [x12, #-0x10]
    38dc: 8b090108     	add	x8, x8, x9
    38e0: 3cde0181     	ldur	q1, [x12, #-0x20]
    38e4: 3dc00583     	ldr	q3, [x12, #0x10]

This reads 64 contiguous bytes, so that's half a tile. Our loop should run for 2 iterations to complete the tile.
    3900: ad3f01a4     	stp	q4, q0, [x13, #-0x20]
    3904: ad0009a1     	stp	q1, q2, [x13]

That is storing 64 contiguous bytes: that is wrong. The destination shape is an incomplete tile, so there needs to be some extract_slice codegen.

; Function Attrs: <Unknown attribute>
define internal i32 @_batch_matmul_narrow_n_2_dispatch_4_unpack_i32(ptr noalias nonnull align 16 %0, ptr noalias nonnull align 16 %1, ptr noalias nonnull align 16 %2) #0 !dbg !111 {
  %4 = load %iree_hal_executable_dispatch_state_v0_t, ptr %1, align 8, !dbg !112
  %5 = extractvalue %iree_hal_executable_dispatch_state_v0_t %4, 10, !dbg !112
  %6 = load ptr, ptr %5, align 8, !dbg !112
  %7 = getelementptr i32, ptr %6, i32 32, !dbg !112
  %8 = ptrtoint ptr %7 to i64, !dbg !112
  %9 = and i64 %8, 63, !dbg !112
  %10 = icmp eq i64 %9, 0, !dbg !112
  call void @llvm.assume(i1 %10), !dbg !112
  %11 = load %iree_hal_executable_dispatch_state_v0_t, ptr %1, align 8, !dbg !113
  %12 = extractvalue %iree_hal_executable_dispatch_state_v0_t %11, 10, !dbg !113
  %13 = getelementptr ptr, ptr %12, i32 1, !dbg !113
  %14 = load ptr, ptr %13, align 8, !dbg !113
  %15 = ptrtoint ptr %14 to i64, !dbg !113
  %16 = and i64 %15, 63, !dbg !113
  %17 = icmp eq i64 %16, 0, !dbg !113
  call void @llvm.assume(i1 %17), !dbg !113
  %18 = load %iree_hal_executable_workgroup_state_v0_t, ptr %2, align 8, !dbg !114
  %19 = extractvalue %iree_hal_executable_workgroup_state_v0_t %18, 0, !dbg !114
  %20 = zext i32 %19 to i64, !dbg !114
  %21 = load %iree_hal_executable_dispatch_state_v0_t, ptr %1, align 8, !dbg !114
  %22 = extractvalue %iree_hal_executable_dispatch_state_v0_t %21, 4, !dbg !114
  %23 = zext i32 %22 to i64, !dbg !114
  br label %24, !dbg !115

24:                                               ; preds = %27, %3
  %25 = phi i64 [ %77, %27 ], [ %20, %3 ]
  %26 = icmp slt i64 %25, 2, !dbg !115
  br i1 %26, label %27, label %78, !dbg !115

27:                                               ; preds = %24
  %28 = mul i64 %25, 16, !dbg !115
  %29 = add i64 %28, 0, !dbg !115
  %30 = add i64 %29, 0, !dbg !115
  %31 = add i64 %30, 0, !dbg !115
  %32 = add i64 %31, 0, !dbg !115
  %33 = getelementptr i32, ptr %7, i64 %32, !dbg !115
  %34 = load <8 x i32>, ptr %33, align 4, !dbg !115
  %35 = add i64 %30, 8, !dbg !115
  %36 = add i64 %35, 0, !dbg !115
  %37 = getelementptr i32, ptr %7, i64 %36, !dbg !115
  %38 = load <8 x i32>, ptr %37, align 4, !dbg !115
  %39 = shufflevector <8 x i32> %34, <8 x i32> %34, <16 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>, !dbg !115
  %40 = shufflevector <16 x i32> %39, <16 x i32> zeroinitializer, <16 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 24, i32 25, i32 26, i32 27, i32 28, i32 29, i32 30, i32 31>, !dbg !115
  %41 = shufflevector <8 x i32> %38, <8 x i32> %38, <16 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>, !dbg !115
  %42 = shufflevector <16 x i32> %41, <16 x i32> %40, <16 x i32> <i32 16, i32 17, i32 18, i32 19, i32 20, i32 21, i32 22, i32 23, i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7>, !dbg !115
  %43 = shufflevector <16 x i32> %42, <16 x i32> %42, <16 x i32> <i32 0, i32 8, i32 1, i32 9, i32 2, i32 10, i32 3, i32 11, i32 4, i32 12, i32 5, i32 13, i32 6, i32 14, i32 7, i32 15>, !dbg !115
  %44 = shufflevector <16 x i32> %43, <16 x i32> %43, <2 x i32> <i32 0, i32 1>, !dbg !115
  %45 = shufflevector <16 x i32> %43, <16 x i32> %43, <2 x i32> <i32 2, i32 3>, !dbg !115
  %46 = shufflevector <16 x i32> %43, <16 x i32> %43, <2 x i32> <i32 4, i32 5>, !dbg !115
  %47 = shufflevector <16 x i32> %43, <16 x i32> %43, <2 x i32> <i32 6, i32 7>, !dbg !115
  %48 = shufflevector <16 x i32> %43, <16 x i32> %43, <2 x i32> <i32 8, i32 9>, !dbg !115
  %49 = shufflevector <16 x i32> %43, <16 x i32> %43, <2 x i32> <i32 10, i32 11>, !dbg !115
  %50 = shufflevector <16 x i32> %43, <16 x i32> %43, <2 x i32> <i32 12, i32 13>, !dbg !115
  %51 = shufflevector <16 x i32> %43, <16 x i32> %43, <2 x i32> <i32 14, i32 15>, !dbg !115
  %52 = mul i64 %25, 6, !dbg !115
  %53 = add i64 %52, 0, !dbg !115
  %54 = add i64 %53, 0, !dbg !115
  %55 = getelementptr i32, ptr %14, i64 %54, !dbg !115
  store <2 x i32> %44, ptr %55, align 4, !dbg !115
  %56 = add i64 %52, 2, !dbg !115
  %57 = add i64 %56, 0, !dbg !115
  %58 = getelementptr i32, ptr %14, i64 %57, !dbg !115
  store <2 x i32> %45, ptr %58, align 4, !dbg !115
  %59 = add i64 %52, 4, !dbg !115
  %60 = add i64 %59, 0, !dbg !115
  %61 = getelementptr i32, ptr %14, i64 %60, !dbg !115
  store <2 x i32> %46, ptr %61, align 4, !dbg !115
  %62 = add i64 %52, 6, !dbg !115
  %63 = add i64 %62, 0, !dbg !115
  %64 = getelementptr i32, ptr %14, i64 %63, !dbg !115
  store <2 x i32> %47, ptr %64, align 4, !dbg !115
  %65 = add i64 %52, 8, !dbg !115
  %66 = add i64 %65, 0, !dbg !115
  %67 = getelementptr i32, ptr %14, i64 %66, !dbg !115
  store <2 x i32> %48, ptr %67, align 4, !dbg !115
  %68 = add i64 %52, 10, !dbg !115
  %69 = add i64 %68, 0, !dbg !115
  %70 = getelementptr i32, ptr %14, i64 %69, !dbg !115
  store <2 x i32> %49, ptr %70, align 4, !dbg !115
  %71 = add i64 %52, 12, !dbg !115
  %72 = add i64 %71, 0, !dbg !115
  %73 = getelementptr i32, ptr %14, i64 %72, !dbg !115
  store <2 x i32> %50, ptr %73, align 4, !dbg !115
  %74 = add i64 %52, 14, !dbg !115
  %75 = add i64 %74, 0, !dbg !115
  %76 = getelementptr i32, ptr %14, i64 %75, !dbg !115
  store <2 x i32> %51, ptr %76, align 4, !dbg !115
  %77 = add i64 %25, %23, !dbg !115
  br label %24, !dbg !115

78:                                               ; preds = %24
  ret i32 0, !dbg !116
}

That is storing 64 contiguous bytes: that is wrong. The destination shape is an incomplete tile, so there needs to be some extract_slice codegen.

We know that the 64 bytes are because of the padding. So in the case of padding up, the allocation of the buffer should consider padding as well.

Some key steps from print-ir-after-all. @MaheshRavishankar , @hanhanW , at which step is this going wrong? The wrong behavior we are seeing here is that 8x2xi32 is being written where only 3x2xi32 should be. What are the semantics of the
%7 = vector.transfer_write %5, %6[%c0, %c0] {in_bounds = [true, true]} : vector<8x2xi32>, tensor<3x2xi32>

that is introduced at OptimizeTensorInsertExtractSlices? Does it have extract-slice semantics to correctly avoid writing more than 3x2, or is that inherently ill-formed?  If that is correct so far, then LLVMCPUVectorTransferLowering is incorrectly dropping the extract-slice semantics.
// -----// IR Dump After GenericVectorization (iree-codegen-generic-vectorization) //----- //
func.func @_batch_matmul_narrow_n_2_dispatch_4_unpack_i32() attributes {translation_info = #iree_codegen.translation_info<CPUDataTiling>} {
  %c0_i32 = arith.constant 0 : i32
  %c2 = arith.constant 2 : index
  %c128 = arith.constant 128 : index
  %c0 = arith.constant 0 : index
  %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c128) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<2x1x1x2x8xi32>>
  %1 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c0) : !flow.dispatch.tensor<writeonly:tensor<2x3x2xi32>>
  %workgroup_id_x = hal.interface.workgroup.id[0] : index
  %workgroup_count_x = hal.interface.workgroup.count[0] : index
  scf.for %arg0 = %workgroup_id_x to %c2 step %workgroup_count_x {
    %2 = flow.dispatch.tensor.load %1, offsets = [%arg0, 0, 0], sizes = [1, 3, 2], strides = [1, 1, 1] : !flow.dispatch.tensor<writeonly:tensor<2x3x2xi32>> -> tensor<1x3x2xi32>
    %3 = flow.dispatch.tensor.load %0, offsets = [%arg0, 0, 0, 0, 0], sizes = [1, 1, 1, 2, 8], strides = [1, 1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<2x1x1x2x8xi32>> -> tensor<1x1x1x2x8xi32>
    %extracted_slice = tensor.extract_slice %3[0, 0, 0, 0, 0] [1, 1, 1, 2, 8] [1, 1, 1, 1, 1] : tensor<1x1x1x2x8xi32> to tensor<2x8xi32>
    %4 = tensor.empty() : tensor<8x2xi32>
    %5 = vector.transfer_read %extracted_slice[%c0, %c0], %c0_i32 {in_bounds = [true, true]} : tensor<2x8xi32>, vector<2x8xi32>
    %6 = vector.transpose %5, [1, 0] : vector<2x8xi32> to vector<8x2xi32>
    %7 = vector.transfer_write %6, %4[%c0, %c0] {in_bounds = [true, true]} : vector<8x2xi32>, tensor<8x2xi32>
    %extracted_slice_0 = tensor.extract_slice %7[0, 0] [3, 2] [1, 1] : tensor<8x2xi32> to tensor<3x2xi32>
    %inserted_slice = tensor.insert_slice %extracted_slice_0 into %2[0, 0, 0] [1, 3, 2] [1, 1, 1] : tensor<3x2xi32> into tensor<1x3x2xi32>
    flow.dispatch.tensor.store %inserted_slice, %1, offsets = [%arg0, 0, 0], sizes = [1, 3, 2], strides = [1, 1, 1] : tensor<1x3x2xi32> -> !flow.dispatch.tensor<writeonly:tensor<2x3x2xi32>>
  }
  return
}

// -----// IR Dump After OptimizeTensorInsertExtractSlices (iree-codegen-optimize-tensor-insert-extract-slices) //----- //
func.func @_batch_matmul_narrow_n_2_dispatch_4_unpack_i32() attributes {translation_info = #iree_codegen.translation_info<CPUDataTiling>} {
  %c0_i32 = arith.constant 0 : i32
  %c2 = arith.constant 2 : index
  %c128 = arith.constant 128 : index
  %c0 = arith.constant 0 : index
  %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c128) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<2x1x1x2x8xi32>>
  %1 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c0) : !flow.dispatch.tensor<writeonly:tensor<2x3x2xi32>>
  %workgroup_id_x = hal.interface.workgroup.id[0] : index
  %workgroup_count_x = hal.interface.workgroup.count[0] : index
  scf.for %arg0 = %workgroup_id_x to %c2 step %workgroup_count_x {
    %2 = flow.dispatch.tensor.load %1, offsets = [%arg0, 0, 0], sizes = [1, 3, 2], strides = [1, 1, 1] : !flow.dispatch.tensor<writeonly:tensor<2x3x2xi32>> -> tensor<1x3x2xi32>
    %3 = flow.dispatch.tensor.load %0, offsets = [%arg0, 0, 0, 0, 0], sizes = [1, 1, 1, 2, 8], strides = [1, 1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<2x1x1x2x8xi32>> -> tensor<1x1x1x2x8xi32>
    %4 = vector.transfer_read %3[%c0, %c0, %c0, %c0, %c0], %c0_i32 {in_bounds = [true, true]} : tensor<1x1x1x2x8xi32>, vector<2x8xi32>
    %5 = vector.transpose %4, [1, 0] : vector<2x8xi32> to vector<8x2xi32>
    %6 = tensor.empty() : tensor<3x2xi32>
    %7 = vector.transfer_write %5, %6[%c0, %c0] {in_bounds = [true, true]} : vector<8x2xi32>, tensor<3x2xi32>
    %inserted_slice = tensor.insert_slice %7 into %2[0, 0, 0] [1, 3, 2] [1, 1, 1] : tensor<3x2xi32> into tensor<1x3x2xi32>
    flow.dispatch.tensor.store %inserted_slice, %1, offsets = [%arg0, 0, 0], sizes = [1, 3, 2], strides = [1, 1, 1] : tensor<1x3x2xi32> -> !flow.dispatch.tensor<writeonly:tensor<2x3x2xi32>>
  }
  return
}

// -----// IR Dump After LLVMCPUVectorTransferLowering (iree-llvmcpu-vector-transfer-lowering) //----- //
func.func @_batch_matmul_narrow_n_2_dispatch_4_unpack_i32() attributes {translation_info = #iree_codegen.translation_info<CPUDataTiling>} {
  %c7 = arith.constant 7 : index
  %c6 = arith.constant 6 : index
  %c5 = arith.constant 5 : index
  %c4 = arith.constant 4 : index
  %c3 = arith.constant 3 : index
  %c1 = arith.constant 1 : index
  %cst = arith.constant dense<0> : vector<2x8xi32>
  %c2 = arith.constant 2 : index
  %c128 = arith.constant 128 : index
  %c0 = arith.constant 0 : index
  %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c128) flags(ReadOnly) : memref<2x1x1x2x8xi32, strided<[16, 16, 16, 8, 1], offset: 32>, #hal.descriptor_type<storage_buffer>>
  memref.assume_alignment %0, 64 : memref<2x1x1x2x8xi32, strided<[16, 16, 16, 8, 1], offset: 32>, #hal.descriptor_type<storage_buffer>>
  %1 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c0) : memref<2x3x2xi32, #hal.descriptor_type<storage_buffer>>
  memref.assume_alignment %1, 64 : memref<2x3x2xi32, #hal.descriptor_type<storage_buffer>>
  %workgroup_id_x = hal.interface.workgroup.id[0] : index
  %workgroup_count_x = hal.interface.workgroup.count[0] : index
  scf.for %arg0 = %workgroup_id_x to %c2 step %workgroup_count_x {
    %subview = memref.subview %1[%arg0, 0, 0] [1, 3, 2] [1, 1, 1] : memref<2x3x2xi32, #hal.descriptor_type<storage_buffer>> to memref<1x3x2xi32, strided<[6, 2, 1], offset: ?>, #hal.descriptor_type<storage_buffer>>
    %subview_0 = memref.subview %0[%arg0, 0, 0, 0, 0] [1, 1, 1, 2, 8] [1, 1, 1, 1, 1] : memref<2x1x1x2x8xi32, strided<[16, 16, 16, 8, 1], offset: 32>, #hal.descriptor_type<storage_buffer>> to memref<1x1x1x2x8xi32, strided<[16, 16, 16, 8, 1], offset: ?>, #hal.descriptor_type<storage_buffer>>
    %subview_1 = memref.subview %subview_0[0, 0, 0, 0, 0] [1, 1, 1, 2, 8] [1, 1, 1, 1, 1] : memref<1x1x1x2x8xi32, strided<[16, 16, 16, 8, 1], offset: ?>, #hal.descriptor_type<storage_buffer>> to memref<2x8xi32, affine_map<(d0, d1)[s0] -> (d0 * 8 + d1 + s0)>, #hal.descriptor_type<storage_buffer>>
    %2 = vector.load %subview_1[%c0, %c0] : memref<2x8xi32, affine_map<(d0, d1)[s0] -> (d0 * 8 + d1 + s0)>, #hal.descriptor_type<storage_buffer>>, vector<8xi32>
    %3 = vector.insert %2, %cst [0] : vector<8xi32> into vector<2x8xi32>
    %4 = vector.load %subview_1[%c1, %c0] : memref<2x8xi32, affine_map<(d0, d1)[s0] -> (d0 * 8 + d1 + s0)>, #hal.descriptor_type<storage_buffer>>, vector<8xi32>
    %5 = vector.insert %4, %3 [1] : vector<8xi32> into vector<2x8xi32>
    %6 = vector.transpose %5, [1, 0] : vector<2x8xi32> to vector<8x2xi32>
    %subview_2 = memref.subview %subview[0, 0, 0] [1, 3, 2] [1, 1, 1] : memref<1x3x2xi32, strided<[6, 2, 1], offset: ?>, #hal.descriptor_type<storage_buffer>> to memref<3x2xi32, strided<[2, 1], offset: ?>, #hal.descriptor_type<storage_buffer>>
    %7 = vector.extract %6[0] : vector<2xi32> from vector<8x2xi32>
    vector.store %7, %subview_2[%c0, %c0] : memref<3x2xi32, strided<[2, 1], offset: ?>, #hal.descriptor_type<storage_buffer>>, vector<2xi32>
    %8 = vector.extract %6[1] : vector<2xi32> from vector<8x2xi32>
    vector.store %8, %subview_2[%c1, %c0] : memref<3x2xi32, strided<[2, 1], offset: ?>, #hal.descriptor_type<storage_buffer>>, vector<2xi32>
    %9 = vector.extract %6[2] : vector<2xi32> from vector<8x2xi32>
    vector.store %9, %subview_2[%c2, %c0] : memref<3x2xi32, strided<[2, 1], offset: ?>, #hal.descriptor_type<storage_buffer>>, vector<2xi32>
    %10 = vector.extract %6[3] : vector<2xi32> from vector<8x2xi32>
    vector.store %10, %subview_2[%c3, %c0] : memref<3x2xi32, strided<[2, 1], offset: ?>, #hal.descriptor_type<storage_buffer>>, vector<2xi32>
    %11 = vector.extract %6[4] : vector<2xi32> from vector<8x2xi32>
    vector.store %11, %subview_2[%c4, %c0] : memref<3x2xi32, strided<[2, 1], offset: ?>, #hal.descriptor_type<storage_buffer>>, vector<2xi32>
    %12 = vector.extract %6[5] : vector<2xi32> from vector<8x2xi32>
    vector.store %12, %subview_2[%c5, %c0] : memref<3x2xi32, strided<[2, 1], offset: ?>, #hal.descriptor_type<storage_buffer>>, vector<2xi32>
    %13 = vector.extract %6[6] : vector<2xi32> from vector<8x2xi32>
    vector.store %13, %subview_2[%c6, %c0] : memref<3x2xi32, strided<[2, 1], offset: ?>, #hal.descriptor_type<storage_buffer>>, vector<2xi32>
    %14 = vector.extract %6[7] : vector<2xi32> from vector<8x2xi32>
    vector.store %14, %subview_2[%c7, %c0] : memref<3x2xi32, strided<[2, 1], offset: ?>, #hal.descriptor_type<storage_buffer>>, vector<2xi32>
  }
  return
}

Note: if I drop OptimizeTensorInsertExtractSlicesPass from the LLVMCPU pipeline, it succeeds.

Whole IR-after-all log: https://gist.githubusercontent.com/bjacob/6b63c0513bdb41fde70722826acc9b40/raw/6c6bf993d3fd8fba1585c6695fafabbf9948ec19/log.mlir

nice investigation benoit!

We know that the 64 bytes are because of the padding. So in the case of padding up, the allocation of the buffer should consider padding as well.

this is the unset_encoding, which should be going from padded to unpadded, so it's the opposite case (IIUC)

(unrelated to this issue but it does highlight it: dispatching two workgroups to handle 64 bytes each is absurd, so this may be something to keep in mind as we try to make these more efficient - there's a lot of instructions between workgroup invocations including potential thread hops, so we want to be shooting for processing 1000-100000 elements and rarely ever <1000 - 128k-256k for parallel memcpy is kind of the minimum)

The change from
    %7 = vector.transfer_write %6, %4[%c0, %c0] {in_bounds = [true, true]} : vector<8x2xi32>, tensor<8x2xi32>
    %extracted_slice_0 = tensor.extract_slice %7[0, 0] [3, 2] [1, 1] : tensor<8x2xi32> to tensor<3x2xi32>
    %inserted_slice = tensor.insert_slice %extracted_slice_0 into %2[0, 0, 0] [1, 3, 2] [1, 1, 1] : tensor<3x2xi32> into tensor<1x3x2xi32>

to
    %7 = vector.transfer_write %5, %6[%c0, %c0] {in_bounds = [true, true]} : vector<8x2xi32>, tensor<3x2xi32>
    %inserted_slice = tensor.insert_slice %7 into %2[0, 0, 0] [1, 3, 2] [1, 1, 1] : tensor<3x2xi32> into tensor<1x3x2xi32>

should at the very least change the in_bounds = [true, true] to in_bounds = [false, true] . Without that the IR is wrong.... Not sure that is the final solution though.

It seems to me like the issue is that the transfer write is still in bounds after OptimizeTensorInsertExtractSlices. Before that it looks fine to me, so I'm guessing some pattern used by OptimizeTensorInsertExtractSlices is failing to update the in_bounds attribute.
This write is clearly the problem:
%7 = vector.transfer_write %5, %6[%c0, %c0] {in_bounds = [true, true]} : vector<8x2xi32>, tensor<3x2xi32>

I guess we can make that a masked write, but it should be out of bounds at least.

Looks like the pattern responsible for this rewrite is conservatively updating the in_bounds atrribute:
https://github.com/llvm/llvm-project/blob/7b6a89f346f281e5b7caa593a8c484eaf4264055/mlir/lib/Dialect/Vector/IR/VectorOps.cpp#L4648-L4649
Based on the comment there, I guess this is an issue with the transfer_write folder:
https://github.com/llvm/llvm-project/blob/7b6a89f346f281e5b7caa593a8c484eaf4264055/mlir/lib/Dialect/Vector/IR/VectorOps.cpp#L4479-L4490

The additional action item could be improving transfer_read/write's verifier. If there are no masks and the shape is static, we should check the size and in_bounds attributes.

As pointed out by @MaheshRavishankar and @hanhanW , can confirm the problem is caused by this line: https://github.com/iree-org/iree/blob/e52b8bf3d4c1e09cca661bc5345a4c0dce5a6f54/compiler/src/iree/compiler/Codegen/Common/FoldTensorSubsetIntoVectorTransferOps.cpp#L284

Bug fixed in #17563


Getting Started page going blank after loading

Description:

Getting started page seems to be going blank after sometime. But, when you move around the cursor, you can see that the buttons are still there (The click hand shows up. You can click as well).
Affected Product Version:
Integration Studio 7.1.0-Alpha
OS, DB, other environment details and versions:
Ubuntu 18.04, Firefox 59.0

Do we still have this issue for the GA version?
If so, we will add the following to the docs?

This issue is only for Firefox users.
And the issue is solved after upgrading to 77.0.1 version or above.

@arunans23 / @prabushi - Please confirm


Fix #446 - Bumped golangci v1.54.2 to v1.61.0 and corrected new lint …

Description
Bumps golangci v1.54.2 to v1.61.0.
Corrects some of the lint warnings.
Dependencies
n/a
Checklist
Sorry I have no idea about the process. Just getting it to work locally ;)

Hi @PMaynard
Thanks for this PR.
Curiously I don't see the problem that you mentioned, not sure why ... Removing + reinstalling golangci-lint 1.54.2 works for me. Anyway, it's a good thing to upgrade it.
/lgtm

/approve


Dilato: Core: Brackets website testing: The string "Search from 1400+ extensions" is truncated on extension registry page if the screen size is small [Wrong Repository]

Wrong repository.


Support InfluxDB v2 format

Goal: Wider database support
InfluxDB 2 has an updated format for receiving data - we should support it.
Introduction to InfluxDB 2 and Migration Procedure - might be useful.
Requested by Nordic Semiconductors

some things noticed so far:

use of API token rather than basic HTTP authentication
no mention of named databases; instead named "buckets"


Tagline updated

:warning: Validation status: warnings

File
Status
Preview URL
Details

rd/jussi-roine.yml
:warning:Warning

Details

rd/jussi-roine.yml

[Warning] the value Profile is undefined for metadata pagetype

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Building throws error

Finally after couple of days grinding my teeth i figured out the error was not my code but something with Parse SDK. So the 1.7.0 version is not working at all with android push (using with xamarin).
I read there were some fixes I need but not released to an official release.
Some guide how to build it and make it like a package that you get though nuget ? Because I tried download a clone and use xbuild on it but it throws an error:
/Users/admin/Downloads/Parse-SDK-dotNET-master/Parse.sln (default targets) ->
(Build target) ->
/Users/admin/Downloads/Parse-SDK-dotNET-master/AssemblyLister/AssemblyLister.UWP/AssemblyLister.UWP.csproj (default targets) ->
/Library/Frameworks/Mono.framework/Versions/4.4.2/lib/mono/xbuild/12.0/bin/Microsoft.Common.targets (GetReferenceAssemblyPaths target) ->
/Library/Frameworks/Mono.framework/Versions/4.4.2/lib/mono/xbuild/12.0/bin/Microsoft.Common.targets: error : Unsupported PCL Profile '.NETPortable,Version=v4.6,Profile=Profile32'.

Does anyone even has push working with android + parse server i am on this for days but it doesnt seem to work with all the tutorials that are around

It is possible to make push working with Android but it requires some work. We made it work by checking out the 1.7.0 tag and after that fixed a bug with gcmsenderid . Then there was a problem with Marshmallow (6.0+) that can be fixed by removing GET_ACCOUNTS permission.
There are a few more glitches with Android Push for example ParseInstallation is not always saved on device and push messages are often duplicated. We made some quick fixes for these problems too and everything is checked into this forked branch. Feel free to check it out and build your own version.

We need to clarify a process for building on your own. Docs are there, but it could be presented in a more transparent fashion.

This issue is outdated and no longer applies to the SDK versions available from this repository.
Please feel free to create a new issue if you encounter any problems building the assembly.
Remember to consult the Readme to check for the steps required to build the SDK.


Maintaining the same session across multiple playbooks

May I ask if there is a way to maintain the same session across multiple playbooks? Thank you!

Essentially, I hope to have another playbook to publish all the changes made by the previous playbooks. I have the UID for each of the sessions that was created by the previous playbook. However, when I run
    - name: Publish session
      cp_mgmt_publish:
        uid: "{{ uid }}"

The output that I get is:
{
    "msg": "Checkpoint device returned error 501 with message {'code': 'not_implemented', 'message': 'Publishing other than current session is not implemented'} Unpublished changes were discarded",
    "invocation": {
        "module_args": {
            "uid": "<<UID>>",
            "wait_for_task": true,
            "wait_for_task_timeout": 30,
            "version": null
        }
    }
}

May check how I can go about resolving this issue? Many thanks in advance!

Seems to be a existing problem from here. Can check if there has been any update to this? Or am I supposed to pre-configure some settings on Smart Console and/or Gaia

Thank you @chkp-edenbr !
Can I confirm that the documentation for cp_mgmt_publish is currently incomplete? In the documentation, it seems that it has wrongly states that uid can be specified as parameter to "publish a different session than the one you currently use".

Hello! Can I check if there is an expected timeline for the cp_mgmt module for switching session to be implemented? Thank you very much!

Hi,
Concerning cp_mgmt_publish, thank you for notifying us, we will update the module and release it in a future version.
Concerning switching sessions module, we currently don't have an expected timeline.
Thank you,
Eden

Thank you @chkp-edenbr ! Cheers!
Will be proceeding to close this issue.


replace "batch update" with "adding batch of info to existing records"

I would prefer "batch update", with a checkbox option to select whether existing data should be overwritten or not. Preferably, before the actual overwrite happens, there should be a list indicating all changes about to happen which the user can verify or still cancel at that moment.

@cdoorenweerd I just implemented this plugin. It has a confirmation page which show the changes that you are going to make. I think it is not possible yet to check items to confirm certain changes. However it would be possible to abort the import, fix the data file and resume import.
This plugin allows importing XLS, CSV, JSON, YaML files!

Beautiful! I think this is fine, no need to verify each individual change


[url_launcher] add immediate dial option on phone call

Idea
I initially wanted to build an IOS / Android app that launch some ussd request in background.
I have made some test with True Caller that can launch a call directly. And also give a final result of an ussd request.
Request
I want to know If the url_launcher plug-in has such functionality or if it you could add such functionality
Potential Solution
I have found intent that could work but it only work on Android devices.
Thanks

url_launcher is intended purely to open URLs by handing them off to the host system. Integration with specific components that go beyond what is available via URL handling would be something to make special-purpose plugins for.


Add default IR attributes to helper functions

Convert several places to use getOrCreateHelperFunction.  Fixes rdar://66707994.
WIP because it needs tests.

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - c3708d919a118d810854f8efa887274948f802cb

Build failed
Swift Test Linux Platform
Git Sha - c3708d919a118d810854f8efa887274948f802cb

@swift-ci Please test.

Build failed
Swift Test Linux Platform
Git Sha - c3708d919a118d810854f8efa887274948f802cb

Build failed
Swift Test OS X Platform
Git Sha - c3708d919a118d810854f8efa887274948f802cb

CC: @shahmishal - seems that the Windows CI didn't trigger here?  One of the changes has a mix up that would've been caught by the CI.