text:
[devtools] What's New In DevTools (Chrome 87)

Target Live Date: 2020-10-01

[x] This has been reviewed and approved by (@chybie )
[x] I have run npm test locally and all tests pass.
[x] I have added the appropriate type-something label.
[x] I've staged the site and manually verified that my content displays correctly.

CC: @petele

Whoops!
There were 27 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/updates/2020/10/devtools.md#L224 - Consider adding a "was this page helpful?" widget to your page: https://developers.google.com/web/resources/widgets#helpful
src/content/en/updates/2020/10/devtools.md#L24 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L26 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L35 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L41 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L43 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L45 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L52 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L54 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L58 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L73 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L85 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L87 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L96 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L103 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L108 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L117 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L131 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L143 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L147 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L160 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L169 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L186 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L191 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L195 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L204 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L209 - Line must be at most 100 characters

Whoops!
There were 43 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/updates/2020/10/devtools.md#L7 - Unknown tag 'chrome7' found, use an existing tag, or add it to 'src/data/commonTags.json'.
src/content/en/updates/2020/10/devtools.md#L224 - Consider adding a "was this page helpful?" widget to your page: https://developers.google.com/web/resources/widgets#helpful
src/content/en/updates/2020/10/devtools.md#L24 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L26 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L35 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L41 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L43 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L45 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L52 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L54 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L58 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L73 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L85 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L87 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L96 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L103 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L108 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L117 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L131 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L143 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L147 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L160 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L169 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L186 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L191 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L195 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L204 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L209 - Line must be at most 100 characters
src/content/en/updates/_shared/discover.md#L313 - Consider adding a "was this page helpful?" widget to your page: https://developers.google.com/web/resources/widgets#helpful
src/content/en/updates/_shared/discover.md#L28 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/updates/_shared/discover.md#L45 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/updates/_shared/discover.md#L23 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L23 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L159 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L184 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L185 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L192 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L193 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L197 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L203 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L203 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L30 - Common typo found: 'Service Worker' Should it be 'service worker'? Capitalize Service if it's the first word in the sentence.
src/content/en/updates/_shared/discover.md#L167 - Line must be at most 100 characters

Whoops!
There were 42 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/updates/2020/10/devtools.md#L7 - Unknown tag 'chrome7' found, use an existing tag, or add it to 'src/data/commonTags.json'.
src/content/en/updates/2020/10/devtools.md#L220 - Consider adding a "was this page helpful?" widget to your page: https://developers.google.com/web/resources/widgets#helpful
src/content/en/updates/2020/10/devtools.md#L24 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L26 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L35 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L41 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L43 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L45 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L52 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L54 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L58 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L73 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L85 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L87 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L96 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L104 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L113 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L127 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L139 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L143 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L156 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L165 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L182 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L187 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L191 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L200 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L205 - Line must be at most 100 characters
src/content/en/updates/_shared/discover.md#L313 - Consider adding a "was this page helpful?" widget to your page: https://developers.google.com/web/resources/widgets#helpful
src/content/en/updates/_shared/discover.md#L28 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/updates/_shared/discover.md#L45 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/updates/_shared/discover.md#L23 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L23 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L159 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L184 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L185 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L192 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L193 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L197 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L203 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L203 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L30 - Common typo found: 'Service Worker' Should it be 'service worker'? Capitalize Service if it's the first word in the sentence.
src/content/en/updates/_shared/discover.md#L167 - Line must be at most 100 characters

Whoops!
There were 43 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/updates/2020/10/devtools.md#L7 - Unknown tag 'chrome7' found, use an existing tag, or add it to 'src/data/commonTags.json'.
src/content/en/updates/2020/10/devtools.md#L220 - Consider adding a "was this page helpful?" widget to your page: https://developers.google.com/web/resources/widgets#helpful
src/content/en/updates/2020/10/devtools.md#L24 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L26 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L35 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L41 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L43 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L45 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L52 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L54 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L58 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L73 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L85 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L87 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L96 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L104 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L113 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L127 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L139 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L143 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L156 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L165 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L182 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L187 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L191 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L200 - Line must be at most 100 characters
src/content/en/updates/2020/10/devtools.md#L205 - Line must be at most 100 characters
src/content/en/updates/_shared/discover.md#L313 - Consider adding a "was this page helpful?" widget to your page: https://developers.google.com/web/resources/widgets#helpful
src/content/en/updates/_shared/discover.md#L28 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/updates/_shared/discover.md#L45 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/updates/_shared/discover.md#L23 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L23 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L159 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L184 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L185 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L192 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L193 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L197 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L203 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L203 - Common typo found: 'node' Should it be 'Node'?
src/content/en/updates/_shared/discover.md#L30 - Common typo found: 'Service Worker' Should it be 'service worker'? Capitalize Service if it's the first word in the sentence.
src/content/en/updates/_shared/discover.md#L167 - Line must be at most 100 characters
src/content/en/updates/images/2020/10/devtools/07-lighthouse.png - Try to keep files below 500K, was 713K

authors: WebFundBot chybie


text:
Need aarch64 release, for both macOS and Linux

Is your feature request related to a problem? Please describe.
There is no release for aarch64 architecture
Describe the solution you'd like
Please release a package which is compiled for aarch64 architecture specially for linux (debian, arch). am64 releases includes binary plugins for IDA Pro, so they are also in amd64 release.

Note that the existing macOS package is a universal build that includes both AArch64 and AMD64 support. This is true for the IDA Pro plugins, the Binary Ninja plugins and the command-line differ.
For Linux, we can definitely build a version for AArch64, but to my knowledge, there is no version of IDA Pro that supports this natively. The situation is similar on Windows on ARM.

After installing font-robot on my linux aarch system, I can install the deb package with dpkg -i command.

no problem on bindiff itself
works on ghidra

as you also mentioned no ida on aarch system/
close #33

source: gharchive/issue

authors: blue-devil cblichmann

repo: google/bindiff

license_type: permissive

license_source: github-api


text:
Aspect Ratio not taken into account

I have tried with aspectRatio="1:1" but nothing change.

Because it is not one of the supported aspect ratios. We will figure out how to deliver errors properly. For now, please make sure to use CameraView#getSupportedAspectRatios before setting an aspect ratio.

@yaraki so if we always want our camera view to be a square but the camera doesn't support a 1:1 ratio, what's your recommended way to achieve this?

I'll investigate.

Couldn't you just put the CameraView inside a square parent? Something like this:
public class SquareRelativeLayout extends RelativeLayout {

    public SquareRelativeLayout(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
        super.onMeasure(heightMeasureSpec , heightMeasureSpec );
    }
}

That will crop the CameraView to square size, but the taken pictures will not be square.
This is a combination of 2 issues. I'm working on a fix.

Aspect Ratio is not working properly.
Nexus 5X reports 1:1 ratio as one of the supported picture format, but the preview crashes with SurfaceView.

@yaraki Do you have any update on this ?

Not yet. I'm working on it.

I added aspect ratio choice in the demo app. Also, setAspectRatio now works after layout. I still need to fix the issue with 1:1 on N5x and such.

Nexus 6P, Android Nougat, 1:1 aspect ratio is ignored

I get the same issue with nexus 5x android nougat/O. can't get a 1:1 setting it with a setAspectRatio call after layout. Is there an update to this problem?

I had the same issue and basically you need to set the aspect ratio after the camera has been initialized in this function
            = new CameraView.Callback() {

        @Override
        public void onCameraOpened(CameraView cameraView) {
            Set s = mCameraView.getSupportedAspectRatios(); // This is just to make sure the set is not empty
            mCameraView.setAspectRatio(AspectRatio.of(1,1));
        }

Do you guys have a fix on the issue? Have white background appearing on my Nexus 5x running Android 8 on 16:9 preview. All other phone I tested running ok. Thanks.

could not achieve aspect ratio 1:1 on Nokia 6

Do you guys have a fix on the issue? Have white background appearing on my Nexus 5x running Android 8 on 16:9 preview. All other phone I tested running ok. Thanks.

Hey can you help me. i'm recording the video on full screen but when i preview this video it not plays in full screen why ?

authors: Himanshu507 bolein bunjix drottemberg iftekhar-ahmed ivacf jgarcia3327 nawinkhatiwada remq yaraki

repo: google/cameraview

license_source: bigquery


text:
cap-validator.appspot.com Error

after updated java 8
every time I try to valid the  atomfeed  or cap URL
will see
"ERROR | URL retriever"

Do you see this for all cap urls, or just those from the cap-validator.appspot.com?
When I upload a local file, the validator tool successfully validates the CAP.

This should now be fixed following https://github.com/google/cap-library/commit/707f0c4e8394eefe58e7f4f1a9b5c3904e61710f.
Please verify and close the issue. Thanks :)

thx. Brad

repo: google/cap-library


text:
Python: Implementation of Merkle tree in-memory.

