feat: Final Boss behaviour, battle and attacks

Okay, here we go, I hope you brought something to drink!
What does this bring to the table you may ask? Well, this pr brings the foundations for what will be the final boss fight.
A lot of files were changed through the development of this pr, but the most important ones are the following:

FinalBossScript -> this script manages the final boss completely, when to trigger their attacks, when to change from one phase from another...
This is the main file that you'd have to tweak around during your testing, as in the Update of this script there's a function called TryAttacksIndividually which shows the attacks alone when the player approaches Bix, and another one called ManageBossPhases, which manages a completely funcional behaviour with four phases depending on how much life the boss has (Right now you may prefer testing the attacks with the first function, as the light and heavy attacks are currently broken after the merge of #580).

This Final Boss has four different attacks, just as it was stated in our GDD, and they are managed by the following scripts:

CHAOTIC PLASMA HAMMER
Managed by ShockWaveAttackScript and ShockWaveAttackAreaScript. There are two versions of these attack, one more defensive (which is triggered when the player casually approaches the boss) and another one more aggresive (which makes the boss run towards the player and attack them). This is managed by two areas (two spherical RigidBodies) and the objective is to damage the player if it's on the floor and they are hit by the shockwave range between the two areas.

BRUTAL CHARGE
Managed by BossChargeAttackScript and BossChargeRockScript.  Upon hitting a wall, rock will fall from the sky through the area where the boss charged and they will damage the player if they hit him while falling. These rocks will stay in the battle area for a while, difficulting the movement of the player.

ENERGY SHIELD
Managed by BossShieldAttackScript and BossShieldScript. This attack will activate a shield around the boss for a certain time, making them invulnerable to attacks while healing himself while the shield is up. While this attack takes place, several enemies will spawn around to keep the player from stoping this attack, so the final boss can heal as much as possible. (Right now the enemies cannot be duplicated correctly from scripts, so until that works, I programmed a work-around with a "pool" of enemies that enable/disable). The only way to stop this shield attack is by hitting a rock or whatever there will be in range, making it fall over the final boss' head, stunning them and making the attack stop. (This is not yet programmed but I left it as prepared as I could).

LAST WISH MISILES
Managed by BossMissilesAttackScript and BossMissilesMissileScript. When really low on health (during the LAST_RESORT phase), the final boss will disappear the battle area and trigger a missile attack that will spawn several missiles through the battle area, trying to inflict as much damage as possible to the player.

Aside from that, all the logic for the final boss was programmed, to change between phases, what happens in each phase... And the attacks could be modified widely through all the values visible on the inspector for each script.
As you could see, a lot of these attacks relay in having the tag Wall for the walls where the BRUTAL CHARGE will collide and stop and Floor for the floor itself, to trigger the missiles, know when the rocks hit the floor... Idk if that may be an issue but I'm hoping not because tags are easy enough to manage.
You can check all these in the Gameplay_FinalBoss.axolotl scene.

Additional work carried out during this pr to improve its funcionality:

Built a basic blockout of the boss area, nothing too shabby.
Fix sound for the steps when finishing jumping or dashing.
Don't jump or move while dashing (now it looks like a more steady dash).
Add vectors for the waypoints of the patrol and the powerups of the enemy death.
Little rework of the powerup system, when a powerup spawns, instead of being set as a child of the dead enemy, just tp it to the position of the dead enemy, so it can be reused again. Also made that the player could attract and get powerups even when they already have one active and one saved up (just like in Super Mario Bros., if you get a powerup when you have no more space, it will simply disappear).
Only 2 decimals shown by the float fields of the ComponentScript in the Inspector Window (4 was way too much IMO).
Small rework to the patrol, now when an entity gets out of its patrol route, when getting back to the patrol route they will do so trough its neares waypoint at the moment, instead as for the nearest waypoint stored when they left the patrol route.
Also added a random patrol for the bosses (looks really weird, but idk how to perform a realistic movement for the bosses with what we have now).
Fix particle timer for the light finisher (it was set way to much time).
Made that both the BRUTAL CHARGE and the ENERGY SHIELD can be reused by any other mini-boss that we may have in the future.

I hope you like it! (I really hope it, I've spent practically every minute of this last week doing this and IMO, it had a really great outcome, altough yet unfinished).

First of all, thank you both for you kind words and for taking the time to check and test this pull request!
Regarding your comments:

Bix gets stucked with her attack. I think this was commented before but now I realized that. It has nothing to do with this PR but it gets the experience more tough to play.

Yes, sadly after merging #580, the simple attacks get stuck (Idk why, I tried to check that pr and it touched nothing related to how the attacks work, so it's a mystery, so I told it to Sara hoping that, as she was the owner of the pr, knows why this is happening). But yea, as you say, that sadly hinders the testability of the boss behaviour itself, so I hope it gets fixed asap.

The final boss gets stucked with his brutal charge attack (I mean, with the rocks fallen). Maybe this won't be a problem because 2 things: the cooldown and probabilities of the attacks in the ManagePhases and if we treat the rocks as obstacles for the NavMesh. But I saw it necessary to comment it just in case.

The rocks make the whole attack area kind of messy for the continued mobility of the boss, I tried to make it as playable as possible but I'm afraid that until we have the NavMesh the rocks will make the final boss get stucked at certain times (thankfull the rocks disappear after a certain time, so the boss doesn't get stuck forever, but ideally it should never get stuck).

Excellent job, I've tried it and liked it.

Thanks!

When you perform the jumping downward attack, you launch the boss into the air along with its areas. The launching into the air part should be removed.

Wdym? That the jump attack shouldn't push the boss back?

well done, a side of the problem mentioned with the attack I don't see any other big problem.

Thank you, Pablo!

I don't see having the camera as you presented, I would put a unique sampler where we can view the whole scenario, but I know is a pre state.

To be franc, me neither, but that is not really for this pr to decide, as it more a level programming thing and I guess they'll decide about that when the final arena is fully built.

As always, haven't tested, but left a bunch of picky comments, as is also tradition :P

Appreciate it! As I'm out this week I can't perform those required changes now, but as soon as I get back, they will get addressed in another pr, because we need to merge this as soon as possible so the project can carry on.


Hoodathunk module sold from storage

'Module sold from storage' better reflects the actual behavior of the 'ModuleSellRemote' event (and is less confusing) than 'Module sell remote'.

Wrong fork I think?


fix(utils): Do not call callback if type(callback) == "table"

Sometimes the cursor freezes for a second and i get a error popup:
Error executing lua callback: ....../event.lua:47: attempt to call local 'callback' ( a table value )
Stack traceback:
....

so i fixed this, it's only a 3 line change

i don't know what caused this issue (shouldn't happen)
but either way it makes way more sense to just make this a type(callback)=="function" check

