io.flutter.embedding.engine.dart.DartMessenger$Reply.reply

MAX Plugin Version
3.7.0
Flutter Version
3.16.8
Device/Platform Info
Android
Current Behavior
Crash during:
AppLovinMAX.initialize("key");
Expected Behavior
No crash during:
AppLovinMAX.initialize("key");
How to Reproduce
Unfortunately, I can't reproduce it on my end. The crash reports are from Crashlytics. It does happen to a small fraction of users about 100 a day.
One interesting observation is that almost all users experiencing this bug have not granted the GDPR consent. I use ConsentForm.loadConsentForm() to get the users consent like described here Admob Documentation After the consent is observed Applovin is initialised via AppLovinMAX.initialize("key").
Crash report:
Fatal Exception: java.lang.IllegalStateException Reply already submitted io.flutter.embedding.engine.dart.DartMessenger$Reply.reply (DartMessenger.java:435) io.flutter.plugin.common.MethodChannel$IncomingMethodCallHandler$1.success (MethodChannel.java:272) com.applovin.applovin_max.AppLovinMAX.lambda$initialize$0 (AppLovinMAX.java:340) com.applovin.impl.sdk.n.a (SourceFile:1027) android.os.Handler.handleCallback (Handler.java:938) android.os.Handler.dispatchMessage (Handler.java:99) android.os.Looper.loopOnce (Looper.java:210) android.os.Looper.loop (Looper.java:299) android.app.ActivityThread.main (ActivityThread.java:8319) java.lang.reflect.Method.invoke (Method.java) com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:556) com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1038)
Additional Info
No response

I may have found the problem. It was due to an old code from the Flutter Admob SDK.


Wildcard Abbreviations

basically the ability to shorthand wildcard, so something like
{devilkkw/attire/attire_uniforms_and_costumes}
would become
{d/a/acac}
the only thing is i'm not quite sure what to use as the syntax to declare that you are using an abbreviation, perhaps if the first character after __ is a /, like how Danbooru does it
maybe even have a special file for personally common abbreviations, such as {/sf} for solo focus

Don't you mean d/a/auac? 😁
Since wildcard files are parsed for other wildcard references, you should be able to make your own wildcard file, e.g. x/ac with the content __devilkkw/attire/attire_uniforms_and_costumes__ and have it act as an alias you can then use with __x/ac__.
Alternately, if you're on an UNIX style system, you should be able to also use a symlink to another wildcard file...

You might also find the globbing syntax helpful - https://github.com/adieyal/sd-dynamic-prompts#fuzzy-globrecursive-wildcard-filedirectory-matching

Closing to tidy up the issue list; some solutions are above :)


Documentation: add a description to each component

Add a description section to each component page.

Closing due to inactivity.


selectionType as a variable