Introduce a complete implementation of a full Merkle tree, in-memory.
It will be used for a reference implementation of 6962-bis.
In particular, the ability to generate inclusion proofs and consistency proofs
in Python was lacking. This class has these abilities.

@RJPercival PTAL.

My bad - seems like I haven't pushed newer commits that clean up the TODOs and you're reviewing an  old set of commits.
I'll ping this PR once it's updated.

@RJPercival PTAL at the updated PR.

PTAL - fixed all pylint/gpylint issues.

@RJPercival once your merge your PR that discovers tests I'll land this one.

It's probably best to mark your test as executable and update this PR, rather than waiting for #1347, as it's not playing too nicely with Travis.

source: gharchive/pull-request

authors: RJPercival eranmes

repo: google/certificate-transparency


text:
goog.ui.PopupMenu 'attach' method confusing parameter handling

This issue was imported from Closure Library's previous home at http://closure-library.googlecode.com
The link to the original issue is:
https://code.google.com/p/closure-library/issues/detail?id=542

I can't understand the issue.

authors: joeltine nanaze

repo: google/closure-library


text:
VarChecker produces null fix

Consider this class:
import com.google.common.io.ByteSource;
import java.io.IOException;
import java.io.InputStream;

final class Dummy {
    public void process(ByteSource byteSource) throws IOException {
        // Error is also triggered if `is` is redundantly declared `final`.
        try (InputStream is = byteSource.openStream()) {
            /* Do something. */
        }
    }
}

When running Error Prone with -XepPatchChecks:Var -XepPatchLocation:IN_PLACE, the following exception occurs:
/path/to/Dummy.java:8: error: An unhandled exception was thrown by the Error Prone static analysis plugin.
        try (InputStream is = byteSource.openStream()) {
                         ^
     Please report this at https://github.com/google/error-prone/issues/new and include the following:

     error-prone version: 2.0.18
     Stack Trace:
     java.lang.IllegalArgumentException: fix must not be null
  	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
  	at com.google.errorprone.matchers.Description$Builder.addFix(Description.java:192)
  	at com.google.errorprone.bugpatterns.VarChecker.handleLocalOrParam(VarChecker.java:94)
  	at com.google.errorprone.bugpatterns.VarChecker.matchVariable(VarChecker.java:72)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitVariable(ErrorProneScanner.java:1195)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitVariable(ErrorProneScanner.java:144)
  	at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:938)
  	at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:71)
  	at com.google.errorprone.scanner.Scanner.scan(Scanner.java:89)
  	at com.google.errorprone.scanner.Scanner.scan(Scanner.java:43)
  	at com.sun.source.util.TreeScanner.scan(TreeScanner.java:105)
  	at com.sun.source.util.TreeScanner.visitTry(TreeScanner.java:373)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitTry(ErrorProneScanner.java:1126)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitTry(ErrorProneScanner.java:144)
  	at com.sun.tools.javac.tree.JCTree$JCTry.accept(JCTree.java:1292)
  	at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:71)
  	at com.google.errorprone.scanner.Scanner.scan(Scanner.java:89)
  	at com.google.errorprone.scanner.Scanner.scan(Scanner.java:43)
  	at com.sun.source.util.TreeScanner.scan(TreeScanner.java:105)
  	at com.sun.source.util.TreeScanner.visitBlock(TreeScanner.java:248)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitBlock(ErrorProneScanner.java:575)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitBlock(ErrorProneScanner.java:144)
  	at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:996)
  	at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:71)
  	at com.google.errorprone.scanner.Scanner.scan(Scanner.java:89)
  	at com.google.errorprone.scanner.Scanner.scan(Scanner.java:43)
  	at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:90)
  	at com.sun.source.util.TreeScanner.visitMethod(TreeScanner.java:206)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitMethod(ErrorProneScanner.java:943)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitMethod(ErrorProneScanner.java:144)
  	at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:868)
  	at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:71)
  	at com.google.errorprone.scanner.Scanner.scan(Scanner.java:89)
  	at com.google.errorprone.scanner.Scanner.scan(Scanner.java:43)
  	at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:90)
  	at com.sun.source.util.TreeScanner.scan(TreeScanner.java:105)
  	at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:113)
  	at com.sun.source.util.TreeScanner.visitClass(TreeScanner.java:187)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitClass(ErrorProneScanner.java:635)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitClass(ErrorProneScanner.java:144)
  	at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:778)
  	at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:71)
  	at com.google.errorprone.scanner.Scanner.scan(Scanner.java:89)
  	at com.google.errorprone.scanner.Scanner.scan(Scanner.java:43)
  	at com.sun.source.util.TreeScanner.scan(TreeScanner.java:105)
  	at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:113)
  	at com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:144)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitCompilationUnit(ErrorProneScanner.java:650)
  	at com.google.errorprone.scanner.ErrorProneScanner.visitCompilationUnit(ErrorProneScanner.java:144)
  	at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:561)
  	at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:52)
  	at com.google.errorprone.scanner.Scanner.scan(Scanner.java:68)
  	at com.google.errorprone.scanner.ErrorProneScannerTransformer.apply(ErrorProneScannerTransformer.java:43)
  	at com.google.errorprone.ErrorProneAnalyzer.finished(ErrorProneAnalyzer.java:145)
  	at com.sun.tools.javac.api.MultiTaskListener.finished(MultiTaskListener.java:120)
  	at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1277)
  	at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1226)
  	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:840)
  	at com.sun.tools.javac.main.Main.compile(Main.java:257)
  	at com.google.errorprone.BaseErrorProneCompiler.run(BaseErrorProneCompiler.java:230)
  	at com.google.errorprone.BaseErrorProneCompiler.run(BaseErrorProneCompiler.java:108)
  	at com.google.errorprone.ErrorProneCompiler.run(ErrorProneCompiler.java:128)
  	at com.google.errorprone.ErrorProneCompiler.compile(ErrorProneCompiler.java:70)
  	at org.codehaus.plexus.compiler.javac.errorprone.JavacCompilerWithErrorProne$CompilerInvoker.compile(JavacCompilerWithErrorProne.java:219)
  	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  	at java.lang.reflect.Method.invoke(Method.java:498)
  	at org.codehaus.plexus.compiler.javac.errorprone.JavacCompilerWithErrorProne.performCompile(JavacCompilerWithErrorProne.java:91)
  	at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:943)
  	at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:137)
  	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
  	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
  	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
  	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
  	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
  	at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
  	at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
  	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
  	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  	at java.lang.Thread.run(Thread.java:745)

Oh man, I filed a duplicate of a ticket I created myself: #498. I need a memory upgrade.

repo: google/error-prone


text:
Clarify the text on signing the 'incremental files' and distributing public keys for this

The original text
"Sending a public key to devices to digitally sign the incremental files with a private key on the device."
was unclear, it somewhat implied that the mobile devices use the private key that's required for signing the "incremental files".

@googlebot I signed it!

/assign @mikehelmick

/approve

/lgtm
/approve

authors: mh- mikehelmick sethvargo

repo: google/exposure-notifications-server


text:
'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'

Is your feature request related to a problem? Please describe.
So I'm updating filament to the latest release (I got behind quite a lot), and now the static libraries don't link to my project anymore.
I suppose there were reasons for removing those md libs from the release  (to save space?) : does that mean I need to recompile all the binaries myself ?
Describe the solution you'd like
I think both md and mt versions of the libraries were useful. If my memory is correct, I'm also expecting the debug versions are needed too, because of some stl shenanigans with debug flags.
OS and backend
Windows

This has been fixed; you can find the latest Windows binaries under the 1.9.24 release.

authors: bejado teub

repo: google/filament


text:
glTF conformance: transmission roughness

It seems Filament is making the roughness artificially high on models with small transmission roughness values: https://modelviewer.dev/fidelity/#khronos-IridescentDishWithOlives

So that one's complicated. All the renderers are wrong, and in Filament we use an empirical scale factor to match cubemap and screenspace refraction (basically at infinity). There was a long discussion between @pixelflinger and I on the glTF Slack. We need the spec to be better defined here (other renderer under-estimate the roughness). Removing the empirical factor brings Filament closer to reference path tracing (which will be more blurry than three/babylon).

Ah, interesting! Sounds like a good discussion for the PBR Next call; anyone available at 9am on Mondays? Anyway, once dspbr-pt puts out a new release I can put in a ground truth to aid the discussion.

authors: elalish romainguy


text:
Flax linnen model init not working on parallelised code

Provide as much information as possible. At least, this should include a description of your issue and steps to reproduce the problem. If possible also provide a summary of what steps or workarounds you have already tried.
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Terminal in JupyterLab

