google/accompanist 3676

A collection of extension libraries for Jetpack Compose

google/adiantum 431

Adiantum and HPolyC specification and test vectors

google/addlicense 413

A program which ensures source code files have copyright license headers by scanning directory patterns recursively

google/acme 378

A simple ACME command line tool without 3rd party deps!

google/access-bridge-explorer 89

Explore accessibility tree of Java Access Bridge enabled applications


issue commentgoogle/iree

"'linalg_ext.scatter' op mismatch in shape of update value dim#1 and original value at dim#1" for `mhlo.scatter` lowering

Before adding support for this it would make sense to ask whether we should support complex types as a special buffer type or whether the decomposed solution is the best going forward.

Good q - we should probably switch to interleaving like numpy at the frontend and then swap the type. So, tensor<50xcomplex<f32>> is really tensor<50x2xf32> in memory. Getting the imaginary or real portions is just an affine map. Nothing about linalg or below should care (beyond implicitly in maps and such) - it'd be a really strong smell if it does.

numpy uses the interleaved format (x2 innermost dimension, effectively) - we can take that stance at the ABI boundary (any complex type gets an innermost dimension of 2 inserted into the type) or allow the user to pass in two tensors and interleave them themselves (as it's just math, and a user setting up the maps on the linalg ops can achieve all the same stuff).

Helpful in understanding the data layout in numpy:

>>> a = np.arange(100, dtype=np.float32)
>>> a
array([ 0.,  1.,  2.,  3.,  4.,  5.,  6.,  7.,  8.,  9., 10., 11., 12.,
       13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25.,
       26., 27., 28., 29., 30., 31., 32., 33., 34., 35., 36., 37., 38.,
       39., 40., 41., 42., 43., 44., 45., 46., 47., 48., 49., 50., 51.,
       52., 53., 54., 55., 56., 57., 58., 59., 60., 61., 62., 63., 64.,
       65., 66., 67., 68., 69., 70., 71., 72., 73., 74., 75., 76., 77.,
       78., 79., 80., 81., 82., 83., 84., 85., 86., 87., 88., 89., 90.,
       91., 92., 93., 94., 95., 96., 97., 98., 99.], dtype=float32)
>>> a.shape
>>> b = a.view(np.csingle)
>>> b.shape
>>> b
array([ 0. +1.j,  2. +3.j,  4. +5.j,  6. +7.j,  8. +9.j, 10.+11.j,
       12.+13.j, 14.+15.j, 16.+17.j, 18.+19.j, 20.+21.j, 22.+23.j,
       24.+25.j, 26.+27.j, 28.+29.j, 30.+31.j, 32.+33.j, 34.+35.j,
       36.+37.j, 38.+39.j, 40.+41.j, 42.+43.j, 44.+45.j, 46.+47.j,
       48.+49.j, 50.+51.j, 52.+53.j, 54.+55.j, 56.+57.j, 58.+59.j,
       60.+61.j, 62.+63.j, 64.+65.j, 66.+67.j, 68.+69.j, 70.+71.j,
       72.+73.j, 74.+75.j, 76.+77.j, 78.+79.j, 80.+81.j, 82.+83.j,
       84.+85.j, 86.+87.j, 88.+89.j, 90.+91.j, 92.+93.j, 94.+95.j,
       96.+97.j, 98.+99.j], dtype=complex64)

We can preserve the complex type information for the runtime for reflection (add a IREE_HAL_ELEMENT_TYPE_COMPLEX_32 and such) and hide the innermost x2 dimension if we wanted, but the sooner we get rid of that in the pipeline and let linalg work its magic the better. We should strive to never ever end up with what TF & co deal with (where they invoke standalone kernels to touch all memory twice to deinterleave each set of values 🤮) - and need to make sure we aren't handicapping linalg by not letting it slice and dice the data. If we went all interleaved we could even leave the complex types in there and just have bitcasts between the complex and x2 form at the boundaries we care about, but removing it entirely seems more robust (otherwise every layer of the system has to be taught that complex<f32> == x2xf32, and that feels hacky).

I suspect switching to this interleaved format will be much easier than what we are doing - just normal type conversion instead of expansion - so that'd be a win. I'd say mhlo->linalg is when it should happen (and tosa->linalg would do the same there, etc).


comment created time in a minute

push eventgoogle/tsunami-security-scanner-plugins


commit sha fd3a89ac297ba6493f054d11d22a680ff0bb38ea

Add gradle wrapper

view details

push time in 2 minutes

issue commentgoogle/tsunami-security-scanner-plugins

PRP: Request CVE-2021-22205 GitLab CE/EE Unauthenticated RCE using ExifTool

Sorry for the late reply! It was Thanksgiving holiday last week and our team members, including myself, were on vacation. You should've been notified on the final decision for this request. We'll catch up with the reviews.

@magl0 Now can you agree to any of the following PRP requests and let me start a new PR?

#198 #189 #82 #70 #71


comment created time in 2 minutes

create barnchgoogle/json_serializable.dart

branch : release

created branch time in 5 minutes


started time in 6 minutes


started time in 6 minutes

fork dreamsxin/go-querystring

go-querystring is Go library for encoding structs into URL query strings.

fork in 6 minutes

pull request commentgoogle/iree

Add assumeAlignmentOp during bufferization to propagate buffer alignment

Depends on


comment created time in 7 minutes


started time in 7 minutes

PR opened google/iree

Add assumeAlignmentOp during bufferization to propagate buffer alignment

This allow propagating alignment info all the way to llvm ir.

+30 -3

0 comment

4 changed files

pr created time in 8 minutes

issue commentgoogle/accompanist

IME padding not getting applied in bottom sheet

Hey there. Just sharing. I found a workaround that fits my needs using the accompanist/insets library. I provided a modifier with navigationBarsWithImePadding. I can show an example of how it looks in my app

Screen Shot 2021-11-30 at 10 08 38 PM .


comment created time in 12 minutes


started time in 14 minutes

pull request commentgoogle/site-kit-wp

Infra/4107 gutenberg webpack config

Size Change: +369 B (0%)

Total Size: 1.22 MB

Filename Size Change
./dist/assets/js/33-********************.js 0 B -3.12 kB (removed) 🏆
./dist/assets/js/googlesitekit-activation-********************.js 38.5 kB +1 B (0%)
./dist/assets/js/googlesitekit-adminbar-********************.js 31.9 kB -6 B (0%)
./dist/assets/js/googlesitekit-api-********************.js 9.15 kB -10 B (0%)
./dist/assets/js/googlesitekit-base-********************.js 1.59 kB +2 B (0%)
./dist/assets/js/googlesitekit-dashboard-details-********************.js 50.7 kB -1 B (0%)
./dist/assets/js/googlesitekit-datastore-forms-********************.js 8.89 kB -1 B (0%)
./dist/assets/js/googlesitekit-datastore-location-********************.js 2.02 kB -1 B (0%)
./dist/assets/js/googlesitekit-datastore-site-********************.js 14.4 kB -1 B (0%)
./dist/assets/js/googlesitekit-datastore-user-********************.js 21.1 kB -1 B (0%)
./dist/assets/js/googlesitekit-idea-hub-notice-********************.js 2.76 kB +351 B (+15%) ⚠️
./dist/assets/js/googlesitekit-idea-hub-post-list-********************.js 24.3 kB +3 B (0%)
./dist/assets/js/googlesitekit-module-********************.js 46.2 kB -7 B (0%)
./dist/assets/js/googlesitekit-modules-********************.js 16.7 kB +1 B (0%)
./dist/assets/js/googlesitekit-modules-adsense-********************.js 64.5 kB +2 B (0%)
./dist/assets/js/googlesitekit-modules-analytics-********************.js 71.6 kB +6 B (0%)
./dist/assets/js/googlesitekit-modules-idea-hub-********************.js 25.1 kB +5 B (0%)
./dist/assets/js/googlesitekit-modules-pagespeed-insights-********************.js 17 kB +2 B (0%)
./dist/assets/js/googlesitekit-modules-subscribe-with-google-********************.js 17.4 kB -8 B (0%)
./dist/assets/js/googlesitekit-modules-tagmanager-********************.js 29.9 kB +38 B (0%)
./dist/assets/js/googlesitekit-polyfills-********************.js 379 B +1 B (0%)
./dist/assets/js/googlesitekit-settings-********************.js 51.2 kB -5 B (0%)
./dist/assets/js/googlesitekit-user-input-********************.js 47 kB -1 B (0%)
./dist/assets/js/googlesitekit-vendor-********************.js 315 kB +2 B (0%)
./dist/assets/js/googlesitekit-widgets-********************.js 13.4 kB +1 B (0%)
./dist/assets/js/googlesitekit-wp-dashboard-********************.js 34.6 kB -3 B (0%)
./dist/assets/js/runtime-********************.js 1.19 kB -1 B (0%)
./dist/assets/js/32-********************.js 3.12 kB +3.12 kB (new file) 🆕

<details><summary>ℹ️ <strong>View Unchanged</strong></summary>

Filename Size
./dist/assets/css/googlesitekit-admin-css-********************.css 40.7 kB
./dist/assets/css/googlesitekit-adminbar-css-********************.css 8.02 kB
./dist/assets/css/googlesitekit-wp-dashboard-css-********************.css 4.59 kB
./dist/assets/js/analytics-advanced-tracking.js 769 B
./dist/assets/js/googlesitekit-dashboard-********************.js 50.4 kB
./dist/assets/js/googlesitekit-dashboard-splash-********************.js 66.3 kB
./dist/assets/js/googlesitekit-data-********************.js 1.65 kB
./dist/assets/js/googlesitekit-datastore-ui-********************.js 8.97 kB
./dist/assets/js/googlesitekit-i18n.js 3.92 kB
./dist/assets/js/googlesitekit-modules-analytics-4-********************.js 18.9 kB
./dist/assets/js/googlesitekit-modules-optimize-********************.js 18.9 kB
./dist/assets/js/googlesitekit-modules-search-console-********************.js 36.5 kB


<a href=""><sub>compressed-size-action</sub></a>


comment created time in 14 minutes


started time in 16 minutes

issue commentgoogle/site-kit-wp

Create separate Webpack configuration for Gutenberg-related entrypoints

@tofumatt I have created a PR with my current progress so far. I think we can sort out the rest in the CR (assuming I haven't done it completely wrong :grimacing: ). Would you mind reviewing it?



comment created time in 16 minutes

delete branch google/json_serializable.dart

delete branch : release

delete time in 16 minutes

push eventgoogle/json_serializable.dart

Kevin Moore

commit sha 04af01c922930610af8328457eafd0927c1760b7

beta release of pkg:json_annotation (#1050) To ensure it's backwards compatible

view details

push time in 16 minutes

PR merged google/json_serializable.dart

beta release of pkg:json_annotation

To ensure it's backwards compatible

+2 -2

0 comment

2 changed files


pr closed time in 16 minutes

push eventgoogle/site-kit-wp


commit sha 70160944453db465b8985afe4a65f5989d6d8dd4

Deploy storybook for pull/4435.

view details

push time in 16 minutes

delete branch google/json_serializable.dart

delete branch : i1038_need_ctor

delete time in 16 minutes

push eventgoogle/json_serializable.dart

Kevin Moore

commit sha cd77f7a3cf0fba34613c9f5ca15685b154f5327c

Don't assume we need a constructor too early in build process (#1049) Fixes

view details

push time in 16 minutes

PR merged google/json_serializable.dart

Don't assume we need a constructor too early in build process


+36 -3

0 comment

3 changed files


pr closed time in 16 minutes

issue closedgoogle/json_serializable.dart

Class needs default constructor even when generating only toJson()

My class looks like this

@JsonSerializable(createFactory: false)
class ArticleId {
  final String? id;
  final String? ean;
    : ean = null;

    : id = null;

  Map<String, dynamic> toJson() => _$ArticleIdToJson(this);

and even though I am generating only toJson, it shows The class `ArticleId` has no default constructor.

I don't know if this is intended or not, but currently I have to create private constructor with // ignore: unused_element to satisfy the analyzer, which would be nice to not have to do.

I'm on latest json_serializable 6.0.1

closed time in 16 minutes



started time in 16 minutes


Pull request review commentgoogle/iree

Rollup of changes to enable JAX to directly target IREE.

+// RUN: iree-opt -split-input-file --iree-mhlo-flatten-tuples-in-cfg -canonicalize %s | IreeFileCheck %s+// We rely on canonicalization to cancel out tuple/get_element operations, so+// we do this as slightly more than a unit test of the pass only.

Left a TODO.


comment created time in 17 minutes