I'm submitting a ...  (check one with "x")
[x ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, post on Stackoverflow or Gitter

Current behavior
I'm not exactly sure if this is a bug or if I'm just not implementing properly.  I want to change the selectionType on the fly.  I realize the [selectionType] wants a value like "'multi" and I've tried several ways to do that.
Expected behavior
I can set selectionType via a variable.
Reproduction of the problem
http://plnkr.co/edit/dEskVNUzz4Npb38s0quX?p=preview
What is the motivation / use case for changing the behavior?
We have users that prefer a variety of selection behaviors depending on the situation.
Please tell us about your environment:
Windows

Table version: 0.8.x
0.8.x

Angular version: 2.0.x
4.2

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
Any

Language: [all | TypeScript X.X | ES6/7 | ES5]
Typescript 2.4.0

@nickhellmich you aren't using Angular binding correctly. See my plunker fork with added styles to see the difference. http://plnkr.co/edit/Ua2uWNjGjDNhIvW7F1sC
Here's what I changed:
[selectionType]="selectionType"

multi = "multi"; // Previously was multi = "'multi'";
multiClick = "multiClick"; // Previously was multiClick = "'multiClick'";

@wizarrc I know this is an old post of yours but can you explain from your plnkr why some of the template for the data table use double quotes, single quotes, and both at the same time. I'm learning this stuff and I cannot find any explanation for this.
I've been battling the data table to force the user to use the CTRL and the Shift key to multi select but it is ignoring my value no matter how I am setting "multi".


[Refactor] Refactor to work with multiple screen sizes and orientations

https://medium.com/flutter-community/developing-for-multiple-screen-sizes-and-orientations-in-flutter-fragments-in-flutter-a4c51b849434
https://docs.flutter.dev/ui/layout/adaptive-responsive

Closed in #123


user guides: update monero-wallet-cli.md

Closes #1593

updated content
updated structure for consistency with the other guides

(Hope you don't mind, I grabbed some minor stuff outside the diffs).

Not at all. Thanks for the review :)


Round new map position before animating pan

This prevents map from panning into a fractional position (and becoming blurry) if panBy is called while already panning.
Demo: http://jsfiddle.net/0x66297q/
Fixes https://github.com/Leaflet/Leaflet/issues/3913 which was closed as a duplicate, however, I think this particular case is worth fixing :)

Nice, thanks! Just wondering, the fractional position is coming from map._getMapPanePos(), right? Would it be worth rounding there to potentially fix similar issues in other places?

Would it be worth rounding there to potentially fix similar issues in other places?

I have looked through usages of _getMapPanePos, and panBy looks like the only place where rounding is needed.

Modifying _getMapPanePos is going to change behavior of map._moved() function—it will return false instead of true if offset is less than 0.5 pixels (although it is unlikely to affect anything).

It also seems to be more reasonable generally to leave private low-level functions as dump as possible.

So I'd rather leave this rounding where it is :) What do you think?

OK, sounds reasonable. Thanks!


Docs: run storages upadte

cc how it looks for last run endpoint

how it looks for run storage endpoints

I meant if the token is necessary in all the endpoints here - my guess is that all of them should work without it not only the /v2/actor-runs/{runId}/log

Actually I think we do check for the token... in actor_jobs.js => getActorRun which is called by each endpoint.. I think it is the same for the last run


Lumina 0.9.0 updates

updated changelog.rst with 0.9.0 notes
-edited conf.py to reflect version 0.9.0
-edits to lumina.rst
-rewrote lumina-screenshots section
-added lumina text editor section
-reworked lumina xconfig section
-updated screenshots in above sections

For the next commit, format lumina-screenshot, lumina-textedit, start-lumina-desktop, xinit, and startx as commands. For example: :command:lumina-screenshot.
Also, format src-qt5 as a file: :file:src-qt5.

Note that github mangled the formatting examples so ping me if unsure.


Added Dynamic Memory Allocation

Fix #368
Topics covered:

Concept & Benefits
Key Concepts

Heap
new operator
delete operator

Example
Cautions

Memory Leaks
Dangling Pointers

Alternatives (Smart Pointers)
Conclusion

@subhadipbhowmik kindly review

@subhadipbhowmik please review.


[FLINK-6367] support custom header settings of allow origin

jobmanager.web.access-control-allow-origin: Enable custom access control parameter for allow origin header, default is *.

[X] General

The pull request references the related JIRA issue ("[FLINK-6367] support custom header settings of allow origin")
The pull request addresses only one issue
Each commit in the PR has a meaningful commit message (including the JIRA id)

[X] Documentation

Documentation has been added for new functionality
Old documentation affected by the pull request has been updated
JavaDoc for public methods has been added

[X] Tests & Build

Functionality added by the pull request is covered by tests
mvn clean verify has been executed successfully locally or a Travis build has passed

@zentol  fix that

Looks good, +1.

merging.

@zentol Has this been merged? If yes, @shijinkui can you close the pull request manually?

hi, @zentol @StephanEwen It didn't merge in. @zentol Please check again.

Patience please...


feat(cheatcodes): Record pranks at increasing depths for rollbacks

WIP

Closing, will reopen later with a better design (this was only meant to be a draft)


Bug when we try to decode non encoded messages.

As visible in the screeenshot, some garbage symbols appear when we try to decode nothing or while trying to decode a non encoded message.
I currently dont know how to fix this, just putting this out here :D

@AthulJoshi Thankyou for Trying out the project and pointing out the bug.
Me and alwin are working out the issue while decoding empty string , and thanks for pointing out that it happens with non-encoded strings too 👍🏽


x/text: "€" is incorrectly encoded as "\x80" in GB18030 (should have been "\xA2\xE3")

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

$ go version
go version go1.17.1 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
Playground.
https://play.golang.org/p/ELVa9gu69JX
What did you do?
Encode "€" (U+20AC).
package main

import (
	"fmt"
	"golang.org/x/text/encoding/simplifiedchinese"
)

func main() {
	s, _ := simplifiedchinese.GB18030.NewEncoder().String("€")
	if s != "\xA2\xE3" {
		panic(fmt.Sprintf("%x", s))
	}
}

What did you expect to see?
Pass.
What did you see instead?
panic: 80

goroutine 1 [running]:
main.main()
	/tmp/sandbox2937657549/prog.go:11 +0xb9

The character "€" is encoded into "\x80". This is a propriety extension by Microsoft in CP936 (GBK). In GB18030 standard the proper encoding should be "\xA2\xE3".
While the GB18030 decoder recognizes both "\x80" and "\xA2\xE3" as "€" (as it should), the encoder should prefer to generate "\xA2\xE3" over the non-standard "\x80".

The question is whether GB18030 should actually decode \x80 into € as the subject suggests:

While the GB18030 decoder recognizes both "\x80" and "\xA2\xE3" as "€" (as it should)

From https://en.wikipedia.org/wiki/GB_18030#cite_note-4

The euro sign is an exception which is given a single byte code of 0x80 in Microsoft's later versions of CP936/GBK and a two byte code of A2 E3 in GB18030.

From https://icu-project.org/docs/papers/gb18030.html

Note: Like some GBK implementations, the original publication of GB 18030-2000 assigned the Euro currency symbol to the single byte 0x80. The updated mapping table from November leaves 0x80 unassigned and instead maps 0xa2e3 U+20ac for the Euro symbol.

E.g. iconv uses \x80 in GBK and \xa2\xe3 in GB18030 and does not cross-decode:
$ echo -n € | iconv -f UTF-8 -t GBK | xxd
00000000: 80                                       .
$ echo -n € | iconv -f UTF-8 -t GB18030 | xxd
00000000: a2e3                                     ..
$ echo -n € | iconv -f UTF-8 -t GBK | iconv -f GB18030 -t UTF-8
iconv: illegal input sequence at position 0
$ echo -n € | iconv -f UTF-8 -t GB18030 | iconv -f GBK -t UTF-8
iconv: illegal input sequence at position 0

Java on the other hand seems to treat GBK equal to GB18030:
import java.io.UnsupportedEncodingException;

class Go48691 {

    public static void main(String[] args) throws UnsupportedEncodingException {
        System.out.print("encode GBK: ");
        for (byte b : "€".getBytes("GBK")) {
            System.out.format("%x", b);
        }
        System.out.println();

        System.out.print("encode GB18030: ");
        for (byte b : "€".getBytes("GB18030")) {
            System.out.format("%x", b);
        }
        System.out.println();

        System.out.format("decode 1 GBK: %s\n", new String(new byte[]{(byte)0x80}, "GBK"));
        System.out.format("decode 1 GBK: %s\n", new String(new byte[]{(byte)0x80}, "GB18030"));

        System.out.format("decode 2 GBK: %s\n", new String(new byte[]{(byte)0xa2, (byte)0xe3}, "GBK"));
        System.out.format("decode 2 GB18030: %s\n", new String(new byte[]{(byte)0xa2, (byte)0xe3}, "GB18030"));
    }
}

encode GBK: a2e3
encode GB18030: a2e3
decode 1 GBK: �
decode 1 GBK: �
decode 2 GBK: €
decode 2 GB18030: €

According to https://encoding.spec.whatwg.org/#gbk-decoder and https://encoding.spec.whatwg.org/#gb18030-decoder

GBK’s decoder is gb18030’s decoder.
If byte is 0x80, return code point U+20AC.

i.e. both should decode \x80 and \xA2\xE3.
According to https://encoding.spec.whatwg.org/#gbk-encoder and https://encoding.spec.whatwg.org/#gb18030-encoder

GBK’s encoder is gb18030’s encoder with its is GBK set to true.
If is GBK is true and code point is U+20AC, return byte 0x80.


[loc][Query][VSCODE] Localizability of strings invscode-extensions\ms-vscode.js-debug-nightly

Hi,
please help localization team to answer question from translator.
In case translator is not sure about context/meaning/localizability of string we raise a question to Core team.

Id
File Name Live Page Extended
String Resource ID
Full Source String
Extended Description
Answer Needed By

49,765
vscode-extensions\ms-vscode.js-debug-nightly.xlf
0;   "browser.runtimeExecutable.edge.description"
Either 'canary', 'stable', dev,   'custom' or path to the browser executable. Custom means a custom wrapper,   custom build or EDGE_PATH environment variable.
Are these entries   translatable?Also, please, define "dev" in this context.

49,768
vscode-extensions\ms-vscode.js-debug-nightly.xlf
0;   "configuration.pickAndAttachOptions"
Default   options used when debugging a process through the Debug: Attach to Node   Process command
Is   it possible that it refers to string "Attach to Node.js Terminal   Process", following this one? We could not find command "Attach to   Node Process".

49,806
vscode-extensions\ms-vscode.js-debug-nightly.xlf
0;   "configuration.pickAndAttachOptions"
Default options used when   debugging a process through the Debug: Attach to Node Process command
is the command name of   "Debug: Attach to Node Process" translatable?

@connor4312 please clarify the questions above in the code.

Are these entries translatable?Also, please, define "dev" in this context.

The items in quotes (canary, stable, custom) are not translatable -- also, "dev" should be wrapped in quotes, I will fix that. EDGE_PATH is not translatable.

Is it possible that it refers to string "Attach to Node.js Terminal Process", following this one? We could not find command "Attach to Node Process".

Yes, I will correct that

is the command name of "Debug: Attach to Node Process" translatable?

Yes

Thank you


Allow preact-render-to-string 6.x in peer dependencies

Hi team! I was using this package in a new project, and noticed it throws peer dependency errors due to the<EMAIL_ADDRESS>requirement. I hope this fix is acceptable.

Thanks!
I'll look to publish a new version w/ this change in a bit.


Use of custom PKI

We are using gotenberg internally against https servers with certificates generated with an internal PKI.
As I usually do for other images, I made a new dockerimage based on thecodingmachine/gotenberg:5
FROM thecodingmachine/gotenberg:5

ADD http://blahblahblah/internal-pki.crt /usr/local/share/ca-certificates/internal-pki.crt
RUN set -xeu \
  && update-ca-certificates

The certificate is properly deployed, rehashed, symlinked and added to ca-certificates.crt and it works with curl, wget and so on.
This is usually enough for being taken in consideration by all our ecosystem including servers and chrome etc on workstations.
Here, it doesn't work. Any clues ?
More generally, it seems that when there is a certificate issue (self signed, unrecognized authority, name issue etc) we only got blank page, without anymore info in the logs :/
Please note that it works like a charm using a commonly accepted Root CA.

Hello @babs!
I'm not familiar with "custom certificate management" (not sure about the wording lol) so I'm afraid I may not be able to help that much.
That's said, there is maybe an option to launch Google Chrome in order to skip certificate issue (see https://github.com/thecodingmachine/gotenberg/blob/master/internal/pkg/pm2/chrome.go#L34).

I found a solution.
It seems that Chrome in this case uses ~/.pki/nnsdb as reference and but only creates it at the first start.
My workaround is to create the folder at build time and initialize it. Only then inject my Root CA inside.
At this point everything works.
Here is an example of Dockerfile that mitigate the issue.
FROM thecodingmachine/gotenberg:5

ADD http://blahblahblah/internal-pki.crt /usr/local/share/ca-certificates/internal-pki.crt
RUN set -xeu \
  && update-ca-certificates \
  && apt-get update && apt-get -y libnss3-tools \
  && mkdir -p /root/.pki/nssdb \
  && certutil -d sql:/root/.pki/nssdb -N --empty-password \
  && certutil -d sql:/root/.pki/nssdb -A -t TC -n CorpAuthority -i /usr/local/share/ca-certificates/internal-pki.crt

👍 glad you find a solution!


Failed to connect to remote notebook

Issue Type: Bug

ssh into a remote computer
start a jupyter lab instance jupyter lab --ip=<IP_ADDRESS>
get the jupyter server url: e.g. http://<IP_ADDRESS>:8890/lab?token=*********************************
this url opens up jupyter labs without issue in a browser
in VS Code press ctrl+shift+p
select Jupyter: Specify local or remote Jupyter server for connections
select Existing  Specify the URI of an existing server
reload VS Code when prompted
Once VS Code reloads, run python code in the interactive pane

I get:
Failed to connect to remote Jupyter notebook.
Check that the Jupyter Server URI setting has a valid running server specified. http://<IP_ADDRESS>:8890/lab
Error: Kernel Python 3 is not usable.
Check the Jupyter output tab for more information.

Yet the exact same server URI works just fine in a browser.
What is the problem?
It seems like every couple of updates, this breaks.
In the terminal running the Jupyter server, I see the following every time I try and get VS Code to connect:
[W 2021-02-04 19:55:36.482 LabApp] 405 POST /lab/api/contents/?1612468535735 (<IP_ADDRESS>) 1.49ms referer=None
[W 2021-02-04 19:55:37.165 LabApp] 405 POST /lab/api/contents/?1612468536417 (<IP_ADDRESS>) 4.18ms referer=None

Extension version: 2020.12.414227025
VS Code version: Code 1.52.1 (ea3859d4ba2f3e577a159bc91e3074c5d85c0523, 2020-12-16T16:34:46.910Z)
OS version: Windows_NT x64 10.0.18363

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz (4 x 2496)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
15.88GB (4.51GB free)

Process Argv
--crash-reporter-id f652528b-5678-4b12-9ca0-3de6b1e1135f

Screen Reader
yes

VM
0%

A/B Experiments
vsliv368:30146709
vsreu685:30147344
openlogontheside:30221877
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492:30211401
wsl2promptcf:30224613
pythonvsdeb440:30248342
unusedprompt:30224610
folderexplorercf:30224615
openfilemenu:30224647
pythonvsded773:30248341
pythonvspyt875:30251590

Thanks for filing this issue.

It seems like every couple of updates, this breaks.

I'm sorry about this,
Please could you confirm this exact same scenario used to work previously.
I have personally never tried spinning Jupyter Lab & connecting to that, I'll test this at my end.
Generally we've tried jupyter notebook -ip... I'll check if we do support that & if we've regressed in that area.

Yes, confirming this is the approach I have always used for the past approx. two years.

Thanks, I've tested this at my end and it seems to work as expected.
Please could you try installing our latest development build of the VSIX and let us know if this makes any difference  https://github.com/microsoft/vscode-jupyter/suites/1970511305/artifacts/39153932
Also, please could you try the following (if the above doesn't work):

Change the IP to something else & try again
Remove the IP completely & try again
If none of these work, can you try to install an older version of the extension & let us know if it works.

Do you know when this stopped working? Were you using this last week or last month?
If you haven't got this information, please try to install the October release of the Python extesnion (to do this, you'll first need to uninstall the existing Jupyter & Python extensions in that order & then install the October version of Python extension)
Trying to figure out when we regressed for you.

earlier today it worked just fine.
It still did not work after I:

tried notebook instead of lab
Tried all your suggestions above
restarted my computer

However, it did start working again after I refreshed my group and security policies.
Not sure why Jupyter labs or notebook worked in the browser just fine, but would not work in VS Code.
Anyway, this issue can be closed now.


Fixed typo

What is the purpose of the change
 Fixed typo.

Coverage increased (+0.01%) to 38.787% when pulling<PHONE_NUMBER>7a60c5ac6f254a4b9615a09669c39b on fucongchan:fixed_typo into 3a0451b286686199270adaa8d2252052c86eddbb on apache:master.


#289 Implement viewer

Implement viewer button in top left of scripture view. Needs style polish and proper labeling.
Implements #289

It shouldn't be over the scrollbar. So it needs some right padding.

see if you like it with a border

I don't see any change in the spacing.
BTW, I see "Merge branch 'main'" in the list of commits?


Skillmap: Deleting profile doesn't convert cloud-saved projects to local projects

Describe the bug
Skillmap: Deleting profile doesn't convert cloud-saved projects to local projects
Steps to reproduce the behavior
1.Navigate to https://arcade.makecode.com/stable--skillmap#
2.Sign in Microsoft account
3.Delte Profile
Expect behavior
My cloud-saved projects will be converted to local projects after Deleting profile
Actual behavior
Skillmap: Deleting profile doesn't convert cloud-saved projects to local projects

Additional context
1.OS: Windows(rs6)
2.arcade version: 1.6.4
3.Microsoft MakeCode version: 7.2.6

We need to do this for compliance.

We need to:

Export all cloud projects to local (skillmap and non-skillmap)
Overwrite local skillmap progress with cloud progress (preserving progress in the now-local activities)

Fixed by https://github.com/microsoft/pxt/pull/8482 in stable. Will port to master soon.

@eanders-ms Still not fixed

On profile delete, cloud-to-local project conversion was not working generally. That's been fixed. We have more work to do to export skillmap progress to local.


Scam Thread Submission

Duplicate Submissions

[X] Yes, I checked that the name is not currently in the list
[X] I read the wiki explaining each different categories and examples before submitting

(Required) Spam Comment Direct Link
https://www.youtube.com/watch?v=bJjMz-iDTg8&lc=UgzwfrMJQdFJ_E9p38N4AaABAg.9drrU523eJg9drsaUIR0ic
(Optional) Screenshot of comments referencing the scammer names

(Required) List of the scammer names
donna jean boyette

Closed with https://github.com/ThioJoe/YT-Spam-Lists/commit/84bca687ca365a48c757b78063dcd88798c1b271


add "--include-checks" flag to changelog

Codecov Report

Merging #304 (6cbaa3a) into main (9851dd6) will increase coverage by 0.00%.
The diff coverage is 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main     #304   +/-   ##
=======================================
  Coverage   79.46%   79.46%
=======================================
  Files         172      172
  Lines        9619     9620    +1
=======================================
+ Hits         7644     7645    +1
  Misses       1685     1685
  Partials      290      290

Flag
Coverage Δ

unittests
79.46% <100.00%> (+<0.01%)
:arrow_up:

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

Impacted Files
Coverage Δ

checker/default_checks.go
90.56% <100.00%> (ø)

internal/changelog.go
78.18% <100.00%> (+0.20%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Add hunt for rlo char

https://resources.infosecinstitute.com/topic/spoof-using-right-to-left-override-rtlo-technique-2/

hunt added


Improve forest-cli error message when making RPC calls with insufficient permission

Issue summary

When I call forest-cli net connect(which requires write permission), the error message should explain the failure and instruct me on how to set an proper API token.
Current output:
     Running `target/debug/forest-cli net connect /ip4/<IP_ADDRESS>/tcp/12346/p2p/12D3KooWKaD4rUzxNWVty62M7xJFAZqMizbjWBvwr4HZYxj52bJj`
addr_info: AddrInfo { id: "12D3KooWKaD4rUzxNWVty62M7xJFAZqMizbjWBvwr4HZYxj52bJj", addrs: {"/ip4/<IP_ADDRESS>/tcp/12346/p2p/12D3KooWKaD4rUzxNWVty62M7xJFAZqMizbjWBvwr4HZYxj52bJj"} }
Error: error trying to connect: tcp connect error: Connection refused (os error 111)

Caused by:
    0: error trying to connect: tcp connect error: Connection refused (os error 111)
    1: error trying to connect: tcp connect error: Connection refused (os error 111)
    2: error trying to connect: tcp connect error: Connection refused (os error 111)
    3: tcp connect error: Connection refused (os error 111)
    4: Connection refused (os error 111)

Other information and links

Fixed by #4406 . The error message now looks like
forest-cli net connect /ip4/<IP_ADDRESS>/tcp/12346/p2p/12D3KooWKaD4rUzxNWVty62M7xJFAZqMizbjWBvwr4HZYxj52bJj
Error: ErrorObject { code: ServerError(401), message: "Unauthorized", data: None }

Caused by:
    ErrorObject { code: ServerError(401), message: "Unauthorized", data: None }

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: __libc_start_call_main
             at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  14: __libc_start_main_impl
             at ./csu/../csu/libc-start.c:392:3
  15: <unknown>


cubestore persistency with remoteDir doesn't work on gcp

Hello,
standard storageClass on gcp with readwrite access type won't be able to provision volume as the standard storage class doesn't support mounting volume on multiple pods in GCP.

Thanks for your response.
I did encode the gcp service account json with base64 and passed it as CUBESTORE_GCP_CREDENTIALS. However, cube unable to decode it and throws the following error:
2023-05-30 21:57:13,670 ERROR [cubestore::remotefs::gcs] <pid:1> Could not decode 'CUBESTORE_GCP_CREDENTIALS': Internal: Invalid byte 10, offset 3080.

I also tried to encode service account JSON file 2 times before creating the secret. as all the secrets need to base64 encoded and even cube expects CUBESTORE_GCP_CREDENTIALS to be in encoded format.

You need to encode twice in base64 because k8s secrets are stored in base64 and cubestore expect a base64 value too.
exemple:
 cat service-account.json | base64 | base64


Inappwebview Samsung tablet - When connected using bluetooth mouse webview screen not clickable

[x] I have read the README
[x] I have already searched for the same problem
[x] I have read and done the setup for Android: IMPORTANT Note for Android and iOS and IMPORTANT Note for Android
[x] I have read and done the setup for iOS: IMPORTANT Note for Android and iOS and IMPORTANT Note for iOS
[x] I have ran the sample app and it does not work there

Environment

Technology
Version

Flutter version
1.22.4  & Dart 2.10.4

Plugin version
^4.0.0+4

Android version
Samsung Tablet 10

iOS version

Xcode version

Device information:  Samsung tablet
Samsung Galaxy Tab S5e
Samsung Galaxy Tab 6S
Description
InAppWebView screen not listen to click event when connected using bluetooth mouse using Android Samsung Tablet Dex and normal mode.
Same InAppWebView  and impl. listen to click event when screen touch used.
Device Used  -  Samsung Tablet DEX mode and Normal Mode with Android 10
Expected behavior:
In App Webview screen should listen to click of mouse connected to Tablet device
Current behavior:
Screen not allowing to click anywhere in web page rendered in webview

can some one please suggest solution around this issue

Please, try to use the new latest version of the plugin and set the useHybridComposition: true Android-specific InAppWebView option.

Thanks, the issue has been resolved.


Improve search benchmark with random sampling

Closes #627.
Changes

Fix benchmark number for external blog
Fix typos in CONTRIBUTING.md
Add random sampling of movie names to perform a more realistic & fair comparison for search times between sync and async clients (a mix of regular and lowercased movie names are searched at random)

Results
No random sampling (searching the 1000 times)
The timing for the search benchmarks, simply looking for the term "the" again and again, were as follows:
Running async multi function benchmark... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:01
Running sync multi function benchmark... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:32
0.16360001564025878
3.275240921974182

Speedup factor using async was 20.01.
With random sampling (searching 1000 random movies)
The timing for the search benchmarks, with 1000 randomly sampled movies with a mix of regular and lowercasing, are as follows:
Running async multi function benchmark... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:02
Running sync multi function benchmark... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:01:33
0.26131467819213866
9.372976708412171

Speedup factor using async is now 35.86.
Observations
It makes sense that we'd see a higher speedup when doing random searches (because we avoid triggering any internal DB caching along the way). Your numbers for speedup could be different, but I feel the trend will be similar.

Thanks for this @prrao87 ... and thanks for being the first person to take the time to read the contributing file and fixing the typos there :smile:
The only change I made was to merge the latest main. Shortly after we talked I got a report from a user that the new TTL cache was causing an out of memory error for him. I haven't been able to recreate this issue, but I know the user that reported it and I'm confident he came across a real issue. With that I decided to remove the cache.
I ran the tests on your branch both before and after removing the cache and in both cases got nearly identical numbers to yours.


[CPU] i4 pack op fails to compile

It looks like some memref.subviews are not optimized away for this i4 pack op and we try to apply narrow type emulation to it:
#config = #iree_codegen.lowering_config<tile_sizes = [[20000, 16000], [1, 1]]>
#executable_target_system_elf_arm_64_ = #hal.executable.target<"llvm-cpu", "system-elf-arm_64", {cpu = "", cpu_features = "+neon", data_layout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128", link_embedded = false, native_vector_size = 16 : index, target_triple = "aarch64-none-linux-android34", ukernels = "none"}>
#pipeline_layout = #hal.pipeline.layout<push_constants = 0, sets = [<0, bindings = [<0, storage_buffer, ReadOnly>, <1, storage_buffer>]>]>
#translation = #iree_codegen.translation_info<CPUDataTiling>
module {
  hal.executable public @pack_i4 {
    hal.executable.variant public @system_elf_arm_64 target(#executable_target_system_elf_arm_64_) {
      hal.executable.export public @pack_i4 ordinal(0) layout(#pipeline_layout) attributes {translation_info = #translation} {
      ^bb0(%arg0: !hal.device):
        %x, %y, %z = flow.dispatch.workgroup_count_from_slice
        hal.return %x, %y, %z : index, index, index
      }
      builtin.module {
        func.func @pack_i4() {
          %c0_i4 = arith.constant 0 : i4
          %c0 = arith.constant 0 : index
          %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c0) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<16000x32000xi4>>
          %1 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c0) : !flow.dispatch.tensor<writeonly:tensor<200000x16000x64x1xi4>>
          %2 = flow.dispatch.tensor.load %0, offsets = [0, 0], sizes = [16000, 32000], strides = [1, 1] : !flow.dispatch.tensor<readonly:tensor<16000x32000xi4>> -> tensor<16000x32000xi4>
          %3 = tensor.empty() : tensor<200000x16000x64x1xi4>
          %pack = tensor.pack %2 padding_value(%c0_i4 : i4) outer_dims_perm = [1, 0] inner_dims_pos = [1, 0] inner_tiles = [64, 1] into %3 {lowering_config = #config} : tensor<16000x32000xi4> -> tensor<200000x16000x64x1xi4>
          flow.dispatch.tensor.store %pack, %1, offsets = [0, 0, 0, 0], sizes = [200000, 16000, 64, 1], strides = [1, 1, 1, 1] : tensor<200000x16000x64x1xi4> -> !flow.dispatch.tensor<writeonly:tensor<200000x16000x64x1xi4>>
          return
        }
      }
    }
  }
}

Error:
iree-compile --iree-hal-target-backends=llvm-cpu --iree-llvmcpu-target-cpu-features="+neon" --iree-llvmcpu-target-triple=aarch64-none-linux-android34 --iree-opt-dcata-tiling=true --iree-llvmcpu-enable-ukernels=none --compile-from=executable-sources repro.mlir

repro.mlir:21:19: error: failed to legalize operation 'memref.subview' that was explicitly marked illegal
          %pack = tensor.pack %2 padding_value(%c0_i4 : i4) outer_dims_perm = [1, 0] inner_dims_pos = [1, 0] inner_tiles = [64, 1] into %3 {lowering_config = #config} : tensor<16000x3
2000xi4> -> tensor<200000x16000x64x1xi4>
                  ^
repro.mlir:21:19: note: see current operation: %29 = "memref.subview"(%7, %27, %28, %24) <{operandSegmentSizes = array<i32: 1, 2, 1, 0>, static_offsets = array<i64: -92233720368547758
08, -9223372036854775808>, static_sizes = array<i64: 1, -9223372036854775808>, static_strides = array<i64: 1, 1>}> : (memref<16000x32000xi4>, index, index, index) -> memref<1x?xi4, strided<[32000, 1], offset: ?>>

IR before the compilation error:
// -----// IR Dump After FoldMemRefAliasOps (fold-memref-alias-ops) //----- //
module {
  func.func @pack_i4() {
    %c1 = arith.constant 1 : index
    %c20000 = arith.constant 20000 : index
    %c16000 = arith.constant 16000 : index
    %c200000 = arith.constant 200000 : index
    %c0_i4 = arith.constant 0 : i4
    %c0 = arith.constant 0 : index
    %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c0) flags(ReadOnly) : memref<16000x32000xi4>
    memref.assume_alignment %0, 64 : memref<16000x32000xi4>
    %1 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c0) : memref<200000x16000x64x1xi4>
    memref.assume_alignment %1, 64 : memref<200000x16000x64x1xi4>
    %workgroup_id_x = hal.interface.workgroup.id[0] : index
    %workgroup_count_x = hal.interface.workgroup.count[0] : index
    %workgroup_id_y = hal.interface.workgroup.id[1] : index
    %workgroup_count_y = hal.interface.workgroup.count[1] : index
    %2 = affine.apply affine_map<()[s0] -> (s0 * 20000)>()[%workgroup_id_y]
    %3 = affine.apply affine_map<()[s0] -> (s0 * 20000)>()[%workgroup_count_y]
    %4 = affine.apply affine_map<()[s0] -> (s0 * 16000)>()[%workgroup_id_x]
    %5 = affine.apply affine_map<()[s0] -> (s0 * 16000)>()[%workgroup_count_x]
    cf.br ^bb1(%2 : index)
  ^bb1(%6: index):  // 2 preds: ^bb0, ^bb11
    %7 = arith.cmpi slt, %6, %c200000 : index
    cf.cond_br %7, ^bb2, ^bb12
  ^bb2:  // pred: ^bb1
    cf.br ^bb3(%4 : index)
  ^bb3(%8: index):  // 2 preds: ^bb2, ^bb10
    %9 = arith.cmpi slt, %8, %c16000 : index
    cf.cond_br %9, ^bb4, ^bb11
  ^bb4:  // pred: ^bb3
    cf.br ^bb5(%c0 : index)
  ^bb5(%10: index):  // 2 preds: ^bb4, ^bb9
    %11 = arith.cmpi slt, %10, %c20000 : index
    cf.cond_br %11, ^bb6, ^bb10
  ^bb6:  // pred: ^bb5
    %12 = affine.min affine_map<()[s0, s1] -> (s0 * -64 - s1 * 64 + 32000, 64)>()[%10, %6]
    cf.br ^bb7(%c0 : index)
  ^bb7(%13: index):  // 2 preds: ^bb6, ^bb8
    %14 = arith.cmpi slt, %13, %c16000 : index
    cf.cond_br %14, ^bb8, ^bb9
  ^bb8:  // pred: ^bb7
    %15 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%8, %13]
    %16 = affine.apply affine_map<()[s0, s1] -> (s0 * 64 + s1 * 64)>()[%6, %10]
    %subview = memref.subview %0[%15, %16] [1, %12] [1, 1] : memref<16000x32000xi4> to memref<1x?xi4, strided<[32000, 1], offset: ?>>
    %17 = vector.transfer_read %subview[%c0, %c0], %c0_i4 : memref<1x?xi4, strided<[32000, 1], offset: ?>>, vector<64xi4>
    %18 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%6, %10]
    %19 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%8, %13]
    vector.store %17, %1[%18, %19, %c0, %c0] : memref<200000x16000x64x1xi4>, vector<64xi4>
    %20 = arith.addi %13, %c1 : index
    cf.br ^bb7(%20 : index)
  ^bb9:  // pred: ^bb7
    %21 = arith.addi %10, %c1 : index
    cf.br ^bb5(%21 : index)
  ^bb10:  // pred: ^bb5
    %22 = arith.addi %8, %5 : index
    cf.br ^bb3(%22 : index)
  ^bb11:  // pred: ^bb3
    %23 = arith.addi %6, %3 : index
    cf.br ^bb1(%23 : index)
  ^bb12:  // pred: ^bb1
    return
  }
}