Flax, jax, jaxlib versions (obtain with pip show flax jax jaxlib:
Name: flax
Version: 0.5.3
Summary: Flax: A neural network library for JAX designed for flexibility
Home-page: https://github.com/google/flax
Author: Flax team
Author-email: flax-dev@google.com
License: UNKNOWN
Location: /home/fernanda/.local/lib/python3.8/site-packages
Requires: jax, matplotlib, msgpack, numpy, optax, PyYAML, rich, tensorstore, typing-extensions
Required-by: orbax

Name: jax
Version: 0.4.6
Summary: Differentiate, compile, and transform Numpy code.
Home-page: https://github.com/google/jax
Author: JAX team
Author-email: jax-dev@google.com
License: Apache-2.0
Location: /home/fernanda/.local/lib/python3.8/site-packages
Requires: numpy, opt-einsum, scipy
Required-by: chex, diffrax, equinox, flax, optax, orbax, orbax-checkpoint, richmol
Name: jaxlib
Version: 0.4.6
Summary: XLA library for JAX
Home-page: https://github.com/google/jax
Author: JAX team
Author-email: jax-dev@google.com
License: Apache-2.0
Location: /home/fernanda/.local/lib/python3.8/site-packages
Requires: numpy, scipy
Required-by: chex, optax, orbax, orbax-checkpoint

Python version: 3.8

Problem you have encountered:
When using paralellisation with joblib Parallel, delayed, recently the code is unavailable to init the parameters of the NN model. Depending on the backend that I use it will give a bug error (using loky) or it will just get stuck ('multiprocessing').
This behaviour was not previously observed.
What you expected to happen:
Being able to initialise parameters as regularly.

For further looking, I have upgraded all the versions of jax, jaxlib, flax and Joblib and found that the error stills exits. The error message when I used loky is:
joblib.externals.loky.process_executor._RemoteTraceback:
"""
Traceback (most recent call last):
File "/home/fernanda/.local/lib/python3.8/site-packages/joblib/externals/loky/process_executor.py", line 391, in _process_worker
call_item = call_queue.get(block=True, timeout=timeout)
File "/gpfs/cfel/group/cmi/common/psi4/psi4conda/lib/python3.8/multiprocessing/queues.py", line 116, in get
return _ForkingPickler.loads(res)
File "/home/fernanda/.local/lib/python3.8/site-packages/joblib/externals/cloudpickle/cloudpickle.py", line 649, in subimport
import(name)
ModuleNotFoundError: No module named 'jax._src.interpreters'
"""

@afcorral-desy can you post this on the JAX repo? The error doesn't seem to be related specifically to Flax.

authors: afcorral-desy cgarciae

repo: google/flax


text:
FlexItem can not acces

Cannot access 'FlexItem': it is package-private in 'com.google.android.flexbox'
why do you named the demo package name same as the lib package name ?

Not sure if this library is still actively maintained, but opening up the visibility of FlexItem will improve the usage experience from Kotlin/Compose UI.

authors: saket sumincy

repo: google/flexbox-layout


text:
Broken link for codelab.in README

The link for codelab is not available.
https://github.com/google/fuzztest/blob/6d21a370df3c897c02922e5c7e53ff5fc4f273ee/README.md?plain=1#L62
I don't see doc/tutorial.md is ever uploaded. Do you want to link it to codelab/ instead?

+1
Link is broken

+1
link is broken

+1
link is broken

+1
link is broken

authors: ArthurSonzogni Changochen Zzhiter rmarinbe stonebrakert6

repo: google/fuzztest


text:
Updated ClassMD

I have updated the markdown file.

@michaelmoynihan

authors: Masomabayat rexionmars


text:
Save and Load a Keras NLP Tuned model

Hi,
I was following this tutorial
Link : https://colab.research.google.com/github/google/generative-ai-docs/blob/main/site/en/gemma/docs/lora_tuning.ipynb
Could please tell me as to how to save a fine tuned model to disk and load it back from Keras NLP?

gemma_lm.save_weights("/dir/model.weights.h5")
gemma_lm.preprocessor.tokenizer.save_assets("dir")

authors: RYangData msmmpts

repo: google/generative-ai-docs


text:
Nodejs _debugger stalls between reqContinue and on('break')

From @hankduan on March 3, 2015 6:50
There is an unusual stall between reqContinue and on('break') in node's debugger.
NOTE: this only occurs on node version 0.10.31 or above.
For example, given a program that is in a busy loop (with a break point inside the loop), I don't expect any delay between when I call continue and when my program hit the next break point. However, given such a program, when my program is paused (i.e. on break), if I wait x seconds to call continue, then it will take my program x seconds to hit the break point.
I'll clarify with a reduced case below:
Given the program below. All it does is busy loop.
process._debugProcess(process.pid);
var nodedebug = require('child_process').fork(__dirname + '/client.js', [5858]);
process.on('exit', function() {
  nodedebug.kill('SIGTERM');
});
// wait for debugger to attach

setInterval(function() {
  console.log('.'); // this is line 9
}, 100);

Now I write a client. This client will attach to the above busy loop program. Then, every n seconds, it will call continue, and measure how long it takes for the program to hit the next break point.
var repl = require('repl');
var baseDebugger = require('_debugger');

var client = new baseDebugger.Client();

var iteration = function () {
  timeout = Math.floor(Math.random() * 10)*1000;
  var time;
  client.once('break', function() {
    console.log("BREAK. waited " + (new Date().getTime() - time)/1000 + 's')
    iteration();
  });

  setTimeout(function() {
    client.reqContinue(function() {
      console.log("REQCONTINUE after " + timeout/1000 +'s')
      time = new Date().getTime()
    });
  }, timeout)

};

client.once('ready', function() {
  client.setBreakpoint({
    type: 'scriptRegExp',
    target: '.*infiniteloop\.js',
    line: 9
  }, function() {
    client.once('break', iteration);
  });
});

var host = 'localhost';
var port = 5858;
client.connect(port, host);

I would expect such program to break almost immediately with <200ms latency. However, this is not the case. It turns out that (except for the first break point) this program will take at least as much time as I waited to hit continue before it can break. (i.e. if I wait 5s to hit continue, it would wait another >5s before it would reach the break point).
Here's a sample output:
$ node ./infiniteloop.js
Hit SIGUSR1 - starting debugger agent.
debugger listening on port 5858
.
.
.
.
.
REQCONTINUE after 3s
.
BREAK. waited 0.007s
REQCONTINUE after 2s
.
BREAK. waited 2.117s
REQCONTINUE after 5s
.
BREAK. waited 5.109s
REQCONTINUE after 5s
.
BREAK. waited 5.109s
REQCONTINUE after 9s
.
BREAK. waited 9.115s
REQCONTINUE after 7s
.
BREAK. waited 7.116s
REQCONTINUE after 4s
.
BREAK. waited 4.109s
REQCONTINUE after 7s
.
BREAK. waited 7.11s
REQCONTINUE after 0s
.
BREAK. waited 0.064s
REQCONTINUE after 9s
.
BREAK. waited 9.111s
REQCONTINUE after 2s
.
BREAK. waited 2.107s
REQCONTINUE after 9s
.
BREAK. waited 9.115s
REQCONTINUE after 4s
.
BREAK. waited 4.107s

This is the output on my mac, and is the output that I'm expecting:
$ node infiniteloop.js
Hit SIGUSR1 - starting debugger agent.
debugger listening on port 5858
REQCONTINUE after 2s
.
BREAK. waited 0.007s
REQCONTINUE after 8s
.
BREAK. waited 0.103s
REQCONTINUE after 8s
.
BREAK. waited 0.1s
REQCONTINUE after 2s
.
BREAK. waited 0.101s
REQCONTINUE after 4s
.
BREAK. waited 0.102s
REQCONTINUE after 3s
.
BREAK. waited 0.102s
REQCONTINUE after 3s
.
BREAK. waited 0.102s

Copied from original issue: joyent/node#9319

This issue was moved to google/github-issue-mover#21

This issue was moved to google/github-issue-mover#22

This issue was moved to google/github-issue-mover#23

This issue was moved to google/github-issue-mover#24

repo: google/github-issue-mover


text:
use -host=loongarch64 compiler ok，when using libglog.a an undefined reference  error

[  0%] Linking CXX executable ../../../build/release/proto-bin/protoc-gen-insertions
/usr/bin/ld: ../../../thirdparty/glog-0.3.5.M.20181214/.libs/libglog.a(libglog_la-utilities.o): in function `.L70':
utilities.cc:(.text+0xa24): undefined reference to `_Uloongarch_getcontext'
/usr/bin/ld: utilities.cc:(.text+0xa40): undefined reference to `_ULloongarch_init_local'
/usr/bin/ld: ../../../thirdparty/glog-0.3.5.M.20181214/.libs/libglog.a(libglog_la-utilities.o): in function `.L78':
utilities.cc:(.text+0xae0): undefined reference to `_ULloongarch_get_reg'
/usr/bin/ld: ../../../thirdparty/glog-0.3.5.M.20181214/.libs/libglog.a(libglog_la-utilities.o): in function `.L76':
utilities.cc:(.text+0xb70): undefined reference to `_ULloongarch_step'
collect2: error: ld returned 1 exit status

According to your log, you seem to be using glog 0.3.5 which is over 6 years old. This release is no longer supported.
I suggest updating to version 0.6.0 before we can continue investigating. Please also provide the full CMake log.

According to your log, you seem to be using glog 0.3.5 which is over 6 years old. This release is no longer supported.
I suggest updating to version 0.6.0 before we can continue investigating. Please also provide the full CMake log.

Thank you very much for your response. I have used version 0.6.0 , but it had the same error. I want to know if the glog 0.6.0 support loongarch,  it seams no _ULloongarch_get_reg interface. This is the cmake command, and the compilation is successful. "CXX="${GCC_PATH}/bin/g++" LDFLAGS="-L$XCLOUD_HOME/thirdparty/boost-1.68.0/lib" CPPFLAGS="-I/thirdparty/boost-1.68.0/include/" LIBS="-lboost_system" ./configure --with-pic --with-gflags=${GFLAGS_INSTALL} CXXFLAGS="-std=c++11 -D_GLIBCXX_USE_CXX11_ABI=1" --host=loongarch64"

Please provide the full logs both for CMake configuration step and the compilation. Without this information it is not possible to determine why the issue occurs.

This is the cmake command, and the compilation is successful.
CXX="${GCC_PATH}/bin/g++" LDFLAGS="-L$XCLOUD_HOME/thirdparty/boost-1.68.0/lib" CPPFLAGS="-I/thirdparty/boost-1.68.0/include/" LIBS="-lboost_system" ./configure --with-pic --with-gflags=${GFLAGS_INSTALL} CXXFLAGS="-std=c++11 -D_GLIBCXX_USE_CXX11_ABI=1" --host=loongarch64`

This is not a CMake command-line but rather the command-line for unsupported autoconf builds.

@sergiud
build_glog.log
echo "build glog..."
cd $/XXX_HOME/thirdparty/glog-${XCLOUD_GLOG_VERSION}
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${/XXX_HOME}/thirdparty/boost-1.68.0/lib"
LDFLAGS=
CPPFLAGS=
LIBS=
CXXFLAGS=
if [ "${ESB}" = "loong" ]; then
GLOGVERSION=0.3.5
GFLAGS_INSTALL=//XXX_HOME/thirdparty/gflags-2.2.1/third-party-install
if ["${GLOGVERSION}" = "0.3.5"]; then
CXX="${GCC_PATH}/bin/g++" LDFLAGS="-L$/XXX_HOME/thirdparty/boost-1.68.0/lib" CPPFLAGS="-I$/XXX_HOME/thirdparty/boost-1.68.0/include/" LIBS="-lboost_system" ./configure --with-pic --with-gflags=${GFLAGS_INSTALL} CXXFLAGS="-std=c++11 -D_GLIBCXX_USE_CXX11_ABI=1" --build=loongarch64-kylin-linux-gnu --host=loongarch64
else
cmake
-DCMAKE_CXX_COMPILER="${GCC_PATH}/bin/g++"
-DCMAKE_EXE_LINKER_FLAGS="-L$/XXX_HOME/thirdparty/boost-1.68.0/lib"
-DCMAKE_CXX_FLAGS="-std=c++11 -D_GLIBCXX_USE_CXX11_ABI=1 -I$/XXX_HOME/thirdparty/boost-1.68.0/include/"
-DBoost_SYSTEM_LIBRARY="-lboost_system"
-DCMAKE_INSTALL_PREFIX=${GFLAGS_INSTALL}
-DCMAKE_POSITION_INDEPENDENT_CODE=ON
-DHOST_ARCH=loongarch64
-DBUILD_ARCH=loongarch64-kylin-linux-gnu
-S .
fi
SLES's gcc45-c++ is required for sse2 support (default is 4.3), but crashes
when building logging_unittest-logging_unittest.o. Telling it to uses the
stabs format for debugging symbols instead of dwarf exercises a different
code path to work around this issue.
cat > Makefile.gcc45sles_workaround <<EOF
logging_unittest-logging_unittest.o : CXXFLAGS= -gstabs -O2
EOF
cat Makefile >> Makefile.gcc45sles_workaround
mv Makefile.gcc45sles_workaround Makefile
make -j${CPU}
echo "build glog done"

Your glog is using autoconf which is no longer supported as previously explained. You need to use the latest glog version and build either using CMake or Bazel.

Your glog is using autoconf which is no longer supported as previously explained. You need to use the latest glog version and build either using CMake or Bazel.

i use following command, version 0.6.0, and obtained libglogtest.a .
cmake
-DCMAKE_CXX_COMPILER="${GCC_PATH}/bin/g++"
-DCMAKE_EXE_LINKER_FLAGS="-L$XXX_HOME/thirdparty/boost-1.68.0/lib"
-DCMAKE_CXX_FLAGS="-std=c++11 -D_GLIBCXX_USE_CXX11_ABI=1 -I$XXX_HOME/thirdparty/boost-1.68.0/include/"
-DBoost_SYSTEM_LIBRARY="-lboost_system"
-DCMAKE_PREFIX_PATH=${GFLAGS_INSTALL}
-DCMAKE_POSITION_INDEPENDENT_CODE=ON
-DHOST_ARCH=loongarch64
-DBUILD_ARCH=loongarch64-kylin-linux-gnu
-DBUILD_SHARED_LIBS=ON
.
when i use  nm libglogtest.a | grep _Uloongarch_getcontext , got                  U _Uloongarch_getcontext

Unfortunately, I don't see how that command-line can be used to compile glog. Some of the options such HOST_ARCH and BUILD_ARCH are unknown to glog. Also Boost is not a dependency of glog.
If you want to cross-compile glog using CMake you can use a CMake toolchain file. Once you've created one please configure glog using CMake and the toolchain file without specifying any additional options. Please attach the output both for

the CMake configuration and
the build step.

libglogtest.a is internal artifact you should not be using.

I have resolved the issue. The reason was that the system had an incompatible version of the libunwind library. After uninstalling this library, it worked fine.

authors: minguofeng sergiud

repo: google/glog


text:
Fix IndexError to TypeError

Supposed to fix IndexError to TypeError except int, long or with __index__ method.
Added passing None to start or end, which supposed to take as default values.
Note that sys.maxsize + 1 issue is not yet fixed.

@trotterdylan, I have read CPython source code of PySlice_GetIndicesEx, and _PyEval_SliceIndex,
and come up with new function sliceGetIndices, what do you think?
It pass all existing tests, including sys.maxsize + 1.
One coverage missing because I don't know how to write following in Go.
class Foo(object):
  def __index__(self):
    return 3

Instead of adding new functions, I have modified IndexInt and adjustIndex functions.
adjustIndex logic is basically copy from CPython
Coverage is still yet to be confirmed.

repo: google/grumpy


text:
Examples vs. syntax spec inconsistencies

Hi! I've recently been working on a Rust implementation for this, and found a few corner cases where the syntax from the README didn't match up with the examples:
The straightforwardest one is probably the duplicate-despite-quotes.hrx part of example/invalid/duplicates.hrx – it looks like (syntax says naught, #1) quotes are no longer specialcased?
The next one I ran into was duplicate-files.hrx from that same file – that archive should, according to the spec, (a) be valid and (b) contain <======> file\n.
I think so due to the following: contents is defined as "any sequence of characters that does not include U+000A LINE FEED followed immediately by boundary", and file as boundary " "+ path newline body?.
Now, given a buffer containing
<======> file
A      BCD  EF
<======> file

We can see, that the AB span matches boundary, C – the spaces, DE – path, and F – newline. What is left? To match the optional body, which consists of the following:
<======> file

Note, how this chunk doesn't start with U+000A LINE FEED, despite the line starting with boundary. This means, that the file contents continue until EOF.
The third mismatched example plagues example/empty-file.hrx. Assuming the same symbols as before, we get (after the first comment)
<===> file1
A   BCD   EF
<===>
So is this one.
<===> file2

thereby hitting the first LF+boundary sequence on the line declaring file2 (my parser returns {file1: {cmt: "This file is empty.", ctnt: "<===>\nSo is this one."}, file2: { cmt: null, ctnt: "" }}, which I feel is correct, going solely by the syntax?).
My hunch as to why these weren't noticed earlier is due to the usage of splitting parsers (e.g. in hrx.js and hrx.py), which probably handle these examples as expected.
I'd be more than happy to submit a PR addressing these issues, if deemed valid :)

I just want to be on the same page here with those other two parsers, just so I can catch any significant spec-violating they're doing. I tried to make them to be a bit more tolerant of mistakes.
So if I'm understanding correctly, this tends to show up on empty files. They're looking for a LF then a boundary to end the file, but there's no LF, there's just a boundary.
body is optional, however determining whether body is file contents or a continuation of the archive (in the case of empty files)
I feel that the spec should cover something such that a content block shouldn't begin with a boundary of the current size the parser is processing, which is probably why my parsers didn't catch it.

Good catches! They all seem right, and @rebeccajae is correct that the spec should forbid a contents production that starts with a boundary. I'll put out a fix.

authors: nabijaczleweli nex3 rebeccajae

repo: google/hrx


text:
Conversion from loop.parallel to gpu.launch

The lowering from loop.parallel to gpu.launch currently in MLIR core doesnt work out-of-the-box for IREE.  That needs to be adapted to work for IREE use case (or have custom lowering within IREE)
This is the thread that will dictate the work here :
https://llvm.discourse.group/t/understanding-parallel-loops-to-gpu-lowering/727

Implemented by commit c5d332c3eebc109c9aca1ea90c9dcc35100ffb9a

repo: google/iree


text:
C++ binding that wraps the C runtime API

bindings/cc/ should provide C++ wrappers for the C API that make working with it more natural (using std::string, vector, etc) and provide RAII safety. Could use abseil for all the things it provides (string view, span, etc) but try to limit it to only those types that are on the standards track/easy to substitute if a user wants. The nice thing about a C++/C/C++ sandwich is that we don't need API/ABI stability and have more leeway with respect to how we wrap things.
I'm not sure what namespace to put it in yet - iree would conflict with the main codebase. ireert perhaps?
This would then be the primary thing we use in most samples. There are places inside the main codebase that would be nicer to work with, however I'm not sure the iree/ <-> bindings/cc/ circular dependency is a good idea. Since the bindings would still be modularized like the C API (iree/base/api.h, iree/hal/api.h, etc) we can avoid real cycles, but the directory crossing could still be confusing. Probably still worth it though.

As an example, iree/vm/module_abi_cc.h could be moved to bindings/cc/ireert/vm/module.h. Modules implemented in C++, like iree/modules/hal/ and iree/modules/string/, could then depend on that file as they only need the C API as a bridge and don't reach directly into the core code.

I was thinking it'd also be nice to clean up the C API, possibly moving all of the api files to bindings/c/. Then the main iree/ source dir is all private, all of our public APIs are under bindings/, and I could split the files so they aren't all api.h :)

So a layout like this:
bindings/c/ <- current api.h files split up and better named
bindings/cc/ <- c++ bindings layered on top of bindings/c/
bindings/java/
bindings/python/ <- could layer on top of c++ or c bindings
iree/ <- core c++ source code (hal, vm, modules)

Again the tricky part is that some of the iree/ code will be using the C/C++ bindings. Maybe that calls for moving modules/ out to a sibling directory with bindings/ and iree/ to make that more clear? At some point iree/ just becomes the C++ HAL, C VM, and base/ with some utils.

Since the VM is already C it seems a shame to duplicate things, so if bindings/c/ existed it would likely just contain build system copied headers for the public VM files (like invocation.h, module.h, etc).

Priority of this is pretty low - we want to make it easier for us to iterate on the C API as we start plumbing through real uses and don't want additional (unused) bindings/ to slow that down.

Closing for now; one day maybe but there's still too much in flight for the maintenance burden to be worth it. Once we finish the python side we'd probably want to make the C++ side look similar instead of growing one from scratch with slightly different semantics.


text:
Initial commit: Add new iree_pydm dialect and supporting code to compile to it.

Short for "python data-model", which is the closest thing to an authoritative spec as exists.
Attempts to be a faithful modeling of Python (currently incomplete) which also has been engineered to be realized on the IREE VM.
Aim is for Python program extraction which can preserve full generality while also benefiting (greatly) from any present type information.
Trying to be a counter-balance to previous approaches which tended to make "not quite Python" uncanny valleys: it will be a while before this is complete but it attempts to model the dynamism of the language.
Inspired by my previous work on npcomp but a complete rewrite with lessons learned incorporated. Conceptually builds on the npcomp version in several key ways:

Models the Python type system with both generality and specialization in mind (npcomp required specialization just making a "not quite Python").
Leverages knowledge of the types and constraints of the IREE VM, paying attention to having an IR which should lower without much fuss.
Aims to be self-contained, not mixing and matching unrelated MLIR dialects and types (currently just incorporates parts of SCF and CFG operations).
More general Python importer bridge, with an interop model based on intrinsics and supporting a runtime library largely authored in the language itself.
Implements general flow control.

I am landing this here, as an IREE public dialect because:

It is already setup for other LLVM projects to take a source dep on it (allowing others to compile their Python DSLs to IREE). NPComp already does this.
This is the only place that also allows the IREE compiler to lower it to run on its VM.
It is already plumbed through to IREE's (new) public C and Python compiler API distributables.

There are three forks of work from here:

Finish modeling the dialect and importer (needs for/while support, type/op support for containers and iterators).
Implement first pass source dialect optimizations, namely type propagation, and simplification away from dynamic forms where possible.
Lowerings to IREE VM. The types and ops are laid out so that this can hopefully be a mostly 1:1, relatively simple lowering.

I expect getting everything to connect is roughly a week of coding on each category.

PTAL


text:
Update tensorflow and llvm submodules.

tensorflow -> head
llvm -> head (not tensorflow version because incompatible)
llvm bazel build files: imported from tensorflow and manually patched
adapted to new dialect registration scheme by adding calls to the registration method
all tests pass on my linux vm with bazel (sans Vulkan due to no graphics card)
will give cmake a shot in a minute but this has been a lot already and need to sign off

@stellaraccident I can take over and give CMake a try based on what you already did.

Thanks - I was just about to email you. I really need to sign off now but
was poking CMake a bit...
The primary thing that changed upstream is how they are doing dialect
registration. There is now an explicit mlir::registerAllDialects() in any
binary that needs them (from mlir/InitAllDialects.h). It looks like this is
an intermediate state, still doing static registration in some way that I
haven't untangled how to depend on properly from the CMake side. There is
an MLIRAllDialects target which is sufficient to get enough headers to
compile, but then linking fails.
One issue is that this new mechanism pulls in all MLIR dialects, whether we
need them or not, and it appears that the ones we weren't using are the
ones that then fail on link (FxpMathOps is one that jumps out and that I
clue in on). We will probably eventually want our own, properly scoped
list, but for now, just pulling them all in from upstream is better than
being broken (which the most recent integrate was causing). I think we just
need every binary to depend on the full set of dialects -- maybe a common
list somewhere so we can at least not repeat ourselves?
I'd really love to get the cmake version working again and stable so I can
use it as a main mechanism of developing... believe it or not, my CMake
builds are ~3-5x faster than corresponding Bazel builds and build the whole
project in about 2 minutes (CMake maxes out all 64 cores in my machine,
whereas Bazel rarely utilizes more than ~20). I feel like Bazel claimed to
have required all of the complex build machinery for parallelism... and
does not seem to deliver on local builds. I bet it is rare that big
projects have an apples to apples comparison of the same build on both
systems.
On Thu, Feb 13, 2020 at 10:32 PM Marius Brehler notifications@github.com
wrote:

@stellaraccident https://github.com/stellaraccident I can take over and
give CMake a try based on what you already did.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/iree/pull/762?email_source=notifications&email_token=AADYVAFYZQTYBGBDL3HDV6TRCY3IBA5CNFSM4KVBRTVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELXXNVA#issuecomment-586118868,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADYVAGSOGTO6DLOKAW3UIDRCY3IBANCNFSM4KVBRTVA
.

+Lei Zhang antiagainst@google.com who was oncall this week for MLIR
integration issues and may have more context on the static registration
stuff.
On Thu, Feb 13, 2020 at 10:50 PM Stella Laurenzo laurenzo@google.com
wrote:

Thanks - I was just about to email you. I really need to sign off now but
was poking CMake a bit...
The primary thing that changed upstream is how they are doing dialect
registration. There is now an explicit mlir::registerAllDialects() in any
binary that needs them (from mlir/InitAllDialects.h). It looks like this is
an intermediate state, still doing static registration in some way that I
haven't untangled how to depend on properly from the CMake side. There is
an MLIRAllDialects target which is sufficient to get enough headers to
compile, but then linking fails.
One issue is that this new mechanism pulls in all MLIR dialects, whether
we need them or not, and it appears that the ones we weren't using are the
ones that then fail on link (FxpMathOps is one that jumps out and that I
clue in on). We will probably eventually want our own, properly scoped
list, but for now, just pulling them all in from upstream is better than
being broken (which the most recent integrate was causing). I think we just
need every binary to depend on the full set of dialects -- maybe a common
list somewhere so we can at least not repeat ourselves?
I'd really love to get the cmake version working again and stable so I can
use it as a main mechanism of developing... believe it or not, my CMake
builds are ~3-5x faster than corresponding Bazel builds and build the whole
project in about 2 minutes (CMake maxes out all 64 cores in my machine,
whereas Bazel rarely utilizes more than ~20). I feel like Bazel claimed to
have required all of the complex build machinery for parallelism... and
does not seem to deliver on local builds. I bet it is rare that big
projects have an apples to apples comparison of the same build on both
systems.
On Thu, Feb 13, 2020 at 10:32 PM Marius Brehler notifications@github.com
wrote:

@stellaraccident https://github.com/stellaraccident I can take over
and give CMake a try based on what you already did.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/iree/pull/762?email_source=notifications&email_token=AADYVAFYZQTYBGBDL3HDV6TRCY3IBA5CNFSM4KVBRTVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELXXNVA#issuecomment-586118868,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADYVAGSOGTO6DLOKAW3UIDRCY3IBANCNFSM4KVBRTVA
.

Intermediate status:

Got a build working with all test passing, expect the tree also failing before.
168 - iree_tools_vm_util_test (Failed)
172 - iree_samples_custom_modules_custom_modules_test (Failed)
173 - iree_samples_simple_embedding_simple_embedding_test (Failed)
Further refactoring required with regard to ALWAYSLINK. The current configuration doubles the sizes of the executables (e.g. iree-opt).

I opened #763 as a follow up and to discuses my modifications. My branch might need rebasing (this and an earlier PR of mine are merged), but if you like feel free to take back over again.

I'd really love to get the cmake version working again and stable so I can use it as a main mechanism of developing... believe it or not, my CMake builds are ~3-5x faster than corresponding Bazel builds and build the whole project in about 2 minutes (CMake maxes out all 64 cores in my machine, whereas Bazel rarely utilizes more than ~20).

@oliverurbann We need a more powerfull build machine as well. My 16GB RAM are not sufficient to run six linker processes in parallel. It actually resulted in eating up nearly my whole swap and an unusable system. 64 cores and appropriate RAM sounds adequate ;)

