text:
How do I use io_chunks to let xee auto-compute a chunk size relative to the request byte limit?

# By default, automatically optimize io_chunks.
    self.chunks = self._auto_chunks(max_dtype, request_byte_limit)
    if chunks == -1:
      self.chunks = -1
    elif chunks is not None and chunks != 'auto':
      self.chunks = self._assign_index_chunks(chunks)

  io_chunks (optional): Specifies the chunking strategy for loading data
        from EE. By default, this automatically calculates optional chunks based
        on the `request_byte_limit`.

The above is source code in xee that is supposed to automatically optimize io_chunks based on the request byte size (which is defined in the source code as approximately 48 MBs) when chunks=None. However, when I set chunks=None when running xarray.open_dataset I get back an xarray Dataset that is not chunked at all. What am I missing here?

Could you add a code sample to reproduce? chunks=None should automatically set an appropriate chunk size.

i = ee.ImageCollection(ee.Image("LANDSAT/LC08/C02/T1_TOA/LC08_044034_20140318"))
ds = xr.open_dataset(i, engine='ee', chunks=None)

I feel like I'm missing something obvious here, but just taking this sample code snippet from the xee readme and printing ds shows that the data variables are just xarray DataArrays and not Dask arrays.

authors: adrianom-gh naschmitz

repo: google/Xee


text:
Pager composable

A new Pager layout! 🎉
Fixes #189
Demo
https://user-images.githubusercontent.com/227486/108872201-d7061400-75f1-11eb-9131-88065ed080f5.mp4
Todo for first merge

[x] Tests
[x] RTL support
[x] Kdoc
[x] Documentation
[x] Semantics selectable state

Todo for follow-up