@hanhanW, @MaheshRavishankar this is the memref.subview error. Also pinging @Max191. This is currently blocking our DT+UK enablement for i4.

Dont we have patterns to fold memref.subview into vector.transfer_read ? It is here https://github.com/shark-infra/llvm-project/blob/6a22c340976abaa0a65f580f8e83fd8ea1593b95/mlir/lib/Dialect/MemRef/Transforms/FoldMemRefAliasOps.cpp#L379-L380  That subview shouldnt be there after fold memref subviews.

Is there a reason not to fold when in_bounds is false? https://github.com/shark-infra/llvm-project/blob/6a22c340976abaa0a65f580f8e83fd8ea1593b95/mlir/lib/Dialect/MemRef/Transforms/FoldMemRefAliasOps.cpp#L351
I'm trying to understand what would be needed to support this case...

Thanks! I gave that a try: https://github.com/llvm/llvm-project/pull/80517
It fixes this issue.

Hitting similar error in the narrow type emulation pass, this time involving a memref.subview + memref.colapse_shape + vector.load (no out of bounds this time) that I don't think we can/should fold into the vector load :
    %subview_4 = memref.subview %7[%15, 0, 0, 0] [4, 512, 8, 8] [1, 1, 1, 1] : memref<256x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>> to memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
    %collapse_shape_5 = memref.collapse_shape %subview_4 [[0], [1], [2, 3]] : memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>> into memref<4x512x64xi4, strided<[32768, 64, 1], offset: ?>>
    %41 = vector.load %collapse_shape_5[%19, %21, %c0] : memref<4x512x64xi4, strided<[32768, 64, 1], offset: ?>>, vector<64xi4>