Yeah right now we can rely on the gigantic initAllDialects and initAllPasses. In the future we will need distilled ones with explicit register*() in binaries like what is happening with
https://github.com/llvm/llvm-project/blob/b6a9fe209992789be3ed95664d25196361cfad34/mlir/tools/mlir-opt/mlir-opt.cpp#L81-L104

This needs some surgery upstream where we have stricter checks on depending on the rule that exports the headers you use.

Yeah right now we can rely on the gigantic initAllDialects and initAllPasses. In the future we will need distilled ones with explicit register*() in binaries like what is happening with
https://github.com/llvm/llvm-project/blob/b6a9fe209992789be3ed95664d25196361cfad34/mlir/tools/mlir-opt/mlir-opt.cpp#L81-L104

Would you propose to fork mlir-opt.cpp and maintain an IREE specific main entry function, like IREE's translate_main.cc replacing mlir-translate.cpp?

Sorry for the late reply. Yeah I think that makes sense. mlir-opt is for testing purpose in MLIR core so it's pulling in all core dialects/passes for that. TF has its own tf-opt. Right now our iree-opt does not control the main function but I think we should.

Okay, will go for it after I returned to the office from C4ML. I think I will send a PR latest end of the week.

authors: GMNGeoffrey antiagainst marbre stellaraccident