[ ] Move to Modifier.scrollable() (WIP: #236)
[ ] Semantics scroll event support (hopefully automatically with Modifier.scrollable())
[ ] Add test for state restoration path
[ ] More samples

Just need to get the tests to pass on CI (they work fine locally), then I think this is ready to be merged.

source: gharchive/pull-request

repo: google/accompanist

license_type: permissive

license_source: github-api


text:
Purge API implemented

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #1472
Description
Purge API - purge(), clearDatabase() and getLocalChange() API implemented and test cases added for all API
Alternative(s) considered
Yes, details are mentioned in design doc
Type
Choose one: | Feature
Screenshots (if applicable)
Checklist

[x] I have read and acknowledged the Code of conduct.
[x] I have read the Contributing page.
[x] I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
[x] I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
[x] I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
[x] I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

move local change data class outside of db package.

Done

repo: google/android-fhir

license_source: bigquery


text:
Add DeviceCheck isSupported check

Added a DeviceCheck isSupported check and return a GACAppCheckErrorCodeUnsupported error when not supported (e.g., when running on the simulator or older Macs).
This is a port of https://github.com/firebase/firebase-ios-sdk/pull/11663 to AppCheckCore.

How is this exposed to the public API?

@paulb777 No changes to the public API signature but now if you call limitedUseToken: or tokenForcingRefresh:completion: on a device where DeviceCheck isn't supported, you'll get a GACAppCheckErrorCodeUnsupported error saying "The attestation provider DeviceCheckProvider is not supported on current platform and OS version" instead of GACAppCheckErrorCodeUnknown with no additional debugging details.

repo: google/app-check


text:
Google Closure Compiler REST API, AJAX, No Compiled Code Returned

OK. Here's a headscratcher.
Setting up the various params for the Closure Compiler, with text as my Javascript string:
var scriptRequestData = {
        'output_format': 'json',
        'output_info': 'compiled_code',
        'output_info': 'warnings',
        'output_info': 'errors',
        'output_info': 'statistics',
        'compilation_level': 'WHITESPACE_ONLY',
        'language': 'ECMASCRIPT6',
        'warning_level': 'default',
        'js_code': text
    };

Here's the settings object for the AJAX call:
var RXpostSettingsObject = {
        method:'POST',
        url: "https://closure-compiler.appspot.com/compile",
        timeout: 500,
        headers: {"Content-Type": "application/x-www-form-urlencoded;charset=utf-8"},
        responseType: 'json',
        body: $.param( scriptRequestData )
    };

The body yields this on check:
output_format=json&output_info=statistics&compilation_level=WHITESPACE_ONLY&language=ECMASCRIPT6&warning_level=default&js_code=document.write('%20%26middot%3B%20%3Ca%20href%3D%22'%2B'mai'%2B'l_to%3Apet_er_%40mrc_oles.c_om'.split('_').join('')%2B'%22%3Econtact%3C%2Fa%3E')

All good so far. So I send the request in using Rx wrapper for Ajax (I've also tried plain Ajax):
Rx.Observable.ajax(RXpostSettingsObject).retry(3)
        .subscribe(
            function(data) {
                console.log(data.response);
            },
            function(errors) {
                console.log(errors);
            },
            function(complete) {
                console.log("Closure Compiler Script Check Complete"); }
        });

And it clearly works, as I get this back:
statistics: {compileTime:0, compressedGzipSize:117, compressedSize:109,
originalGzipSize:115, originalSize:108 }

But I get no compiled code, which should be returned in the JSON response as compiledCode. Nothing there. I've run the exact same query on Postman and I get the following response:
{"compiledCode":"document.write(' \u0026middot; \u003ca href\u003d\"'+\"mai\"+\"l_to:pet_er_@mrc_oles.c_om\".split(\"_\").join(\"\")+'\"\u003econtact\u003c/a\u003e');","statistics":{"originalSize":108,"originalGzipSize":115,"compressedSize":109,"compressedGzipSize":117,"compileTime":0}}

So, my question is, WTF? My only thought is that AJAX is somehow filtering out the top level of JSON data as it is at the root. Anyone with any ideas on what's going wrong?
Any help much appreciated.

So just to update if anyone's reading this: if I remove all the output info options apart from the compiled code, I get the compiled code back. So it seems that when you add errors and statistics in, the format of the JSON response cannot be read by ajax, so it just does its best and returns the statistics. Indeed, when I get the JSON response from Postman and try to parse it using JSON.parse, I get Uncaught SyntaxError: Unexpected token o in JSON at position 1

source: gharchive/issue

repo: google/closure-compiler-js


text:
Allow comments in flagfile

The --flagfile argument to the compiler is a convenient way to package up the many options needed.
However, the options can be surprising, so the flag file would strongly benefit from being able to add comments:

what this option does
explanation for why it's used in the project
a TODO to change the option to another value, link to a bug

@alexeagle Would a JSON config file similar to webpack and typescript be better?

I just started playing with the closure compiler (with @alexeagle's help).
But my 2 cents would be that being a Javascript tool, using a Javascript notation makes sense to me.

Typically a JSON configuration format would not accommodate the thing @alexeagle was hoping for, comments intermixed with configuration. As I understand some systems work around this by accepting yet another format which is not JSON per se, but a kind of hybrid JSON it also allows comments.
https://www.npmjs.com/package/comment-json
However, for the sake of moving things along, swapping the whole thing over to a completely different way of specifying configuration sound like a lot more work than just tolerating comment lines in the existing format. I don't have a "vote" but if I did I would encourage the effort be spent on numerous essential features instead of migrating to a different configuration format.

Yeah, not an essential feature but I think it can easily be converted...
By the way, this is what i came up with for how it might look..
{
	"compilation_level": "ADVANCED_OPTIMIZATIONS",
	"language_out": "ES5",
	"js_output_file": "dist/bundle.js",
	"create_source_map": "%outnamee%.map",
	"variable_renaming_report": "dist/variable_renaming_report",
	"property_renaming_report": "dist/property_renaming_report",
	"warning_level": "QUIET",
	"rewrite_polyfills": false,
	"entry_point": "./aot-built/app/client.aot.js",
	"dependency_mode": "STRICT",
	"output_manifest": "dist/manifest.MF",
	"files": [
		"node_modules/@angular/core/@angular/core.js",
		"node_modules/@angular/common/@angular/common.js",
		"node_modules/@angular/forms/@angular/forms.js",
		"node_modules/@angular/http/@angular/http.js",
		"node_modules/@angular/router/@angular/router.js",
		"node_modules/@angular/platform-browser/@angular/platform-browser.js",
		"externs/zone_externs.js",
		"externs/angular_testability_externs.js"
	],
	"js_module_roots": [
		"node_modules/@angular/core",
		"node_modules/@angular/common",
		"node_modules/@angular/forms",
		"node_modules/@angular/http",
		"node_modules/@angular/router",
		"node_modules/@angular/platform-browser"
	]
}

A JSON config file could simply be require()d and passed to the API:
https://github.com/google/closure-compiler-npm#specifying-options
so I think that already works. Allowing comments there might be nice but it's a different issue.
For correct layering, I think the closure-compiler package should not know about the npm CLI? So any changes here should be in terms of the java-based API exposed by compiler.jar.
Indeed this is not that important, so I hope we don't do more than just dropping lines as the file content is read.

Just last week my team members proposed a project config file to help with tooling and IDE plugins - that's why I asked.
The compiler package should NOT know about the npm cli. But the npm cli is where we really care about these issues.
I'm probably not going to be spending time on a flagfile that is hard to maintain and use in other tools - that's why I'm asking. I really only concern myself with the NPM ecosystem.
Or are you wanting to use the flagfile from another tooling system? Like Bazel?

The flagfile is just an intermediate state. It doesn't support globs so it
isn't comprehensive anyway, at least until the compiler can resolve paths
from disk to files that weren't presented on the command line. And
eventually from Bazel we will just construct a full command line (like
rules_closure)
This issue is really low priority, I might contribute it anyway though.
On Sat, Apr 8, 2017, 9:15 AM Chad Killingsworth notifications@github.com
wrote:

Just last week my team members proposed a project config file to help with
tooling and IDE plugins - that's why I asked.
The compiler package should NOT know about the npm cli. But the npm cli is
where we really care about these issues.
I'm probably not going to be spending time on a flagfile that is hard to
maintain and use in other tools - that's why I'm asking. I really only
concern myself with the NPM ecosystem.
Or are you wanting to use the flagfile from another tooling system? Like
Bazel?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/closure-compiler/issues/2413#issuecomment-292724251,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC5I7UZCxjXiTSarFSHFFjRlu8rL2uwks5rt6R9gaJpZM4M3S-1
.

The command line does support globs. I thought the flagfile did too. Slightly different format from Node though.

You're right, I hadn't read the docs on the wiki. My flagfile is very nice now
https://github.com/alexeagle/closure-compiler-angular-bundling/blob/master/closure.conf
(you might be interested to see how Closure is used in that repo, this is the model for how Angular apps will do it)
I'll probably send a PR for comments in the flagfile.

@ChadKillingsworth Yes, right - but see my comment in the other issue #2423. NODE doesn't know about the fancy new es2015 package.json field. ( @alexeagle - is that feature of the Angular build output, stable enough to ask Closure to know about it yet?)

It would be interesting for Closure to understand the alternate main fields such as esnext:main and es2015. But these aren't standardized anywhere, and closure usually avoids anything non-standard.
@ChadKillingsworth we just announced a package format for Angular apps to follow that allows them to work with Closure Compiler, and they also have to do a particular pattern to workaround the fact that ES2015 files are not the "main" main.
(as I'm sure you know, Closure does a much better job optimizing ES2015 code, eg. classes, which is why we don't hand it the primary files which are ES5)

Those alternate field status' are "loosely" defined everywhere. We only look at the main field right now - simply because I haven't gotten around to writing in more support. I know that module and browser need to be honored, but I haven't done that yet.
If a major framework like angular wants to add support for other fields, I'm completely open to do that. We just need to define the order of precedence.

If you can get webpack to follow suite - then that only adds more credence to this.

That would be awesome for us. /cc @jasonaden who wrote the packaging spec for Angular.

@ChadKillingsworth @alexeagle So Webpack has a configuration option for this called "resolve.mainFields". They default to ["browser", "module", "main"] but this can be easily updated.
I don't think Webpack will directly support the es2015 key as they don't parse es2015 by default. You need to add the babel loader in order to support it, at which point modifying resolve.mainFields would work.

Vaguely related: rollup comes with a note module resolver. That resolver does not yet support the es2015 key, for the same reasons as discussed earlier here:  That they are aiming to support things that are at least somewhat official standards. I made an alternative resolver that does understand these files, suitable for use with angular:
https://www.npmjs.com/package/rollup-plugin-node-resolve-angular
This is a feasible approach for rollup or webpack (although the letter does not need it, see @jasonaden  comment about the configuration option). It's not feasible for Closure because Closure does not have (that I know of) any way to write a plug-in resolver.

authors: ChadKillingsworth FrozenPandaz alexeagle jasonaden kylecordes

repo: google/closure-compiler


text:
INTERNAL COMPILER ERROR when using --transform_amd_modules

This issue was imported from Closure Compiler's previous home at http://closure-compiler.googlecode.com
The original discussion is archived at:
http://blickly.github.io/closure-compiler-issues/#758

Repro:
// x.js
define(['text!a.txt'], function() {
  return {};
})

Run
java -jar compiler.jar --js x.js --transform_amd_modules --process_common_js_modules --entry_point x


text:
Change some 'contains' to 'runs' relations and add 'createdBy' attributes

Closes issues #7, #25.

Supriya,
I addressed your comments. Please take another look.

Supriya,
I addressed your comment. Please take another look.
Eran

Hi Eran,
When I ran the tests in collector_test 7 of them failed. I noticed that they were all due to the compare_to_golden test. It is basically failing due to differences in whitespace used. If you replace the code between lines 71-89 by the following, it will work.
#Strip the sanitized strings, and replace multiple whitespaces by a single space
sanitized_golden_data = re.sub('\\s+', ' ', sanitized_golden_data.strip())
sanitized_ret_value = re.sub('\\s+', ' ', sanitized_ret_value.strip())

self.assertEqual(sanitized_golden_data, sanitized_ret_value)

Eran,
Eran,
Here are my last set of comments for this pull. In utilities.py, when re.match is used in boolean expressions (lines 50 and 204), it should be checked against None to get a boolean value:
(re.match('^[0-9a-fA-F]+$', x) is not None)

Similarly, in lines 222, and 239, the assertion statements should be: assert (m is not None)

Supriya,
The latest committed code works for me. It does not fail. In any case, I
changed the code according to your suggestion. However, I did not change
the assertion. I explained why the original assertion is superior for
debugging in a new comment.
Eran
On Wed, Apr 1, 2015 at 11:29 AM, supriyagarg notifications@github.com
wrote:

Hi Eran,
When I ran the tests in collector_test 7 of them failed. I noticed that
they were all due to the compare_to_golden test. It is basically failing
due to differences in whitespace used. If you replace the code between
lines 71-89 by the following, it will work.
#Strip the sanitized strings, and replace multiple whitespaces by a single space
sanitized_golden_data = re.sub('\s+', ' ', sanitized_golden_data.strip())
sanitized_ret_value = re.sub('\s+', ' ', sanitized_ret_value.strip())
self.assertEqual(sanitized_golden_data, sanitized_ret_value)
—
Reply to this email directly or view it on GitHub
https://github.com/google/cluster-insight/pull/26#issuecomment-88523278.

I beg to differ.
The Python documentation says about the result of the re.match() function:
Match objects always have a boolean value of True. Since match() and
search() return None when there is no match, you can test whether there was
a match with a simple if statement:
match = re.search(pattern, string)
if match:
process(match)
Since the idiomatic way to test for a successful match is:
if re.match(pattern, string):
I prefer to keep it this way.
Eran
On Wed, Apr 1, 2015 at 1:00 PM, supriyagarg notifications@github.com
wrote:

Eran,
Here are my last set of comments for this pull. In utilities.py, when
re.match is used in boolean expressions (lines 50 and 204), it should be
checked against None to get a boolean value:
(re.match('^[0-9a-fA-F]+$', x) is not None)
Similarly, in lines 222, and 239, the assertion statements should be: assert
(m is not None)
—
Reply to this email directly or view it on GitHub
https://github.com/google/cluster-insight/pull/26#issuecomment-88544931.

authors: EranGabber supriyagarg

repo: google/cluster-insight


text:
Bring common CSV version back up to 1.10.0

The commit 1a99cef4a4e4f8828b98a93d822404ca80ae3889 to make Gradle use a version catalog accidentally downgraded the common CSV library version to 1.9.0 but the license report uses a method signature that was introduced in 1.10.0.

Noting that the release job failed with:
> Task :buildSrc:compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':buildSrc:compileJava'.
> Could not resolve all files for configuration ':buildSrc:compileClasspath'.
   > Could not resolve org.apache.commons:commons-csv:1.10.0.
     Required by:
         project :buildSrc
      > Could not resolve org.apache.commons:commons-csv:1.10.0.
         > Could not get resource '[https://plugins.gradle.org/m2/org/apache/commons/commons-csv/1.10.0/commons-csv-1.10.0.pom](https://www.google.com/url?q=https://plugins.gradle.org/m2/org/apache/commons/commons-csv/1.10.0/commons-csv-1.10.0.pom&sa=D)'.
            > Could not GET '[https://jcenter.bintray.com/org/apache/commons/commons-csv/1.10.0/commons-csv-1.10.0.pom](https://www.google.com/url?q=https://jcenter.bintray.com/org/apache/commons/commons-csv/1.10.0/commons-csv-1.10.0.pom&sa=D)'.
               > Read timed out
   > Could not resolve com.diffplug.spotless:spotless-lib:2.24.1.
     Required by:
         project :buildSrc > com.diffplug.spotless:spotless-plugin-gradle:6.4.1
      > Skipped due to earlier error
   > Could not resolve com.diffplug.spotless:spotless-lib-extra:2.24.1.
     Required by:
         project :buildSrc > com.diffplug.spotless:spotless-plugin-gradle:6.4.1
      > Skipped due to earlier error

Noting that the release job failed with:

And it just succeeded, so it must have just been a network issue.

authors: haselbach mjquinn-google

repo: google/dwh-migration-tools


text:
Add two-column mobile-friendly Hugo site.

This is a simple place to host WebGL demos and tutorials, we can prettify later. It will show up at:
https://google.github.io/filament/

The hugo config specifies the output holder to be ../docs which is where our GitHub Pages site is located.
Note that this commit adds the source to the site, it does not publish the actual site. When we're ready to publish the actual site, we'll do:
cd site ; hugo ; cd ..
git add docs ; git commit

My only comment is that I don't like the theme :) The content is also extremely Filament-JS oriented. We should definitely surface that but the google.github.io website should provide a clear description of the project with a section about the JS binding, not just the JS bindings/tutorials/docs.

I added content to the landing page and added a live demo there.  I also reorganized the content so that all webgl stuff is on one page, and all "core filament" stuff is on another page.  Screenshots below.
Also changed blue to gray but yeah the theme isn't great.

authors: prideout romainguy

repo: google/filament


text:
Add SubmoduleGitURL to RepositoryContent

Fixes: #2877.

@Parker77 - do you have time for another review, please?

repo: google/go-github


text:
feat!: Rename code scanning params from plural to singular

BREAKING CHANGE: Rename RuleRequiredCodeScanningTools to RuleRequiredCodeScanningTool.
Some improvements for #3256

@air-hand Could you review please?

Thank you, @air-hand !
Merging.

authors: gmlewis ihor-hrytskiv


text:
Export function to extract and validate AK from server

We need to export a function from server to extract/validate AK, and populate GCE instance info into machine state so that GAV can consume.

/gcbrun

/gcbrun

/gcbrun

Please give my changes a look @yawangwang and merge it in if you feel it looks okay.

LGTM, now merging this PR

authors: alexmwu yawangwang

repo: google/go-tpm-tools


text:
Authentication Failed with UrlShortener API Key

Hi,
I have a Google project with:

An OAuth2 Token to authenticate users
An API Key for server side urlshortener

var google       = require('googleapis')
var shortener  = google.urlshortener('v1');
shortener.url.insert({ 'longUrl': longUrl, key: 'MY_SERVER_KEY' }, function(err, result) {
    if (err) callback();
    if (result){  plugin.minify = result.id.substring("http://goo.gl/".length);  }
    else { console.log(err, result); }
    callback();
});

I get the given log :
{ [Error: Required] code: 400 } null

According to Google documentation I can use server key for this action.

That request requires that the longUrl be in the resource (body) of the request. Here's the valid request:
var google       = require('googleapis')
var shortener  = google.urlshortener('v1');
shortener.url.insert({ resource: {'longUrl': 'https://google.com' }, key: 'API_KEY' }, function(err, result) {
  console.log(err, result);
});

Thanks for your quick answer ! I missed that while migrating from 0.x

authors: JpEncausse ryanseys

repo: google/google-api-nodejs-client


text:
v2 does not have the create function, updating to v3

This is a simple fix to the readme

[ x ] Approprate changes to readme/docs are included in PR

I signed it!

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

Merging [#571][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master       #571   diff @@
==========================================
  Files             8          8
  Lines           264        264
  Methods          41         41
  Messages          0          0
  Branches         58         58
==========================================
  Hits            239        239
  Misses           25         25
  Partials          0          0

Powered by Codecov. Last updated by [d99ca56...2b1c6ec][cc-compare]
[cc-base-branch]: https://codecov.io/gh/google/google-api-nodejs-client/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/google/google-api-nodejs-client/compare/d99ca561d0cdcfc9bc8911c9419963a94bc4a74e...2b1c6ec6d620ab9cf2dc799e08cc9631db8dcc93
[cc-pull]: https://codecov.io/gh/google/google-api-nodejs-client/pull/571?src=pr

I signed it!
(try again with another email, sorry)

authors: codecov-io georules


text:
IPv6 SRH decoding

Added support for SRv6 SRH decoding.

@googlebot I signed it! and we'll verify it.
On Tue, Jun 29, 2021 at 9:05 PM google-cla[bot] @.***>
wrote:

Thanks for your pull request. It looks like this may be your first
contribution to a Google open source project (if not, look below for help).
Before we can look at your pull request, you'll need to sign a Contributor
License Agreement (CLA).
📝 Please visit https://cla.developers.google.com/
https://cla.developers.google.com/ to sign.
Once you've signed (or fixed any issues), please reply here with @googlebot
I signed it! and we'll verify it.
What to do if you already signed the CLA Individual signers

It's possible we don't have your GitHub username or you're using a
different email address on your commit. Check your existing CLA data
https://cla.developers.google.com/clas and verify that your email is
set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.

Corporate signers

Your company has a Point of Contact who decides which employees are
authorized to participate. Ask your POC to be added to the group of
authorized contributors. If you don't know who your Point of Contact is,
direct the Google project maintainer to go/cla#troubleshoot (Public
version https://opensource.google/docs/cla/#troubleshoot).
The email used to register you as an authorized contributor must be
the email used for the Git commit. Check your existing CLA data
https://cla.developers.google.com/clas and verify that your email is
set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.
The email used to register you as an authorized contributor must
also be attached to your GitHub account
https://github.com/settings/emails.

ℹ Googlers: Go here
https://goto.google.com/prinfo/https%3A%2F%2Fgithub.com%2Fgoogle%2Fgopacket%2Fpull%2F889
for more info.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/gopacket/pull/889#issuecomment-871021065, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AFLJ7DXGZTZLYKK6L2S6PELTVJUUHANCNFSM47RJPZZA
.

@googlebot I signed it! and we'll verify it.
On Tue, Jun 29, 2021 at 9:05 PM google-cla[bot] @.***>
wrote:

Thanks for your pull request. It looks like this may be your first
contribution to a Google open source project (if not, look below for help).
Before we can look at your pull request, you'll need to sign a Contributor
License Agreement (CLA).
📝 Please visit https://cla.developers.google.com/
https://cla.developers.google.com/ to sign.
Once you've signed (or fixed any issues), please reply here with @googlebot
I signed it! and we'll verify it.
What to do if you already signed the CLA Individual signers

It's possible we don't have your GitHub username or you're using a
different email address on your commit. Check your existing CLA data
https://cla.developers.google.com/clas and verify that your email is
set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.

Corporate signers

Your company has a Point of Contact who decides which employees are
authorized to participate. Ask your POC to be added to the group of
authorized contributors. If you don't know who your Point of Contact is,
direct the Google project maintainer to go/cla#troubleshoot (Public
version https://opensource.google/docs/cla/#troubleshoot).
The email used to register you as an authorized contributor must be
the email used for the Git commit. Check your existing CLA data
https://cla.developers.google.com/clas and verify that your email is
set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.
The email used to register you as an authorized contributor must
also be attached to your GitHub account
https://github.com/settings/emails.

ℹ Googlers: Go here
https://goto.google.com/prinfo/https%3A%2F%2Fgithub.com%2Fgoogle%2Fgopacket%2Fpull%2F889
for more info.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/gopacket/pull/889#issuecomment-871021065, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AFLJ7DXGZTZLYKK6L2S6PELTVJUUHANCNFSM47RJPZZA
.

@googlebot I signed it!

@googlebot I fixed it.

Any chance this PR to get attention some day?

Hi @rozeps  and thank you for this work. I would really like to use this feature.
Do you still have issues with the CLA? Any chance to get the PR merged?

authors: louisroyer rozeps

repo: google/gopacket


text:
Ill-named variable in "waysToMakeZero"

Variable "opaqueOneFactories" in "waysToMakeZero" should really be "opaqueZeroFactories".

Fixed, thank you!

Fixed via #475

authors: afd jiradeto

repo: google/graphicsfuzz


text:
Fetch Basemap sources from projects

This PR changes our approach to getting json sources for offline areas--we now pull them from the active project instead of a file preloaded on the user's device.
Note that everything should work, however--we don't yet have a project that has a valid basemap source to test with (afaict).

@gino-m was the URL for the sources still the same? I can test this out properly if so--theoretically, it should work as is.

Thanks for the feedback @shobhitagarwal1612! @gino-m this is fixed now and is ready for another look!

Please fix the merge conflicts. Rest looks great! Thanks

Please fix the merge conflicts. Rest looks great! Thanks

Thanks, Shobhit! Should be fixed now.

repo: google/ground-android


text:
chore: use PR labels to indicate final merge status

Because of internal requirements, we require that PRs be squashed into a single commit before being merged. Currently, this is implemented with a pr_style workflow that checks the number of commits. However, enforcing this during the review process makes it difficult to see changes after comments are addressed.
Instead, we may want to allow the author to keep multiple commits (and potentially disallow merge commits to make this easier), and simply require a squash at the end of the review process.

Closing, as this seems to have been achieved with the current workflow (c.f. https://google.github.io/heir/docs/contributing/)

authors: AlexanderViand-Intel asraa

repo: google/heir


text:
Demo elementwise lowering of tensor to loops

Adds the MemRefElementTypeInterface to the polynomial type, and demonstrates the lowering to affine loops
bazel run //tools:heir-opt -- --convert-elementwise-to-linalg --one-shot-bufferize --convert-linalg-to-affine-loops $PWD/tests/polynomial/elementwise.mlir

The strange part is that lowering linalg to loops requires de-tensorizing the inputs to linalg.generic, which inserts bufferization.to_memref and bufferization.to_tensor as materializations. To completely eliminate those requires converting everything to memrefs, see https://github.com/google/heir/blob/main/tools/heir-opt.cpp#L85-L99
I tried running --polynomial-to-standard after this, but ran into another issue
/home/j2kun/fhe/heir/tests/polynomial/elementwise.mlir:8:8:
error: failed to legalize unresolved materialization from
'!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>'
to 'tensor<1024xi25>' that remained live after conversion
  %0 = polynomial.add(%arg0, %arg1) : tensor<2x!poly>
       ^
/home/j2kun/fhe/heir/tests/polynomial/elementwise.mlir:8:8:
note: see current operation: %7 = "builtin.unrealized_conversion_cast"(%6) :
 (!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>) -> tensor<1024xi25>
/home/j2kun/fhe/heir/tests/polynomial/elementwise.mlir:8:8:
note: see existing live user here: %8 = arith.extsi %6 : tensor<1024xi25> to tensor<1024xi26>

The strange part is that lowering linalg to loops requires de-tensorizing the inputs to linalg.generic, which inserts bufferization.to_memref and bufferization.to_tensor as materializations. To completely eliminate those requires converting everything to memrefs, see https://github.com/google/heir/blob/main/tools/heir-opt.cpp#L85-L99

That's a bit unfortunate, but it's great to see that there is a way after all ❤


text:
no coverage info on Android(build target with -fsanitize=address)

I got same situation as https://github.com/google/honggfuzz/issues/342
I try to add -fsanitize-coverage=trace-pc-guard,trace-cmp,trace-div,indirect-calls, but I got many warnings:
WARNING: found 1 unrecognized flag(s):
    detect_odr_violation

I checked google's doc :
in Application.mk :
APP_STL := c++_shared # Or system, or none.
APP_CFLAGS := -fsanitize=address -fno-omit-frame-pointer
APP_LDFLAGS := -fsanitize=address

For each module in your Android.mk:
LOCAL_ARM_MODE := arm

so I modified my demo as follow:
LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)
LOCAL_PATH = .
LOCAL_MODULE := hfuzz
LOCAL_EXPORT_C_INCLUDES := $HOME/honggfuzz/includes
LOCAL_SRC_FILES := /home/user/honggfuzz/libs/arm64-v8a/libhfuzz.a
LOCAL_ARM_MODE := arm
include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_PATH = .
LOCAL_MODULE := hfuzzcommon
LOCAL_EXPORT_C_INCLUDES := $HOME/honggfuzz/includes
LOCAL_SRC_FILES := /home/user/honggfuzz/obj/local/arm64-v8a/libcommon.a
LOCAL_ARM_MODE := arm
include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_STATIC_LIBRARIES := hfuzz hfuzzcommon
LOCAL_SRC_FILES := fuzz_test.c
LOCAL_MODULE := fuzz_test
LOCAL_ARM_MODE := arm

include $(BUILD_EXECUTABLE)

cat Application.mk
APP_BUILD_SCRIPT := ./Android.mk
APP_STL := c++_shared # Or system, or none.
APP_CFLAGS := -fsanitize=address  -fno-omit-frame-pointer
APP_LDFLAGS := -fsanitize=address

After ndk-build， I test it on my pixel2 :

It seems ASAN works fine.
But when I try to fuzzing fuzz_test with honggfuzz, I find I cannot get any coverage infomation :
./honggfuzz -i in -o out -z -- fuzz_test ___FILE___

What I did wrong? Could you suggest something, please?

First of all, I never fuzzed on Android - the Android port is work of other people (both inside and inside my company) and I have little knowledge on how it works (should work).
You said that you get warnings about detect_odr_violation if you add . Is this the only problem? Because if so, you can simply remove it from sanitizers.c

First of all, I never fuzzed on Android - the Android port is work of other people (both inside and inside my company) and I have little knowledge on how it works (should work).
You said that you get warnings about detect_odr_violation if you add . Is this the only problem? Because if so, you can simply remove it from sanitizers.c

Thanks for your reply, fix detect_odr_violation is easy. But I still cannot get any coverage info :(
Is there any doc about building harness on Android?

First of all, I never fuzzed on Android - the Android port is work of other people (both inside and inside my company) and I have little knowledge on how it works (should work).
You said that you get warnings about detect_odr_violation if you add . Is this the only problem? Because if so, you can simply remove it from sanitizers.c

Thanks for your reply, fix detect_odr_violation is easy. But I still cannot get any coverage info :( Is there any doc about building harness on Android?

Hi, I have the same problem, did you solve it ?

repo: google/honggfuzz


text:
CredentialTypeRepository

Features

CredentialTypeRepository in Identity library
Self signed documents in wallet using the CredentialTypeRepository

Fixes #401

It's a good idea to open an issue first for discussion.

[x ] Tests pass

Changed the AuthConfirmationFragment.kt code. Is it ok to create another pull request for the usage of the CredentialTypeRepository in the reader app?

Changed the AuthConfirmationFragment.kt code. Is it ok to create another pull request for the usage of the CredentialTypeRepository in the reader app?

Yes, that's fine!

repo: google/identity-credential


text:
Updated validations.py python script

Updated validations.py python script.
Fixed the behavior of validate_user function in validations.py.
Fixes #11387

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

@googlebot I signed it!

@googlebot I signed it!

repo: google/it-cert-automation-practice


text:
updated some test cases like username shouldn't start with '.' or '_'…

… characters.
Closes: #1
Updated validations.py python script.
Fixed the behavior of validate_user function in validations.py.
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

here are some changes


text:
Updated validations.py python script.

Updated validations.py python script.
Fixed the behavior of validate_user function in validations.py.
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

aa


text:
Closes: #1

Updated validations.py python script.
Fixed the behavior of validate_user function in validations.py.Closes: #1 Updated validations.py python script.
Fixed the behavior of validate_user function in validations.py.
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[x] Tests pass
[x] Appropriate changes to README are included in PR

some try and demo over course's scenerio.

successfully completed


text:
Help with modified sample (Calendar cannot be resolved to a type)

I was wondering if you could help me understand what it is missing. I am unable to build after adding some imports and calls to the "j2cl\samples\helloworld\src\main\java\com\google\j2cl\samples\helloworldlib\HelloWorld.java" as follows:
package com.google.j2cl.samples.helloworldlib;

import jsinterop.annotations.JsType;
import java.util.Date;
import java.util.Calendar;

/**
 * A simple hello world example.
 *
 * <p>Note that it is marked as @JsType as we would like to call have whole class available to use
 * from JavaScript.
 */
@JsType
public class HelloWorld {

  public static String getHelloWorld() {
    **Calendar cal = Calendar.getInstance();
    cal.set(Calendar.HOUR_OF_DAY, 0);
    Date tod = new Date();
    return "Hello from Java!" + tod.toString() + " " + cal.toString();
  }
}

Running bazel build src/main/java/com/google/j2cl/samples/helloworld:helloworld --incompatible_disable_deprecated_attr_params=false --verbose_failures gives me the following:
[587 / 606] Transpiling to JavaScript @com_google_j2cl//jre/java:jre; 30s worker ... (4 actions, 3 running)
ERROR: D:/devtools/eclipse/neon/workspace/j2cl/samples/helloworld/src/main/java/com/google/j2cl/samples/helloworldlib/BUILD:13:1: Transpiling to JavaScript //src/main/java/com/google/j2cl/samples/helloworldlib:helloworldlib failed (Exit 1)
Error:C:\Users\user\AppData\Local\Temp\j2cl_sources4775520020060075074\src\main\java\com\google\j2cl\samples\helloworldlib\HelloWorld.java:20: The import java.util.Calendar cannot be resolved
Error:C:\Users\user\AppData\Local\Temp\j2cl_sources4775520020060075074\src\main\java\com\google\j2cl\samples\helloworldlib\HelloWorld.java:32: Calendar cannot be resolved to a type
Error:C:\Users\user\AppData\Local\Temp\j2cl_sources4775520020060075074\src\main\java\com\google\j2cl\samples\helloworldlib\HelloWorld.java:32: Calendar cannot be resolved
Error:C:\Users\user\AppData\Local\Temp\j2cl_sources4775520020060075074\src\main\java\com\google\j2cl\samples\helloworldlib\HelloWorld.java:33: Calendar cannot be resolved to a variable
4 error(s), 0 warning(s).
Target //src/main/java/com/google/j2cl/samples/helloworld:helloworld failed to build
INFO: Elapsed time: 237.551s, Critical Path: 86.52s
INFO: 568 processes: 529 local, 39 worker.
FAILED: Build did NOT complete successfully
FAILED: Build did NOT complete successfully

I'm completely new to this bazel, GWT, Closure, transpilers world, so being able to setup bazel and build (behind a corporate NTLM proxy) the provided sample was already a personal achievement. However, I'm still struggling to understand how to make j2cl work with simple JDK imports and maven stored libraries (it would be nice if you could provide more examples... perhaps how to transpile a Java class that uses guava.jar from a maven repository).
Build label: 0.29.0
Build target: bazel-out/x64_windows-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Aug 28 14:35:37 2019 (1567002937)
Build timestamp: 1567002937
Build timestamp as int: 1567002937

Thanks in advance!

J2CL supports a subset of the Java standard library. The error you see is because java.util.Calendar is not in the supported Set. Here you can find a list of supported Java standard library classes; it might be slightly outdated.

authors: rluble smfukaya


text:
jax.lax.pmean with jax.pmap hang infinitely. (with gpu 100%)

Description
>>> import jax, numpy as np
>>> jax.pmap(lambda x: jax.lax.pmean(x, 'i'), axis_name='i')(np.arange(4))

Running even these simple examples take the GPU to 100% and do not exit forever.
What jax/jaxlib version are you using?
jax==0.4.8, jaxlib==0.4.7+cuda12.cudnn88
Which accelerator(s) are you using?
GPU (4 X 4090)
Additional system info
python 3.10.6, ubuntu 22.04
NVIDIA GPU info
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.89.02    Driver Version: 525.89.02    CUDA Version: 12.0     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0 Off |                    0 |
|  0%   23C    P8    28W / 450W |      6MiB / 23028MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   1  NVIDIA GeForce ...  Off  | 00000000:2C:00.0 Off |                    0 |
|  0%   23C    P8    19W / 450W |      6MiB / 23028MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   2  NVIDIA GeForce ...  Off  | 00000000:41:00.0 Off |                    0 |
|  0%   22C    P8    12W / 450W |     71MiB / 23028MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   3  NVIDIA GeForce ...  Off  | 00000000:61:00.0 Off |                    0 |
|  0%   23C    P8    21W / 450W |      6MiB / 23028MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

Is this still an issue? We routinely run almost identical tests on 4xT4 GPUs as part of CI, so I'm guessing this was something specific to your setup.
If it's still a problem, try with an up to date jax and jaxib?

@hawkinsp
I encountered this issue as well. pmap hangs indefinitely.
For me, this happens if I use Cuda driver 545.23.8 and install jax[cuda12_pip]==0.4.20
Wed Nov 22 20:00:33 2023
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 545.23.08              Driver Version: 545.23.08    CUDA Version: 12.3     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA GeForce RTX 3080        On  | 00000000:01:00.0 Off |                  N/A |
|  0%   59C    P2             148W / 340W |   7898MiB / 10240MiB |    100%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA GeForce RTX 3080        On  | 00000000:21:00.0 Off |                  N/A |
|  0%   55C    P2             140W / 340W |   7878MiB / 10240MiB |    100%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|    0   N/A  N/A      2156      G   /usr/lib/xorg/Xorg                            9MiB |
|    0   N/A  N/A      2588      G   /usr/bin/gnome-shell                          4MiB |
|    0   N/A  N/A      5464      C   python                                     7870MiB |
|    1   N/A  N/A      2156      G   /usr/lib/xorg/Xorg                            4MiB |
|    1   N/A  N/A      5464      C   python                                     7862MiB |
+---------------------------------------------------------------------------------------+

Single GPU is fine, and it also runs fine if I use an older driver version like 535.*. But in this case.
JAX will complain that I am using an older driver version and ask me to use the forward compat package. I think this is because the CUDA 12.3 packages are on PyPI.

@ethanluoyc Does it reproduce with the same simple example as the original post? If not, can you share a reproducer?

Yes it does.

On Nov 22, 2023, at 22:05, Peter Hawkins @.***> wrote:
@ethanluoyc https://github.com/ethanluoyc Does it reproduce with the same simple example as the original post? If not, can you share a reproducer?
—
Reply to this email directly, view it on GitHub https://github.com/google/jax/issues/15336#issuecomment-1823566923, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOCZODUGMY7MZJYG6RYJATYFZZMFAVCNFSM6AAAAAAWOEQTYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRTGU3DMOJSGM.
You are receiving this because you were mentioned.

authors: ethanluoyc hawkinsp inosphe

repo: google/jax


text:
Add fields to support overrides in file decorations serving data [phab:D1325]

Created by schroederc at 2017-02-10 00:16:51:

zarko commented inline (context lost during migration) at 2017-02-10 01:09:47:
kind is deprecated (they're always DEFINITION; this was from a previous design before MarkedSource).

zarko commented inline (context lost during migration) at 2017-02-10 01:09:47:
I think this is the ticket of the node that would appear as the target of a Decoration.

zarko commented inline (context lost during migration) at 2017-02-10 01:09:47:
Given the above, I think that this is the node that's being overridden/extended (e.g,, Object if ticket were String).

zarko commented inline (context lost during migration) at 2017-02-10 01:09:47:
Maybe document this as the MarkedSource for the node being overridden/extended.

zarko commented inline (context lost during migration) at 2017-02-10 01:09:47:
Kind can go away.

zarko wrote at 2017-02-10 01:09:47:
Some questions about documentation and field names.

schroederc wrote at 2017-02-10 01:33:47:
Rename fields

schroederc commented inline (context lost during migration) at 2017-02-10 01:33:56:
I meant for them to be the reverse of your description.  Is this better?

schroederc wrote at 2017-02-10 01:35:15:
Remove stray comment

zarko commented inline (context lost during migration) at 2017-02-10 01:36:38:
Leftover comment?

zarko commented inline (context lost during migration) at 2017-02-10 01:36:38:
node whose ticket is overridden?

zarko wrote at 2017-02-10 01:36:38:
Yes, thanks.

zarko accepted this revision at 2017-02-10 01:36:38

schroederc wrote at 2017-02-10 01:52:53:
Fix comments

schroederc closed via commit da4838d1653a2df9a5a662b71ffbd22ce26743d7 at 2017-02-10 01:53:11

repo: google/kythe


text:
Missing /kythe/edge/param for /kythe/edge/ref/call function

This is a follow up from: https://groups.google.com/forum/#!topic/kythe/I2vpv8L9oV0
I'm using Kythe 0.28
The instructions to produce the triples file which is missing the /kythe/edge/param should be:
git clone https://github.com/bfergerson/otherproject
cd otherproject

export REAL_JAVAC="$(which javac)"
export JAVAC_EXTRACTOR_JAR=/opt/kythe/extractors/javac_extractor.jar
export KYTHE_ROOT_DIRECTORY="$PWD"
export KYTHE_OUTPUT_DIRECTORY="/tmp/kythe"
export KYTHE_CORPUS=otherproject
mkdir -p "$KYTHE_OUTPUT_DIRECTORY"

mvn clean compile \
  -Dmaven.compiler.forceJavacCompilerUse=true \
  -Dmaven.compiler.fork=true \
  -Dmaven.compiler.executable=/opt/kythe/extractors/javac-wrapper.sh

cd ..

java -Xbootclasspath/p:/opt/kythe/indexers/java_indexer.jar com.google.devtools.kythe.analyzers.java.JavaIndexer /tmp/kythe/#3ff8f033c31a2273ebfbbccc40b02b9187b7c87f3f2a690f7bf5821d6451319e.kindex | /opt/kythe/tools/dedup_stream | /opt/kythe/tools/triples >> /tmp/kythe/triples_results.txt

Which should result in:
2018/08/11 18:01:02 dedup_stream: skipped 8 records
2018/08/11 18:01:02 Skipped 0 reverse edges
2018/08/11 18:01:02 Wrote 529 triples

But while trying to reproduce the issue outside of my application I'm running into another issue. The above actually creates an empty triples_results.txt file. Not sure what's happening here as the resulting .kindex file is only 232 bytes as compared to 6.6kB when I run it in my application.
Considering this isn't the issue I brought up I'll step over this for now and use the .kindex that my application produces using: https://github.com/CodeBrig/GitDetective/blob/ccb25e69875a74bfd1a61a602aecf1c33c8086d0/indexer/src/main/groovy/io/gitdetective/indexer/support/KytheMavenBuilder.groovy#L59. I believe this is the correct .kindex file anyway.
Now that the .kindex has been built and the triples_results.txt has been created you can search for: 5d3c119e684b5d35f9c2ccd0145b2dfc18ee25c83bafc92e212af6203459f0e1.
You won't find any /kythe/edge/param facts associated to that signature. This would seem to indicate that the function has no arguments but you can see it does here: https://github.com/BFergerson/otherproject/blob/b0be5053300ef5baabe7706f1cb440e38aa55565/src/main/java/com/gitdetective/App2.java#L26
So now I have two questions:

Why does the above script produce empty triples_results.txt?
Shouldn't there be /kythe/edge/param for 5d3c119e684b5d35f9c2ccd0145b2dfc18ee25c83bafc92e212af6203459f0e1 in the resulting triples_results.txt file?

First of all.  I'm very sorry for taking so long to get back to you.  We've had some technical difficulties as of late...

For the first issue, this appears in /tmp/javac-extractor.err:
SEVERE: compiler error: Source option 1.5 is no longer supported. Use 1.6 or later.
Errors encountered during compilation

Your KytheMavenBuilder handles this by adding -Dmaven.compiler.source=1.8 -Dmaven.compiler.target=1.8 to the build: https://github.com/CodeBrig/GitDetective/blob/ccb25e69875a74bfd1a61a602aecf1c33c8086d0/indexer/src/main/groovy/io/gitdetective/indexer/support/KytheMavenBuilder.groovy#L76.  You can do the same for the raw invocation and the .kindex file will be correctly extracted.

For the second case, param edges will only be emitted when visiting the function's definition.  Since App2.java only references myMethod2, only the function node will be emitted for the /kythe/edge/ref edge.

I believe all of this is working as intended so I'm going to close this issue.  Please reopen if you disagree or find another issue.

authors: BFergerson schroederc


text:
Compile C++ indexer with Bazel using clang-3.5. [phab:D191]

Created by zarko at 2015-04-16 00:36:37:
We might need to do some work on the CROSSTOOL file;
please let me know if this causes you problems with
your personal configuration.
These BUILD files will work only if you have LLVM
checked out to the default location. In future CLs we
should restore the configurability we have in Campfire.

schroederc commented inline (context lost during migration) at 2015-04-16 15:42:26:
This file is basically Kythe's now.  We should move this into //tools/ and clean it up.

schroederc commented inline (context lost during migration) at 2015-04-16 15:42:26:
Modifications should be listed in README.google.

schroederc commented inline (context lost during migration) at 2015-04-16 15:42:26:
Modifications should be listed in README.google.

schroederc required changes at 2015-04-16 15:42:26

schroederc wrote at 2015-04-16 15:51:57:
I also get this error when trying to run bazel test //....  I'm assuming this is because I don't have exactly llvm-3.5 installed on my machine (3.4 instead).  This seems to be too harsh of a build constraint for both us and our users, though.
ERROR: /usr/local/google/home/schroederc/kythe/third_party/googleflags/BUILD:5:1: undeclared inclusion(s) in rule '//third_party/googleflags:gflags':
this rule is missing dependency declarations for the following files included by 'third_party/googleflags/src/gflags_reporting.cc':
  '/usr/lib/clang/3.4/include/stddef.h'
  '/usr/lib/clang/3.4/include/stdarg.h'
  '/usr/lib/clang/3.4/include/stdint.h'.
INFO: Elapsed time: 20.786s, Critical Path: 15.32s

Executed 0 out of 32 tests: 32 fail to build.

zarko wrote at 2015-04-16 17:59:07:

Autoconfigure header search paths.

schroederc commented inline (context lost during migration) at 2015-04-16 18:10:08:
We should keep our files out of third_party and put this in tools/cpp/CROSSTOOL.
rm tools/cpp
mkdir tools/cpp
ln -s ../../third_party/bazel/tools/cpp/BUILD tools/cpp/
ln -s ../../third_party/bazel/tools/cpp/empty.cc tools/cpp/
ln -s ../../third_party/bazel/tools/cpp/osx_gcc_wrapper.sh tools/cpp/

schroederc required changes at 2015-04-16 18:10:08

zarko wrote at 2015-04-16 18:21:26:

Move files and make symlinks

schroederc commented inline (context lost during migration) at 2015-04-16 18:31:44:
third-party header?

schroederc wrote at 2015-04-16 18:31:44:
I'm still getting the same error as before.
bazel test //...                                                                                ~/kythe [─✗─]
INFO: Found 196 targets and 32 test targets...
ERROR: /usr/local/google/home/schroederc/kythe/third_party/zlib/BUILD:5:1: undeclared inclusion(s) in rule '//third_party/zlib:zlib':
this rule is missing dependency declarations for the following files included by 'third_party/zlib/compress.c':
  '/usr/lib/clang/3.4/include/limits.h'
  '/usr/lib/clang/3.4/include/stddef.h'
  '/usr/lib/clang/3.4/include/stdarg.h'.
INFO: Elapsed time: 1.296s, Critical Path: 0.32s

Executed 0 out of 32 tests: 32 fail to build.

./setup_bazel.sh just says that it found clang at /usr/bin/clang.  tools/cpp/CROSSTOOL contains
  cxx_builtin_include_directory: "/usr/include/c++/4.8"
  cxx_builtin_include_directory: "/usr/include/c++/4.8/backward"
  cxx_builtin_include_directory: "/usr/include/x86_64-linux-gnu/c++/4.8"
  cxx_builtin_include_directory: "/usr/local/include"
  cxx_builtin_include_directory: "/usr/lib/llvm-3.4/lib/clang/3.4/include"
  cxx_builtin_include_directory: "/usr/lib/gcc/x86_64-linux-gnu/4.8/include"
  cxx_builtin_include_directory: "/usr/include/x86_64-linux-gnu"
  cxx_builtin_include_directory: "/usr/include"

schroederc required changes at 2015-04-16 18:31:51

zarko wrote at 2015-04-16 19:56:31:

Use realpath too.

schroederc wrote at 2015-04-16 20:01:26:
I'm getting some -Wimplicit-function-declaration and -Wdeprecated-register warnings now, but everything seems to build at least.

schroederc accepted this revision at 2015-04-16 20:01:26

zarko closed via commit 76ddcb127946e64a94f2608a04fd1b50604cb59f at 2015-04-16 20:03:51


text:
Update tutorial to work with Breadboard 0.4.0

shukri reports:
in  https://github.com/google/labs-prototypes/blob/main/seeds/breadboard/docs/tutorial/tutorial-4.js
const diagram = board2.mermaid();
TypeError: board2.mermaid is not a function

in https://github.com/google/labs-prototypes/blob/main/seeds/breadboard/docs/tutorial/tutorial-6b.js
Error: Uncaught exception in node handler. Catch by wiring up the $error output.
    at #processCompletedNode (file:///workspaces/labs-prototypes/seeds/breadboard/dist/src/traversal/iterator.js:27:19)
    at TraversalMachineIterator.next (file:///workspaces/labs-prototypes/seeds/breadboard/dist/src/traversal/iterator.js:85:59)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async BoardRunner.run (file:///workspaces/labs-prototypes/seeds/breadboard/dist/src/runner.js:90:26)
    at async BoardRunner.runOnce (file:///workspaces/labs-prototypes/seeds/breadboard/dist/src/runner.js:167:26)
    at async file:///workspaces/labs-prototypes/typscript_quickly/dist/main.js:13:16 {
  [cause]: {
    kind: 'error',
    error: Error: No graph found for slot "news"
        at Object.invoke (file:///workspaces/labs-prototypes/seeds/breadboard/dist/src/nodes/slot.js:27:19)
        at callHandler (file:///workspaces/labs-prototypes/seeds/breadboard/dist/src/handler.js:10:24)
        at BoardRunner.run (file:///workspaces/labs-prototypes/seeds/breadboard/dist/src/runner.js:128:19)
        at run.next (<anonymous>)
        at BoardRunner.runOnce (file:///workspaces/labs-prototypes/seeds/breadboard/dist/src/runner.js:167:26)
        at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
        at async file:///workspaces/labs-prototypes/typscript_quickly/dist/main.js:13:16,
    inputs: { slot: 'news', topic: 'Latest news on breadboards' },
    descriptor: { id: 'slot-3', type: 'slot', configuration: { slot: 'news' } }
  }
}

Ah, mermaid() is just on Board and not BoardRunner? We should probably move it there.

All done!

authors: dglazkov seefeldb

repo: google/labs-prototypes


text:
Apache license recognized as ECL-2

The text below, from https://github.com/hyperledger/burrow/blob/v0.21.0/LICENSE.md, is identical to the Apache 2.0 license without appendix.
At the previous head (e43db20c1115), Cover reported a single Match, to Apache-2.0:
{Name:Apache-2.0 Type:Apache Percent:89.40355329949239 Start:33 End:10172 IsURL:false}

At the current head (9240d01bd357), it reports a single match to ECL-2.0:
{Name:ECL-2.0 Type:Other Percent:81.6793893129771 Start:161 End:10172 IsURL:false}

The text lacks ECL-2.0's preamble and its additional sentence in section 3.
                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.

      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.

      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.

      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.

      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).

      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.

      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."

      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.

   5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.

   6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.

   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

   9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.

   END OF TERMS AND CONDITIONS

I guess this would be fixed by #6.

I've reproduced this and will send a fix. I don't believe it is related to #6.

I take it back. This is fixed by #6 in the sense that #6 lets us remove removeCopyright and removeCopyright is the root cause of this bug.

authors: dsymonds jba rsc

repo: google/licensecheck


text:
List of all possible color combinations / stylesheets

I know about the color wheel at http://www.getmdl.io/customize/ and I did some playing around on my own outside of it.
I discovered that setting primary and secondary colors to the same is apparently OK, although the color wheel does not allow picking/previewing this.
Examples:

teal-teal exists: https://storage.googleapis.com/code.getmdl.io/1.0.1/material.teal-teal.min.css even though it's not selectable via the color wheel

Primary teal is RGB(0,150,136)
Secondary teal is RGB(100,255,218)
so I guess it's good to go!

teal-brown does not exist: https://storage.googleapis.com/code.getmdl.io/1.0.1/material.teal-brown.min.css which makes sense since it's disallowed on the color wheel
brown-brown does not exist

I found https://github.com/google/material-design-lite/blob/master/docs/_assets/customizer.js#L74-78:
  var COLORS = ['Cyan', 'Teal', 'Green', 'Light Green', 'Lime',
                        'Yellow', 'Amber', 'Orange', 'Brown', 'Blue Grey',
                        'Grey', 'Deep Orange', 'Red', 'Pink', 'Purple',
                        'Deep Purple', 'Indigo', 'Blue', 'Light Blue'];
  var FORBIDDEN_ACCENTS = ['Blue Grey', 'Brown', 'Grey'];

But it wasn't clear to me, since Brown is allowed as secondary/accent if Orange is the primary.
If it helps, here's a list of all the existing / "valid" color combos for v1.0.1 CSS files, as of today:
teal-teal
teal-purple
teal-deep_purple
teal-deep_orange
teal-pink
teal-indigo
teal-red
teal-yellow
teal-blue
teal-green
teal-orange
teal-light_blue
teal-amber
teal-cyan
teal-light_green
teal-lime
purple-teal
purple-purple
purple-deep_purple
purple-deep_orange
purple-pink
purple-indigo
purple-red
purple-yellow
purple-blue
purple-green
purple-orange
purple-light_blue
purple-amber
purple-cyan
purple-light_green
purple-lime
deep_purple-teal
deep_purple-purple
deep_purple-deep_purple
deep_purple-deep_orange
deep_purple-pink
deep_purple-indigo
deep_purple-red
deep_purple-yellow
deep_purple-blue
deep_purple-green
deep_purple-orange
deep_purple-light_blue
deep_purple-amber
deep_purple-cyan
deep_purple-light_green
deep_purple-lime
deep_orange-teal
deep_orange-purple
deep_orange-deep_purple
deep_orange-deep_orange
deep_orange-pink
deep_orange-indigo
deep_orange-red
deep_orange-yellow
deep_orange-blue
deep_orange-green
deep_orange-orange
deep_orange-light_blue
deep_orange-amber
deep_orange-cyan
deep_orange-light_green
deep_orange-lime
pink-teal
pink-purple
pink-deep_purple
pink-deep_orange
pink-pink
pink-indigo
pink-red
pink-yellow
pink-blue
pink-green
pink-orange
pink-light_blue
pink-amber
pink-cyan
pink-light_green
pink-lime
indigo-teal
indigo-purple
indigo-deep_purple
indigo-deep_orange
indigo-pink
indigo-indigo
indigo-red
indigo-yellow
indigo-blue
indigo-green
indigo-orange
indigo-light_blue
indigo-amber
indigo-cyan
indigo-light_green
indigo-lime
blue_grey-teal
blue_grey-purple
blue_grey-deep_purple
blue_grey-deep_orange
blue_grey-pink
blue_grey-indigo
blue_grey-red
blue_grey-yellow
blue_grey-blue
blue_grey-green
blue_grey-orange
blue_grey-light_blue
blue_grey-amber
blue_grey-cyan
blue_grey-light_green
blue_grey-lime
red-teal
red-purple
red-deep_purple
red-deep_orange
red-pink
red-indigo
red-red
red-yellow
red-blue
red-green
red-orange
red-light_blue
red-amber
red-cyan
red-light_green
red-lime
yellow-teal
yellow-purple
yellow-deep_purple
yellow-deep_orange
yellow-pink
yellow-indigo
yellow-red
yellow-yellow
yellow-blue
yellow-green
yellow-orange
yellow-light_blue
yellow-amber
yellow-cyan
yellow-light_green
yellow-lime
blue-teal
blue-purple
blue-deep_purple
blue-deep_orange
blue-pink
blue-indigo
blue-red
blue-yellow
blue-blue
blue-green
blue-orange
blue-light_blue
blue-amber
blue-cyan
blue-light_green
blue-lime
green-teal
green-purple
green-deep_purple
green-deep_orange
green-pink
green-indigo
green-red
green-yellow
green-blue
green-green
green-orange
green-light_blue
green-amber
green-cyan
green-light_green
green-lime
brown-teal
brown-purple
brown-deep_purple
brown-deep_orange
brown-pink
brown-indigo
brown-red
brown-yellow
brown-blue
brown-green
brown-orange
brown-light_blue
brown-amber
brown-cyan
brown-light_green
brown-lime
grey-teal
grey-purple
grey-deep_purple
grey-deep_orange
grey-pink
grey-indigo
grey-red
grey-yellow
grey-blue
grey-green
grey-orange
grey-light_blue
grey-amber
grey-cyan
grey-light_green
grey-lime
orange-teal
orange-purple
orange-deep_purple
orange-deep_orange
orange-pink
orange-indigo
orange-red
orange-yellow
orange-blue
orange-green
orange-orange
orange-light_blue
orange-amber
orange-cyan
orange-light_green
orange-lime
light_blue-teal
light_blue-purple
light_blue-deep_purple
light_blue-deep_orange
light_blue-pink
light_blue-indigo
light_blue-red
light_blue-yellow
light_blue-blue
light_blue-green
light_blue-orange
light_blue-light_blue
light_blue-amber
light_blue-cyan
light_blue-light_green
light_blue-lime
amber-teal
amber-purple
amber-deep_purple
amber-deep_orange
amber-pink
amber-indigo
amber-red
amber-yellow
amber-blue
amber-green
amber-orange
amber-light_blue
amber-amber
amber-cyan
amber-light_green
amber-lime
cyan-teal
cyan-purple
cyan-deep_purple
cyan-deep_orange
cyan-pink
cyan-indigo
cyan-red
cyan-yellow
cyan-blue
cyan-green
cyan-orange
cyan-light_blue
cyan-amber
cyan-cyan
cyan-light_green
cyan-lime
light_green-teal
light_green-purple
light_green-deep_purple
light_green-deep_orange
light_green-pink
light_green-indigo
light_green-red
light_green-yellow
light_green-blue
light_green-green
light_green-orange
light_green-light_blue
light_green-amber
light_green-cyan
light_green-light_green
light_green-lime
lime-teal
lime-purple
lime-deep_purple
lime-deep_orange
lime-pink
lime-indigo
lime-red
lime-yellow
lime-blue
lime-green
lime-orange
lime-light_blue
lime-amber
lime-cyan
lime-light_green
lime-lime

Please advise:

Is there a maintained whitelist of all existing color combinations? (Instead of me just testing for all possible files that exist)
What's up with teal-teal, purple-purple, etc? (I see they're valid CSS files but why not selectable on the color wheel if valid)?

teal-teal exists

It shouldn’t :smile: That’s a case I forgot to eliminate. AFAIK primary and accent color have to be distinct.

But it wasn't clear to me, since Brown is allowed as secondary/accent if Orange is the primary.

Where do you get that idea from?

Please advise:

Is there a maintained whitelist of all existing color combinations? (Instead of me just testing for all possible files that exist)

No, we don’t have an explicit list. The snippet you pasted actually says it best:
  var COLORS = ['Cyan', 'Teal', 'Green', 'Light Green', 'Lime',
                        'Yellow', 'Amber', 'Orange', 'Brown', 'Blue Grey',
                        'Grey', 'Deep Orange', 'Red', 'Pink', 'Purple',
                        'Deep Purple', 'Indigo', 'Blue', 'Light Blue'];
  var FORBIDDEN_ACCENTS = ['Blue Grey', 'Brown', 'Grey'];

Choose two colors from COLORS, although the second color cannot be any color in FORIBDDEN_ACCENTS and they must be distinct.
HTH

But it wasn't clear to me, since Brown is allowed as secondary/accent if Orange is the primary.

Um, not sure now. Maybe color picker allowed it before? Disregard now.
The picker at http://www.getmdl.io/customize/ now does follow the var COLORS and var FORBIDDEN_ACCENTS and everything makes more sense now.
However, https://storage.googleapis.com/code.getmdl.io/1.0.1/material.teal-teal.min.css still exists. Will that be deleted or will it just not exist for v1.0.2 and future versions?
Thanks.

@cliffordp What exists now, exists. We can't remove it. The changes will take effect with the next version push.

:+1:

Now I’m really curious if people have been downloading the unofficial color combinations.

FYI just for my own curiosity and to share...
There are 240 "valid" color combinations (listed below):
[304 actually exist for v1.0.1, as previously discussed]
teal-purple
teal-deep_purple
teal-deep_orange
teal-pink
teal-indigo
teal-red
teal-yellow
teal-blue
teal-green
teal-orange
teal-light_blue
teal-amber
teal-cyan
teal-light_green
teal-lime
purple-teal
purple-deep_purple
purple-deep_orange
purple-pink
purple-indigo
purple-red
purple-yellow
purple-blue
purple-green
purple-orange
purple-light_blue
purple-amber
purple-cyan
purple-light_green
purple-lime
deep_purple-teal
deep_purple-purple
deep_purple-deep_orange
deep_purple-pink
deep_purple-indigo
deep_purple-red
deep_purple-yellow
deep_purple-blue
deep_purple-green
deep_purple-orange
deep_purple-light_blue
deep_purple-amber
deep_purple-cyan
deep_purple-light_green
deep_purple-lime
deep_orange-teal
deep_orange-purple
deep_orange-deep_purple
deep_orange-pink
deep_orange-indigo
deep_orange-red
deep_orange-yellow
deep_orange-blue
deep_orange-green
deep_orange-orange
deep_orange-light_blue
deep_orange-amber
deep_orange-cyan
deep_orange-light_green
deep_orange-lime
pink-teal
pink-purple
pink-deep_purple
pink-deep_orange
pink-indigo
pink-red
pink-yellow
pink-blue
pink-green
pink-orange
pink-light_blue
pink-amber
pink-cyan
pink-light_green
pink-lime
indigo-teal
indigo-purple
indigo-deep_purple
indigo-deep_orange
indigo-pink
indigo-red
indigo-yellow
indigo-blue
indigo-green
indigo-orange
indigo-light_blue
indigo-amber
indigo-cyan
indigo-light_green
indigo-lime
red-teal
red-purple
red-deep_purple
red-deep_orange
red-pink
red-indigo
red-yellow
red-blue
red-green
red-orange
red-light_blue
red-amber
red-cyan
red-light_green
red-lime
yellow-teal
yellow-purple
yellow-deep_purple
yellow-deep_orange
yellow-pink
yellow-indigo
yellow-red
yellow-blue
yellow-green
yellow-orange
yellow-light_blue
yellow-amber
yellow-cyan
yellow-light_green
yellow-lime
blue-teal
blue-purple
blue-deep_purple
blue-deep_orange
blue-pink
blue-indigo
blue-red
blue-yellow
blue-green
blue-orange
blue-light_blue
blue-amber
blue-cyan
blue-light_green
blue-lime
green-teal
green-purple
green-deep_purple
green-deep_orange
green-pink
green-indigo
green-red
green-yellow
green-blue
green-orange
green-light_blue
green-amber
green-cyan
green-light_green
green-lime
orange-teal
orange-purple
orange-deep_purple
orange-deep_orange
orange-pink
orange-indigo
orange-red
orange-yellow
orange-blue
orange-green
orange-light_blue
orange-amber
orange-cyan
orange-light_green
orange-lime
light_blue-teal
light_blue-purple
light_blue-deep_purple
light_blue-deep_orange
light_blue-pink
light_blue-indigo
light_blue-red
light_blue-yellow
light_blue-blue
light_blue-green
light_blue-orange
light_blue-amber
light_blue-cyan
light_blue-light_green
light_blue-lime
amber-teal
amber-purple
amber-deep_purple
amber-deep_orange
amber-pink
amber-indigo
amber-red
amber-yellow
amber-blue
amber-green
amber-orange
amber-light_blue
amber-cyan
amber-light_green
amber-lime
cyan-teal
cyan-purple
cyan-deep_purple
cyan-deep_orange
cyan-pink
cyan-indigo
cyan-red
cyan-yellow
cyan-blue
cyan-green
cyan-orange
cyan-light_blue
cyan-amber
cyan-light_green
cyan-lime
light_green-teal
light_green-purple
light_green-deep_purple
light_green-deep_orange
light_green-pink
light_green-indigo
light_green-red
light_green-yellow
light_green-blue
light_green-green
light_green-orange
light_green-light_blue
light_green-amber
light_green-cyan
light_green-lime
lime-teal
lime-purple
lime-deep_purple
lime-deep_orange
lime-pink
lime-indigo
lime-red
lime-yellow
lime-blue
lime-green
lime-orange
lime-light_blue
lime-amber
lime-cyan
lime-light_green

I'm not really understanding, does this all mean that for example indigo-blue_grey is forbidden or discouraged in the material design spec?
If not why is this not available in the customizer at https://getmdl.io/customize/index.html ?
Please advise, because this would actually be the perfect combo for our brand.

What would make you think indigo-blue_grey is forbidden?

because https://code.getmdl.io/1.3.0/material.indigo-blue_grey.min.css is 404
whereas e.g.  https://code.getmdl.io/1.3.0/material.indigo-blue_grey.min.css is not

That's an odd one. Not sure exactly why it isn't allowed. Could be something the spec doesn't allow or could be a bug in the contrast math happening.
You can always download and build your own version from the source with the colors you want.

Well, it can only either be a bug or the spec.. I posted on this thread with the hopes of narrowing down which of these two it is so that if it is the former then we can open an issue for it.

MDL is no longer being maintained by the core team so much. We are focusing on Material Components for Web (previously MDLv2) and MDL is primarily up to community members to handle at this point.
A color combination, possible bug, with the color picker is a non-critical issue. If someone really wants it, they can do a manual build with the colors. I have a feeling the a11y contrast is the problem here and that is why it is a discouraged color setup.
Remember, in reality you can use whatever colors you want. The palettes provided are just examples build to work well together in most cases.

thanks for pointing me to Material Components. I was unaware. appreciate it

Is there a link to find out more about Material Components for Web (previously MDLv2) ?

https://github.com/material-components/material-components-web or you could have just searched Google for the name.

Javascript array
var COLORS=["teal-purple","teal-deep_purple","teal-deep_orange","teal-pink","teal-indigo","teal-red","teal-yellow","teal-blue","teal-green","teal-orange","teal-light_blue","teal-amber","teal-cyan","teal-light_green","teal-lime","purple-teal","purple-deep_purple","purple-deep_orange","purple-pink","purple-indigo","purple-red","purple-yellow","purple-blue","purple-green","purple-orange","purple-light_blue","purple-amber","purple-cyan","purple-light_green","purple-lime","deep_purple-teal","deep_purple-purple","deep_purple-deep_orange","deep_purple-pink","deep_purple-indigo","deep_purple-red","deep_purple-yellow","deep_purple-blue","deep_purple-green","deep_purple-orange","deep_purple-light_blue","deep_purple-amber","deep_purple-cyan","deep_purple-light_green","deep_purple-lime","deep_orange-teal","deep_orange-purple","deep_orange-deep_purple","deep_orange-pink","deep_orange-indigo","deep_orange-red","deep_orange-yellow","deep_orange-blue","deep_orange-green","deep_orange-orange","deep_orange-light_blue","deep_orange-amber","deep_orange-cyan","deep_orange-light_green","deep_orange-lime","pink-teal","pink-purple","pink-deep_purple","pink-deep_orange","pink-indigo","pink-red","pink-yellow","pink-blue","pink-green","pink-orange","pink-light_blue","pink-amber","pink-cyan","pink-light_green","pink-lime","indigo-teal","indigo-purple","indigo-deep_purple","indigo-deep_orange","indigo-pink","indigo-red","indigo-yellow","indigo-blue","indigo-green","indigo-orange","indigo-light_blue","indigo-amber","indigo-cyan","indigo-light_green","indigo-lime","red-teal","red-purple","red-deep_purple","red-deep_orange","red-pink","red-indigo","red-yellow","red-blue","red-green","red-orange","red-light_blue","red-amber","red-cyan","red-light_green","red-lime","yellow-teal","yellow-purple","yellow-deep_purple","yellow-deep_orange","yellow-pink","yellow-indigo","yellow-red","yellow-blue","yellow-green","yellow-orange","yellow-light_blue","yellow-amber","yellow-cyan","yellow-light_green","yellow-lime","blue-teal","blue-purple","blue-deep_purple","blue-deep_orange","blue-pink","blue-indigo","blue-red","blue-yellow","blue-green","blue-orange","blue-light_blue","blue-amber","blue-cyan","blue-light_green","blue-lime","green-teal","green-purple","green-deep_purple","green-deep_orange","green-pink","green-indigo","green-red","green-yellow","green-blue","green-orange","green-light_blue","green-amber","green-cyan","green-light_green","green-lime","orange-teal","orange-purple","orange-deep_purple","orange-deep_orange","orange-pink","orange-indigo","orange-red","orange-yellow","orange-blue","orange-green","orange-light_blue","orange-amber","orange-cyan","orange-light_green","orange-lime","light_blue-teal","light_blue-purple","light_blue-deep_purple","light_blue-deep_orange","light_blue-pink","light_blue-indigo","light_blue-red","light_blue-yellow","light_blue-blue","light_blue-green","light_blue-orange","light_blue-amber","light_blue-cyan","light_blue-light_green","light_blue-lime","amber-teal","amber-purple","amber-deep_purple","amber-deep_orange","amber-pink","amber-indigo","amber-red","amber-yellow","amber-blue","amber-green","amber-orange","amber-light_blue","amber-cyan","amber-light_green","amber-lime","cyan-teal","cyan-purple","cyan-deep_purple","cyan-deep_orange","cyan-pink","cyan-indigo","cyan-red","cyan-yellow","cyan-blue","cyan-green","cyan-orange","cyan-light_blue","cyan-amber","cyan-light_green","cyan-lime","light_green-teal","light_green-purple","light_green-deep_purple","light_green-deep_orange","light_green-pink","light_green-indigo","light_green-red","light_green-yellow","light_green-blue","light_green-green","light_green-orange","light_green-light_blue","light_green-amber","light_green-cyan","light_green-lime","lime-teal","lime-purple","lime-deep_purple","lime-deep_orange","lime-pink","lime-indigo","lime-red","lime-yellow","lime-blue","lime-green","lime-orange","lime-light_blue","lime-amber","lime-cyan","lime-light_green"];

authors: Garbee cliffordp mandadimuralidharreddy somombo surma

repo: google/material-design-lite


text:
Support non Latin script fonts

Please add support for non Latin script fonts (Noto Sans), with a mechanism to change the script font based on user selection.
Is this a new component, or a missing feature in an existing one?
This is a missing feature in Typography.
Material Design spec URL for the component (if any):
https://www.google.com/design/spec/style/typography.html. Material design recommends Noto Sans for non Latin script fonts.
What does this component or feature allow you to do which isn’t possible at the moment?
When built, it will allow serving locales using non Latin scripts. Currently, it is not possible to use non Latin script fonts. The file at src/typography/_typography.scss supports only Latin script fonts (Roboto et al).
Please provide any URLs or screenshots of good examples of usage of this component or feature that you may have come across.
A typical use case would be a global site serving multiple locales. For example, support.google.com with its support for multiple locales via a dropdown selection.
There is some "super early" work (author's own words) at #1435. We would appreciate a robust solution.

This is an still ongoing effort, as you already found out yourself. I’m sorry we haven’t shown any progress here, but we are working on it and it’s on the roadmap for sure :)
Closing this in favor of #1435.

Thank you @surma for sharing that. And please don't apologize - we are thankful to the entire team for all your help in this gargantuan effort.

Can we change our font stack from Roboto, Helvetica... to Roboto, Noto, Helvetica... ?
On https://developer.mozilla.org/en/docs/Web/CSS/font-family, the "Note" suggests that the browser selects the font on a per-glyph basis. So if the glyph is present in the first font in the font-family, the browser uses that font else the font family is further traversed till it finds the requisite glyph. I presume it displays a tofu in the default case.

Now, the material design spec (https://www.google.com/design/spec/style/typography.html) recommends the web font stack to be Roboto, Noto and then sans-serif. This is also implemented in Polymer (https://github.com/PolymerElements/paper-styles/blob/master/typography.html#L25). However, our font stack is 'Roboto', 'Helvetica', 'Arial', sans-serif !default (https://github.com/google/material-design-lite/blob/master/src/_variables.scss#L64-L65).
Let me know in case you want me to open a new issue for this request.

Would it be possible for us to tag #1435 onto a milestone?
I am requesting this in order to allow the effort to be tracked. In case this is being tracked internally, please disregard this request.

Can we change our font stack from Roboto, Helvetica... to Roboto, Noto, Helvetica... ?

Interesting suggestion. I like it. Not sure about the implications. @addyosmani @sgomes WDYT?

Would it be possible for us to tag #1435 onto a milestone?
I am requesting this in order to allow the effort to be tracked. In case this is being tracked internally, please disregard this request.

Not sure what you mean by being tracked here. You can follow the issue to get informed about updates.

@surma I don't think there would be any grave implications, but I'm not sure it's just enough to change the font stack. We'd likely have to import the font from Google Fonts as well, to have any hope of coverage across devices.

From my understanding of the "Note" on https://developer.mozilla.org/en/docs/Web/CSS/font-family, the addition of Noto font will cause the following behavior modification:

If there was a glyph which was earlier displayed using Helvetica or later fonts, it may now be displayed using Noto.
If there was a glyph which was earlier displayed as a tofu, it may now be displayed using Noto.

The first modification is expected. The second modification is where the change shines - it would allow non Latin script fonts to be displayed using Noto instead of being shown as tofu (no tofu = Noto).
Should MDL start loading Noto from Google fonts?
Not in this change. I assume that will be addressed by #1435 in the long term.
So how does this change help?
In the short term, the developer can load the appropriate script font from Google Fonts and escape tofu land. For example, if a developer wants to display Sanskrit text, he can load the Devanagari subset of Noto via Google Fonts () and the browser will display non-tofus.
In summary, the new stack provides the developer an opportunity to display non Latin script fonts. In the old stack, the developer is destined to the all-welcoming all-encompassing tofu land, even when the appropriate Noto font is web-loaded.

Not sure what you mean by being tracked here

I presume that if and when the issue is put on a milestone, its chances of witnessing progress increase by the virtue of it being part of the milestone. It may not make the milestone and may get re-tagged to future releases, but it will be tracked by the project (unless it goes WontFix). In either case, no sweat.

As far as issue tracking goes, everything is being "Tracked" if the issue remains open. We are simply prioritizing work on milestone assigned issues to try and hit the fixes for the given milestone. We don't tag to a milestone just to later put it off to another one. That is only done when necessary and the issue simply can't be resolved in a reasonable manner before the milestone lands.

authors: Brahmasmi Garbee sgomes surma


text:
Error creating uuu file using ObjParser

I'm trying to create a uuu file in objectron (object_detection_3d) using ObjParser. I tried to follow the documentation by writing the command:
bazel run -c opt mediapipe/graphs/object_detection_3d/obj_parser:ObjParser -- input_dir=[INTERMEDIATE_OUTPUT_DIR] output_dir=[OUTPUT_DIR]
But I get an error:
Error: Must provide input directory with --input_dir=
And if I change the command to something like this (removing the space between -- and input_dir=),
bazel run -c opt mediapipe/graphs/object_detection_3d/obj_parser:ObjParser --input_dir=[INTERMEDIATE_OUTPUT_DIR] output_dir=[OUTPUT_DIR]
I get an error message like this:
ERROR: --input_dir=/Users/bagus/mediapipe/output :: Unrecognized option: --input_dir=/Users/bagus/mediapipe/output

Hi @miftahulbagusp, Have you followed the steps mentioned over here

here

Yes, I followed the documentation that was there.

I tried to build from Java successfully, only error when build from bazel.

I tried to build from Java successfully, only error when build from bazel.
@miftahulbagusp
Can you list the command used for building directly via Java.

I tried to build from Java successfully, only error when build from bazel.
@miftahulbagusp
Can you list the command used for building directly via Java.

javac ObjParserMain.java
java ObjParserMain --input_dir=[INTERMEDIATE_OUTPUT_DIR] --output_dir=[OUTPUT_DIR]

If you use bazel run, which compiles then runs the app, you can pass the flags to the actual binary (not bazel) with --.
So it would look like bazel run  -- --input_dir=...

If you use bazel run, which compiles then runs the app, you can pass the flags to the actual binary (not bazel) with --.
So it would look like bazel run -- --input_dir=...

Thanks. It's worked well!

authors: Suraj520 ahmadyan miftahulbagusp sgowroji

repo: google/mediapipe


text:
OpenGL backend: implement features needed for testing

PTAL this implements the missing features that were required to run some test on OpenGL. Note that the T->B copy implementation conflicts with the rowPitch PR as it doesn't do the rowPitch alignment for now.

CI failed because the jobs were cancelled on a single builder. Other builders pass, are you ok with merging this anyway?

Restarted the build on that builder.

Thanks for restarting the build! Landing this before the rowPitch patch because the rowPitch patch has a merge conflict for now.

repo: google/nxt-standalone


text:
Rust: Redundant Static Lifetime

Redundant static lifetime in consts.rs:9:30
Constants have by default a static lifetime.

Happy to address

repo: google/open-location-code


text:
usage of addDifferent method produce invalid model in CpSat

Hello,
I tried to formulate inequality in java and found method CpModel.addDifferent. Unfortunatelly usage of the method always lead to invalid model.
There's a small example with same result.
    CpModel cpModel = new CpModel();
    IntVar endVar = cpModel.newIntVar(0, 100, "end");
    cpModel.addDifferent(endVar, 50);

    CpSolver cpSolver = new CpSolver();
    cpSolver.getParameters().setLogSearchProgress(true);

    cpSolver.solveWithSolutionCallback(cpModel, new CpSolverSolutionCallback()
    {
        @Override
        public void onSolutionCallback()
        {
            System.out.println("solution found");
        }
    });

and there's a result
Parameters: log_search_progress: true
Invalid domain in constraint #0 : linear { vars: 0 coeffs: 1 domain: 0 domain: 49 domain: 51 domain: -1 }
CpSolverResponse:
status: MODEL_INVALID
objective: NA
best_bound: NA
booleans: 0
conflicts: 0
branches: 0
propagations: 0
integer_propagations: 0
walltime: 0
usertime: 0
deterministic_time: 0

Sounds like a duplicate of #1448

Thanks.
Issues are close, but different methods are used and my case is produced invalid model so I get no valid or invalid solutions :-)

Can you print the proto ?
model.build().toString() ?
I suppose this is the same issue.
Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53
00
Le mar. 30 juil. 2019 à 08:23, gregy4 notifications@github.com a écrit :

Thanks.
Issues are close, but different methods are used and my case is produced
invalid model so I get no valid or invalid solutions :-)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/or-tools/issues/1464?email_source=notifications&email_token=ACUPL3PAJ5C2YQBBULRE4HLQCBMG5A5CNFSM4IH5NLK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3EK2DY#issuecomment-516467983,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACUPL3JXLH5XNCA5ADAI3BDQCBMG5ANCNFSM4IH5NLKQ
.

variables {
name: "end"
domain: 0
domain: 100
}
constraints {
linear {
vars: 0
coeffs: 1
domain: 0
domain: 49
domain: 51
domain: -1
}
}

yep, same bug.
Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53
00
Le mar. 30 juil. 2019 à 13:24, gregy4 notifications@github.com a écrit :

variables {
name: "end"
domain: 0
domain: 100
}
constraints {
linear {
vars: 0
coeffs: 1
domain: 0
domain: 49
domain: 51
domain: -1
}
}
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/or-tools/issues/1464?email_source=notifications&email_token=ACUPL3PB2AB4YP5FLW3RY2DQCCPOLA5CNFSM4IH5NLK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3FGPTQ#issuecomment-516581326,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACUPL3NCBL7WX4DLYGE6KK3QCCPOLANCNFSM4IH5NLKQ
.

repo: google/or-tools