managed to get the content of the table ( sort of ):

}
}
[python] => table: 0x7f4c73176d78 {
[(] => table: 0x7f4c72fc7c38 {
[kind] => table: 0x7f4c73000f30 {
[1] => 3
[2] => 2
}
[1] => 3
[python] => table: 0x7f857c69d2c0 {
[(] => table: 0x7f857c69d5b8 {
[handler] => function: 0x7f857c69d1a0
[kind] => table: 0x7f857c69d638 {
[1] => 3
[2] => 2
}
}
}
[tex] => false
[haskell] => false
[fennel] => table: 0x7f857c69d2c0 {
[(] => table: 0x7f857c5695f8 {
[handler] => function: 0x7f857c69d168
[kind] => table: 0x7f857c569678 {


Extract corridor solids

https://forum.dynamobim.com/t/extract-solids-for-multiple-corridors/76337/26?u=mzjensen

https://forum.dynamobim.com/t/how-to-access-external-database-to-use-them-in-methods/80306/7?u=mzjensen


Add parse args function to make code cleaner, update send_privmsg test

TODO comments are addressed in #57.

So, I have no idea what happened. To be able to change variable verb to command, I changed the name of command.py to commands.py. I have no clue how it didn't get included in the commit.
Pulled the file from err_handling which means that now, this PR includes even #57. What a mess.


docs: Missing Contributing File

Area of Improvement
Hello:)
The contributing guide file is missing. It is nice to have one.
Link to related docs
No response
Additional information
No response
👨👧👦 Contributing

[X] 🙋♂ Yes, I'd be down to file a PR implementing the suggested changes!

https://github.com/pingdotgg/uploadthing#contributing

A separate CONTRIBUTING.md file is better. Here's why:

A separate file for contributing guidelines helps organize information better. The README.md can describe the project, its use, and features. The CONTRIBUTING.md can give detailed guidelines on how to contribute.
GitHub recognizes the CONTRIBUTING.md file. It gives a direct link to it when someone creates a new issue or pull request. This makes it more likely for contributors to see and read the guidelines.
A dedicated file lets you include detailed information without making the README.md messy. You can cover many aspects like coding standards how to set up the development environment, and how to submit pull requests.
A clear guide for contributors can inspire more people to help out. It gives step-by-step instructions and makes the whole process less scary.

Still, you can add a short part in your README.md that links to the CONTRIBUTING.md file. This way, people who start with the README.md will know about the rules for contributing.


Feature/test server deployment

What does it do?
Describe the technical changes you did.
Why is it needed?
Describe the issue you are solving.
How to test it?
Provide information about the environment and the path to verify the behaviour.
Related issue(s)/PR(s)
Let us know if this is related to any issue/pull request

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 30.22%. Comparing base (2e516f7) to head (2821817).
Report is 16 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master     #164   +/-   ##
=======================================
  Coverage   30.22%   30.22%
=======================================
  Files           4        4
  Lines       13967    13967
  Branches     4975     4975
=======================================
  Hits         4222     4222
  Misses       7709     7709
  Partials     2036     2036

Flag
Coverage Δ

unit
30.22% <ø> (ø)

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

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


Release Google.Cloud.Metastore.V1Alpha version 2.0.0-alpha06

Changes in this release:
New features

Added Admin Interface (v1) (commit a162298)
Added gRPC endpoint protocol (v1) (commit a162298)
Added BigQuery as a backend metastore (v1) (commit a162298)

Created release for Google.Cloud.Metastore.V1Alpha-2.0.0-alpha06


Web Workers: Fixed broken link to caniuse.com

Awesome! Thanks.

Raynos this needs to be fixed in the markdown post not in index.html.

._. my bad


Cleaner JSON format for characters in game state

Currently, the JSON format for hunters/characters in the game state is messy - the "player state" object contains certain fixed keys like value or color, but also the individual character states are there directly with keys like "0" or "42".  This makes parsing on the client side harder, as one has to check each key either against a hard-coded black list of known fixed keys or for being a valid number formatted as a string in order to determine which character states are present.
We propose to change the format such that all character states are moved to their own subobject characters, so that it is easy to enumerate all characters of a player (by just going over all keys of the subobject).
In other words, let's change this:
"domob": {
  "color": 2,
  "value": 1.00000000,
  "0": {
    "x": 263,
    "y": 442,
    ...
  },
  "1": {...},
}

To this:
"domob": {
  "color": 2,
  "value": 1.00000000,
  "characters": {
    "0": {
      "x": 263,
      "y": 442,
      ...
    },
    "1": {...},
  }
}

This change requires all front-end software parsing the game state to be updated, but will make the parsing there simpler.  Until all users are updated (e. g., after the next hard fork has taken place), client software can support both formats by checking for the presence of the characters field.  In addition, we will update the client version (version in getinfo output) with this change.

We need similar change for:
UniValue jsonPlayers(UniValue::VOBJ);  inside state.cpp line 957;
into
UniValue jsonPlayers(UniValue::VARR);
else it makes impossible to deserialize it easily on client side.

Thanks for your feedback!  Can you please give a more concrete example of what the current JSON looks like that you want to change and how it should look like after the change?  If I understood you correctly, this is about the players, similarly to characters in the original proposal.  As far as I can see, the players are already in a separate JSON object for themselves.  Why do you think that an array is better?  Since they are key/value pairs (names and state objects), it makes sense to have dictionaries and not an array.

Ah, you are correct, those would deserialise into dictionary just fine, so my last comments can be ignored

If you are interested, take a look at my implementation in #13.  I'll merge it if there are no objections or suggestions for further improvements in the next couple of days.


possible to connect to multiple kubernetes cluster with one nfs server binary deployment?

Hi I'm wondering that whether I can run multiple nfs-provisioner binary process, to connection to multiple k8s clusters? I try that, pvc and pv are created separately for different cluster, but somehow pv seems not working. Or are there other ways to do that?

I'm using outside of kubernetes binary deployment

No, it won't work because every instance assumes it has exclusive ability to assign fsids which have to be unique. What failures with the PV do you see? Can you inspect the /etc/exports and see if there are duplicate fsids or other problems?
I don't know/remember what the consequences of reusing fsid for different exports are.
One possible solution would be to allow you to specify a range of ids for an instance to allocate from

pv created but somehow I got IOException for my java process. I'll check /etc/exports later.
BTW  would it work, if I build nfs-provisioner with different export folder? say cluster1 point to /export1  and cluster2 point to /export2?

and how can I specify a range of ids?seems there is no option for the binary privisioner to do that. Thanks a lot

I'm not sure how IOException could occur.
No, using different export folders shouldn't solve it. Even if they're all touching the same /export they should be writing to unique child directories, I think UUID generation guarantees that. You can certainly try it though...
Sorry, I meant setting ranges as a potential future solution for me to implement. Just in general I have never considered this use-case, so I need some time to think about it I guess. Any other info you can give about your setup is helpful too

I'll see whether I can assign different fsid by building different binary, each hard coding with a specific range.
Thanks for all the helpful info


Is padding also required in model.predict function?

This template is for miscellaneous issues not covered by the other issue categories.
For questions on how to work with TensorFlow, or support for problems that are not verified bugs in TensorFlow, please go to StackOverflow.
If you are reporting a vulnerability, please use the dedicated reporting process.
For high-level discussions about TensorFlow, please post to<EMAIL_ADDRESS>for questions about the development or internal workings of TensorFlow, or if you would like to know how to contribute to TensorFlow, please post to<EMAIL_ADDRESS>

The question does not mentions which padding are we talking about so I will answer wrt CNN . No padding is not required in model.predict function. Its only used in conv2D while making a CNN. You can find more about padding here.

The question does not mentions which padding are we talking about so I will answer wrt CNN . No padding is not required in model.predict function. Its only used in conv2D while making a CNN. You can find more about padding here.

I am talking about LSTM

I think this link is very helpful in answering your question .

@Vignesh1-art
Padding is not required in model.predict function. As suggested by @PrattJena you can go through the link which explains clearly about padding.
This question is better asked on StackOverflow since it is not a bug or feature request. There is also a larger community that reads questions there and provide better and faster support for such issues. Thanks!


Fix an overly specific pass

As explained in comments, slice_index does not need to be rewritten in case the type of indices is an array. A nano-pass was recovering from the over-zealous pass_by_ref phase from krml, but for some reason was crafted to only trigger on a very specific form of expressions. This fixes it.

This pass was trying to recover from some poor, earlier, code-gen decisions. Closing in favor of a proper fix.


Error: Cannot find module 'cst'

Hi, after installation I have this error when I try to use jscs app/
Error: Cannot find module 'cst'
    at Function.Module._resolveFilename (module.js:326:15)
    at Function.Module._load (module.js:277:25)
    at Module.require (module.js:354:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (/home/travis/build/Selleo/NTFrontend/node_modules/ember-suave/node_modules/jscs-ember-deprecations/lib/rules/disallow-emberkeys.js:2:11)
    at Module._compile (module.js:410:26)
    at Object.Module._extensions..js (module.js:417:10)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)
    at Module.require (module.js:354:17)

How can I solve it?

See the discussion in #120.

The issue appears to be because of ember-jscs-deprecations. It declares jscs as a dev dependency. So upon installing ember-suave, the node_modules looks like this:

ember-jscs-deprecations doesn't download jscs. The reason we can circumvent the issue by including cst in ember-suave is because the dependency lookup will traverse the hierarchy, but I think the real fix needs to happen in ember-jscs-deprecations.

https://github.com/cst/cst/issues/134


MySQL no SSL fix

Adds support for MySQL DBs that don't use SSL connections, and in doing so allows the docker-compose-mysql.yml file to work as expected with:
docker-compose -f docker-compose-mysql.yml up

NOTE: I checked that the test source table contents had successfully been received in the target DB.


Title bar does not display properly

The moment it is just opened, it can be displayed normally, but soon the title bar will be covered by gray.
OS: Windows 11

download from MS Store

There must be some kind of overflow happening, would you be able to build on debug mode and see what the issue is?
I am not able to replicate it

Managed to reproduce on linux:

Will push fix ASAP


Persist metadata to metadata center with sharding-jdbc

For #5128.
Changes proposed in this pull request:

Persist metadata to metadata center with sharding-jdbc

Pull Request Test Coverage Report for Build 11104

8 of 8 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 57.437%

Totals

Change from base Build 11100:
0.02%

Covered Lines:
11840

Relevant Lines:
20614

💛  - Coveralls


Upgrade Pulsar to 3.2.2

Fix #12713

@KKcorps Can you share some context on why we pull in so many dependencies in pinot-pulsar? Seems like it works without most of them

Codecov Report
Attention: Patch coverage is 0% with 11 lines in your changes are missing coverage. Please review.

Project coverage is 0.00%. Comparing base (59551e4) to head (b4ae841).
Report is 335 commits behind head on master.

Files
Patch %
Lines

...apache/pinot/plugin/stream/pulsar/PulsarUtils.java
0.00%
11 Missing :warning:

Additional details and impacted files
@@              Coverage Diff              @@
##             master   #12967       +/-   ##
=============================================
- Coverage     61.75%    0.00%   -61.76%
=============================================
  Files          2436     2427        -9
  Lines        133233   132868      -365
  Branches      20636    20581       -55
=============================================
- Hits          82274        0    -82274
- Misses        44911   132868    +87957
+ Partials       6048        0     -6048

Flag
Coverage Δ

custom-integration1
?

integration
0.00% <0.00%> (-0.01%)
:arrow_down:

integration1
?

integration2
0.00% <0.00%> (ø)

java-11
?

java-21
0.00% <0.00%> (-61.63%)
:arrow_down:

skip-bytebuffers-false
0.00% <0.00%> (-61.75%)
:arrow_down:

skip-bytebuffers-true
0.00% <0.00%> (-27.73%)
:arrow_down:

temurin
0.00% <0.00%> (-61.76%)
:arrow_down:

unittests
?

unittests1
?

unittests2
?

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

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

ohh at that time I did it to solve multiple maven enforcer errors. Seems like they all work now finr


Margin between chips and search field

Added vertical spacing between the search field and chips. Margin may be added from the constructor of the FlutterTagging class

I made this change because on web, there was no space between the chip and the text field


Double-click the node title to edit

When changing parameters such as the number of steps, it frequently malfunctions. I would appreciate it if you could limit the double-click area to the top of the node or, if that's difficult, make it possible to turn off this feature.
The shortcut for group nodes is extremely convenient!

When changing parameters such as the number of steps, it frequently malfunctions. I would appreciate it if you could limit the double-click area to the top of the node or, if that's difficult, make it possible to turn off this feature.
The shortcut for group nodes is extremely convenient!

It's fixed 15 hours ago, try update to the lastest.

Thakyou!


samples/boards/stm32: stm32wb_ble: Fix shutdown

Still not working

Attempt to fix potential sample issue for https://github.com/zephyrproject-rtos/zephyr/issues/42308


missing table

An exception occurred while executing ' SELECT mlocsi."id" AS "locale.site.id", mlocsi."code" AS "locale.site.code", mlocsi."label" AS "locale.site.label", mlocsi."config" AS "locale.site.config", mlocsi."status" AS "locale.site.status", mlocsi."editor" AS "locale.site.editor", mlocsi."mtime" AS "locale.site.mtime", mlocsi."ctime" AS "locale.site.ctime" FROM "mshop_locale_site" AS mlocsi WHERE mlocsi."level" = 0 AND mlocsi."code" = 'default' GROUP BY mlocsi."id", mlocsi."code", mlocsi."label", mlocsi."config", mlocsi."status", mlocsi."editor", mlocsi."mtime", mlocsi."ctime" ORDER BY mlocsi."id" ASC LIMIT 100 OFFSET 0 ': SQLSTATE[42S02]
missing this table

Have there been any error during the setup process?
Which environment do you use?


python310Packages.aiobotocore: 2.3.4 -> 2.4.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.aiobotocore is: "Python client for amazon services"
meta.homepage for python310Packages.aiobotocore is: "https://github.com/aio-libs/aiobotocore"
meta.changelog for python310Packages.aiobotocore is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.4.0 with grep in /nix/store/ad64ajas6sm9bf2dkwx8i7kdjsis9r0m-python3.10-aiobotocore-2.4.0
found 2.4.0 in filename of file in /nix/store/ad64ajas6sm9bf2dkwx8i7kdjsis9r0m-python3.10-aiobotocore-2.4.0

Rebuild report (if merged into master) (click to expand)

6 total rebuild path(s)

6 package rebuild(s)

First fifty rebuilds by attrpath
dvc-with-remotes
home-assistant-component-tests.aws
python310Packages.aiobotocore
python310Packages.s3fs
python39Packages.aiobotocore
python39Packages.s3fs

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ad64ajas6sm9bf2dkwx8i7kdjsis9r0m-python3.10-aiobotocore-2.4.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.aiobotocore https://github.com/r-ryantm/nixpkgs/archive/f74baf7f21490441d84f7dd226a10e29982c679d.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ad64ajas6sm9bf2dkwx8i7kdjsis9r0m-python3.10-aiobotocore-2.4.0
ls -la /nix/store/ad64ajas6sm9bf2dkwx8i7kdjsis9r0m-python3.10-aiobotocore-2.4.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

3 packages failed to build:

dvc-with-remotes
python310Packages.s3fs
python39Packages.s3fs

3 packages built:

home-assistant-component-tests.aws
python310Packages.aiobotocore
python39Packages.aiobotocore

Maintainer pings
cc @teh for testing.

Result of nixpkgs-review pr 188703 run on x86_64-linux 1

3 packages failed to build:

dvc-with-remotes
python310Packages.s3fs
python39Packages.s3fs

3 packages built:

home-assistant-component-tests.aws
python310Packages.aiobotocore
python39Packages.aiobotocore

Why has this been closed?

Was obsoleted by python-updates.

Where can I find these?

https://github.com/NixOS/nixpkgs/commit/d4579920f807231bdc73201c8838ffc1d28eb325
via #191333

Ah okay didn't know about this. Thank you!

See https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/python.section.md#package-set-maintenance


Connection between Graylog and Riemann is established but no event are forwarded

Hi, I am using the 1.1.2 plugin with Graylog 2.0.3 and configured it to communicate with riemann on another server over tcp/5555. I see the established connection (nestat and tcpdump) but no events are forwarded. I can't see any events in the riemann log.
I also tried UDP with the same outcome.
Any sugestions?
Thank you very much in advance.

Hi,
do you have any messages in the stream that is associated to the output?

Hi, of course. A stream with all events which arrive at the graylog.

Without any error message it's then hard to say if this is a bug or a missconfiguration. Do you see anything in the Graylog server log or in Riemann?

Nothing at all. In the graylog log I see the start of the plugin, as mentioned I can observe the connection establishment but after that nothing more happens ...

I'm seeing a similar behavior. The graylog2 server log shows plugin is loaded:
Loaded plugin: Riemann Output Plugin 1.1.2 [org.graylog2.outputs.riemann.RiemannOutput]
It functions fine in Web UI. The stream has messages. Connection between riemann and graylog is established on port 5555.
`root@graylog:/var/log/graylog# netstat -tunap | grep 5555
tcp6       0      0 <IP_ADDRESS>:5555            :::*                    LISTEN      11646/java
tcp6       0      0 <IP_ADDRESS>:5555          <IP_ADDRESS>:58950         ESTABLISHED 11646/java
tcp6       0      0 <IP_ADDRESS>:58950         <IP_ADDRESS>:5555          ESTABLISHED 15215/java
udp6       0      0 :::5555                 :::*                                11646/java
riemann  11646     1  0 15:16 ?        00:00:11 java -cp :/usr/share/riemann/riemann.jar riemann.bin start /etc/riemann/riemann.config
root     15215   839 74 15:29 ?        00:04:46 /opt/graylog/embedded/jre/bin/java -Xms1g -Xmx1500m -XX:NewRatio=1 -server -XX:+ResizeTLAB<...>`
But I see nothing in either riemann log or the riemann-dash. Both work with other inputs, such as riemann-health.

I see the same as these guys, it doesn't work.  I used netstat to verify the handshake and see the ESTABLISHED connection.  I also see the plugin start up in the graylog server.log.  I used tcpdump and see the handshake, but after that nothing is coming across the wire.  We created the output and mapped it to a stream... we tried both udp and tcp and nothing.
here are the versions we are using:
dpkg -l | grep graylog
ii  graylog-server                           2.0.3-1                             all          Graylog server
/etc/graylog/server$ ls -al /usr/share/graylog-server/plugin/ | grep riemann
-rw-r--r-- 1 root root  135371 Aug 20  2015 graylog-plugin-output-riemann-1.1.3-SNAPSHOT.jar

I have updated the Riemann Java client in v1.1.3, UDP and TCP is working on my machine. When you see an established TCP connection without events on the Riemann server side, keep in mind that this plugin is working in batches. It waits until there are enough messages for a batch and sends them together. With a batch size of 1 you can see the events immediately but it comes with a performance degradation: https://github.com/Graylog2/graylog-plugin-riemann/releases/tag/v1.1.3


[DT] Move set encoding after forming dispatch region

Learning from the past experience and the needs of quantization, we want to explore moving SetEncoding pass right after flow dispatch formation. At this point, we know that what the actual dispatch looks like. E.g., the dequant/broadcast ops and the consumers are already formed into matmul dispatch. We can set encoding based on those dispatches. The encoding now carries padding semantics, so it also provides a chance to cleanup all padding and query_upper_tile_size tech debts. Also, this will enable fusion for data-tiling. E.g., it enables mmt4d on CPU side.
TBD: Add subtasks for the issue. There are an amount of work in the issue.

I wrote down what should happen step by step here, and I'm using the below example as input:
util.func public @broadcasting_dequant_op(%arg0 : tensor<?x?xi8>, %rhs : tensor<?x?x?xi32>) -> tensor<?x?x?xi32> {
  %c0 = arith.constant 0 : index
  %c1 = arith.constant 1 : index
  %d1 = tensor.dim %arg0, %c0 : tensor<?x?xi8>
  %d2 = tensor.dim %arg0, %c1 : tensor<?x?xi8>
  %d0 = tensor.dim %rhs, %c0 : tensor<?x?x?xi32>
  %empty = tensor.empty(%d0, %d1, %d2) : tensor<?x?x?xi32>
  %dequant = linalg.generic {
      indexing_maps = [affine_map<(d0, d1, d2) -> (d1, d2)>,
                       affine_map<(d0, d1, d2) -> (d0, d1, d2)>],
      iterator_types = ["parallel", "parallel", "parallel"]}
      ins(%arg0 : tensor<?x?xi8>) outs(%empty : tensor<?x?x?xi32>) {
    ^bb0(%in: i8, %out: i32):
      %12 = arith.extui %in : i8 to i32
      linalg.yield %12 : i32
    } -> tensor<?x?x?xi32>

  %B = tensor.dim %dequant, %c0 : tensor<?x?x?xi32>
  %M = tensor.dim %dequant, %c1 : tensor<?x?x?xi32>
  %N = tensor.dim %rhs, %c1 : tensor<?x?x?xi32>
  %init = tensor.empty(%B, %M, %N) : tensor<?x?x?xi32>
  %cst = arith.constant 0 : i32
  %fill = linalg.fill ins(%cst : i32) outs(%init : tensor<?x?x?xi32>) -> tensor<?x?x?xi32>
  %op = linalg.batch_matmul_transpose_b
      ins(%dequant, %rhs : tensor<?x?x?xi32>, tensor<?x?x?xi32>)
      outs(%fill : tensor<?x?x?xi32>) -> tensor<?x?x?xi32>
  util.return %op : tensor<?x?x?xi32>
}

After FormDispatchRegionsPass, the dequant ops are still outside of dispatch region.
util.func public @broadcasting_dequant_op(%arg0: !hal.buffer_view, %arg1: !hal.buffer_view) -> !hal.buffer_view attributes {iree.abi.stub, iree.reflection = {iree.abi.declaration = "sync func @broadcasting_dequant_op(%input0: tensor<?x?xi8>, %input1: tensor<?x?x?xi32>) -> (%output0: tensor<?x?x?xi32>)"}} {
  %c0_i32 = arith.constant 0 : i32
  %0 = hal.buffer_view.dim<%arg0 : !hal.buffer_view>[0] : index
  %1 = hal.buffer_view.dim<%arg0 : !hal.buffer_view>[1] : index
  %2 = hal.tensor.import %arg0 "input0" : !hal.buffer_view -> tensor<?x?xi8>{%0, %1}
  %3 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[0] : index
  %4 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[1] : index
  %5 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[2] : index
  %6 = hal.tensor.import %arg1 "input1" : !hal.buffer_view -> tensor<?x?x?xi32>{%3, %4, %5}
  %7 = tensor.empty(%3, %0, %1) : tensor<?x?x?xi32>
  %8 = linalg.generic {indexing_maps = [affine_map<(d0, d1, d2) -> (d1, d2)>, affine_map<(d0, d1, d2) -> (d0, d1, d2)>], iterator_types = ["parallel", "parallel", "parallel"]} ins(%2 : tensor<?x?xi8>) outs(%7 : tensor<?x?x?xi32>) {
  ^bb0(%in: i8, %out: i32):
    %13 = arith.extui %in : i8 to i32
    linalg.yield %13 : i32
  } -> tensor<?x?x?xi32>
  %9 = tensor.empty(%3, %0, %4) : tensor<?x?x?xi32>
  %10 = linalg.fill ins(%c0_i32 : i32) outs(%9 : tensor<?x?x?xi32>) -> tensor<?x?x?xi32>
  %11 = flow.dispatch.region -> (tensor<?x?x?xi32>{%3, %0, %4}) {
    %13 = linalg.batch_matmul_transpose_b ins(%8, %6 : tensor<?x?x?xi32>, tensor<?x?x?xi32>) outs(%10 : tensor<?x?x?xi32>) -> tensor<?x?x?xi32>
    flow.return %13 : tensor<?x?x?xi32>
  }
  %12 = hal.tensor.export %11 "output0" : tensor<?x?x?xi32>{%3, %0, %4} -> !hal.buffer_view
  util.return %12 : !hal.buffer_view
}

Then we run CloneProducersIntoDispatchRegionsPass, which moves the deqaunt ops into dispatch region. The outside one is converted to a dispatch region, but it will be killed later. Let's ignore it for now. So the IR would be
#map = affine_map<(d0, d1, d2) -> (d1, d2)>
#map1 = affine_map<(d0, d1, d2) -> (d0, d1, d2)>
module {
  util.func public @broadcasting_dequant_op(%arg0: !hal.buffer_view, %arg1: !hal.buffer_view) -> !hal.buffer_view attributes {iree.abi.stub, iree.reflection = {iree.abi.declaration = "sync func @broadcasting_dequant_op(%input0: tensor<?x?xi8>, %input1: tensor<?x?x?xi32>) -> (%output0: tensor<?x?x?xi32>)"}} {
    %c0_i32 = arith.constant 0 : i32
    %0 = hal.buffer_view.dim<%arg0 : !hal.buffer_view>[0] : index
    %1 = hal.buffer_view.dim<%arg0 : !hal.buffer_view>[1] : index
    %2 = hal.tensor.import %arg0 "input0" : !hal.buffer_view -> tensor<?x?xi8>{%0, %1}
    %3 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[0] : index
    %4 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[1] : index
    %5 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[2] : index
    %6 = hal.tensor.import %arg1 "input1" : !hal.buffer_view -> tensor<?x?x?xi32>{%3, %4, %5}
    %7 = flow.dispatch.region -> (tensor<?x?x?xi32>{%3, %0, %4}) {
      %9 = tensor.empty(%3, %0, %4) : tensor<?x?x?xi32>
      %c0_i32_0 = arith.constant 0 : i32
      %10 = tensor.empty(%3, %0, %1) : tensor<?x?x?xi32>
      %11 = linalg.generic {indexing_maps = [#map, #map1], iterator_types = ["parallel", "parallel", "parallel"]} ins(%2 : tensor<?x?xi8>) outs(%10 : tensor<?x?x?xi32>) {
      ^bb0(%in: i8, %out: i32):
        %14 = arith.extui %in : i8 to i32
        linalg.yield %14 : i32
      } -> tensor<?x?x?xi32>
      %12 = linalg.fill ins(%c0_i32_0 : i32) outs(%9 : tensor<?x?x?xi32>) -> tensor<?x?x?xi32>
      %13 = linalg.batch_matmul_transpose_b ins(%11, %6 : tensor<?x?x?xi32>, tensor<?x?x?xi32>) outs(%12 : tensor<?x?x?xi32>) -> tensor<?x?x?xi32>
      flow.return %13 : tensor<?x?x?xi32>
    }
    %8 = hal.tensor.export %7 "output0" : tensor<?x?x?xi32>{%3, %0, %4} -> !hal.buffer_view
    util.return %8 : !hal.buffer_view
  }
}

I think this is where SetEncoding should happen. The result of SetEncoding would be something like below. We look through the producers of matmul input operands, and set encodings on the source of it outside the dispatch. And we set encodings on inits within the dispatch region. The set_encoding ops outside the dispatch region will be handled by the later pass (e.g., "CloneEncodingsIntoProducerPass").
For init part, the empty->set_encoding will be folded into tensor.empty with encodings. The empty->fill->set_encoding will be folded to empty->fill by the pattern.
util.func public @broadcasting_dequant_op(%arg0: !hal.buffer_view, %arg1: !hal.buffer_view) -> !hal.buffer_view attributes {iree.abi.stub, iree.reflection = {iree.abi.declaration = "sync func @broadcasting_dequant_op(%input0: tensor<?x?xi8>, %input1: tensor<?x?x?xi32>) -> (%output0: tensor<?x?x?xi32>)"}} {
  %c0_i32 = arith.constant 0 : i32
  %0 = hal.buffer_view.dim<%arg0 : !hal.buffer_view>[0] : index
  %1 = hal.buffer_view.dim<%arg0 : !hal.buffer_view>[1] : index
  %2 = hal.tensor.import %arg0 "input0" : !hal.buffer_view -> tensor<?x?xi8>{%0, %1}
  %3 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[0] : index
  %4 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[1] : index
  %5 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[2] : index
  %6 = hal.tensor.import %arg1 "input1" : !hal.buffer_view -> tensor<?x?x?xi32>{%3, %4, %5}
  // We'll need role/indexOperand, element_types, original_type?, and indexing maps
  // in the encoding.
  %2_with_encoding = iree_encoding.set_encoding %2
    : tensor<?x?xi8> -> tensor<?x?xi8, #iree_encoding.encoding<...>>
  %6_with_encoding = iree_encoding.set_encoding %2
    : tensor<?x?x?xi32> -> tensor<?x?x?i32, #iree_encoding.encoding<...>>

  %10 = flow.dispatch.region -> (tensor<?x?x?xi32>{%3, %0, %4}) {
    %12 = tensor.empty(%3, %0, %4) : tensor<?x?x?xi32>
    %12_with_encoding = iree_encoding.set_encoding %12
      : tensor<?x?x?xi32> -> tensor<?x?x?xi32>, #iree_encoding.encoding<...>>
    %c0_i32_0 = arith.constant 0 : i32
    %13 = tensor.empty(%3, %0, %1) : tensor<?x?x?xi32>
    // the role is LHS
    %13_with_encoding = iree_encoding.set_encoding %13
      : tensor<?x?x?xi32> -> tensor<?x?x?xi32>, #iree_encoding.encoding<...>>
    %14 = linalg.generic {indexing_maps = [affine_map<(d0, d1, d2) -> (d1, d2)>, affine_map<(d0, d1, d2) -> (d0, d1, d2)>], iterator_types = ["parallel", "parallel", "parallel"]} ins(%2_with_encoding : tensor<?x?xi8>) outs(%13_with_encoding : tensor<?x?x?xi32>) {
    ^bb0(%in: i8, %out: i32):
      %17 = arith.extui %in : i8 to i32
      linalg.yield %17 : i32
    } -> tensor<?x?x?xi32>
    %15 = linalg.fill ins(%c0_i32_0 : i32) outs(%12_with_encoding : tensor<?x?x?xi32>) -> tensor<?x?x?xi32>
    %15_with_encoding = iree_encoding.set_encoding %15
      : tensor<?x?x?xi32> -> tensor<?x?x?xi32>, #iree_encoding.encoding<...>>

    %16 = linalg.batch_matmul_transpose_b ins(%14, %6_with_encoding : tensor<?x?x?xi32>, tensor<?x?x?xi32>) outs(%15_with_encoding : tensor<?x?x?xi32>) -> tensor<?x?x?xi32>
    flow.return %16 : tensor<?x?x?xi32>
  }
  %11 = hal.tensor.export %10 "output0" : tensor<?x?x?xi32>{%3, %0, %4} -> !hal.buffer_view
  util.return %11 : !hal.buffer_view
}

Then we implement CloneEncodingsIntoProducerPass pass, which either moves the set_encoding op to the producer dispatch region or wrap it into a new dispatch region in-place. The reason that I don't move encoding to the previous dispatch is that it could be complicated. Because

The producer region could have other uses. In this case, we might don't want to move it into the dispatch.
We'll need to update the return type of the producer dispatch region op, which makes the SetEncoding pass more complicated.

@MaheshRavishankar @Max191 does it make sense to you? We can chat more details tomorrow or some time this week.

Yes, this makes sense. A Small niy is that you are still moving the encodings into the producer dispatch. Doing it as a separate pass makes sense.

That looks similar to what I had in mind. The one difference is that I was thinking SetEncoding should only be responsible for setting the encodings on the target ops (i.e., not dequant ops). Then a separate pass will propagate the encoding ops and possibly also form dispatch regions. The reason I think this is better is that it could make SetEncoding complicated if including all the logic for setting encodings on dequant ops.
I'm actually still not entirely sure how to propagate the encodings past dequant-like ops, since they may not necessarily be unary like the one in your example IR. Dequant-like ops could be doing real dequantization, meaning they have scale and zero point inputs along with the quantized values. Setting encoding on this op means we have to set encoding on the scales and zero points as well. This leads to 2 issues:

The scales and zero points have a single value for each quantization group, meaning that they have 1 fewer dimensions than the quantized tensor. We may need some extra representation in encodings to capture which dimensions in the encoded tensor are present/correspond to which dimensions in the encoding user (i.e., matmul). Broadcast ops have a similar problem, since the inputs to broadcasts are also missing a dimension. Although this is more long term, propagation through transposes would most likely need this as well.
Dequantization ops with zero points cause issues with padding. For example, say there is a tensor<2x30xi4> quantized tensor, with a group size of 30. The scales and zero points will be tensor<2xi32>. If we pack the 30 dimension of the quantized values with an inner tile of 16, then we get tensor<2x2x16xi4> and tensor<2xi32>. The padded dimensions of the quantized tensor will now use the non-zero zero points from their tiles, which could create non-zero values in the dequantized result along the padded border.

(1) is probably a prerequisite to these flow changes, since we will not be able to propagate through dequant ops without it. After some discussion with @hanhanW, the current idea is to add a projected permutation map to the encoding, which indicates which values in the tensor correspond to the dimensions of the originalType.
(2) is more of a codegen/materialization issue, so it is not blocking any progress on flow level changes, but it is something we need to be careful with. I will create a separate issue about this tomorrow.

That looks similar to what I had in mind. The one difference is that I was thinking SetEncoding should only be responsible for setting the encodings on the target ops (i.e., not dequant ops). Then a separate pass will propagate the encoding ops and possibly also form dispatch regions. The reason I think this is better is that it could make SetEncoding complicated if including all the logic for setting encodings on dequant ops.
I'm actually still not entirely sure how to propagate the encodings past dequant-like ops, since they may not necessarily be unary like the one in your example IR. Dequant-like ops could be doing real dequantization, meaning they have scale and zero point inputs along with the quantized values. Setting encoding on this op means we have to set encoding on the scales and zero points as well. This leads to 2 issues:

The scales and zero points have a single value for each quantization group, meaning that they have 1 fewer dimensions than the quantized tensor. We may need some extra representation in encodings to capture which dimensions in the encoded tensor are present/correspond to which dimensions in the encoding user (i.e., matmul). Broadcast ops have a similar problem, since the inputs to broadcasts are also missing a dimension. Although this is more long term, propagation through transposes would most likely need this as well.

Yeah, the encoding needs to represent how this data is accessed in the eventual operation... but at the point you are setting the encoding you can encode that logic into the indexing maps.

Dequantization ops with zero points cause issues with padding. For example, say there is a tensor<2x30xi4> quantized tensor, with a group size of 30. The scales and zero points will be tensor<2xi32>. If we pack the 30 dimension of the quantized values with an inner tile of 16, then we get tensor<2x2x16xi4> and tensor<2xi32>. The padded dimensions of the quantized tensor will now use the non-zero zero points from their tiles, which could create non-zero values in the dequantized result along the padded border.

This is implicitly doing pad propagation during encoding. So again, we will have to be careful what the padding value we want to use will be....

(1) is probably a prerequisite to these flow changes, since we will not be able to propagate through dequant ops without it. After some discussion with @hanhanW, the current idea is to add a projected permutation map to the encoding, which indicates which values in the tensor correspond to the dimensions of the originalType.

I hope what I said above is consistent with what you meant here.

(2) is more of a codegen/materialization issue, so it is not blocking any progress on flow level changes, but it is something we need to be careful with. I will create a separate issue about this tomorrow.

Yeah, the encoding needs to represent how this data is accessed in the eventual operation... but at the point you are setting the encoding you can encode that logic into the indexing maps.

I don't think this is possible. The user_indexing_maps are used to determine the contraction dimensions of the operation. In cases where the encoding is set on the input of a broadcast, some of the dimensions would be missing, and the contractions dims would not be properly inferred. We need a separate indexing map to show how the encoded tensor's dims map to the originalType (i.e., the type used in the matmul).

Yeah, the encoding needs to represent how this data is accessed in the eventual operation... but at the point you are setting the encoding you can encode that logic into the indexing maps.

I don't think this is possible. The user_indexing_maps are used to determine the contraction dimensions of the operation. In cases where the encoding is set on the input of a broadcast, some of the dimensions would be missing, and the contractions dims would not be properly inferred. We need a separate indexing map to show how the encoded tensor's dims map to the originalType (i.e., the type used in the matmul).

I think that is just a fix to the contraction dims inference rather than a new field.

status update, I have a change that sets encodings for matmul, see below snippet. The next step is bubble up the encodings op across generic ops, set the bcast_map if there is a broadcast semantics in the generic op, and hoist the set_encodings op out of dispatch region.
#map = affine_map<(d0, d1, d2) -> (d1, d2)>
#map1 = affine_map<(d0, d1, d2) -> (d0, d1, d2)>
#map2 = affine_map<(d0, d1, d2, d3) -> (d0, d1, d3)>
#map3 = affine_map<(d0, d1, d2, d3) -> (d0, d2, d3)>
#map4 = affine_map<(d0, d1, d2, d3) -> (d0, d1, d2)>
module {
  util.func public @broadcasting_dequant_op(%arg0: !hal.buffer_view, %arg1: !hal.buffer_view) -> !hal.buffer_view attributes {iree.abi.stub, iree.reflection = {iree.abi.declaration = "sync func @broadcasting_dequant_op(%input0: tensor<?x?xi8>, %input1: tensor<?x?x?xi32>) -> (%output0: tensor<?x?x?xi32>)"}} {
    %c0_i32 = arith.constant 0 : i32
    %0 = hal.buffer_view.dim<%arg0 : !hal.buffer_view>[0] : index
    %1 = hal.buffer_view.dim<%arg0 : !hal.buffer_view>[1] : index
    %2 = hal.tensor.import %arg0 "input0" : !hal.buffer_view -> tensor<?x?xi8>{%0, %1}
    %3 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[0] : index
    %4 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[1] : index
    %5 = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[2] : index
    %6 = hal.tensor.import %arg1 "input1" : !hal.buffer_view -> tensor<?x?x?xi32>{%3, %4, %5}
    %7 = flow.dispatch.region -> (tensor<?x?x?xi32>{%3, %0, %4}) {
      %9 = tensor.empty(%3, %0, %1) : tensor<?x?x?xi32>
      %10 = linalg.generic {indexing_maps = [#map, #map1], iterator_types = ["parallel", "parallel", "parallel"]} ins(%2 : tensor<?x?xi8>) outs(%9 : tensor<?x?x?xi32>) {
      ^bb0(%in: i8, %out: i32):
        %17 = arith.extui %in : i8 to i32
        linalg.yield %17 : i32
      } -> tensor<?x?x?xi32>
      %11 = iree_encoding.set_encoding %10 : tensor<?x?x?xi32> -> tensor<?x?x?xi32, #iree_encoding.encoding<operand_index = 0 : index, element_types = [i8, i32, i32], original_type = tensor<?x?x?xi32>, user_indexing_maps = [#map2, #map3, #map4], round_dims_to = array<i64: 16, 16, 16, 16>>>
      %12 = iree_encoding.set_encoding %6 : tensor<?x?x?xi32> -> tensor<?x?x?xi32, #iree_encoding.encoding<operand_index = 1 : index, element_types = [i8, i32, i32], original_type = tensor<?x?x?xi32>, user_indexing_maps = [#map2, #map3, #map4], round_dims_to = array<i64: 16, 16, 16, 16>>>
      %13 = tensor.empty(%3, %0, %4) : tensor<?x?x?xi32, #iree_encoding.encoding<operand_index = 2 : index, element_types = [i8, i32, i32], original_type = tensor<?x?x?xi32>, user_indexing_maps = [#map2, #map3, #map4], round_dims_to = array<i64: 16, 16, 16, 16>>>
      %14 = linalg.fill ins(%c0_i32 : i32) outs(%13 : tensor<?x?x?xi32, #iree_encoding.encoding<operand_index = 2 : index, element_types = [i8, i32, i32], original_type = tensor<?x?x?xi32>, user_indexing_maps = [#map2, #map3, #map4], round_dims_to = array<i64: 16, 16, 16, 16>>>) -> tensor<?x?x?xi32, #iree_encoding.encoding<operand_index = 2 : index, element_types = [i8, i32, i32], original_type = tensor<?x?x?xi32>, user_indexing_maps = [#map2, #map3, #map4], round_dims_to = array<i64: 16, 16, 16, 16>>>
      %15 = linalg.batch_matmul_transpose_b ins(%11, %12 : tensor<?x?x?xi32, #iree_encoding.encoding<operand_index = 0 : index, element_types = [i8, i32, i32], original_type = tensor<?x?x?xi32>, user_indexing_maps = [#map2, #map3, #map4], round_dims_to = array<i64: 16, 16, 16, 16>>>, tensor<?x?x?xi32, #iree_encoding.encoding<operand_index = 1 : index, element_types = [i8, i32, i32], original_type = tensor<?x?x?xi32>, user_indexing_maps = [#map2, #map3, #map4], round_dims_to = array<i64: 16, 16, 16, 16>>>) outs(%14 : tensor<?x?x?xi32, #iree_encoding.encoding<operand_index = 2 : index, element_types = [i8, i32, i32], original_type = tensor<?x?x?xi32>, user_indexing_maps = [#map2, #map3, #map4], round_dims_to = array<i64: 16, 16, 16, 16>>>) -> tensor<?x?x?xi32, #iree_encoding.encoding<operand_index = 2 : index, element_types = [i8, i32, i32], original_type = tensor<?x?x?xi32>, user_indexing_maps = [#map2, #map3, #map4], round_dims_to = array<i64: 16, 16, 16, 16>>>
      %16 = iree_encoding.unset_encoding %15 : tensor<?x?x?xi32, #iree_encoding.encoding<operand_index = 2 : index, element_types = [i8, i32, i32], original_type = tensor<?x?x?xi32>, user_indexing_maps = [#map2, #map3, #map4], round_dims_to = array<i64: 16, 16, 16, 16>>> -> tensor<?x?x?xi32>
      %extracted_slice = tensor.extract_slice %16[0, 0, 0] [%3, %0, %4] [1, 1, 1] : tensor<?x?x?xi32> to tensor<?x?x?xi32>
      flow.return %extracted_slice : tensor<?x?x?xi32>
    }
    %8 = hal.tensor.export %7 "output0" : tensor<?x?x?xi32>{%3, %0, %4} -> !hal.buffer_view
    util.return %8 : !hal.buffer_view
  }
}

Mahesh, I understand that you have concerns about bcast_map. I'll try to connect more pieces and see if it is needed or not. My intuition tells me that it is needed, like I explained in https://github.com/iree-org/iree/pull/17763#issuecomment-2195806300. Let's see..
(inlining the comment below for convenience)

Say that we have broadcasting_deqaunt + matmul in a dispatch, and we need to allocate a buffer for the input of the dispatch; the original indexing_map from batch_matmul is (b, m, n, k) -> (b, n, k), and we are broadcasting across the batch dimension (i.e., the indexing_map in broadcast op is (b, n, k) -> (n, k)). At stream level, we want to allocate a n * k buffer. If we don't encode the broadcast indexing map, we don't know the allocation size. The missing dimension could be any of b, n and k. I think this is the cost we pay for broadcast fusion.
I think we can't reuse the original indexing_maps field, because it makes logics very very tricky. We could need the original matmul indexing maps to infer contraction dims. Replacing the corresponding indexing map with broadcast map is very bad to me. Decoupling the logic out to a new field reduces the complexity.

Cross posting response as well
"One way to maybe fix it is to change the indexing maps to be an list(list(indexing_maps)). So basically a composition of the indexing maps allows you to get back to the original op. For example for the broadcast case the indexing map would be [[affine_map<(b, m, n, k) -> (b, n, k)>, affine_map<(b,n,k) -> (n, k)>], .., ...] Then this also generalizes (say you want to fuse the transpose in or some arbitrary chain in the future."

I push the changes to https://github.com/iree-org/iree/tree/shared/data-tiling-fusion
Run e2e compilation flow: iree-compile --iree-hal-target-backends=llvm-cpu --iree-llvmcpu-target-cpu=znver4 --iree-llvmcpu-target-triple=x86_64-unknown-linux-gnu --iree-opt-data-tiling=false --iree-flow-enable-data-tiling ~/matmul.mlir -o /tmp/z.vmfb
The current status is that all the ops are in the same dispatch. As mentioned in other comments, next steps are moving the set_encodings out and fusing them with their producers. Max and I will work on this.
util.func public @broadcasting_dequant_op(%arg0 : tensor<?x?xi8>, %rhs : tensor<?x?x?xi32>) -> tensor<?x?x?xi32> {
  %c0 = arith.constant 0 : index
  %c1 = arith.constant 1 : index
  %d1 = tensor.dim %arg0, %c0 : tensor<?x?xi8>
  %d2 = tensor.dim %arg0, %c1 : tensor<?x?xi8>
  %d0 = tensor.dim %rhs, %c0 : tensor<?x?x?xi32>
  %empty = tensor.empty(%d0, %d1, %d2) : tensor<?x?x?xi32>
  %dequant = linalg.generic {
      indexing_maps = [affine_map<(d0, d1, d2) -> (d1, d2)>,
                       affine_map<(d0, d1, d2) -> (d0, d1, d2)>],
      iterator_types = ["parallel", "parallel", "parallel"]}
      ins(%arg0 : tensor<?x?xi8>) outs(%empty : tensor<?x?x?xi32>) {
    ^bb0(%in: i8, %out: i32):
      %12 = arith.extui %in : i8 to i32
      linalg.yield %12 : i32
    } -> tensor<?x?x?xi32>

  %B = tensor.dim %dequant, %c0 : tensor<?x?x?xi32>
  %M = tensor.dim %dequant, %c1 : tensor<?x?x?xi32>
  %N = tensor.dim %rhs, %c1 : tensor<?x?x?xi32>
  %init = tensor.empty(%B, %M, %N) : tensor<?x?x?xi32>
  %cst = arith.constant 0 : i32
  %fill = linalg.fill ins(%cst : i32) outs(%init : tensor<?x?x?xi32>) -> tensor<?x?x?xi32>
  %op = linalg.batch_matmul_transpose_b
      ins(%dequant, %rhs : tensor<?x?x?xi32>, tensor<?x?x?xi32>)
      outs(%fill : tensor<?x?x?xi32>) -> tensor<?x?x?xi32>
  util.return %op : tensor<?x?x?xi32>
}

I took a stab at writing down the IR for materialization pass. The first two set encoding ops should be hoisted to other new dispatches, but it is okay for testing. The pass should be able to handle the case. I'm working on teaching the materialization patterns to take bcast_map into account. So far it just crashes in my prototype.
#map = affine_map<(d0, d1, d2, d3) -> (d0, d1, d3)>
#map1 = affine_map<(d0, d1, d2, d3) -> (d0, d2, d3)>
#map2 = affine_map<(d0, d1, d2, d3) -> (d0, d1, d2)>
#map3 = affine_map<(d0, d1, d2) -> (d1, d2)>
#map4 = affine_map<(d0, d1, d2) -> (d0, d1, d2)>
func.func @broadcasting_deqaunt_matmul(%arg0: !hal.buffer_view, %arg1: !hal.buffer_view) -> !hal.buffer_view attributes {
  hal.executable.target = #hal.executable.target<"xyz", "xyz", {target_triple="aarch64-xyz-xyz"}>
} {

  %M = hal.buffer_view.dim<%arg0 : !hal.buffer_view>[0] : index
  %B = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[0] : index
  %N = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[1] : index
  %K = hal.buffer_view.dim<%arg1 : !hal.buffer_view>[2] : index

  %0 = hal.tensor.import %arg0 "input0" : !hal.buffer_view -> tensor<?x?xi8>{%M, %K}
  %1 = hal.tensor.import %arg1 "input1" : !hal.buffer_view -> tensor<?x?x?xi32>{%B, %N, %K}

  %encoding_0 = iree_encoding.set_encoding %0 : tensor<?x?xi8>
    -> tensor<?x?xi8, #iree_encoding.encoding<
        operand_index = 0 : index,
        element_types = [i8, i32, i32],
        user_indexing_maps = [#map, #map1, #map2],
        bcast_map = #map3,
        round_dims_to = array<i64: 16, 16, 16>>>

  %encoding_1 = iree_encoding.set_encoding %1 : tensor<?x?x?xi32>
    -> tensor<?x?x?xi32, #iree_encoding.encoding<
        operand_index = 1 : index,
        element_types = [i8, i32, i32],
        user_indexing_maps = [#map, #map1, #map2],
        round_dims_to = array<i64: 16, 16, 16>>>

  %3 = tensor.empty(%B, %M, %K) : tensor<?x?x?xi32, #iree_encoding.encoding<
        operand_index = 0 : index,
        element_types = [i8, i32, i32],
        user_indexing_maps = [#map, #map1, #map2],
        bcast_map = #map3,
        round_dims_to = array<i64: 16, 16, 16>>>

  %4 = linalg.generic {indexing_maps = [#map3, #map4], iterator_types = ["parallel", "parallel", "parallel"]}
    ins(%encoding_0 : tensor<?x?xi8, #iree_encoding.encoding<
        operand_index = 0 : index,
        element_types = [i8, i32, i32],
        user_indexing_maps = [#map, #map1, #map2],
        bcast_map = #map3,
        round_dims_to = array<i64: 16, 16, 16>>>)
     outs(%3 : tensor<?x?x?xi32, #iree_encoding.encoding<
        operand_index = 0 : index,
        element_types = [i8, i32, i32],
        user_indexing_maps = [#map, #map1, #map2],
        bcast_map = #map3,
        round_dims_to = array<i64: 16, 16, 16>>>) {
  ^bb0(%in: i8, %out: i32):
    %5 = arith.extui %in : i8 to i32
    linalg.yield %5 : i32
  } -> tensor<?x?x?xi32, #iree_encoding.encoding<
        operand_index = 0 : index,
        element_types = [i8, i32, i32],
        user_indexing_maps = [#map, #map1, #map2],
        bcast_map = #map3,
        round_dims_to = array<i64: 16, 16, 16>>>

  %c0_i32 = arith.constant 0 : i32
  %5 = tensor.empty(%B, %M, %N) : tensor<?x?x?xi32, #iree_encoding.encoding<
        operand_index = 2 : index,
        element_types = [i8, i32, i32],
        user_indexing_maps = [#map, #map1, #map2],
        round_dims_to = array<i64: 16, 16, 16>>>
  %6 = linalg.fill
    ins(%c0_i32 : i32)
    outs(%5 : tensor<?x?x?xi32, #iree_encoding.encoding<
        operand_index = 2 : index,
        element_types = [i8, i32, i32],
        user_indexing_maps = [#map, #map1, #map2],
        round_dims_to = array<i64: 16, 16, 16>>>)
    -> tensor<?x?x?xi32, #iree_encoding.encoding<
    operand_index = 2 : index,
        element_types = [i8, i32, i32],
        user_indexing_maps = [#map, #map1, #map2],
        round_dims_to = array<i64: 16, 16, 16>>>

  %7 = linalg.batch_matmul_transpose_b
    ins(%4, %encoding_1 :
      tensor<?x?x?xi32, #iree_encoding.encoding<
        operand_index = 0 : index,
        element_types = [i8, i32, i32],
        user_indexing_maps = [#map, #map1, #map2],
        bcast_map = #map3,
        round_dims_to = array<i64: 16, 16, 16>>>,
      tensor<?x?x?xi32, #iree_encoding.encoding<
        operand_index = 1 : index,
        element_types = [i8, i32, i32],
        user_indexing_maps = [#map, #map1, #map2],
        round_dims_to = array<i64: 16, 16, 16>>>)
    outs(%6 :
      tensor<?x?x?xi32, #iree_encoding.encoding<
        operand_index = 2 : index,
            element_types = [i8, i32, i32],
            user_indexing_maps = [#map, #map1, #map2],
            round_dims_to = array<i64: 16, 16, 16>>>)
    -> tensor<?x?x?xi32, #iree_encoding.encoding<
        operand_index = 2 : index,
            element_types = [i8, i32, i32],
            user_indexing_maps = [#map, #map1, #map2],
            round_dims_to = array<i64: 16, 16, 16>>>
  %8 = iree_encoding.unset_encoding %7
    : tensor<?x?x?xi32, #iree_encoding.encoding<
        operand_index = 2 : index,
            element_types = [i8, i32, i32],
            user_indexing_maps = [#map, #map1, #map2],
            round_dims_to = array<i64: 16, 16, 16>>>
    -> tensor<?x?x?xi32>
  %extracted_slice = tensor.extract_slice %8[0, 0, 0] [%B, %M, %N] [1, 1, 1] : tensor<?x?x?xi32> to tensor<?x?x?xi32>
  %9 = hal.tensor.export %extracted_slice "output0" : tensor<?x?x?xi32>{%B, %M, %N} -> !hal.buffer_view

  func.return %9 : !hal.buffer_view
}


Docs don't include structs

I'm trying to generate documentation from my contracts, and it looks like the structs are not included in the generated documentation.
Are there plans to include structs? If not, would it be possible for you to let me know how to set up a development environment to make a PR that adds struct information to the generated documentation?
Thanks!

Thanks for the suggestion! One of the issues with structs is that solc doesn't parse NatSpec comments on them, so we would only be able to provide basic information about the type: name, and type and name for each member.
We don't have plans for it but it's something I would be interested in.
In order to make a PR you should fork this repo, clone the fork on your computer, and run npm install. You will have to add a function in SourceContract that would be called ownStructs. You will need to define a new type for the AST node StructDefinition in solc.ts and add it as an option to ContractItem. You can use this page as a reference of what fields are available in the node.
Let me know if you want to work on this. Feel free to submit a Draft PR if you need any more help.

I see, thanks for your reply! I'll see if there's anything I can help with at some point. It would be really great to have all of our documentation generated from source.

Thanks for the suggestion! One of the issues with structs is that solc doesn't parse NatSpec comments on them, so we would only be able to provide basic information about the type: name, and type and name for each member.
We don't have plans for it but it's something I would be interested in.
In order to make a PR you should fork this repo, clone the fork on your computer, and run npm install. You will have to add a function in SourceContract that would be called ownStructs. You will need to define a new type for the AST node StructDefinition in solc.ts and add it as an option to ContractItem. You can use this page as a reference of what fields are available in the node.
Let me know if you want to work on this. Feel free to submit a Draft PR if you need any more help.

Hi.
I have been blocked by this issue, and I have solved it.
Please review my PR: #310
Thank you.