text:
Added the final check required 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

@googlebot I signed it!

@googlebot I signed it!

repo: google/it-cert-automation-practice


text:
Updated validations.py script

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

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

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

@googlebot I signed it!


text:
Updated validations.py python script.

Added check to make sure first character was a letter.
Closes: #1
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

I signed the CLA


text:
Commit para el test

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

Thanks for the course!


text:
Closes: #1 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

@googlebot I signed it


text:
array.ravel() takes orders of magnitude longer

After switching a function from Autograd to Jax, I found that it ran 10^3 times slower. I tried to isolate the reason for this slowdown, and it appears to be the ravel function.
NumPy - 1.7 microseconds
Autograd - 2.8 microseconds
Jax - 173 microseconds
See example:
https://drive.google.com/file/d/1mkzMPPqkX-x_bTkiLXGyXXKiquN93l9I/view?usp=sharing
Any idea how to fix this?

Thanks for digging into this, and making such a concise test.
My first thought was that this is a performance bug, but I decided I should poke at it a bit first!

Here's the python code for the test:
def test_func():
    result = np.ones((10, 10)).ravel()

import numpy as np
print('Running with NumPy:')
%timeit test_func()

import autograd.numpy as np
print('\nRunning with NumPy (Autograd):')
%timeit test_func()