I haven't thought too much about this yet but it looks like we may want to add support for memref.subview and memref.collapse_shape to NarrowTypeEmulation regardless of them being fused or not in some cases. I would appreciate some brainstorming @Max191, @hanhanW, @MaheshRavishankar.
Full IR before NarrowTypeEmulation:
module {
  func.func @main_dispatch_65_mmt4d_64x256x512x8x8x8_i8xi4xi32() {
    %c7 = arith.constant 7 : index
    %c6 = arith.constant 6 : index
    %c5 = arith.constant 5 : index
    %c3 = arith.constant 3 : index
    %cst = arith.constant dense<0> : vector<64xi32>
    %cst_0 = arith.constant dense<0> : vector<8x8xi4>
    %cst_1 = arith.constant dense<0> : vector<8x8xi8>
    %cst_2 = arith.constant dense<0> : vector<8x8xi32>
    %cst_3 = arith.constant dense<0> : vector<1x1x8x8xi32>
    %c512 = arith.constant 512 : index
    %c4 = arith.constant 4 : index
    %c1 = arith.constant 1 : index
    %c2 = arith.constant 2 : index
    %c0 = arith.constant 0 : index
    %c256 = arith.constant 256 : index
    %c64 = arith.constant 64 : index
    %0 = hal.interface.constant.load[0] : i32
    %1 = hal.interface.constant.load[1] : i32
    %2 = hal.interface.constant.load[2] : i32
    %3 = arith.index_castui %0 : i32 to index
    %4 = arith.index_castui %1 : i32 to index
    %5 = arith.index_castui %2 : i32 to index
    %6 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%3) flags(ReadOnly) : memref<64x512x8x8xi8, strided<[32768, 64, 8, 1], offset: ?>>
    memref.assume_alignment %6, 1 : memref<64x512x8x8xi8, strided<[32768, 64, 8, 1], offset: ?>>
    %7 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%4) flags(ReadOnly) : memref<256x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
    memref.assume_alignment %7, 1 : memref<256x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
    %8 = hal.interface.binding.subspan set(0) binding(2) type(storage_buffer) alignment(64) offset(%5) : memref<64x256x8x8xi32, strided<[16384, 64, 8, 1], offset: ?>>
    memref.assume_alignment %8, 1 : memref<64x256x8x8xi32, strided<[16384, 64, 8, 1], offset: ?>>
    %workgroup_id_x = hal.interface.workgroup.id[0] : index
    %workgroup_count_x = hal.interface.workgroup.count[0] : index
    %workgroup_id_y = hal.interface.workgroup.id[1] : index
    %workgroup_count_y = hal.interface.workgroup.count[1] : index
    %9 = affine.apply affine_map<()[s0] -> (s0 * 2)>()[%workgroup_id_y]
    %10 = affine.apply affine_map<()[s0] -> (s0 * 2)>()[%workgroup_count_y]
    %11 = affine.apply affine_map<()[s0] -> (s0 * 4)>()[%workgroup_id_x]
    %12 = affine.apply affine_map<()[s0] -> (s0 * 4)>()[%workgroup_count_x]
    cf.br ^bb1(%9 : index)
  ^bb1(%13: index):  // 2 preds: ^bb0, ^bb12
    %14 = arith.cmpi slt, %13, %c64 : index
    cf.cond_br %14, ^bb2, ^bb13
  ^bb2:  // pred: ^bb1
    %subview = memref.subview %6[%13, 0, 0, 0] [2, 512, 8, 8] [1, 1, 1, 1] : memref<64x512x8x8xi8, strided<[32768, 64, 8, 1], offset: ?>> to memref<2x512x8x8xi8, strided<[32768, 64, 8, 1], offset: ?>>
    cf.br ^bb3(%11 : index)
  ^bb3(%15: index):  // 2 preds: ^bb2, ^bb11
    %16 = arith.cmpi slt, %15, %c256 : index
    cf.cond_br %16, ^bb4, ^bb12
  ^bb4:  // pred: ^bb3
    %subview_4 = memref.subview %7[%15, 0, 0, 0] [4, 512, 8, 8] [1, 1, 1, 1] : memref<256x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>> to memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
    cf.br ^bb5(%c0 : index)
  ^bb5(%17: index):  // 2 preds: ^bb4, ^bb10
    %18 = arith.cmpi slt, %17, %c2 : index
    cf.cond_br %18, ^bb6(%c0 : index), ^bb11
  ^bb6(%19: index):  // 2 preds: ^bb5, ^bb9
    %20 = arith.cmpi slt, %19, %c4 : index
    cf.cond_br %20, ^bb7(%c0, %cst_3 : index, vector<1x1x8x8xi32>), ^bb10
  ^bb7(%21: index, %22: vector<1x1x8x8xi32>):  // 2 preds: ^bb6, ^bb8
    %23 = arith.cmpi slt, %21, %c512 : index
    cf.cond_br %23, ^bb8, ^bb9
  ^bb8:  // pred: ^bb7
    %collapse_shape = memref.collapse_shape %subview [[0], [1], [2, 3]] : memref<2x512x8x8xi8, strided<[32768, 64, 8, 1], offset: ?>> into memref<2x512x64xi8, strided<[32768, 64, 1], offset: ?>>
    %24 = vector.load %collapse_shape[%17, %21, %c0] : memref<2x512x64xi8, strided<[32768, 64, 1], offset: ?>>, vector<64xi8>
    %25 = vector.extract_strided_slice %24 {offsets = [0], sizes = [8], strides = [1]} : vector<64xi8> to vector<8xi8>
    %26 = vector.insert %25, %cst_1 [0] : vector<8xi8> into vector<8x8xi8>
    %27 = vector.extract_strided_slice %24 {offsets = [8], sizes = [8], strides = [1]} : vector<64xi8> to vector<8xi8>
    %28 = vector.insert %27, %26 [1] : vector<8xi8> into vector<8x8xi8>
    %29 = vector.extract_strided_slice %24 {offsets = [16], sizes = [8], strides = [1]} : vector<64xi8> to vector<8xi8>
    %30 = vector.insert %29, %28 [2] : vector<8xi8> into vector<8x8xi8>
    %31 = vector.extract_strided_slice %24 {offsets = [24], sizes = [8], strides = [1]} : vector<64xi8> to vector<8xi8>
    %32 = vector.insert %31, %30 [3] : vector<8xi8> into vector<8x8xi8>
    %33 = vector.extract_strided_slice %24 {offsets = [32], sizes = [8], strides = [1]} : vector<64xi8> to vector<8xi8>
    %34 = vector.insert %33, %32 [4] : vector<8xi8> into vector<8x8xi8>
    %35 = vector.extract_strided_slice %24 {offsets = [40], sizes = [8], strides = [1]} : vector<64xi8> to vector<8xi8>
    %36 = vector.insert %35, %34 [5] : vector<8xi8> into vector<8x8xi8>
    %37 = vector.extract_strided_slice %24 {offsets = [48], sizes = [8], strides = [1]} : vector<64xi8> to vector<8xi8>
    %38 = vector.insert %37, %36 [6] : vector<8xi8> into vector<8x8xi8>
    %39 = vector.extract_strided_slice %24 {offsets = [56], sizes = [8], strides = [1]} : vector<64xi8> to vector<8xi8>
    %40 = vector.insert %39, %38 [7] : vector<8xi8> into vector<8x8xi8>
    %collapse_shape_5 = memref.collapse_shape %subview_4 [[0], [1], [2, 3]] : memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>> into memref<4x512x64xi4, strided<[32768, 64, 1], offset: ?>>
    %41 = vector.load %collapse_shape_5[%19, %21, %c0] : memref<4x512x64xi4, strided<[32768, 64, 1], offset: ?>>, vector<64xi4>
    %42 = vector.extract_strided_slice %41 {offsets = [0], sizes = [8], strides = [1]} : vector<64xi4> to vector<8xi4>
    %43 = vector.insert %42, %cst_0 [0] : vector<8xi4> into vector<8x8xi4>
    %44 = vector.extract_strided_slice %41 {offsets = [8], sizes = [8], strides = [1]} : vector<64xi4> to vector<8xi4>
    %45 = vector.insert %44, %43 [1] : vector<8xi4> into vector<8x8xi4>
    %46 = vector.extract_strided_slice %41 {offsets = [16], sizes = [8], strides = [1]} : vector<64xi4> to vector<8xi4>
    %47 = vector.insert %46, %45 [2] : vector<8xi4> into vector<8x8xi4>
    %48 = vector.extract_strided_slice %41 {offsets = [24], sizes = [8], strides = [1]} : vector<64xi4> to vector<8xi4>
    %49 = vector.insert %48, %47 [3] : vector<8xi4> into vector<8x8xi4>
    %50 = vector.extract_strided_slice %41 {offsets = [32], sizes = [8], strides = [1]} : vector<64xi4> to vector<8xi4>
    %51 = vector.insert %50, %49 [4] : vector<8xi4> into vector<8x8xi4>
    %52 = vector.extract_strided_slice %41 {offsets = [40], sizes = [8], strides = [1]} : vector<64xi4> to vector<8xi4>
    %53 = vector.insert %52, %51 [5] : vector<8xi4> into vector<8x8xi4>
    %54 = vector.extract_strided_slice %41 {offsets = [48], sizes = [8], strides = [1]} : vector<64xi4> to vector<8xi4>
    %55 = vector.insert %54, %53 [6] : vector<8xi4> into vector<8x8xi4>
    %56 = vector.extract_strided_slice %41 {offsets = [56], sizes = [8], strides = [1]} : vector<64xi4> to vector<8xi4>
    %57 = vector.insert %56, %55 [7] : vector<8xi4> into vector<8x8xi4>
    %58 = arith.extsi %40 : vector<8x8xi8> to vector<8x8xi32>
    %59 = arith.extsi %57 : vector<8x8xi4> to vector<8x8xi32>
    %60 = vector.extract %59[0] : vector<8xi32> from vector<8x8xi32>
    %61 = vector.insert_strided_slice %60, %cst {offsets = [0], strides = [1]} : vector<8xi32> into vector<64xi32>
    %62 = vector.extract %59[1] : vector<8xi32> from vector<8x8xi32>
    %63 = vector.insert_strided_slice %62, %61 {offsets = [8], strides = [1]} : vector<8xi32> into vector<64xi32>
    %64 = vector.extract %59[2] : vector<8xi32> from vector<8x8xi32>
    %65 = vector.insert_strided_slice %64, %63 {offsets = [16], strides = [1]} : vector<8xi32> into vector<64xi32>
    %66 = vector.extract %59[3] : vector<8xi32> from vector<8x8xi32>
    %67 = vector.insert_strided_slice %66, %65 {offsets = [24], strides = [1]} : vector<8xi32> into vector<64xi32>
    %68 = vector.extract %59[4] : vector<8xi32> from vector<8x8xi32>
    %69 = vector.insert_strided_slice %68, %67 {offsets = [32], strides = [1]} : vector<8xi32> into vector<64xi32>
    %70 = vector.extract %59[5] : vector<8xi32> from vector<8x8xi32>
    %71 = vector.insert_strided_slice %70, %69 {offsets = [40], strides = [1]} : vector<8xi32> into vector<64xi32>
    %72 = vector.extract %59[6] : vector<8xi32> from vector<8x8xi32>
    %73 = vector.insert_strided_slice %72, %71 {offsets = [48], strides = [1]} : vector<8xi32> into vector<64xi32>
    %74 = vector.extract %59[7] : vector<8xi32> from vector<8x8xi32>
    %75 = vector.insert_strided_slice %74, %73 {offsets = [56], strides = [1]} : vector<8xi32> into vector<64xi32>
    %76 = vector.shuffle %75, %75 [0, 8, 16, 24, 32, 40, 48, 56, 1, 9, 17, 25, 33, 41, 49, 57, 2, 10, 18, 26, 34, 42, 50, 58, 3, 11, 19, 27, 35, 43, 51, 59, 4, 12, 20, 28, 36, 44, 52, 60, 5, 13, 21, 29, 37, 45, 53, 61, 6, 14, 22, 30, 38, 46, 54, 62, 7, 15, 23, 31, 39, 47, 55, 63] : vector<64xi32>, vector<64xi32>
    %77 = vector.extract_strided_slice %76 {offsets = [0], sizes = [8], strides = [1]} : vector<64xi32> to vector<8xi32>
    %78 = vector.extract_strided_slice %76 {offsets = [8], sizes = [8], strides = [1]} : vector<64xi32> to vector<8xi32>
    %79 = vector.extract_strided_slice %76 {offsets = [16], sizes = [8], strides = [1]} : vector<64xi32> to vector<8xi32>
    %80 = vector.extract_strided_slice %76 {offsets = [24], sizes = [8], strides = [1]} : vector<64xi32> to vector<8xi32>
    %81 = vector.extract_strided_slice %76 {offsets = [32], sizes = [8], strides = [1]} : vector<64xi32> to vector<8xi32>
    %82 = vector.extract_strided_slice %76 {offsets = [40], sizes = [8], strides = [1]} : vector<64xi32> to vector<8xi32>
    %83 = vector.extract_strided_slice %76 {offsets = [48], sizes = [8], strides = [1]} : vector<64xi32> to vector<8xi32>
    %84 = vector.extract_strided_slice %76 {offsets = [56], sizes = [8], strides = [1]} : vector<64xi32> to vector<8xi32>
    %85 = vector.extract %58[0, 0] : i32 from vector<8x8xi32>
    %86 = vector.broadcast %85 : i32 to vector<8xi32>
    %87 = vector.extract %22[0, 0, 0] : vector<8xi32> from vector<1x1x8x8xi32>
    %88 = arith.muli %86, %77 : vector<8xi32>
    %89 = arith.addi %88, %87 : vector<8xi32>
    %90 = vector.extract %58[1, 0] : i32 from vector<8x8xi32>
    %91 = vector.broadcast %90 : i32 to vector<8xi32>
    %92 = vector.extract %22[0, 0, 1] : vector<8xi32> from vector<1x1x8x8xi32>
    %93 = arith.muli %91, %77 : vector<8xi32>
    %94 = arith.addi %93, %92 : vector<8xi32>
    %95 = vector.extract %58[2, 0] : i32 from vector<8x8xi32>
    %96 = vector.broadcast %95 : i32 to vector<8xi32>
    %97 = vector.extract %22[0, 0, 2] : vector<8xi32> from vector<1x1x8x8xi32>
    %98 = arith.muli %96, %77 : vector<8xi32>
    %99 = arith.addi %98, %97 : vector<8xi32>
    %100 = vector.extract %58[3, 0] : i32 from vector<8x8xi32>
    %101 = vector.broadcast %100 : i32 to vector<8xi32>
    %102 = vector.extract %22[0, 0, 3] : vector<8xi32> from vector<1x1x8x8xi32>
    %103 = arith.muli %101, %77 : vector<8xi32>
    %104 = arith.addi %103, %102 : vector<8xi32>
    %105 = vector.extract %58[4, 0] : i32 from vector<8x8xi32>
    %106 = vector.broadcast %105 : i32 to vector<8xi32>
    %107 = vector.extract %22[0, 0, 4] : vector<8xi32> from vector<1x1x8x8xi32>
    %108 = arith.muli %106, %77 : vector<8xi32>
    %109 = arith.addi %108, %107 : vector<8xi32>
    %110 = vector.extract %58[5, 0] : i32 from vector<8x8xi32>
    %111 = vector.broadcast %110 : i32 to vector<8xi32>
    %112 = vector.extract %22[0, 0, 5] : vector<8xi32> from vector<1x1x8x8xi32>
    %113 = arith.muli %111, %77 : vector<8xi32>
    %114 = arith.addi %113, %112 : vector<8xi32>
    %115 = vector.extract %58[6, 0] : i32 from vector<8x8xi32>
    %116 = vector.broadcast %115 : i32 to vector<8xi32>
    %117 = vector.extract %22[0, 0, 6] : vector<8xi32> from vector<1x1x8x8xi32>
    %118 = arith.muli %116, %77 : vector<8xi32>
    %119 = arith.addi %118, %117 : vector<8xi32>
    %120 = vector.extract %58[7, 0] : i32 from vector<8x8xi32>
    %121 = vector.broadcast %120 : i32 to vector<8xi32>
    %122 = vector.extract %22[0, 0, 7] : vector<8xi32> from vector<1x1x8x8xi32>
    %123 = arith.muli %121, %77 : vector<8xi32>
    %124 = arith.addi %123, %122 : vector<8xi32>
    %125 = vector.extract %58[0, 1] : i32 from vector<8x8xi32>
    %126 = vector.broadcast %125 : i32 to vector<8xi32>
    %127 = arith.muli %126, %78 : vector<8xi32>
    %128 = arith.addi %127, %89 : vector<8xi32>
    %129 = vector.extract %58[1, 1] : i32 from vector<8x8xi32>
    %130 = vector.broadcast %129 : i32 to vector<8xi32>
    %131 = arith.muli %130, %78 : vector<8xi32>
    %132 = arith.addi %131, %94 : vector<8xi32>
    %133 = vector.extract %58[2, 1] : i32 from vector<8x8xi32>
    %134 = vector.broadcast %133 : i32 to vector<8xi32>
    %135 = arith.muli %134, %78 : vector<8xi32>
    %136 = arith.addi %135, %99 : vector<8xi32>
    %137 = vector.extract %58[3, 1] : i32 from vector<8x8xi32>
    %138 = vector.broadcast %137 : i32 to vector<8xi32>
    %139 = arith.muli %138, %78 : vector<8xi32>
    %140 = arith.addi %139, %104 : vector<8xi32>
    %141 = vector.extract %58[4, 1] : i32 from vector<8x8xi32>
    %142 = vector.broadcast %141 : i32 to vector<8xi32>
    %143 = arith.muli %142, %78 : vector<8xi32>
    %144 = arith.addi %143, %109 : vector<8xi32>
    %145 = vector.extract %58[5, 1] : i32 from vector<8x8xi32>
    %146 = vector.broadcast %145 : i32 to vector<8xi32>
    %147 = arith.muli %146, %78 : vector<8xi32>
    %148 = arith.addi %147, %114 : vector<8xi32>
    %149 = vector.extract %58[6, 1] : i32 from vector<8x8xi32>
    %150 = vector.broadcast %149 : i32 to vector<8xi32>
    %151 = arith.muli %150, %78 : vector<8xi32>
    %152 = arith.addi %151, %119 : vector<8xi32>
    %153 = vector.extract %58[7, 1] : i32 from vector<8x8xi32>
    %154 = vector.broadcast %153 : i32 to vector<8xi32>
    %155 = arith.muli %154, %78 : vector<8xi32>
    %156 = arith.addi %155, %124 : vector<8xi32>
    %157 = vector.extract %58[0, 2] : i32 from vector<8x8xi32>
    %158 = vector.broadcast %157 : i32 to vector<8xi32>
    %159 = arith.muli %158, %79 : vector<8xi32>
    %160 = arith.addi %159, %128 : vector<8xi32>
    %161 = vector.extract %58[1, 2] : i32 from vector<8x8xi32>
    %162 = vector.broadcast %161 : i32 to vector<8xi32>
    %163 = arith.muli %162, %79 : vector<8xi32>
    %164 = arith.addi %163, %132 : vector<8xi32>
    %165 = vector.extract %58[2, 2] : i32 from vector<8x8xi32>
    %166 = vector.broadcast %165 : i32 to vector<8xi32>
    %167 = arith.muli %166, %79 : vector<8xi32>
    %168 = arith.addi %167, %136 : vector<8xi32>
    %169 = vector.extract %58[3, 2] : i32 from vector<8x8xi32>
    %170 = vector.broadcast %169 : i32 to vector<8xi32>
    %171 = arith.muli %170, %79 : vector<8xi32>
    %172 = arith.addi %171, %140 : vector<8xi32>
    %173 = vector.extract %58[4, 2] : i32 from vector<8x8xi32>
    %174 = vector.broadcast %173 : i32 to vector<8xi32>
    %175 = arith.muli %174, %79 : vector<8xi32>
    %176 = arith.addi %175, %144 : vector<8xi32>
    %177 = vector.extract %58[5, 2] : i32 from vector<8x8xi32>
    %178 = vector.broadcast %177 : i32 to vector<8xi32>
    %179 = arith.muli %178, %79 : vector<8xi32>
    %180 = arith.addi %179, %148 : vector<8xi32>
    %181 = vector.extract %58[6, 2] : i32 from vector<8x8xi32>
    %182 = vector.broadcast %181 : i32 to vector<8xi32>
    %183 = arith.muli %182, %79 : vector<8xi32>
    %184 = arith.addi %183, %152 : vector<8xi32>
    %185 = vector.extract %58[7, 2] : i32 from vector<8x8xi32>
    %186 = vector.broadcast %185 : i32 to vector<8xi32>
    %187 = arith.muli %186, %79 : vector<8xi32>
    %188 = arith.addi %187, %156 : vector<8xi32>
    %189 = vector.extract %58[0, 3] : i32 from vector<8x8xi32>
    %190 = vector.broadcast %189 : i32 to vector<8xi32>
    %191 = arith.muli %190, %80 : vector<8xi32>
    %192 = arith.addi %191, %160 : vector<8xi32>
    %193 = vector.extract %58[1, 3] : i32 from vector<8x8xi32>
    %194 = vector.broadcast %193 : i32 to vector<8xi32>
    %195 = arith.muli %194, %80 : vector<8xi32>
    %196 = arith.addi %195, %164 : vector<8xi32>
    %197 = vector.extract %58[2, 3] : i32 from vector<8x8xi32>
    %198 = vector.broadcast %197 : i32 to vector<8xi32>
    %199 = arith.muli %198, %80 : vector<8xi32>
    %200 = arith.addi %199, %168 : vector<8xi32>
    %201 = vector.extract %58[3, 3] : i32 from vector<8x8xi32>
    %202 = vector.broadcast %201 : i32 to vector<8xi32>
    %203 = arith.muli %202, %80 : vector<8xi32>
    %204 = arith.addi %203, %172 : vector<8xi32>
    %205 = vector.extract %58[4, 3] : i32 from vector<8x8xi32>
    %206 = vector.broadcast %205 : i32 to vector<8xi32>
    %207 = arith.muli %206, %80 : vector<8xi32>
    %208 = arith.addi %207, %176 : vector<8xi32>
    %209 = vector.extract %58[5, 3] : i32 from vector<8x8xi32>
    %210 = vector.broadcast %209 : i32 to vector<8xi32>
    %211 = arith.muli %210, %80 : vector<8xi32>
    %212 = arith.addi %211, %180 : vector<8xi32>
    %213 = vector.extract %58[6, 3] : i32 from vector<8x8xi32>
    %214 = vector.broadcast %213 : i32 to vector<8xi32>
    %215 = arith.muli %214, %80 : vector<8xi32>
    %216 = arith.addi %215, %184 : vector<8xi32>
    %217 = vector.extract %58[7, 3] : i32 from vector<8x8xi32>
    %218 = vector.broadcast %217 : i32 to vector<8xi32>
    %219 = arith.muli %218, %80 : vector<8xi32>
    %220 = arith.addi %219, %188 : vector<8xi32>
    %221 = vector.extract %58[0, 4] : i32 from vector<8x8xi32>
    %222 = vector.broadcast %221 : i32 to vector<8xi32>
    %223 = arith.muli %222, %81 : vector<8xi32>
    %224 = arith.addi %223, %192 : vector<8xi32>
    %225 = vector.extract %58[1, 4] : i32 from vector<8x8xi32>
    %226 = vector.broadcast %225 : i32 to vector<8xi32>
    %227 = arith.muli %226, %81 : vector<8xi32>
    %228 = arith.addi %227, %196 : vector<8xi32>
    %229 = vector.extract %58[2, 4] : i32 from vector<8x8xi32>
    %230 = vector.broadcast %229 : i32 to vector<8xi32>
    %231 = arith.muli %230, %81 : vector<8xi32>
    %232 = arith.addi %231, %200 : vector<8xi32>
    %233 = vector.extract %58[3, 4] : i32 from vector<8x8xi32>
    %234 = vector.broadcast %233 : i32 to vector<8xi32>
    %235 = arith.muli %234, %81 : vector<8xi32>
    %236 = arith.addi %235, %204 : vector<8xi32>
    %237 = vector.extract %58[4, 4] : i32 from vector<8x8xi32>
    %238 = vector.broadcast %237 : i32 to vector<8xi32>
    %239 = arith.muli %238, %81 : vector<8xi32>
    %240 = arith.addi %239, %208 : vector<8xi32>
    %241 = vector.extract %58[5, 4] : i32 from vector<8x8xi32>
    %242 = vector.broadcast %241 : i32 to vector<8xi32>
    %243 = arith.muli %242, %81 : vector<8xi32>
    %244 = arith.addi %243, %212 : vector<8xi32>
    %245 = vector.extract %58[6, 4] : i32 from vector<8x8xi32>
    %246 = vector.broadcast %245 : i32 to vector<8xi32>
    %247 = arith.muli %246, %81 : vector<8xi32>
    %248 = arith.addi %247, %216 : vector<8xi32>
    %249 = vector.extract %58[7, 4] : i32 from vector<8x8xi32>
    %250 = vector.broadcast %249 : i32 to vector<8xi32>
    %251 = arith.muli %250, %81 : vector<8xi32>
    %252 = arith.addi %251, %220 : vector<8xi32>
    %253 = vector.extract %58[0, 5] : i32 from vector<8x8xi32>
    %254 = vector.broadcast %253 : i32 to vector<8xi32>
    %255 = arith.muli %254, %82 : vector<8xi32>
    %256 = arith.addi %255, %224 : vector<8xi32>
    %257 = vector.extract %58[1, 5] : i32 from vector<8x8xi32>
    %258 = vector.broadcast %257 : i32 to vector<8xi32>
    %259 = arith.muli %258, %82 : vector<8xi32>
    %260 = arith.addi %259, %228 : vector<8xi32>
    %261 = vector.extract %58[2, 5] : i32 from vector<8x8xi32>
    %262 = vector.broadcast %261 : i32 to vector<8xi32>
    %263 = arith.muli %262, %82 : vector<8xi32>
    %264 = arith.addi %263, %232 : vector<8xi32>
    %265 = vector.extract %58[3, 5] : i32 from vector<8x8xi32>
    %266 = vector.broadcast %265 : i32 to vector<8xi32>
    %267 = arith.muli %266, %82 : vector<8xi32>
    %268 = arith.addi %267, %236 : vector<8xi32>
    %269 = vector.extract %58[4, 5] : i32 from vector<8x8xi32>
    %270 = vector.broadcast %269 : i32 to vector<8xi32>
    %271 = arith.muli %270, %82 : vector<8xi32>
    %272 = arith.addi %271, %240 : vector<8xi32>
    %273 = vector.extract %58[5, 5] : i32 from vector<8x8xi32>
    %274 = vector.broadcast %273 : i32 to vector<8xi32>
    %275 = arith.muli %274, %82 : vector<8xi32>
    %276 = arith.addi %275, %244 : vector<8xi32>
    %277 = vector.extract %58[6, 5] : i32 from vector<8x8xi32>
    %278 = vector.broadcast %277 : i32 to vector<8xi32>
    %279 = arith.muli %278, %82 : vector<8xi32>
    %280 = arith.addi %279, %248 : vector<8xi32>
    %281 = vector.extract %58[7, 5] : i32 from vector<8x8xi32>
    %282 = vector.broadcast %281 : i32 to vector<8xi32>
    %283 = arith.muli %282, %82 : vector<8xi32>
    %284 = arith.addi %283, %252 : vector<8xi32>
    %285 = vector.extract %58[0, 6] : i32 from vector<8x8xi32>
    %286 = vector.broadcast %285 : i32 to vector<8xi32>
    %287 = arith.muli %286, %83 : vector<8xi32>
    %288 = arith.addi %287, %256 : vector<8xi32>
    %289 = vector.extract %58[1, 6] : i32 from vector<8x8xi32>
    %290 = vector.broadcast %289 : i32 to vector<8xi32>
    %291 = arith.muli %290, %83 : vector<8xi32>
    %292 = arith.addi %291, %260 : vector<8xi32>
    %293 = vector.extract %58[2, 6] : i32 from vector<8x8xi32>
    %294 = vector.broadcast %293 : i32 to vector<8xi32>
    %295 = arith.muli %294, %83 : vector<8xi32>
    %296 = arith.addi %295, %264 : vector<8xi32>
    %297 = vector.extract %58[3, 6] : i32 from vector<8x8xi32>
    %298 = vector.broadcast %297 : i32 to vector<8xi32>
    %299 = arith.muli %298, %83 : vector<8xi32>
    %300 = arith.addi %299, %268 : vector<8xi32>
    %301 = vector.extract %58[4, 6] : i32 from vector<8x8xi32>
    %302 = vector.broadcast %301 : i32 to vector<8xi32>
    %303 = arith.muli %302, %83 : vector<8xi32>
    %304 = arith.addi %303, %272 : vector<8xi32>
    %305 = vector.extract %58[5, 6] : i32 from vector<8x8xi32>
    %306 = vector.broadcast %305 : i32 to vector<8xi32>
    %307 = arith.muli %306, %83 : vector<8xi32>
    %308 = arith.addi %307, %276 : vector<8xi32>
    %309 = vector.extract %58[6, 6] : i32 from vector<8x8xi32>
    %310 = vector.broadcast %309 : i32 to vector<8xi32>
    %311 = arith.muli %310, %83 : vector<8xi32>
    %312 = arith.addi %311, %280 : vector<8xi32>
    %313 = vector.extract %58[7, 6] : i32 from vector<8x8xi32>
    %314 = vector.broadcast %313 : i32 to vector<8xi32>
    %315 = arith.muli %314, %83 : vector<8xi32>
    %316 = arith.addi %315, %284 : vector<8xi32>
    %317 = vector.extract %58[0, 7] : i32 from vector<8x8xi32>
    %318 = vector.broadcast %317 : i32 to vector<8xi32>
    %319 = arith.muli %318, %84 : vector<8xi32>
    %320 = arith.addi %319, %288 : vector<8xi32>
    %321 = vector.insert %320, %cst_2 [0] : vector<8xi32> into vector<8x8xi32>
    %322 = vector.extract %58[1, 7] : i32 from vector<8x8xi32>
    %323 = vector.broadcast %322 : i32 to vector<8xi32>
    %324 = arith.muli %323, %84 : vector<8xi32>
    %325 = arith.addi %324, %292 : vector<8xi32>
    %326 = vector.insert %325, %321 [1] : vector<8xi32> into vector<8x8xi32>
    %327 = vector.extract %58[2, 7] : i32 from vector<8x8xi32>
    %328 = vector.broadcast %327 : i32 to vector<8xi32>
    %329 = arith.muli %328, %84 : vector<8xi32>
    %330 = arith.addi %329, %296 : vector<8xi32>
    %331 = vector.insert %330, %326 [2] : vector<8xi32> into vector<8x8xi32>
    %332 = vector.extract %58[3, 7] : i32 from vector<8x8xi32>
    %333 = vector.broadcast %332 : i32 to vector<8xi32>
    %334 = arith.muli %333, %84 : vector<8xi32>
    %335 = arith.addi %334, %300 : vector<8xi32>
    %336 = vector.insert %335, %331 [3] : vector<8xi32> into vector<8x8xi32>
    %337 = vector.extract %58[4, 7] : i32 from vector<8x8xi32>
    %338 = vector.broadcast %337 : i32 to vector<8xi32>
    %339 = arith.muli %338, %84 : vector<8xi32>
    %340 = arith.addi %339, %304 : vector<8xi32>
    %341 = vector.insert %340, %336 [4] : vector<8xi32> into vector<8x8xi32>
    %342 = vector.extract %58[5, 7] : i32 from vector<8x8xi32>
    %343 = vector.broadcast %342 : i32 to vector<8xi32>
    %344 = arith.muli %343, %84 : vector<8xi32>
    %345 = arith.addi %344, %308 : vector<8xi32>
    %346 = vector.insert %345, %341 [5] : vector<8xi32> into vector<8x8xi32>
    %347 = vector.extract %58[6, 7] : i32 from vector<8x8xi32>
    %348 = vector.broadcast %347 : i32 to vector<8xi32>
    %349 = arith.muli %348, %84 : vector<8xi32>
    %350 = arith.addi %349, %312 : vector<8xi32>
    %351 = vector.insert %350, %346 [6] : vector<8xi32> into vector<8x8xi32>
    %352 = vector.extract %58[7, 7] : i32 from vector<8x8xi32>
    %353 = vector.broadcast %352 : i32 to vector<8xi32>
    %354 = arith.muli %353, %84 : vector<8xi32>
    %355 = arith.addi %354, %316 : vector<8xi32>
    %356 = vector.insert %355, %351 [7] : vector<8xi32> into vector<8x8xi32>
    %357 = vector.broadcast %356 : vector<8x8xi32> to vector<1x1x8x8xi32>
    %358 = arith.addi %21, %c1 : index
    cf.br ^bb7(%358, %357 : index, vector<1x1x8x8xi32>)
  ^bb9:  // pred: ^bb7
    %359 = vector.extract %22[0, 0, 0] : vector<8xi32> from vector<1x1x8x8xi32>
    %360 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%13, %17]
    %361 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%15, %19]
    vector.store %359, %8[%360, %361, %c0, %c0] : memref<64x256x8x8xi32, strided<[16384, 64, 8, 1], offset: ?>>, vector<8xi32>
    %362 = vector.extract %22[0, 0, 1] : vector<8xi32> from vector<1x1x8x8xi32>
    %363 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%13, %17]
    %364 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%15, %19]
    vector.store %362, %8[%363, %364, %c1, %c0] : memref<64x256x8x8xi32, strided<[16384, 64, 8, 1], offset: ?>>, vector<8xi32>
    %365 = vector.extract %22[0, 0, 2] : vector<8xi32> from vector<1x1x8x8xi32>
    %366 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%13, %17]
    %367 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%15, %19]
    vector.store %365, %8[%366, %367, %c2, %c0] : memref<64x256x8x8xi32, strided<[16384, 64, 8, 1], offset: ?>>, vector<8xi32>
    %368 = vector.extract %22[0, 0, 3] : vector<8xi32> from vector<1x1x8x8xi32>
    %369 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%13, %17]
    %370 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%15, %19]
    vector.store %368, %8[%369, %370, %c3, %c0] : memref<64x256x8x8xi32, strided<[16384, 64, 8, 1], offset: ?>>, vector<8xi32>
    %371 = vector.extract %22[0, 0, 4] : vector<8xi32> from vector<1x1x8x8xi32>
    %372 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%13, %17]
    %373 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%15, %19]
    vector.store %371, %8[%372, %373, %c4, %c0] : memref<64x256x8x8xi32, strided<[16384, 64, 8, 1], offset: ?>>, vector<8xi32>
    %374 = vector.extract %22[0, 0, 5] : vector<8xi32> from vector<1x1x8x8xi32>
    %375 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%13, %17]
    %376 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%15, %19]
    vector.store %374, %8[%375, %376, %c5, %c0] : memref<64x256x8x8xi32, strided<[16384, 64, 8, 1], offset: ?>>, vector<8xi32>
    %377 = vector.extract %22[0, 0, 6] : vector<8xi32> from vector<1x1x8x8xi32>
    %378 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%13, %17]
    %379 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%15, %19]
    vector.store %377, %8[%378, %379, %c6, %c0] : memref<64x256x8x8xi32, strided<[16384, 64, 8, 1], offset: ?>>, vector<8xi32>
    %380 = vector.extract %22[0, 0, 7] : vector<8xi32> from vector<1x1x8x8xi32>
    %381 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%13, %17]
    %382 = affine.apply affine_map<()[s0, s1] -> (s0 + s1)>()[%15, %19]
    vector.store %380, %8[%381, %382, %c7, %c0] : memref<64x256x8x8xi32, strided<[16384, 64, 8, 1], offset: ?>>, vector<8xi32>
    %383 = arith.addi %19, %c1 : index
    cf.br ^bb6(%383 : index)
  ^bb10:  // pred: ^bb6
    %384 = arith.addi %17, %c1 : index
    cf.br ^bb5(%384 : index)
  ^bb11:  // pred: ^bb5
    %385 = arith.addi %15, %12 : index
    cf.br ^bb3(%385 : index)
  ^bb12:  // pred: ^bb3
    %386 = arith.addi %13, %10 : index
    cf.br ^bb1(%386 : index)
  ^bb13:  // pred: ^bb1
    return
  }
}