import jax.numpy as np
print('\nRunning with Jax:')
%timeit test_func()

@greydanus and I talked a bit off-thread. I'll summarize here for posterity!
There are two things going on here: NumPy's ravel is really fast (because it doesn't even do a copy), and separately the dispatch overheads for the XLA client that JAX uses are currently really slow (like ~70us per call on my machine, compared to 0.5us for NumPy). There's no fundamental reason JAX couldn't do the just as well as NumPy in both of these cases (especially the latter), but these things haven't been optimized yet. (Contributions welcome!)
Those two effects work together to make the difference particularly stark in this test: we pair JAX's currently-slow dispatch with really fast-to-execute operations. If the operations took more time (like milliseconds to multiply large matrices) then the fixed-size overhead of ~70us wouldn't look so bad. But on small operations, it's really costly.
@greydanus explained that his workload involves a lot of small operations. So other than waiting for JAX's XLA client to lower dispatch overheads, or for the JAX team to implement reshape-without-copy, what can JAX do for workloads with lots of small operations?
One answer is jit! That ~70us dispatch cost is for any JIT-compiled operation, no matter its size. If you can use jit to compile a lot of your operations together, you still only have to pay that dispatch cost once. In fact, using jit will compile away all the Python and tracing overheads (e.g. for doing autodiff), reducing overheads further. And the biggest win of all is that it gives a chance for XLA to end-to-end optimize the code, which includes things like eliminating unnecessary copies.
Another answer is that if NumPy covers your use case well, maybe because you can't use jit and you don't need to run on accelerator hardware, consider sticking with Autograd. Luckily, switching back and forth should be pretty easy: all your NumPy and grad code can stay the same, and you just need to change the import statement at the top.
Finally, in addition to improving the overheads in the XLA client and reducing copies, there's one more avenue for getting JAX to be always-at-least-as-fast-as-Autograd on CPU: we have some ideas to get JAX to use NumPy (rather than XLA) on CPU when there's no JIT going on. That's still on the drawing board, though.
I'm going to close this issue for now because things are working as expected in this example, but we'll certainly keep improving JAX's dispatch performance.

Thanks for the thorough response, Matt. The long-horizon idea of getting JAX to use NumPy on CPU would be pretty awesome for my use case (eg. run 200+ debugging tests, scaled down experiments, etc. on CPU and then run 5 big jobs on GPU once everything is working)

authors: greydanus mattjj

repo: google/jax


text:
Fix check_is_flash_attention

layout is a literal, so it has to take value of AttentionLayout.BNTH. @kaixih  @Cjkkkk

how about we add a simple test to catch this?

authors: wenscarl zhangqiaorjc


text:
Make ingress use v1 instead of v1beta1

https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122

operator-sdk depends on k8s.io/api/auditregistration/v1alpha1 which was deleted https://github.com/kubernetes/kubernetes/pull/91502 as of https://v1-19.docs.kubernetes.io/docs/setup/release/notes/ v1.19 - looks like we need to upgrade the operator to v1

so we need the auditregistration/v1alpha1 package: https://pkg.go.dev/k8s.io/api/auditregistration/v1alpha1 which was last on v0.18.9 and the network/v1 package which was first on v0.19

https://sdk.operatorframework.io/docs/building-operators/golang/migration/

repo: google/kctf


text:
use automaxprocs to calculate the number of CPUs

this is  useful for container environments
Addresses: https://github.com/google/ko/issues/642

Related issue: https://github.com/golang/go/issues/33803

Essentially GOMAXPROCS is not cgroup aware so it reports the total CPUs on the machine instead of the # of CPUs allocated to the container

got the typo fixed upstream - force pushing the fix

Keep in mind that automaxprocs doesn't (yet) support cgroups v2 :)

authors: akshayjshah dprotaso

repo: google/ko


text:
How to Convert LandmarkProto.NormalizedLandmark into android screen pixel ..?

I want to know that how to convert LandmarkProto.NormalizedLandmark convert into android screen pixel, like now x and y landmark in coming in the range of [0..1]  but i want to convert it according to my screen size...?.
.
.

Hi @ni3-sharma, Could you please elaborate your issue with complete details. Thanks!

Hi @ni3-sharma, Could you please respond to my above comment. Thanks!

hello @sgowroji
sorry for the delay,
my point is that i am using this mediapipe hand tracking code in my android app and i got the points for the tracker that is in between 0 to 1 i just want to know about how to convert this normalize points according to android phone screen size.
Thanks!

Hi @ni3-sharma, You can make the changes from both android platform side and graph as you have coordinates with you (you get coordinates by multiplying the normalized landmark value with the height and width of the image).
If you are looking at graphs then you can refer here graph changes which you need to change as per  your requirement. Reach us back if you still have any quries on top of it. Thanks!