The type emulation cannot work for subviews. You can only do type emulation for memrefs types that can be linearized. (You can't type emulate on multi-dimensional memrefs).
All subviews must be folded into their uses before type emulation. It seems like the collapse shape is blocking the folding here.
I guess we need separate patterns to fold collapse shapes into loads stores. Those must be easy to do

Hmm, I thought there were already some existing patterns that would handle cases like this. Maybe I wrote some a while ago and never upstreamed it :p
I can take a closer look on Monday, but I think this collapse shape should be easy to fold.

    %subview_4 = memref.subview %7[%15, 0, 0, 0] [4, 512, 8, 8] [1, 1, 1, 1] : memref<256x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>> to memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
    %collapse_shape_5 = memref.collapse_shape %subview_4 [[0], [1], [2, 3]] : memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>> into memref<4x512x64xi4, strided<[32768, 64, 1], offset: ?>>
    %41 = vector.load %collapse_shape_5[%19, %21, %c0] : memref<4x512x64xi4, strided<[32768, 64, 1], offset: ?>>, vector<64xi4>

Ok, I think we can rewrite this into a vector.transfer_read on the subview, and then a vector.shape_cast to collapse the read. Then the subview will fold with the transfer_read, and we will also need to add narrow type emulation for vector.shape_cast. What do you guys think?

    %subview_4 = memref.subview %7[%15, 0, 0, 0] [4, 512, 8, 8] [1, 1, 1, 1] : memref<256x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>> to memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
    %collapse_shape_5 = memref.collapse_shape %subview_4 [[0], [1], [2, 3]] : memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>> into memref<4x512x64xi4, strided<[32768, 64, 1], offset: ?>>
    %41 = vector.load %collapse_shape_5[%19, %21, %c0] : memref<4x512x64xi4, strided<[32768, 64, 1], offset: ?>>, vector<64xi4>

Ok, I think we can rewrite this into a vector.transfer_read on the subview, and then a vector.shape_cast to collapse the read. Then the subview will fold with the transfer_read, and we will also need to add narrow type emulation for vector.shape_cast. What do you guys think?

Nothing that is multi-dimensional will  be easy to support for type emulation. Fold the shape_cast as well?

@dcaballe why do we have memref.collapse_shape? Did you enable vector flatten in your local build?

Ok, I think we can rewrite this into a vector.transfer_read on the subview, and then a vector.shape_cast to collapse the read.

The emulation happens ways after vector lowering. Are you saying to add the pattern in vector lowering? I think the collapse_shape is intended. Otherwise we will unroll multi-dimensional vector.transfer_read ops, which introduces scalar loads.

The type emulation cannot work for subviews. You can only do type emulation for memrefs types that can be linearized.

Since we are able to collapse the memref, the below memref types seem to be linearizable? Can we teach the emulation to handle subview -> memref.collapse_shape chain?
%subview_4 = memref.subview %7[%15, 0, 0, 0] [4, 512, 8, 8] [1, 1, 1, 1]
  : memref<256x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
  to memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
%collapse_shape_5 = memref.collapse_shape %subview_4 [[0], [1], [2, 3]]
  : memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
  into memref<4x512x64xi4, strided<[32768, 64, 1], offset: ?>>
%41 = vector.load %collapse_shape_5[%19, %21, %c0] : memref<4x512x64xi4, strided<[32768, 64, 1], offset: ?>>, vector<64xi4>

Thanks for the quick response, appreciate it!

@dcaballe why do we have memref.collapse_shape? Did you enable vector flatten in your local build?

Yes, I'm experimenting with this here: #16456. You may have also seen some fixed/extensions on that pass. More to come!
Regarding the emulation discussion, I'm not sure I totally understand. Why does everything have to be folded into the transfer read/write ops? Memref subview and collapse ops are only index computation so it should be easy to add emulation for them directly. As we discussed in llvm/llvm-project#80517 , it's unlikely we can fold all the memrefs subviews into their transfer read/write op consumers so we may need direct emulation support for them. Multi dimensional support should be ok as long as the number of elements in the contiguous dimension by their bitwidth is multiple of 1 byte. Am I missing something?

That is a very restricted case and can only support static shapes. So I dont count them as something that can be "supported". It will force you to walk a very tight path. Moreover I think it is unnecessary. If you cannot fold a memref.subview with the load/store then there are going to be other issues anyway. So adding type propagation for subviews is treating a symptom and not the cause (and is unnecessarily complicated). https://github.com/llvm/llvm-project/pull/80517 is really pointing a pit fall in vector.transfer_read semantics. So again thats a symptom, not the root cause.

That is a very restricted case and can only support static shapes. So I dont count them as something that can be "supported". It will force you to walk a very tight path. Moreover I think it is unnecessary. If you cannot fold a memref.subview with the load/store then there are going to be other issues anyway. So adding type propagation for subviews is treating a symptom and not the cause (and is unnecessarily complicated). llvm/llvm-project#80517 is really pointing a pit fall in vector.transfer_read semantics. So again thats a symptom, not the root cause.

Probably not a high priority but this is a compilation issue that would impact any Android phone without SVE support so I'm not sure we can just skip it. IIRC, the missing folding for this case was due to the transfer read having in_bounds = false. The dynamic shape was due to not being able to apply masking (target doesn't support it) or peeling (related to https://github.com/openxla/iree/issues/16406), not due to a truly dynamic case so it should be a valid case (e.g., the number of i4 elements is even but it's not a multiple of the vector size so a dynamic dim is generated in the absence of masking/peeling).
Anyway, let's focus on the common case since that is the main blocker right now! Is it clear how to move forward, @Max191? Do you have code for this or planning to help with it? Thanks!

Anyway, let's focus on the common case since that is the main blocker right now! Is it clear how to move forward, @Max191? Do you have code for this or planning to help with it? Thanks!

Sorry, I lost this thread for a few days. I found my old pattern, but I'm not sure it is what we would want to do. I believe it would rewrite this to something like:
%subview_4 = memref.subview %7[%15, 0, 0, 0] [4, 512, 8, 8] [1, 1, 1, 1]
  : memref<256x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
  to memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
%41 = vector.load %collapse_shape_5[%19, %21, %c0, %c0] : memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>, vector<64xi4>

IIRC, this worked fine when I tested it for a similar case, and this would also get rid of the collapse_shape, but it does create a strange vector.load.

Anyway, let's focus on the common case since that is the main blocker right now! Is it clear how to move forward, @Max191? Do you have code for this or planning to help with it? Thanks!

Sorry, I lost this thread for a few days. I found my old pattern, but I'm not sure it is what we would want to do. I believe it would rewrite this to something like:
%subview_4 = memref.subview %7[%15, 0, 0, 0] [4, 512, 8, 8] [1, 1, 1, 1]
  : memref<256x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
  to memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>
%41 = vector.load %collapse_shape_5[%19, %21, %c0, %c0] : memref<4x512x8x8xi4, strided<[32768, 64, 8, 1], offset: ?>>, vector<64xi4>

IIRC, this worked fine when I tested it for a similar case, and this would also get rid of the collapse_shape, but it does create a strange vector.load.

I would expect the vector.load to generate a vector<1x1x8x8xi4> and shape cast it down to vector<64xi4> . So at this stage this seems OK. We are just translating through and everything gets linearized anyway.

Hmm... A bit borderline to me. This is probably something that would fit into the versatility of transfer reads/write but I'm doubtful of whether we want this at vector load/store level, where things are expected to be simpler. There's also the fact that this folding is actually undoing the tensor collapse on the memref so I think we shouldn't consider this a canonical form or requirement to apply emulation. What are the main blockers to support emulation on tensor collapse directly?

Hmm... A bit borderline to me. This is probably something that would fit into the versatility of transfer reads/write but I'm doubtful of whether we want this at vector load/store level, where things are expected to be simpler. There's also the fact that this folding is actually undoing the tensor collapse on the memref so I think we shouldn't consider this a canonical form or requirement to apply emulation. What are the main blockers to support emulation on tensor collapse directly?

Like I said, you cannot do emulation for multi-dimensional types. Adding that is just for a very specific use case and doesnt actually solve the problem.

Like I said, you cannot do emulation for multi-dimensional types. Adding that is just for a very specific use case and doesnt actually solve the problem.

Sorry, I'm still missing this point. Why we can't apply emulation to multi-dim memrefs? Could you provide an example for my understanding? Thanks in advance!

Like I said, you cannot do emulation for multi-dimensional types. Adding that is just for a very specific use case and doesnt actually solve the problem.

Sorry, I'm still missing this point. Why we can't apply emulation to multi-dim memrefs? Could you provide an example for my understanding? Thanks in advance!

You cannot emulate a memref<?x?xf32, strides=[?, ?], offset=?>. Everything else is very special casey and just punting the problem down stream or working around a real issue. The only realistic way of supporting emulation is on a type memref<?xf32, offset=?>

Thanks for clarifying. I think there must have been some miscommunication. We all agree that a memref with multi-dimensional dynamic shapes can't be emulated. The discussion point is if we should only support cases where all the address computation (i.e., memref.subview, memref.collapse_shape, ...) can be folded into the vector load/store or we should also add emulation support for cases where, while still valid from the emulation point of view, their address computation can't be folded into a single vector load/store.
In the example I provided above, it's easy to prove that the memref.subview and the memref.collapse_shape are valid from the emulation point of view (i.e., collapsed dimensions are contiguous, number of elements of the trailing dimension is even, etc.) so we just have to rewrite them using the corresponding i8 offset. That would be cleaner that just enforcing a folding of those ops into a vector.load/store that would end up reading beyond the dimension bounds.
It's interesting because I'm now thinking that folding the address computation into the vector load/store could actually lead to emulation cases that shouldn't be supported. For example, we may think that a memref<6xi4> can be emulated, that that wouldn't be the case if the memref is coming from an original memref<2x3xi4>. Same for a memref<?xi4>, assuming that it can be collapsed from a memref<?x?xi4> case. How do we make sure that these cases are not accidentally emulated?

In the example I provided above, it's easy to prove that the memref.subview and the memref.collapse_shape are valid from the emulation point of view (i.e., collapsed dimensions are contiguous, number of elements of the trailing dimension is even, etc.) so we just have to rewrite them using the corresponding i8 offset. That would be cleaner that just enforcing a folding of those ops into a vector.load/store that would end up reading beyond the dimension bounds.

+1 on what Diego said.. It would be very awesome if we can emulate subtypes for memref.subview + memref.collapse_shape case. We will really need that to generate non-scalar load/store.. In most of CPUs, we usually want to flatten inner most dimensions. Diego and I have been looking at flattening. Introducing a memref.collapse_shape sounds reasonable to me. We don't want a vector.shape_cast for many reasons.

Thanks for clarifying. I think there must have been some miscommunication. We all agree that a memref with multi-dimensional dynamic shapes can't be emulated. The discussion point is if we should only support cases where all the address computation (i.e., memref.subview, memref.collapse_shape, ...) can be folded into the vector load/store or we should also add emulation support for cases where, while still valid from the emulation point of view, their address computation can't be folded into a single vector load/store.
In the example I provided above, it's easy to prove that the memref.subview and the memref.collapse_shape are valid from the emulation point of view (i.e., collapsed dimensions are contiguous, number of elements of the trailing dimension is even, etc.) so we just have to rewrite them using the corresponding i8 offset. That would be cleaner that just enforcing a folding of those ops into a vector.load/store that would end up reading beyond the dimension bounds.

I don't see how this is cleaner. This is supporting a very narrow case. At the end of the day really subviews are "not a thing". At the LLVM/SPIRV level you only have loads and stores. So eventually all the subviews have to fold away. There is no magic here. You could only write emulation after linearization to get the offset + base pointer. Think of how you would handle i5 or i3 with multi dimensional memrefs? I don't see how you would do that. But if you linearized the memrefs you can support any bit width.

It's interesting because I'm now thinking that folding the address computation into the vector load/store could actually lead to emulation cases that shouldn't be supported. For example, we may think that a memref<6xi4> can be emulated, that that wouldn't be the case if the memref is coming from an original memref<2x3xi4>. Same for a memref<?xi4>, assuming that it can be collapsed from a memref<?x?xi4> case. How do we make sure that these cases are not accidentally emulated?

You are actually making the case for supporting only linearized memrefs. In a memref<?xi4> you have all the information for emulation. If you try to emulate memref<?x?xi4> unless you prove it is contiguous you cannot emulate this (and if it is contiguous then it is valid to collapse). So if you stick to 1d memrefs as a prerequisite for emulation, you don't have any ambiguity.

In the example I provided above, it's easy to prove that the memref.subview and the memref.collapse_shape are valid from the emulation point of view (i.e., collapsed dimensions are contiguous, number of elements of the trailing dimension is even, etc.) so we just have to rewrite them using the corresponding i8 offset. That would be cleaner that just enforcing a folding of those ops into a vector.load/store that would end up reading beyond the dimension bounds.

+1 on what Diego said.. It would be very awesome if we can emulate subtypes for memref.subview + memref.collapse_shape case. We will really need that to generate non-scalar load/store.. In most of CPUs, we usually want to flatten inner most dimensions. Diego and I have been looking at flattening. Introducing a memref.collapse_shape sounds reasonable to me. We don't want a vector.shape_cast for many reasons.

I don't follow. This is mixing concerns in my book. Subviews + collapse shape to get a 1d memrefs? If you have that why can't you fold these into loads/stores. I am not saying anything with respect to scalar or vector load stores. At this level, if you have scalar loads you fold things with memref.load/store. If you have vector loads you fold things with vector.load/store. At this level f you are dealing with multi dimensional vectors, you aren't at a place in the compilation flow that needs to introduce emulation


run error

if I run xcunsign 8.0, the iterm will show : too many levels of symbolic links: xcunsign

@cconecode, I believe that often indicates that the symbolic link was setup using a relative path rather than an absolute path. Try deleting the symlink and recreating using absolute paths for both the source and destination. If that works for you, let me know and I can update the readme to highlight that distinction for others.

@johntmcintosh yeah,it's works for me, thank you very much!


Forcing use of transactions

Say I have a model that updates some other table in its $afterInsert() method. If that code for whatever reason throws an exception, I want it to roll back the originating database insert. I can do that if I remember to start the query() with a transaction. So far so good.
Say I forget to put that transaction in place. Is it possible (i.e. not too much of a hack) to force using a transaction in $beforeInsert() or is it simply too late (or just not supported)?
Somehing along these lines:
async $beforeInsert(queryContext) {
  const trx = queryContext.transaction;
  if (typeof trx.commit !== 'function' || typeof trx.rollback !== 'function') {
    queryContext.transaction = await transaction.start(queryContext.transaction);
  }

  // ...
}

async $afterInsert(queryContext) {
  // queryContext.transaction is now an actual transaction

  // ...
}

Starting a transacrtion on the fly will cause more problems than it solves. Just consider an eager query that suddenly starts multiple nested transactions for the created queries. Not good.
Why not just use something like this:
async $beforeInsert(queryContext) {
  const trx = queryContext.transaction;
  if (typeof trx.commit !== 'function' || typeof trx.rollback !== 'function') {
    throw new Error('transaction needed');
  }
}

which would get caught in the tests immediately and would force you to start a transaction explicitly? Unfortunately that's the best way to detect if queryContext.transaction is actually a transaction since knex doesn't provide a isTransaction or similar.

I kind of feared it wasn't a very good idea ;) I wanted a way keep the "dependency" logic contained within the Model, preferably without having to wrap the query().insert() stuff. But it is not a big deal - thanks! And thanks for this project, it is a joy to use :)


Pointing Positions in EventContainer

Hello,
The pointing position for each telescope are always 0 in the latest master.
Is this expected behaviour?

>>>event.mc.tel[1].azimuth_raw
0
>>> event.mc.tel[1].altitude_raw
0
>>> event.pointing.as_dict()
{}

When I try it I get:
print(event.mc.tel[34].altitude_raw)
1.2217304706573486
print(event.mc.tel[34].azimuth_raw)
0.0
print(event.mcheader.run_array_direction)
<Quantity [ 0.        , 1.22173047] rad>

The event-wise ones are:
In [15]: event.mc.alt
Out[15]: <Angle 1.1591475009918213 rad>

In [16]: event.mc.az
Out[16]: <Angle 6.153833866119385 rad>

Obviously this needs to be cleaned up (I think the alt/az values in the mc tel container are the header values, not the event-wise ones, which makes little sense), but it seems to be relatively ok.

Are you sure you aren't looking at an MC that is simulated at az,alt=0,0? In that case, those values would never change.

relates to: #466 #499

Are you sure you aren't looking at an MC that is simulated at az,alt=0,0? In that case, those values would never change.

Pretty sure. I tried on three different files:
gamma_20deg_0deg_run11194___cta-prod3-merged_desert-2150m-Paranal-3HB89-NGFD_cone10.simtel.gz
proton_20deg_0deg_run20640___cta-prod3-merged_desert-2150m-Paranal-3HB89-NGFD.simtel.gz
gamma_20deg_0deg_run993___cta-prod3-merged_desert-2150m-Paranal-3HB89-NGFD.simtel.gz

The output is the same for each of the files:
print(event.mc.tel[34].altitude_raw)
0

print(event.mc.tel[34].azimuth_raw)
0

print(event.mcheader.run_array_direction)
[ 0.          1.22173047] rad

I'm on the latest master with both ctapipe and pyhessio

The event-wise ones are:
In [15]: event.mc.alt
Out[15]: <Angle 1.1591475009918213 rad>
In [16]: event.mc.az
Out[16]: <Angle 6.153833866119385 rad>

This one seems to be okay for me. But this is the position of the simulated source right?

Ah, just noticed I was not in the master branch when I tried it - I'll test again.  It does look like there were some changes to that code, so perhaps something broke (and we need a unit test somewhere probably)

I still get values with the master - can you tell me what version of pyhessio you are using? It could be a bug in that. I'm using 2.0.1

I'm also on 2.0.1
▶ pip freeze | grep hess
pyhessio==2.0.1

I don't know whats going on. I'll try on another computer later this week.

I still have the same problem on another machine. Can somebody else confirm?

Ah. I just noticed that the pointing information is only non zero for telescopes with data. That explains it. Is that new behaviour?

Afraid to sound dumb here but could you tell me what exactly to do, to reproduce this?
I assume one has to download some data from somewhere and execute some script, but I seem to be unable to find this information.

Sure. You need some simtel file for that. I did it like this:
event_source = EventSourceFactory.produce(
     input_url= 'some_simtel_file',
     max_events=10,
     product='HESSIOEventSource',
)

event = [event for event in event_source][0]
ids = event.inst.subarray.tel_ids
print([(i, event.mc.tel[i].altitude_raw) for i in ids])

Of course I'd simply use next(event_source) but that doesn't work.

Max just noticed that one could use next(iter(event_source) as well.


Library name change request

Library repository URL
https://github.com/felixthecat8a/LCD_BacklightRGB

The url in the library manager list is correct, but the name property in the library.properties was incorrect.

Hi @felixthecat8a. I am confirming your request.
Unlike submissions, this type of request is still handled manually. The Library Manager index maintainer occasionally comes through to clear all the outstanding requests. They will close this issue when it is done. You will get a notification from GitHub at that time.
After that, you can monitor the indexing of the library via its dedicated logs web page.
Information about that here:
https://github.com/arduino/library-registry/blob/main/FAQ.md#can-i-check-on-library-releases-being-added-to-library-manager

Done:
2024/06/13 14:56:52 Loaded 7065 libraries from DB
Removing LCD_BackgroundRGB
Success!


Fix heartbeat for short-running WorkerServices

Changes
Fixes the heartbeat by sending the first heartbeat af 1 second instead of 30.
This is configurable
Fixes #2759
Checklist

[x] I ran Unit Tests locally.
[x] CHANGELOG.md updated with one line description of the fix, and a link to the original issue if available.

The PR will trigger build, unit tests, and functional tests automatically. Please follow these instructions to build and test locally.
Notes for reviewers:

We support comment build triggers

/AzurePipelines run will queue all builds
/AzurePipelines run <pipeline-name> will queue a specific build

How could I get this one reviewed?


Adjust release merge workflow

The workflow triggered by the merge/rebase of #4925 failed, presumably because it was accessing the merge_commit_sha but the PR was closed via rebase. I've updated the workflow to just use sha, which still points to the rebased commit, and tested on my repo.

This is a release management task, as per our policy, we are self-approving it.

@valadas @mitchelsellers it looks like there's still a permissions issue (I guess on my test repo opening a PR for my own repo didn't trigger this scenario). I think we may need to add a secret with an access token that has permission to create branches, and use that instead of GITHUB_TOKEN.

I don't know, I have done it with GITHUB_TOKEN for the updating of versions one...

I saw someone saying that GitHub won't allow editing workflow files with GITHUB_TOKEN, so maybe it's just that develop currently has some changes to the workflow files…

I guess it just successfully created #4934, so maybe it has to do with who created the PR it's reacting to?


[Data Builders] Fields with aliases are always using Resolver default values

Summary
When a query uses aliases, no matter what value is assigned inside the data builder, the default resolver value is used.
Version
3.6.2
Logs
Steps to reproduce the behavior
I have an open source repository which illustrates this issue https://github.com/AKJAW/ApolloDataBuilders/tree/alias-issue
Basically after this commit all of the tests stopped working.
At 214493b377b1b768ff867194805eb3352ed9db32

At 32434ea1c3478ab63db7a1ff757565ab50ca792e

Hi 👋 Many thanks for the detailed report 🙏
I made a follow up PR there: https://github.com/AKJAW/ApolloDataBuilders/pull/1
When using aliases, you'll need to specify the aliases name when building the fake object:
index ee336a9..0391067 100644
--- a/app/src/test/java/com/akjaw/apollo/builders/domain/GetCountryTest.kt
+++ b/app/src/test/java/com/akjaw/apollo/builders/domain/GetCountryTest.kt
@@ -121,9 +121,9 @@ object Responses {

     val SUCCESS =
         CountryQuery.Data {
-            country = buildCountry {
+            this["countrySchema"] = buildCountry {
                 name = "United Kingdom"
-                languages = listOf(
+                this["languagesSchema"] = listOf(
                     buildLanguage {
                         name = "English"
                     }

There isn't a way to "guess" the aliases name automatically because the same field can have multiple aliases:
{
  poland: country(code: "PL") {
    name
  }
  france: country(code: "FR") {
    name
  }
}

I see, must've missed that, maybe it might be worth adding an example with aliases in the docs? I tried finding info about it, but had no luck. Thanks for the quick response and the PR!

Makes sense 👍  Doc updates are there: https://github.com/apollographql/apollo-kotlin/pull/4503


No Documentation available related to "Sophos XG" on Azure Docs.

I have browsed through Azure docs for finding a step by step process to deploy Sophos XG but did not find it anywhere. Since Sophos is mentioned as a supported image on Azure Market place (https://azuremarketplace.microsoft.com/en-us/marketplace/apps/sophos.sophos-xg-firewall-solution), there should be a documentation on Azure Docs on its deployment process.
This will be helpful to the clients as well as to the engineers too.

@PrHar Thanks for the feedback. We are actively investigating and will get back to you soon.

@amanarneja , @tysonn , unable to find a service contact to action on this comment. Any ideas?

@tysonn re-assigning to you as I am unable to find the Content lead for Marketplace on the Service Leads page.

@PrHar please review the "learn more" links on the Sophos XG offer. There is a "quickstart" guide near the bottom of the page that would help address your question: https://azuremarketplace.microsoft.com/en-us/marketplace/apps/sophos.sophos-xg-firewall-solution?tab=Overview

#please-close


Switched from @actions/glob to glob

Current dependencies on/for this PR:

main

PR #141   👈

This comment was auto-generated by Graphite.


Disable tests for documentation related PRs

We have a parts-docs label which means a PR is related to documentation. This could potentially be used to skip all or most of the CI when only pushing something into the docs - we'd like to be able to move ahead quickly with the docs and the only way to get something up on RTD is to merge it here.
Documentation changes are highly unlikely to break stuff as long as they don't really touch anything outside the docs themselves. So perhaps filtering on the directory of the files changed (docs/) could be a better idea, dunno which is easier to implement.
@mithro offered to look into this, so assigning him.

Send the pull request for non master branch and the tests will not be automatically run.

Alright: course of action - we will build docs from a "docs" branch instead, and do merges between that and the master branch. I'll close this issue once I verify that this indeed works.

Seems to work, closing!


Coinbase Mobile Wallet might not be working just yet because of their SDK

Unsure why it is happening, is investigating with peers to find a solution.


Can the project be used for vertical scientific research projects of the university?

Can the OpenPCDet project be used for vertical scientific research projects of the university? I will mention this project in the final report of the project and annotate the references.

Sure.


Restore Default button doesn't work in some places

System information:

Operating system (distribution) and version Win10
DBeaver version 21.0.5 EA

We have to fix Restore default buttons which are broken on DBeaver side. See attached screenshots with places where the buttons don't work.
restore_default.zip

Note: "Restore Default" button returns properties to the state they were in, when the window was opened.

Closed as duplicate of https://github.com/dbeaver/dbeaver/issues/19928


resolve #228

rebased on top of master

Are there standalone test cases that one could add to ScottySpec to test new jsonData functionality?

hmmm, i think it might be. might depend on hspec-wai's limitations. i dont immediately see how to implement those.


Fix #72

Wait for merging; I think I can get rid of the unnecessary "attributes." level for the case layout templates

Ready to merge...


Convert a C style string to a Crystal style string

Any reason this would be better than String.new(ptr)? I'ld rather prefer not adding specific methods to Pointer(T). Keep in mind that this only works for pointers to C strings, but the method would be present in all pointer types.

D'oh, great! :-D I searched for any method that convert a C string back to a Crystal string and I thought it must be a method with a name like [c]str. I have never thought on String.new(ptr). Because of the absence of a complete api I came up with this naive implementation (C.strlen would raise an error if the type is not a UInt8*).
Many thanks @waj  to point me in the right direction.

Yes, we have a preliminary API docs but right now it's pretty useless because the actual method docs are missing from the source code.
Thanks anyway for helping us improve the API :-)


Reduced precision with single Elem Tx with low F#

Calculation of cross-section area to forward propagate is a bit too small

Solved in d9ef2b1307bd7abce260f6246a412740bccaf379


Change "What is Kubeflow" in master from v0.2 branch

Fixes: https://github.com/kubeflow/website/issues/268.
Copy information "What is Kubeflow" from v0.2 branch to master branch.

This change is

@sarahmaddox I changed information in master branch as well.