repo: google/mediapipe


text:
Mediapipe hand tracking build error on ubuntu20.04

I tried to build hand tracking on Ubuntu 20.04 and I got the following error:
DEBUG: Rule 'rules_foreign_cc' indicated that a canonical reproducible form can be obtained by modifying arguments sha256 = "c2cdcf55ffaf49366725639e45dedd449b8c3fe22b54e31625eb80ce3a240f1e"
DEBUG: Repository rules_foreign_cc instantiated at:
  /home/qwerty/mediapipe/WORKSPACE:42:13: in <toplevel>
Repository rule http_archive defined at:
  /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/bazel_tools/tools/build_defs/repo/http.bzl:336:31: in <toplevel>
DEBUG: /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/org_tensorflow/third_party/repo.bzl:108:14:
Warning: skipping import of repository 'com_google_absl' because it already exists.
DEBUG: /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/org_tensorflow/third_party/repo.bzl:108:14:
Warning: skipping import of repository 'com_google_protobuf' because it already exists.
DEBUG: /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/org_tensorflow/third_party/repo.bzl:108:14:
Warning: skipping import of repository 'com_google_googletest' because it already exists.
DEBUG: /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/org_tensorflow/third_party/repo.bzl:108:14:
Warning: skipping import of repository 'com_github_gflags_gflags' because it already exists.
DEBUG: /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/org_tensorflow/third_party/repo.bzl:108:14:
Warning: skipping import of repository 'build_bazel_rules_apple' because it already exists.
DEBUG: /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/org_tensorflow/third_party/repo.bzl:108:14:
Warning: skipping import of repository 'build_bazel_rules_swift' because it already exists.
DEBUG: /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/org_tensorflow/third_party/repo.bzl:108:14:
Warning: skipping import of repository 'build_bazel_apple_support' because it already exists.
DEBUG: /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/org_tensorflow/third_party/repo.bzl:108:14:
Warning: skipping import of repository 'bazel_skylib' because it already exists.
DEBUG: /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/org_tensorflow/third_party/repo.bzl:108:14:
Warning: skipping import of repository 'pybind11' because it already exists.
DEBUG: /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/tf_runtime/third_party/cuda/dependencies.bzl:51:10: The following command will download NVIDIA proprietary software. By using the software you agree to comply with the terms of the license agreement that accompanies the software. If you do not agree to the terms of the license agreement, do not use the software.
INFO: Build option --action_env has changed, discarding analysis cache.
DEBUG: Rule 'rules_cc' indicated that a canonical reproducible form can be obtained by modifying arguments sha256 = "02413e4a077107711ecc21458432e7c9ba63e75e63f3fa84ae4da2d6b2c82700"
DEBUG: Repository rules_cc instantiated at:
  /home/qwerty/mediapipe/WORKSPACE:36:13: in <toplevel>
Repository rule http_archive defined at:
  /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/bazel_tools/tools/build_defs/repo/http.bzl:336:31: in <toplevel>
INFO: Analyzed target //mediapipe/examples/desktop/hand_tracking:hand_tracking_cpu (123 packages loaded, 6397 targets configured).
INFO: Found 1 target...
INFO: From ProtoCompile mediapipe/calculators/video/opencv_video_encoder_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/annotation_overlay_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/framework/calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/rect_transformation_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/non_max_suppression_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/thresholding_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/tensors_to_floats_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/landmark_projection_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/framework/tool/calculator_graph_template.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/tensors_to_classification_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/tensors_to_landmarks_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/inference_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/core/split_vector_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tflite/tflite_custom_op_resolver_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/framework/calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/framework/calculator_profile.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/core/split_vector_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/framework/tool/calculator_graph_template.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/tensors_to_detections_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/internal/callback_packet_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/framework/calculator_profile.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/rect_transformation_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/rect_to_render_data_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/landmarks_to_render_data_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/labels_to_render_data_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/detections_to_render_data_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/core/gate_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/landmarks_to_render_data_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/labels_to_render_data_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/core/gate_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/rect_to_render_data_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/detections_to_render_data_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/collection_has_min_size_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/collection_has_min_size_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/image_to_tensor_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/annotation_overlay_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/image_to_tensor_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/thresholding_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/detections_to_rects_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/core/clip_vector_size_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/detections_to_rects_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tflite/ssd_anchors_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/core/constant_side_packet_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tflite/tflite_custom_op_resolver_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/core/flow_limiter_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/association_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/tensors_to_detections_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/non_max_suppression_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/association_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/core/flow_limiter_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tflite/ssd_anchors_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/core/constant_side_packet_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/core/clip_vector_size_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/internal/callback_packet_calculator.pb.h:
bazel-out/k8-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/tensors_to_landmarks_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/util/landmark_projection_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/inference_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/tensors_to_floats_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/tensor/tensors_to_classification_calculator.pb.h [for host]:
bazel-out/host/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From Compiling mediapipe/framework/calculator.pb.cc [for host]:
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc: In member function 'virtual google::protobuf::uint8* mediapipe::ProfilerConfig::_InternalSerialize(google::protobuf::uint8*, google::protobuf::io::EpsCopyOutputStream*) const':
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:1714:41: warning: 'bool mediapipe::ProfilerConfig::enable_input_output_latency() const' is deprecated [-Wdeprecated-declarations]
 1714 |   if (this->enable_input_output_latency() != 0) {
      |                                         ^
In file included from bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:4:
bazel-out/host/bin/mediapipe/framework/calculator.pb.h:2734:13: note: declared here
 2734 | inline bool ProfilerConfig::enable_input_output_latency() const {
      |             ^~~~~~~~~~~~~~
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:1781:39: warning: 'bool mediapipe::ProfilerConfig::trace_log_duration_events() const' is deprecated [-Wdeprecated-declarations]
 1781 |   if (this->trace_log_duration_events() != 0) {
      |                                       ^
In file included from bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:4:
bazel-out/host/bin/mediapipe/framework/calculator.pb.h:3001:13: note: declared here
 3001 | inline bool ProfilerConfig::trace_log_duration_events() const {
      |             ^~~~~~~~~~~~~~
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc: In member function 'virtual size_t mediapipe::ProfilerConfig::ByteSizeLong() const':
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:1863:41: warning: 'bool mediapipe::ProfilerConfig::enable_input_output_latency() const' is deprecated [-Wdeprecated-declarations]
 1863 |   if (this->enable_input_output_latency() != 0) {
      |                                         ^
In file included from bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:4:
bazel-out/host/bin/mediapipe/framework/calculator.pb.h:2734:13: note: declared here
 2734 | inline bool ProfilerConfig::enable_input_output_latency() const {
      |             ^~~~~~~~~~~~~~
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:1918:39: warning: 'bool mediapipe::ProfilerConfig::trace_log_duration_events() const' is deprecated [-Wdeprecated-declarations]
 1918 |   if (this->trace_log_duration_events() != 0) {
      |                                       ^
In file included from bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:4:
bazel-out/host/bin/mediapipe/framework/calculator.pb.h:3001:13: note: declared here
 3001 | inline bool ProfilerConfig::trace_log_duration_events() const {
      |             ^~~~~~~~~~~~~~
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc: In member function 'void mediapipe::ProfilerConfig::MergeFrom(const mediapipe::ProfilerConfig&)':
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:1979:40: warning: 'bool mediapipe::ProfilerConfig::enable_input_output_latency() const' is deprecated [-Wdeprecated-declarations]
 1979 |   if (from.enable_input_output_latency() != 0) {
      |                                        ^
In file included from bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:4:
bazel-out/host/bin/mediapipe/framework/calculator.pb.h:2734:13: note: declared here
 2734 | inline bool ProfilerConfig::enable_input_output_latency() const {
      |             ^~~~~~~~~~~~~~
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:2006:38: warning: 'bool mediapipe::ProfilerConfig::trace_log_duration_events() const' is deprecated [-Wdeprecated-declarations]
 2006 |   if (from.trace_log_duration_events() != 0) {
      |                                      ^
In file included from bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:4:
bazel-out/host/bin/mediapipe/framework/calculator.pb.h:3001:13: note: declared here
 3001 | inline bool ProfilerConfig::trace_log_duration_events() const {
      |             ^~~~~~~~~~~~~~
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc: In member function 'virtual google::protobuf::uint8* mediapipe::CalculatorGraphConfig_Node::_InternalSerialize(google::protobuf::uint8*, google::protobuf::io::EpsCopyOutputStream*) const':
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:2575:33: warning: 'bool mediapipe::CalculatorGraphConfig_Node::has_profiler_config() const' is deprecated [-Wdeprecated-declarations]
 2575 |   if (this->has_profiler_config()) {
      |                                 ^
In file included from bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:4:
bazel-out/host/bin/mediapipe/framework/calculator.pb.h:3855:13: note: declared here
 3855 | inline bool CalculatorGraphConfig_Node::has_profiler_config() const {
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc: In member function 'virtual size_t mediapipe::CalculatorGraphConfig_Node::ByteSizeLong() const':
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:2711:33: warning: 'bool mediapipe::CalculatorGraphConfig_Node::has_profiler_config() const' is deprecated [-Wdeprecated-declarations]
 2711 |   if (this->has_profiler_config()) {
      |                                 ^
In file included from bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:4:
bazel-out/host/bin/mediapipe/framework/calculator.pb.h:3855:13: note: declared here
 3855 | inline bool CalculatorGraphConfig_Node::has_profiler_config() const {
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc: In member function 'void mediapipe::CalculatorGraphConfig_Node::MergeFrom(const mediapipe::CalculatorGraphConfig_Node&)':
bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:2797:32: warning: 'bool mediapipe::CalculatorGraphConfig_Node::has_profiler_config() const' is deprecated [-Wdeprecated-declarations]
 2797 |   if (from.has_profiler_config()) {
      |                                ^
In file included from bazel-out/host/bin/mediapipe/framework/calculator.pb.cc:4:
bazel-out/host/bin/mediapipe/framework/calculator.pb.h:3855:13: note: declared here
 3855 | inline bool CalculatorGraphConfig_Node::has_profiler_config() const {
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~
ERROR: /home/qwerty/.cache/bazel/_bazel_qwerty/a12d07e16a57f8d88ea378494a9d1b0e/external/org_tensorflow/tensorflow/core/util/BUILD:376:24: error executing shell command: '/bin/bash -c bazel-out/k8-opt-ST-e0f78fafe98f/bin/external/org_tensorflow/tensorflow/tools/git/gen_git_source --generate "$@" --git_tag_override=${GIT_TAG_OVERRIDE:-}  external/local_config_git/gen...' failed (Exit 127): bash failed: error executing command /bin/bash -c 'bazel-out/k8-opt-ST-e0f78fafe98f/bin/external/org_tensorflow/tensorflow/tools/git/gen_git_source --generate "$@" --git_tag_override=${GIT_TAG_OVERRIDE:-}' '' ... (remaining 4 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox bash failed: error executing command /bin/bash -c 'bazel-out/k8-opt-ST-e0f78fafe98f/bin/external/org_tensorflow/tensorflow/tools/git/gen_git_source --generate "$@" --git_tag_override=${GIT_TAG_OVERRIDE:-}' '' ... (remaining 4 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
/usr/bin/env: 'python': No such file or directory
Target //mediapipe/examples/desktop/hand_tracking:hand_tracking_cpu failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 131.882s, Critical Path: 120.89s
INFO: 561 processes: 132 internal, 429 linux-sandbox.
FAILED: Build did NOT complete successfully

I tried https://github.com/google/mediapipe/blob/master/docs/getting_started/troubleshooting.md#missing-python-binary-path
but an error has occurred.
OS  Ubuntu 20.04.2
gcc/g++ 9.3.0
Bazelisk version 1.1.0
OpenCV version 3.4.15

@hotuemon, Issue either because of multiple python versions installed.  Duplicate of https://github.com/google/mediapipe/issues/2284

Thank you for your reply. I was able to solve this problem with the following command:
$ cd /usr/bin/
$ sudo ln -s /usr/bin/python3 ./python

authors: hotuemon sgowroji


text:
How do I rearrange face image as close as to 206*206 size?

How do I rearrange face image as close as to 206*206 size?

Hi @martinenkoEduard ,
The model is trained for 128x128. You'll need to find a replacement model and adjust the graph around it.

authors: martinenkoEduard sureshdagooglecom


text:
Is there any way around to disable unsafe-eval for JavaScript?

Problem
Mediapipe library doesn't work without enabling unsafe-eval in JavaScript, that may lead to cross site scripting attacks, is there any way to use library without unsafe eval?

Duplicate of #3458

Hi @github-itsec-oculavis, We are following up with the issue #3458 and will revert back if there is any specific update on issue. Thank you!

Hi @github-itsec-oculavis, We are following up with the issue #3458 and will revert back if there is any specific update on issue. Thank you!

Hi @kuaashish I had a look there, nobody is responding to that issue.

Hi @github-itsec-oculavis, Looks like we could do that but we would need to publish new packages. There might be some downsides so I am not sure that we will do so (at least not in the near future). Thank you!

This is a big problem for anyone that wants to use MediaPipe and a Chrome Extension now that Manifest v3 is required. Is there any movement on this at Google? Thanks.

Any roadmap updates about CSP issues?

authors: github-itsec-oculavis kuaashish mmerezhko-hv nskaiser


text:
Did the Face landmark detection can tell us whether the face is swollen and unsymmetric？

MediaPipe Solution (you are using)
Face landmark detection
Programming language
android
Are you willing to contribute it
None
Describe the feature and the current behaviour/state
I'm testing this project. The examples run up successfully. I want to know is the results can tell whether the face is swollen and unsymmetric
Will this change the current API? How?
no
Who will benefit with this feature?
Medical practitioners
Please specify the use cases for this feature
Showcasing the patient's injury situation
Any Other info
No response

Hi @joveth1,
We believe this is out of scope section of MediaPipe face landmarker, which is primarily designed for entertainment and assistive technologies. It is not intended for making critical human life decisions or medical purposes.
For a more comprehensive understanding, please refer to our model card.
Thank you!!!


text:
Migrating build logic from Groovy to Kotlin (KTS)

Migrate all .gradle (groovy files) to .gradle.kts (Kotlin DSL)
Benefits
Auto-completion and content assist
Quick documentation
Navigation to source
Refactoring and more

I've seen some issues few months ago on KTS, let's see how's the support once Arctic Fox is out!

Can I take a shot to resolve this issue?

@ghostbear Go for it! The only thing I would prefer to avoid is buildSrc. We can rely on the Gradle catalog feature to centralize dependencies

authors: akhilesh0707 ghostbear yrezgui

repo: google/modernstorage


text:
high DP monitors cause preference windows to be too cramped

After installing mozc onto Linux Mint 20.1, I went to set some preferred settings, but I found the settings window to be far too cramped to find anything and no way to resize it. Attached figure 1 shows the default size of a few of the menus. Some of the menus can be resized and made easier to view, but not the main settings menu (labeled config_dialog under the gui src).
I'm not familiar with C++ GUI applications so I can't say for a definitive fact that this is the problem, but I found this .ui file which locks the window width and height to a really small size. Realistically, there should be either a scroll or allow the windows to resize as needed.
The biggest cause, I think for this to happen is having a high resolution monitor set up which requires a certain UI scale factor which mozc does not take into account. (see figures 3 and 4 for display settings)

fig. 1 - Primary monitor with the various GUI windows open

fig. 2 - System Information

fig. 3 - Main monitor display settings

fig. 4 - Secondary monitor display settings

This bug used to affect me, but it was fixed for me in an update.
After the update, the look and feel of the window changed to the following and the buttons were no longer squished together:

I am on Ubuntu 21.04. I tried Googling for the development branch for Linux Mint, but couldn't find one. You could report this to downstream Linux Mint maintainers and ask them to backport the fix, or wait for the LTS in April 2022.
I think a workaround I used a few months ago (only tested on one monitor with 200% scaling) was to do ibus restart before opening the preferences. Running /usr/lib/mozc/mozc_tool --mode=config_dialog to open the window directly from the terminal might also work

It seems your version is 2.23.2815.102, which does not contain the following fix yet.
https://github.com/google/mozc/blame/master/src/gui/base/util.cc#L94
Would you try an updated version as Daniel also suggested?
Thank you,

OK. After fighting with the docker build and the existing apt-package for ibus-mozc, I think I was able to get the latest source for the tool which fixed the scaling. I will also try and find where to submit a bug ticket with Linux Mint to backport a fresher version of mozc for HiDPI support. HiDPI setups are becoming more and more common already, and I don't see any major issues with the newer version so far. Thanks for the help.
ありがとうございます　＾＿＾

authors: E1337Kat danielzgtg hiroyuki-komatsu

repo: google/mozc


text:
「愛新覚羅」が変換できない

あいしんかくらでスペースキーを押しても愛新覚羅と変換できません。「愛新覚羅溥儀」「愛新覚羅溥傑」であれば変換できます。辞書追加お願いいたします。

Thank you for your report.
This issue was merged to https://github.com/google/mozc/issues/668


text:
Fix GCS bucket/subdir handling in IcannReportingStager

This change is

Commit/PR description can be more precise than "Fixed a bug in _____". Should be something like "Fix GCS bucket/subdir handling in IcannReportingStager". That way it's more findable if we need to look for it in the future (which given the change to this API, may well be the case).

Reviewable status: 0 of 1 files reviewed, all discussions resolved

Done.

repo: google/nomulus