text:
Erro charmap

Can someone please help me with this error? I am using python 3.8 and windows 10. Thanks
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 1380: character maps to

Hello @Luananayara , thank you for reaching out! Please follow our github issue template and describe your issue in English. Thank you!
https://github.com/google/shaka-player/issues/new?assignees=&labels=&template=bug_report.md&title=

I'm trying to follow the tutorial, shaka-player version 2.5, when I put to compile in python 3.8 gives the error and I can't move on ... follow the description of the error;
this step gives the error below:
Compile the library and generate the docs
python build/all.py
[WARNING] No changes detected, skipping. Use --force to override.
Traceback (most recent call last):
File "build/all.py", line 150, in
shakaBuildHelpers.run_main(main)
File "C:\Users\shaka-player\build\shakaBuildHelpers.py", line 322, in run_main
sys.exit(main(sys.argv[1:]))
File "build/all.py", line 92, in main
if not localizations.generate(parsed_args.force):
File "C:\Users\shaka-player\build\compiler.py", line 472, in generate
not self._locales_changed()):
File "C:\Users\shaka-player\build\compiler.py", line 451, in _locales_changed
for line in f:
File "C:\Users\AppData\Local\Programs\Python\Python38\lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 1380: character maps to

My guess is the default locale for Windows is not UTF8, so when it tries to read the file, it gets an error.  We should either read as bytes and decode explicitly as UTF8, or we can set the default locale to UTF8.

I installed python 2.7 and it now works without charmap errors. I have already tested with other versions of python and have the same charmap error. So using python 2.7 works perfectly, thanks

Let's see if we can fix this for Python 3.  Users should not need such an old version of Python to build Shaka Player.
@TheModMaker, setting the default locale sounds good to me, so that we don't regress in future calls to decode().  Especially since we don't test this regularly on Windows.  But if there is a good reason to prefer setting decoding explicitly in utf8 every time, I would trust your judgement.

I tested with python 3.5, 3.6, 3.8 and everyone in windows has the same problem, my text editor is already set to UTF8.

authors: Luananayara TheModMaker joeyparrish michellezhuogg


text:
AE import error: The positionY of the text layer in AE is higher than that in Figma

The positionY of the text layer in AE is higher than that in Figma
As far as I know, the positionY of text layer of text is related to lineHeight.

r('ADBE Transform Group')('ADBE Position').setValue([ layer.frame.x * compMult, (layer.frame.y + layer.fontSize/6) * compMult]);
maybe this line shouldbe include lineHeight in calculate postionY of textLayer on figma import to ae

As far as I know, in AE, the text will be on top of the text box, and in figma, it will be centered. This may be the cause of the error

https://www.figma.com/blog/line-height-changes/

I hope this link is helpful to you. I tried to fix this bug, but I haven't fixed it yet.

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
sys/targets: use out/x64/x64-shared/gen on fuchsia

out/x64/gen and out/x64/x64-shared/gen seem to contain the same contents.
We already use things in out/x64/x64-shared and we don't use out/x64/gen otehrwise.
By changing the path we depend on fewer things and can have smaller toolchain archive.
Update #1765

Note that a while a go we decided to build syz-executor inside fuchsia because it was easier.
However, if you wish to build syz-executor only I don't think you would need the whole fuchsia tree, you could use the fuchsia sdk. Would that simplify things?

Did not know about SDK.
Is it this one: https://fuchsia.dev/fuchsia-src/development/sdk/download ?
I downloaded it and it does not contain clang, so it does not look complete replacement for the full fuchsia checkout/build. Or should we use normal host clang and the rest is in the SDK?

I am interested in increasing test coverage on CI prevent the bug we got recently in pkg/cover.

I failed to build clang following these instructions:
https://fuchsia.dev/fuchsia-src/development/build/toolchain
I am running:
cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;libcxx;libcxxabi;compiler-rt;lld" -DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi;libunwind" -DSTAGE2_FUCHSIA_SDK=/fuchsia-sdk -C ../clang/cmake/caches/Fuchsia.cmake ../llvm

and getting:
Determining if the include file malloc/malloc.h exists failed with the following output:
Change Dir: /usr/local/google/home/dvyukov/src/llvm/build.fuchsia/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/ninja" "cmTC_2b277"
[1/2] Building C object CMakeFiles/cmTC_2b277.dir/CheckIncludeFile.c.o
FAILED: CMakeFiles/cmTC_2b277.dir/CheckIncludeFile.c.o
/usr/bin/cc     -o CMakeFiles/cmTC_2b277.dir/CheckIncludeFile.c.o   -c CheckIncludeFile.c
CheckIncludeFile.c:1:10: fatal error: malloc/malloc.h: No such file or directory
    1 | #include <malloc/malloc.h>
      |          ^~~~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.

Determining if the include file mach/mach.h exists failed with the following output:
Change Dir: /usr/local/google/home/dvyukov/src/llvm/build.fuchsia/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/ninja" "cmTC_8df31"
[1/2] Building C object CMakeFiles/cmTC_8df31.dir/CheckIncludeFile.c.o
FAILED: CMakeFiles/cmTC_8df31.dir/CheckIncludeFile.c.o
/usr/bin/cc     -o CMakeFiles/cmTC_8df31.dir/CheckIncludeFile.c.o   -c CheckIncludeFile.c
CheckIncludeFile.c:1:10: fatal error: mach/mach.h: No such file or directory
    1 | #include <mach/mach.h>
      |          ^~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.

Determining if the include file histedit.h exists failed with the following output:
Change Dir: /usr/local/google/home/dvyukov/src/llvm/build.fuchsia/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/ninja" "cmTC_4a5b1"
[1/2] Building C object CMakeFiles/cmTC_4a5b1.dir/CheckIncludeFile.c.o
FAILED: CMakeFiles/cmTC_4a5b1.dir/CheckIncludeFile.c.o
/usr/bin/cc     -o CMakeFiles/cmTC_4a5b1.dir/CheckIncludeFile.c.o   -c CheckIncludeFile.c
CheckIncludeFile.c:1:10: fatal error: histedit.h: No such file or directory
    1 | #include <histedit.h>
      |          ^~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.

Fuchsia also provides a prebuilt clang that you could use, download it from here: https://chrome-infra-packages.appspot.com/p/fuchsia/clang/linux-amd64/+/ (similarly for arm64).
If you still want to build it, I think you are missing the sysroot files. The configuration that I use is the one under "Fuchsia Configuration"

Tried to use the prebuilt clang, it seems to work.
However, the SDK misses this include:
executor/common_fuchsia.h:25:10: fatal error: 'ddk/driver.h' file not found
#include <ddk/driver.h>

I can't find any downloads for DDK here:
https://fuchsia.dev/fuchsia-src/concepts/drivers/overview
A separate question: is there a stable URL to down latest compiler from here (or SDK):
https://chrome-infra-packages.appspot.com/p/fuchsia/clang/linux-amd64/+/latest
The download link seem to point to the specific version and includes and auth tokens and does not look like a right link to include in scripts .

Humm... I now can't build executor for fuchsia even with full fuchsia build...
.jiri_root/bin/jiri update
scripts/fx --dir out/x64 set core.x64 --with-base //bundles:tools
scripts/fx clean-build
SOURCEDIR=/fuchsia make executor TARGETOS=fuchsia
...
************************************************************************************
Executor will not be built
Native cross-compiler is missing/broken:
In file included from <stdin>:2: /fuchsia/prebuilt/third_party/clang/linux-x64/bin/../include/c++/v1/stdio.h:107:15: fatal error: 'stdio.h' file not found
************************************************************************************

Oh, I see, we have a dozen of custom patches for what actually run:
https://github.com/mvanotti/syzkaller/commit/a4387cab0506dda50ce6d8cecf0bccd9b70fe617
We need to converge that fork with upstream.

Those patches are mostly testing things/temporary workarounds. Now that KASAN has landed in fuchsia we are looking into getting syzkaller in a better shape and I will start sending patches upstream.
However, we are building syz-executor inside the fuchsia tree, so we haven't looked into what is needed to build syz-executor in the way you want.

Those patches are mostly testing things/temporary workarounds. Now that KASAN has landed in fuchsia we are looking into getting syzkaller in a better shape and I will start sending patches upstream.
However, we are building syz-executor inside the fuchsia tree, so we haven't looked into what is needed to build syz-executor in the way you want.

Ah, good.
Then I assume these paths in sys/targets/targets.go are unused otherwise. I would like to use the old way of building executor (via sys/targets/targets.go) at least for tests, at least for now, because we have pkg/cover tests broken on syzbot, but CI currently can't test fuchsia build.
I noticed that these paths in sys/targets/targets.go have changed again on top of what you have in your fork. So I will need to do more changes.

Superseded by #1779
Now we have coverage reports working for fuchsia and also latest working toolchain available at:
https://storage.googleapis.com/syzkaller/fuchsia-toolchain.tar.gz
and in syz-big-env, so syz-big-env make executor TARGETOS=fuchsia just magically works.

source: gharchive/pull-request

authors: dvyukov mvanotti

repo: google/syzkaller

license_source: bigquery


text:
chore(deps): Included dependency review

Dependency Review GitHub Action in your repository to enforce dependency
reviews on your pull requests.
The action scans for vulnerable versions of dependencies introduced by package version
changes in pull requests,
and warns you about the associated security vulnerabilities.
This gives you better visibility of what's changing in a pull request,
and helps prevent vulnerabilities being added to your repository.

https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#dependency-review-enforcement
Signed-off-by: naveen 172697+naveensrinivasan@users.noreply.github.com

The action scans for vulnerable versions of dependencies introduced by package version changes in pull requests, and warns you about the associated security vulnerabilities.

Do I understand it correctly that this action will just post some status (OK/there are some problems) to PRs?

The action scans for vulnerable versions of dependencies introduced by package version changes in pull requests, and warns you about the associated security vulnerabilities.

Do I understand it correctly that this action will just post some status (OK/there are some problems) to PRs?

Yes, you are right!

authors: dvyukov naveensrinivasan


text:
Support clang in linux bisection jobs

Some outstanding improvements not included in this PR:

use default compiler, instead of one from the bin_dir, if an old compiler isn't required for the commit under test
handle vanishing breaking commit (due to rebases) in the fixing commit bisection
save time while bisecting subtree merges by skipping ahead to subtree merge commit, instead of skipping each subtree commit individually

Confirmed bisection of Chrome OS and upstream still work in my test syc-ci instance and fixed the nit.

Just in case: we need new gcc binaries layout on all machines doing bisection before this is merged to not break bisections.

To be extra clear: I didn't yet test Chrome OS or upstream in clang bisection mode. Instead I left the BisectCompiler blank in my config for these kernels, as it currently is in the production config. Hence I only validated this shouldn't break bisection in production for those kernels if merged.
Before setting BisectCompiler to clang fro icebreaker we also require two clang compilers in the bisect bin of the production bin_dir. I can provide those in due time.

Just in case: we need new gcc binaries layout on all machines doing bisection before this is merged to not break bisections.

Why? The gcc path layout didn't change in this PR, I only added a clang layout which is not used by default.

Just in case: we need new gcc binaries layout on all machines doing bisection before this is merged to not break bisections.

Why? The gcc path layout didn't change in this PR, I only added a clang layout which is not used by default.

You are right. Initially I misread the code that there is an additional "gcc" dir added to the path.
New binaries don't need to be deployed before merging.

👍 :^)

authors: HerrSpace dvyukov


text:
sys/linux: rename dev descriptions files

Prefix file names of descriptions of /dev/* files with dev_.
And give some of them more appropriate names.

Codecov Report

Merging #972 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #972   +/-   ##
=======================================
  Coverage   67.77%   67.77%
=======================================
  Files         114      114
  Lines       20169    20169
=======================================
  Hits        13669    13669
  Misses       5861     5861
  Partials      639      639

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa53be2...8e52199. Read the comment docs.

Fixed.

LGTM

authors: codecov-io dvyukov xairy


text:
Add integration tests for the flash driver.

Commits new in this PR:

Add some integration tests for the flash driver.

----------------------
`make prtest` summary:
----------------------
git rev-parse HEAD
c25fce0bcefcd592857ca5fc7c2b7dc8b9390da5
git status
On branch flash-tests
Your branch is up to date with 'origin/flash-tests'.

nothing to commit, working tree clean

----------------------
`make prtest` summary:
----------------------
git rev-parse HEAD
62e056996af24356a3d385da0d609b4c277531b4
git status
On branch flash-tests
Your branch is up to date with 'origin/flash-tests'.

nothing to commit, working tree clean

repo: google/tock-on-titan


text:
Add a test harness, switching h1b_tests to a test executor.

This allows us to run Rust unit tests directly on Tock as an application. In future changes, I'll add a tool to make it easy for unit tests to do assertions and set expectations (assert!() panics so it cannot be used in these unit tests).

This looks great! The one catch is it depends on print!; once we resolve that (please see #15 ), we should be good to go.

Resolved.


text:
Local Environment: Use latest Docker image again

Context

Summary

Relevant Technical Choices

To-do

User-facing changes

Testing Instructions

QA

[ ] This is a non-user-facing change and requires no QA

This PR can be tested by following these steps:

UAT

[ ] UAT should use the same steps as above.

This PR can be tested by following these steps:

Reviews
Does this PR have a security-related impact?

Does this PR change what data or activity we track or use?

Does this PR have a legal-related impact?

Checklist

[x] This PR addresses an existing issue and I have linked this PR to it in ZenHub
[x] I have tested this code to the best of my abilities
[x] I have verified accessibility to the best of my abilities (docs)
[x] I have verified i18n and l10n (translation, right-to-left layout) to the best of my abilities
[x] This PR contains automated tests (unit, integration, and/or e2e) to verify the code works as intended (docs)
[x] I have added documentation where necessary
[x] I have added a matching Type: XYZ label to the PR

Fixes #7226

I am also seeing this error again now - https://github.com/google/web-stories-wp/issues/4802
I think it is unrelated to the change.

repo: google/web-stories-wp


text:
GoogleAdsClient always generates new access token

In the Google Adwords API, there was a callback in the authentication flow (on OAuth2ProviderForApplications) which would be called whenever an access token was refreshed, and also a call to refresh the access token if needed. We used this because we made many independent calls to the Adwords API and cached the access token to avoid the overhead of refreshing.
In the Google Ads API, it seems that the implemented behavior is to always start by obtaining an access token from the given refresh token. Indeed, any access token passed into the client through the GoogleAdsConfig is ignored with only the refresh token used to initialize the UserCredential.
Furthermore, there's no way to hook the activity on the UserCredential because only an ICredential is exposed, and I can't override this because there's no available interface on GoogleAdsConfig.
So ...

Is it reasonable to refresh access tokens frequently? What's the overhead (presumably at least a server round-trip)? In our case, we might be doing this many, many times as the clients are created in Azure functions ... It's even possible that many of these refreshed access tokens might be used concurrently. Is that a problem?
Alternatively, is there a way to hook that refresh activity?

@AnashOommen Any thoughts on this one?

Hi Adrian,
I'll get you a fix for this issue in the next push.

Thanks Anash!

authors: AdrianPell AnashOommen

repo: googleads/google-ads-dotnet


text:
Enable master branch protection

      This repository does not seem to have master branch
      protection enabled, at least in the way I'm expecting.
      I was hoping for:

      - master branch protection
      - requiring at least one code reviewer
      - requiring at least two status checks
      - enforcing rules for admins

      Please turn it on!

Now enabled, see #176.

authors: JustinBeckwith miraleung

repo: googleapis/api-common-java


text:
Doesn't work with PM2 on Compute Engine

Environment details

OS: Ubuntu 16
Node.js version: 8
npm version: 6
@google-cloud/debug-agent version: ^3.1.0

Steps to reproduce

Install debug client
require('@google-cloud/debug-agent').start({ allowExpressions: true, serviceContext: {    service: config.get('service'),    version: config.get('version') }, projectId: 'my-project' });
Run pm2 start myserverconfig.json
Error reporting and logging (Winston) work fine.
Snapshots and log-points don't do anything
Service and version show up in other consoles but not in debug console
Run node server.js instead of using pm2
Version and service show up in debug console
logpoints and snapshots work as expected.

Thank you for letting us know about this.  For clarity, when visiting the Debug console in the Google Cloud Console UI, you don't even see your service or version appear at all to select if and only if you are using pm2 (i.e. when you are usingnode they do appear)?

That is correct. If I run the application using node then the configured version and service will display and I can choose from source repositories. This includes if I run locally and set NODE_ENV=production. I also can use the debugging tools without issue.
When running from pm2, the service and version show up in Stackdriver Logs Viewer as well as in the Error Reporting console. This is all connected through the node winston Stackdriver library and works as expected. The debug console however, does not show the version or service as an option if I run with pm2. This is particularly strange as the Error Reporting console correctly identifies the file where an error occurred. When I click this it links to the Debug console but the version from the Error Reporting console is not there.
PM2 is configured using an environment file and executed from a different path than source of the application.

Update:
Just tested running with node from the same directory that I run pm2 from and got the following message in the console:
@google-cloud/debug-agent No package.json located in working directory.
This also caused the debug console to stop working.

Thanks for the info.  It looks like the debug agent is looking for the application source in the current working directory, but cannot find it because pm2 is running elsewhere.  I suggest using the workingDirectory configuration option to explicitly specify which directory contains the application's package.json file.  Let me know if that does or does not solve the problem.

Hey, that has worked. Thanks for your help!

Glad to be of help.

authors: DominicKramer MattGson

repo: googleapis/cloud-debug-nodejs


text:
Can I register the authentication key file directly in code

Can I register the authentication key file directly in code for libraries like spannergorm, similar to regular googleapis, instead of using environment variables? I want to set up the authentication key file as part of my application code.

Thanks @sjy-dv for reporting the issue, created the PR to update readme to use authentication file

repo: googleapis/go-gorm-spanner


text:
feat: add PG.OID type

Allows for using PG.OID type in parameterized queries and reading them from result sets.

This change is

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

authors: dbolduc devbww thiagotnunes

repo: googleapis/google-cloud-cpp


text:
impl(pubsub): start the publish span as a root span

Now that https://github.com/open-telemetry/opentelemetry-cpp/pull/2427 is in we can start an async span as a root span

This change is

Since this was added recently, it won't be available in the oldest deps. https://github.com/open-telemetry/opentelemetry-cpp/blame/main/api/include/opentelemetry/trace/span_metadata.h#L24. Gonna do something hacky and just use the string until we upgrade
Opened https://github.com/googleapis/google-cloud-cpp/issues/13287


text:
refactor: ScopedDeleter doesn't require metadata

Before the change, ScopedDeleter kept ObjectMetadata of all object
to delete. This was unnecessary - object names and generation numbers
are enough, so this change stores them instead of the metadata. This is
useful when the caller has the information but doesn't have the full
metadata.

This change is

Codecov Report

Merging #3380 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #3380      +/-   ##
==========================================
+ Coverage   89.34%   89.35%   +<.01%
==========================================
  Files         461      461
  Lines       41929    41944      +15
==========================================
+ Hits        37463    37477      +14
- Misses       4466     4467       +1

Impacted Files
Coverage Δ

google/cloud/storage/parallel_upload.h
96.18% <100%> (-0.03%)
:arrow_down:

google/cloud/storage/client.h
99.77% <100%> (-0.01%)
:arrow_down:

google/cloud/storage/client.cc
94.97% <100%> (+0.12%)
:arrow_up:

google/cloud/storage/well_known_parameters.h
69.56% <0%> (-7.61%)
:arrow_down:

google/cloud/storage/well_known_headers.h
70.37% <0%> (-3.71%)
:arrow_down:

...le/cloud/bigtable/internal/async_retry_unary_rpc.h
78.57% <0%> (-2.92%)
:arrow_down:

google/cloud/bigtable/metadata_update_policy.h
100% <0%> (ø)
:arrow_up:

google/cloud/bigtable/app_profile_config.h
100% <0%> (ø)
:arrow_up:

...gle/cloud/storage/internal/access_control_common.h
100% <0%> (ø)
:arrow_up:

google/cloud/bigtable/mutations.h
100% <0%> (ø)
:arrow_up:

... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 087b578...9af8101. Read the comment docs.

authors: codecov-io dopiera


text:
How to use HMAC credentials to download a file using the StorageClient?

Description
Hello, hope you're good. I'm searching through the docs how to use the HMAC credentials with the StorageClient, but didn't find any example. How should I use it?
I'd like to use the methods from this class like GetObjectAsync to make my life easier, instead of making a common request using an HttpClient and parse the result.
If this is not the right place to ask this question, please let me know.

Update:
I found this StackOverflow thread, where the accepted answer tells us to use the AWS SDK instead of GCP. Is this still valid, or has GCP SDK caught up already?

Authentication via HMAC credentials is only supported by the XML Storage API, and the Google.Cloud.Storage.V1 library is for the JSON API. So if you want to use HMAC credentials for different Storage operations, you cannot use the Google.Cloud.Storage.V1 library.
That said, it seems you are only interested in using HMAC keys for downloading a objects. For that, you can create HMAC signed URLs using Google.Cloud.Storage.V1.

Got it, thanks for the information.

repo: googleapis/google-cloud-dotnet


text:
SIGSEGV on SpeechClient.LongRunningRecognizeAsync call under Alpine Linux (Docker)

Environment details

OS: Alpine Linux (Docker, mcr.microsoft.com/dotnet/core/sdk:3.1-alpine)
.NET version: .NET Core 3.1
Package name and version: Google.Cloud.Speech.V1 v2.0.0

Steps to reproduce

Clone git@github.com:vanufryiuk/Google.Cloud.Speech.V1.SIGSEGV.git (https://github.com/vanufryiuk/Google.Cloud.Speech.V1.SIGSEGV)
Copy your GoogleCredentials.json inside
Run "docker-compose build"
Run "docker-compose up"

I suspect this is a duplicate of the known libc compatibility issue with gRPC 2.x in Alpine.
See https://github.com/googleapis/google-cloud-dotnet/issues/4780#issuecomment-608304477 for a potential solution.
I can try reproducing it (and then applying the fix) next week, but it won't be today, I'm afraid, due to other commitments. If you could try that fix earlier, that would be very useful.

@jskeet thank you. The workaround with libc6-compat=1.1.19-r11 works.
But I can't find any related issue in Alpine repos. Do you know if it exists?

Glad to hear it works.
I'm afraid I don't know much about the details of it, or whether there's any effort on the Alpine or gRPC side to fix things... it's all at least one level lower than I normally work :( I'll close this issue now that we've confirmed the workaround fixes it - I do hope eventually it will be unnecessary, of course.

authors: jskeet vanufryiuk


text:
FirestoreDbBuilder.ConverterRegistry ignored when using Firestore Emulator

Hi. I'm having problems trying to use custom type converters via the Converter Registry in FirestoreDbBuilder when targeting the Firestore Emulator.
Looking a the source code I noticed that FirestoreDbBuilder ignores the value of its ConverterRegistry property when creating an instance of FirestoreDb. The problem seems to be in lines 186-192 of FirestoreDbBuilder.cs, inside the function MaybeUseEmulator:
...
 return new FirestoreDbBuilder
{
    Endpoint = hostAndPort,
    Settings = settings,
    ProjectId = ProjectId,
    ChannelCredentials = ChannelCredentials.Insecure
};

Note that in the new FirestoreDbBuilder returned by this method, ConverterRegistry is not asigned. Thus, the original value is ignored when the FirestoreDb instance is created in the recursive call to Build in line 89 of FirestoreDbBuilder.cs.
Is there any good reason to ignore the value, or is this simply a bug?

I'll have a look when I'm back at work tomorrow. It's almost certainly just a bug.

(I suspect it will be a bug that's easily fixed, and which we can then just roll out a patch release for. But we'll see...)

Thanks! Good to know this could be fixed  soon.

Hi @jrojasledesma, the fix is now released in version 2.3.1. I'm pretty confident in the fix, but please shout if you have any problems :)

Hi, I just tried the new version and confirmed that my issue is now fixed. Thank you @jskeet and @amanda-tarafa!

authors: jrojasledesma jskeet


text:
Can't connect to firestore : Class "Google\ApiCore\Serializer" not found

Environment details

OS: MacOS 15.0
PHP version: 8.2.20
Package name and version: google/cloud-firestore -> ^0.1.0

Steps to reproduce

composer require google/cloud-firestore
Put the code below in a index.php file

Code example
<?php
require 'vendor/autoload.php';

use Google\Cloud\Firestore\FirestoreClient;

$firestore = new FirestoreClient([
    'credentials' => json_decode(file_get_contents('./Liste-Manga-Firebase-Admin.json'), true)
]);

$collection = $firestore->collection('mangas');

Full Error
Fatal error: Uncaught Error: Class "Google\ApiCore\Serializer" not found in /Users/theo/Developer/web_scrapper/vendor/google/cloud-core/src/GrpcRequestWrapper.php:93 Stack trace: #0 /Users/theo/Developer/web_scrapper/vendor/google/cloud-firestore/Connection/Grpc.php(81): Google\Cloud\Core\GrpcRequestWrapper->__construct(Array) #1 /Users/theo/Developer/web_scrapper/vendor/google/cloud-firestore/FirestoreClient.php(110): Google\Cloud\Firestore\Connection\Grpc->__construct(Array) #2 /Users/theo/Developer/web_scrapper/index.php(6): Google\Cloud\Firestore\FirestoreClient->__construct(Array) #3 {main} thrown in /Users/theo/Developer/web_scrapper/vendor/google/cloud-core/src/GrpcRequestWrapper.php on line 93

Thanks!

google/cloud-firestore -> ^0.1.0

You should try upgrading to google/cloud-firestore:^1.0, as the version you've listed there is very out of date.

Uncaught Error: Class "Google\ApiCore\Serializer" not found

I am not sure what version of google/gax you're on, but in the most recent version (and since a long long time ago), that class exists. So my best guess is you need to update your packages.

repo: googleapis/google-cloud-php


text:
feat: Add BigLakeConfiguration Property in StandardTableDefinition.java

The Spark Bigquery connector uses the java-bigquery library to communicate with BigQuery. In some cases, we need to determine if a table is a Biglake table. A table is identified as a Biglake table if it has the BigLakeConfiguration property. Therefore, we need to propagate the BigLakeConfiguration property from the Table class to the StandardTableDefinition class.
Fixes #2915 ☕

@vteja11 to resolve the clirr error, please add an entry to https://github.com/googleapis/java-bigquery/blob/main/google-cloud-bigquery/clirr-ignored-differences.xml
The entry would be something like this:
  <difference>
    <differenceType>7013</differenceType>
    <className>com/google/cloud/bigquery/StandardTableDefinition*</className>
    <method>*BiglakeConfiguration(*)</method>
  </difference>

@obada-ab @shollyman
Could i know when the next release is ? Because i need to make changes in other clients (spark-bigquery connector) using this dependency

@obada-ab @shollyman Could i know when the next release is ? Because i need to make changes in other clients (spark-bigquery connector) using this dependency

Next release should be in around 1-2 weeks

@obada-ab i see that PR was not able to merge, does every reviewer needs to approve this ? If so @shollyman can you please approve this ?

repo: googleapis/java-bigquery


text:
feat: promote to GA

This PR will cause release-please to create a release for 1.0.0. I won't merge it immediately -- instead, I will manually edit the merge request to only promote the google-cloud-pubsublite artifact is made GA.
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

[ ] Make sure to open an issue as a bug/issue before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
[ ] Ensure the tests and linter pass
[ ] Code coverage does not decrease (if any source code was changed)
[ ] Appropriate docs were updated (if necessary)

Fixes #604

We can change the title of the PR and use merge-on-green (add the automerge label)

Sounds good -- I've renamed the commit.
@chingor13 Tianzi mentioned that she was looking into whether the split of versions.txt was enough to release these two artifacts independently. I'm holding off adding the automerge label until then.

@manuelmenzella-google Jeff is fully aware of our needs :-)
This PR is okay to merge - we will hold off on proposed releases until 1) next week's major bump to all Java clients (may exclude Lite) 2) we think they are indeed what we want.

repo: googleapis/java-pubsublite


text:
README examples with environment variables are broken

The examples in the README that involve environment variables are broken.  For example:
  projectId: 'YOUR_PROJECT_ID' || process.env.GCLOUD_PROJECT,

In that example, the environment variable will never be used.  Instead, it should come first:
  projectId: process.env.GCLOUD_PROJECT || 'YOUR_PROJECT_ID',

Assigning to @bcoe as he is reviewing the corresponding fix PR #151

I've closed the PR, so please feel free to fix this any way you see fit.  Thank you for looking into it.

:wave:  closing in favor of #159, thanks for helping with this @cashpipeplusplus.

authors: BenWhitehead bcoe cashpipeplusplus

repo: googleapis/nodejs-datastore-session


text:
chore: change sort order for retrieving err items

This is being done to address the system test flakiness by having
the most recently created error item listed first in the list
of error items retrieved from the error reporting service.

This isn't a user visible change.  The errors-api-transport file, used to retrieve error groups from the API, is only used in the system test.

repo: googleapis/nodejs-error-reporting


text:
test: address test flake in system-tests

we've been seeing a frequent test flake recently, related to credentials being unset, let's make sure after each test we set credential environment variable back.
see: #940

I was hoping I'd figured out what was flaking, but have not yet.

repo: googleapis/nodejs-storage


text:
fix: Support generic updater

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

[x] Make sure to open an issue as a bug/issue before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
[x] Ensure the tests and linter pass
[x] Code coverage does not decrease (if any source code was changed)
[x] Appropriate docs were updated (if necessary)

Fixes #2205 🦕

Also addresses #2125.  It might be nice to have a glob: true example as well.

authors: jyoder-deloitte regseb

repo: googleapis/release-please


text:
Release ruby-style 1.24.0

set required ruby version to 2.4
set rubocop dependency to ~> 0.74.0

Commits since previous releasecommit d9c276f3b286f4a5225439222a86b1d11a5622c6
Author: Graham Paye
Date:   Thu Aug 8 14:26:57 2019 -0700
bump required ruby version to 2.4 (#17)

* bump required ruby version to 2.4
* bump rubocop dependency to ~> 0.74.0

commit 0eb4adad7e98cc4018ba83c0b1564691a28131af
Author: Daniel Azuma dazuma@google.com
Date:   Thu Jun 13 13:14:39 2019 -0700
Bump version to 0.3.1 (#16)

Code changes since previous release
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 03700f4..b81f8b3 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,9 @@
 # Release History

+### 0.3.1 / 2019-06-12
+
+* Fix file permissions
+
 ### 0.3.0 / 2019-05-06

 * Enforce expanded for Style/EmptyMethod
diff --git a/README.md b/README.md
index 731af02..69105b8 100644
--- a/README.md
+++ b/README.md
@@ -51,11 +51,12 @@ This library is licensed under Apache 2.0. Full license text is available in

 ## Supported Ruby Versions

-These libraries are currently supported on Ruby 2.3+.
+These libraries are currently supported on Ruby 2.4+.

 Google provides official support for Ruby versions that are actively supported
 by Ruby Core—that is, Ruby versions that are either in normal maintenance or
-in security maintenance, and not end of life. Currently, this means Ruby 2.3
-and later. Older versions of Ruby _may_ still work, but are unsupported and not
-recommended. See https://www.ruby-lang.org/en/downloads/branches/ for details
-about the Ruby support schedule.
+in security maintenance, and not end of life. Currently, this means Ruby 2.4
+and later. Starting with Ruby 2.4, minor releases of the google-style gem under
+`1.x.x` will correspond with the required Ruby version, with `1.24.x` requiring
+Ruby 2.4.
+See https://www.ruby-lang.org/en/downloads/branches/ for details about the Ruby support schedule.
diff --git a/google-style-1.24.0.gem b/google-style-1.24.0.gem
new file mode 100644
index 0000000..adf25c9
Binary files /dev/null and b/google-style-1.24.0.gem differ
diff --git a/google-style.gemspec b/google-style.gemspec
index 56ad6be..7b8ea7a 100644
--- a/google-style.gemspec
+++ b/google-style.gemspec
@@ -14,7 +14,7 @@

 Gem::Specification.new do |gem|
   gem.name          = "google-style"
-  gem.version       = "0.3.0"
+  gem.version       = "1.24.0"

   gem.authors       = ["Graham Paye"]
   gem.email         = ["paye@google.com"]
@@ -26,9 +26,9 @@ Gem::Specification.new do |gem|
   gem.files         = ["CONTRIBUTING.md", "CODE_OF_CONDUCT.md", "LICENSE",
                        "README.md", "google-style.yml"]

-  gem.required_ruby_version = ">= 2.3.0"
+  gem.required_ruby_version = ">= 2.4.0"

-  gem.add_dependency "rubocop", "~> 0.64.0"
-  gem.add_development_dependency "bundler", "~> 1.17"
+  gem.add_dependency "rubocop", "~> 0.74.0"
+  gem.add_development_dependency "bundler", "~> 2.0"
   gem.add_development_dependency "rake", "~> 12.3"
 end
diff --git a/google-style.yml b/google-style.yml
index 44452df..3404f91 100644
--- a/google-style.yml
+++ b/google-style.yml
@@ -13,7 +13,7 @@
 # limitations under the License.

 AllCops:
-  TargetRubyVersion: 2.3
+  TargetRubyVersion: 2.4
 Layout/AlignHash:
   EnforcedHashRocketStyle: table
   EnforcedColonStyle: table

This pull request was generated using releasetool.

I'm evaluating the recent changes.

We might want to add a section to README discussing the shifted semver nature of this gem. How to declare a dependency, etc...

@blowmage are you good with the updated README?

Yes, that looks good.
I would remove the google-style-1.24.0.gem file.

this PR is removing it, accidentally added it in the previous PR

Release is at https://github.com/googleapis/ruby-style/releases/tag/ruby-style/v1.24.0

repo: googleapis/ruby-style


text:
Remove ApiSource

Remove ApiSource (enum with values PROTO, DISCOVERY) to make toolkit pipeline more general
Abstract some ProtoElements away from SurfaceNamer.java
discogapic message surface to use same getter/setter names as gapic surface; e.g. a getter for a List<Warnings> will be named getWarningsList to follow gapic naming convention
remove various outdated TODOs

Codecov Report

Merging #1880 into master will increase coverage by 0.09%.
The diff coverage is 93.33%.

@@             Coverage Diff              @@
##             master    #1880      +/-   ##
============================================
+ Coverage     84.98%   85.07%   +0.09%
+ Complexity     4726     4710      -16
============================================
  Files           440      440
  Lines         18677    18638      -39
  Branches       1986     1980       -6
============================================
- Hits          15873    15857      -16
+ Misses         2105     2086      -19
+ Partials        699      695       -4

Impacted Files
Coverage Δ
Complexity Δ

...om/google/api/codegen/config/ProtoMethodModel.java
88.23% <ø> (-0.18%)
34 <0> (-1)

...oogle/api/codegen/config/DiscoveryMethodModel.java
82.29% <ø> (-0.19%)
38 <0> (-1)

...i/codegen/transformer/DiscoGapicMethodContext.java
96.87% <ø> (+5.69%)
12 <0> (ø)
:arrow_down:

...google/api/codegen/config/ProtoInterfaceModel.java
92.3% <ø> (-0.29%)
13 <0> (-1)

...a/com/google/api/codegen/config/DiscoApiModel.java
67.64% <ø> (-0.93%)
10 <0> (-1)

.../google/api/codegen/config/ProtoFieldSelector.java
100% <ø> (+14.28%)
3 <0> (ø)
:arrow_down:

...main/java/com/google/api/codegen/GapicContext.java
50% <ø> (+14.1%)
5 <0> (ø)
:arrow_down:

...api/codegen/transformer/GapicInterfaceContext.java
95.08% <ø> (-0.2%)
46 <0> (ø)

...e/api/codegen/viewmodel/StaticLangRpcStubView.java
100% <ø> (ø)
2 <0> (ø)
:arrow_down:

...le/api/codegen/transformer/GapicMethodContext.java
96.87% <ø> (+2.93%)
12 <0> (ø)
:arrow_down:

... and 34 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fb5ea5d...a1ad2fe. Read the comment docs.

PTAL

authors: andreamlin codecov-io

repo: googleapis/toolkit


text:
Support OTF (CFF) fonts with fontbakery-fix-nbsp.py

$ fontbakery-fix-nbsp.py --autofix *otf
ER: global name 'addCFFGlyph' is not defined
$

Ping :)

I'll try to tackle this at an upcoming fontTools documentation sprint. cc @n8wilis

migrated to https://github.com/googlefonts/tools/issues/22

repo: googlefonts/fontbakery


text:
Move some types to fontdrasil. No edits, just move.

Meant to allow access to types to fea-rs. I prefer to make non-move changes in a separate follow-on.

I'm still of the opinion this is a good idea but enough has changed I'd probably want to do it in a new PR

repo: googlefonts/fontc


text:
Grand unified build theory

This has two main aims:

To generalise the various fix-vf-meta/gen_stat.py-like scripts floating around and have a data-driven STAT table solution for arbitrary-axis variable fonts, instead of everyone copying and hacking their own Python code.
To generalise the various build-static.sh/build-vf.sh-like scripts floating around and have a single, config-file-driven project build script.

I'm still very much working on this. The gen_stat stuff isn't there at the moment, but the second part is working nicely with Glyphs sources; I've got Texturina building from a simple JSON config file instead of a multitude of custom shell scripts.

Nice!
I've already covered the stat part, take a look at https://github.com/googlefonts/gftools/blob/master/Lib/gftools/stat.py. The function gen_stat_tables takes an arbitrary number of fonts which belong to a single family and will generate a STAT table for each font. It does use our Axis Registry though so it may be too restricting for some users.

Oh, that's fantastic news! (And partially why I thought I'd send out a draft PR, in case I'm reinventing wheels again.)
So, um, why doesn't gftools-fix-vf-meta use it...?

So, um, why doesn't gftools-fix-vf-meta use it...?

It's legacy. I should really add a deprecation to this script, or just rewrite it and use the stat module.

There's also fix_family in the fix module which should take care of calling each individual fix function for a family fonts.
Personally, I'd prefer yaml over json for the config file but this isn't a big deal.

fix_font works better for this workflow than fix_family but there's not a huge difference between them. YAML is a good idea, and one I have been thinking about ever since I went with JSON (without really thinking), because I have grand plans involving GitHub Actions.

To be honest the config file is largely unnecessary. You can also do:
gftools builder --family-name=Castoro UFO/Castoro-Regular.ufo UFO/Castoro-Italic.ufo
gftools builder --family-name=JetBrainsMono JetBrainsMono.glyphs JetBrainsMono-Italic.glyphs

and it will do the right thing. It's only if you want to customize what kinds of font are produced, where they're put, etc.

I'm going to leave this until Friday and we can discuss more then.

Would be worth checking if we can replicate something like https://github.com/lettersoup/Sofia-Sans/blob/master/sources/sofia_stat_table.py - may need additional config.yaml options.

There's also https://github.com/daltonmaag/statmake for putting STATs into VFs.

Interesting!
gftools.stat is nice because it deals with the common cases for you instead of requiring you to write an explicit stylespace. Perhaps the solution would be to take a stylespaceFile option in the config and, if present (or if org.statmake.stylespacePath is present), use statmake for that, gftools.stat otherwise; that would fix the Sofia issue.
I don't like the duplication of axes between the stylespace and designspace files. Feels wrong when we have that information already. But that's partially a problem with the designspace format; it doesn't take STAT information into account, and I believe it should. And also we have the problem that designspace files only allow you to describe one variable font in a family, when there may be more than one (as in the case of regular/italic).
The real solution is a layer above designspace which specifies relationships between multiple designspaces, and also includes style linking information. But it's a load of effort to design and writing tooling for yet another variable font designspace thing. I'll just use the stylespaceFile thing I described above, and wait until the next UFO meeting before airing my grievances.

Oh, you have all that in designspace 5.0. Very interesting.

Indeed. If only the imaginary v5 would be an actual thing, then I wouldn't have had to come up with statmake 😬.

It's not completely imaginary! You know what it looks like, all you need to do is modify designspaceLib, statmake, and fontmake to support it...

(The serious point here is that an idea for a new format is far more likely to gather support and approval if there is something close to a working implementation already.)

If only someone would make a prototype, i.e. by modifying https://gist.github.com/madig/5a3e13894f75287272a06983052b4322!

Yeah, that trick normally works on me but I'm up to my eyeballs in other stuff right now. :-)

IIRC, yes. You give it names for all fvar stops you have in your entire project and then it tailors the list to each VF you apply it to. For full control, you need buildStatTable().

Right. Now you just put the STAT axes stuff into config.yml, it will add ital axes where necessary and then send it to buildStatTable:
sources:
  - SofiaSans-VF-New.glyphs
  - SofiaSans_Italic_VF-New.glyphs
familyName: Sofia Sans
stat:
  - name: Width
    tag: wdth
    values:
    - name: UltraCondensed
      value: 50
    - name: Condensed
      value: 75
    - name: SemiCondensed
      value: 87.5
    - name: Normal
      value: 100
      flags: 2
  - name: Weight
    tag: wght
    values:
    - name: Hairline
      rangeMinValue: 1
      nominalValue: 1
      rangeMaxValue: 50
    - name: Thin
      rangeMinValue: 50
      nominalValue: 100
      rangeMaxValue: 150
    - name: ExtraLight
      rangeMinValue: 150
      nominalValue: 200
      rangeMaxValue: 250
    - name: Light
      rangeMinValue: 250
      nominalValue: 300
      rangeMaxValue: 350
    - name: Regular
      rangeMinValue: 350
      nominalValue: 400
      rangeMaxValue: 450
      flags: 2
      linkedValue: 700
    - name: Medium
      rangeMinValue: 450
      nominalValue: 500
      rangeMaxValue: 650
    - name: Bold
      rangeMinValue: 650
      nominalValue: 700
      rangeMaxValue: 750
    - name: ExtraBold
      rangeMinValue: 750
      nominalValue: 800
      rangeMaxValue: 850
    - name: Black
      rangeMinValue: 850
      nominalValue: 900
      rangeMaxValue: 950
    - name: ExtraBlack
      rangeMinValue: 950
      nominalValue: 1000
      rangeMaxValue: 1000

it will add ital axes where necessary and then send it to buildStatTable:

It would be great if it could handle other cases such as a family which consists of a normal width font and a condensed font. In order to establish this relationship, you could define a stat for each font e.g
sources:
  - NormalWidth.glyphs
  - Condensed.glyphs
familyName: MyFamily
stat:
  - source: NormalWidth.glyphs
    - name: Width
      tag: wdth
      values:
      - name: Normal
        value: 100
        flags: 2
    - name: Weight
      tag: wght
      values:
      - name: Regular
        rangeMinValue: 350
        nominalValue: 400
        rangeMaxValue: 450
        flags: 2
        linkedValue: 700
      - name: Bold
        rangeMinValue: 650
        nominalValue: 700
        rangeMaxValue: 750

  - source: Condensed.glyphs
    - name: Width
      tag: wdth
      values:
      - name: Condensed
        value: 75
        linkedValue: 100
    - name: Weight
      tag: wght
      values:
      - name: Regular
        rangeMinValue: 350
        nominalValue: 400
        rangeMaxValue: 450
        flags: 2
        linkedValue: 700
      - name: Bold
        rangeMinValue: 650
        nominalValue: 700
        rangeMaxValue: 750

This has the added benefit that each font in a family can have different axis ranges as well.

Sure, will work on.

@simoncozens shall I take another look and merge if good?
Since you're hammering glyphs3 support, I can get this across the line if you want?

Thanks; it should be fine, but please review and do with it what you will. I am up to my eyeballs in Glyphs3 and it really isn't my idea of fun, so it would be great if you could take this off my plate!

@googlebot I consent.

Thanks Simon.
I've just added a few commits which add a functional test, formatting and importing a few more missing dependencies.
It seems we may have an issue regarding output paths (or me just nitpicking). If I have the following config
sources:
  - Lora.glyphs
outputDir: "."
familyName: Lora

The output will be saved relative to my cwd. Wouldn't it be better if the output was relative to the config file path instead?

Good point!

It does already chdir to the configfile though in l.89. Is that not working somehow?

It didn't work for me. I discovered this when I added the test case.

Strange but I'm no longer able to replicate this, I'll merge and if it resurfaces, I'll fix it.

Thanks, guys! This new feature will likely make upstream font repo builds much simpler. I'm excited about it and I'll soon start trying to use it on some font repos.

authors: felipesanches m4rc1e madig simoncozens

repo: googlefonts/gftools


text:
Add metrics to Match filter.

Let's increment counter metrics here for when we find a match vs not, for visibility
Originally posted by @iffyio in https://github.com/googleforgames/quilkin/pull/447#discussion_r759939668

Working on this right now. Needed a good entry to get me back into the Quilkin codebase.

authors: XAMPPRocky markmandel

repo: googleforgames/quilkin


text:
Dialog destroyed on rotation

The dialog fragment for the fingerprint authentication does not survive rotation, despite having setRetainInstanceState(true) set. This appears to be because the CancellationSignal does not emit the cancellation before the dialog fragment is recreated and resumed again -- mSelfCancelled = false then, causing mCallback.onError() to be called and to close the newly created dialog fragment to be dismissed.
Flow looks something like this (user selects Purchase to start):

FingerprintAuthenticationDialogFragment created:

onResume() called -- mFingerprintUiHelper.startListening() called

User rotates device

onPause() called -- mFingerprintUiHelper.stopListening() called (cancels CancellationSignal, sets mSelfCancelled = true)
No messages sent through FingerprintManager.AuthenticationCallback during this time

New FingerprintAuthenticationDialogFragment created:

onResume() and startListening() called -- setting mSelfCancelled = false
now we get a cancellation message in UI Helper's onAuthenticationError, but I believe this cancel message is from the previous onPause() call

So it looks like the cancellation is not sent quickly enough on a rotation, causing the fragment created after the rotation to receive that cancellation message, which then closes the dialog fragment.

Here's a log of the flow as well:

05-24 15:39:30.241 8110-8110/ D/DEBUG_TAG: startListening // Purchase pressed
05-24 15:39:39.811 8110-8110/ D/DEBUG_TAG: stopListening // Rotation happens
05-24 15:39:39.878 8110-8110/ D/DEBUG_TAG: startListening
05-24 15:39:39.882 8110-8110/ D/DEBUG_TAG: onAuthenticationError: errString: Fingerprint operation canceled. mSelfCancelled: false
05-24 15:39:40.110 8110-8110/ D/DEBUG_TAG: stopListening
05-24 15:39:40.203 8110-8110/ D/DEBUG_TAG: onAuthenticationError: errString: Fingerprint operation canceled. mSelfCancelled: true

+1

Late answer but I also found it the hard way.
The way it is handled is:
if(errMsgId !=        android.hardware.fingerprint.FingerprintManager.FINGERPRINT_ERROR_CANCELED) {   //do your thing    }

I am closing this issue/PR, as it has been migrated to the new repo linked above in the comments. Thank you!

authors: Kdoherty11 alex-townsend codingjeremy nikhil-thakkar

repo: googlesamples/android-FingerprintDialog


text:
Wake Word Functionality not supported

Hi,
As I am able to build the sdk on my linux machine.
It is working without wakeword.
Can you please let me know how to build the sdk with wakeword.
Thanks,
Sumit

The C++ sample does not include a wake word detection component. If you want that, you should find a third-party implementation or build your own.

repo: googlesamples/assistant-sdk-cpp


text:
Running a simple PRIMAVERA example - nothing happens

I try to run examples/primavera/prim_atm_6hr.py with a very simple variablelist:

{
    "Amon": [
        "tas",
        "ts"
    ]
}

Everything seems to go well, no error message, but nothing happens -  I don't get any cmorized output. Here is the log:

INFO:ifs2cmor:Executing 0 IFS tasks...
INFO:ifs2cmor:Post-processing surface pressures...
INFO:ifs2cmor:Post-processing 0 IFS tasks...
INFO:ifs2cmor:Post-processed batch of 0 tasks.
INFO:ifs2cmor:Cmorizing 0 IFS tasks...

What am I missing?

Klaus is that the full log or is it still complaining about the variables in the tables?

This is the full log. I have updated ece2cmor3 from the git repository this morning, and also added the submodules to get the CMOR tables, it's all in place now.

Unfortunately I cannot reproduce it, on my system the varlist you posted works as expected. Can you put print statements at the beginning and the end of the filter_tasks function in ifs2cmor.py (line 128) to see how many tasks are passed to it, and how many it filters out? Otherwise you can step through the code by running the script with 'pdb', which works just like gdb.

It may also be useful to put some print statements in the main script, to see whether the jsonloader indeed converts your variable list into tasks.

Klaus I added extra logging to the json parsing code in aea5e2ad56728ad1e22cd9921e225f6eaf958ae1, which may help us to pin the bug...

I updated ece2cmor3 and now get some extra output:

INFO:jsonloader:Found 2 cmor target variables in input variable list.
INFO:jsonloader:Created 2 ece2cmor tasks from input variable list.
INFO:ifs2cmor:Executing 0 IFS tasks...
INFO:ifs2cmor:Post-processing surface pressures...
INFO:ifs2cmor:Post-processing 0 IFS tasks...
INFO:ifs2cmor:Post-processed batch of 0 tasks.
INFO:ifs2cmor:Cmorizing 0 IFS tasks...

Some tasks are created, but somehow they don't end up as IFS tasks.

Ok I added more logging and restructured the filter_tasks a bit, you might want to retry after checking out rev. 53746ddf4e5abf45f67b24807dcf851db9d936bb

Now I get:

INFO:jsonloader:Found 2 cmor target variables in input variable list.
INFO:jsonloader:Created 2 ece2cmor tasks from input variable list.
INFO:ifs2cmor:Inspecting 0 tasks.
INFO:ifs2cmor:Validated 0 tasks for processing.
INFO:ifs2cmor:Executing 0 IFS tasks...
INFO:ifs2cmor:Post-processing surface pressures...
INFO:ifs2cmor:Post-processing 0 IFS tasks...
INFO:ifs2cmor:Post-processed batch of 0 tasks.
INFO:ifs2cmor:Cmorizing 0 IFS tasks...

I tried running with pdb but don't know where to put breakpoints. At l.128 in ifs2cmor varibale task is already empty.
Sine you can run this simple example but I cannot I wonder if something in the whole process is overly sensitive to the exact version of python or any of the modules. Would it make sense to compare our setups?

I suspect our python versions differ. You were also the only one suffering from the temp_dir_ problem. I suspect your python version strictly requires all global module variables to be declared with 'global' inside a function. Can you try once more with the latest commit I did, and can you also share your version of python?
If my theory is correct, I will add the global declarations everywhere, because it is prescribed by the syntax.

BTW does the test suite run on your system? To run it, type nosetests -v in the cloned repo

The latest output shown above (https://github.com/goord/ece2cmor3/issues/16#issuecomment-286780119) is with the latest version, the behaviour hasn't changed.
My python version is 2.7.12, and here are my installed packages (CMOR is 3.2.2!):

appdirs==1.4.3
cdo==1.3.2
CMOR==3.2
f90nml==0.20
netCDF4==1.2.7
nose==1.3.7
numpy==1.11.3
packaging==16.8
pyparsing==2.2.0
python-dateutil==2.6.0
six==1.10.0
testfixtures==4.13.3

Here are the results from nosetests -v: nosetest_triolith.txt
A few warnings, otherwise things seem to work OK.

That seems to be the same configuration as mine. Sorry for the inconvenience, I added extensive logging this time...would it be possible to run your script once more and post the log? Thanks

@goord :+1:   The inconvenience must be on your side, I just update, run and don't understand why it's not working, while you try to troubleshoot my problems remotely which is not the easiest thing to do.
Here is the latest output, not much new:

INFO:jsonloader:Found 2 cmor target variables in input variable list.
INFO:jsonloader:Created 2 ece2cmor tasks from input variable list.
INFO:ece2cmor:Selected 0 IFS tasks from 0 input tasks
INFO:ece2cmor:Extra info for bug#16: the given input tasks are...
INFO:ifs2cmor:Inspecting 0 tasks.
INFO:ifs2cmor:Validated 0 tasks for processing.
INFO:ifs2cmor:Executing 0 IFS tasks...
INFO:ifs2cmor:Post-processing surface pressures...
INFO:ifs2cmor:Post-processing 0 IFS tasks...
INFO:ifs2cmor:Post-processed batch of 0 tasks.
INFO:ifs2cmor:Cmorizing 0 IFS tasks...

Ok, Klaus I think I found your problem: the prim_atm_6hr script removes all tasks that originate from 3-hourly output (see line 56 in the prim_atm_6hr.py), so it can be applied to the 6-hourly filtered output without error messages. Those variables you inserted are surface variables (3-hourly), so you can either comment out line 56, or apply prim_atm_3hr.py to your varlist.
Maybe we should merge the scripts and distinguish between 3- and 6-hourly output variables with some command-line option...

@goord cudos! After commenting l.56 everything works fine and I get the output.
I don't understand all the details of the ece2cmor3 yet, but do you say that tasks are hardcoded to work on either 3-hourly or 6-hourly data? That may good enough for the first prototypes, but we have to make sure that the tool becomes flexible enough to process even model output that has been saved only every 6 hours. But that's something to keep an eye on in the future, so I close this issue now.
Thanks a lot for your great assistance and patience!

authors: goord klauswyser


text:
🛑 goormEDU is down

In 2f04f00, goormEDU (https://edu.goorm.io) was down:

HTTP code: 403
Response time: 731 ms

Resolved: goormEDU is back up in 4957406 after 11 minutes.

repo: goorm-dev/goorm-status

license: MIT


text:
🛑 goormEDU is down

In a1aa1de, goormEDU (https://edu.goorm.io) was down:

HTTP code: 403
Response time: 718 ms

Resolved: goormEDU is back up in 86e9000 after 8 minutes.


text:
🛑 goormIDE is down

In 9324f67, goormIDE (https://ide.goorm.io) was down:

HTTP code: 403
Response time: 542 ms

Resolved: goormIDE is back up in 4e96734 after 17 minutes.


text:
Uncaught TypeError: Object(...) is not a function

Bug
TypeError: Object(...) is not a function error will occur on compile. Error looks like this:
Uncaught TypeError: Object(...) is not a function
    at Module.../../../../../../../../../../Desktop/Code/personal-project/echomobile2/node_modules/@react-native-community/masked-view/js/MaskedView.js (MaskedView.js:14)
    at __webpack_require__ (bootstrap:789)
    at fn (bootstrap:100)
    at Module.../../../../../../../../../../Desktop/Code/personal-project/echomobile2/node_modules/@react-native-community/masked-view/index.js (index.js:1)
    at __webpack_require__ (bootstrap:789)
    at fn (bootstrap:100)
    at
...

Environment info

Library
Version

@gorhom/animated-tabbar
^2.1.1

react-native
40.0.1

react-native-reanimated
~1.13.0

react-native-gesture-handler
^1.9.0

react-native-svg
12.1.0

Steps To Reproduce

Use the sample code
On compile there is an error on me

Describe what you expected to happen:
No error
Reproducible sample code
https://pastebin.com/raw/pqcfVrw4
Thanks for your help (I might just be doing something wrong!)

you need to set icon components like this
component: props => <Feather {...props} name="activity" size={24} color="black" />,

you need to set icon components like this
component: props => <Feather {...props} name="activity" size={24} color="black" />,

I've set it. However, same error.
Full code: https://pastebin.com/raw/MYY5enG0
Thanks for your help! @gorhom

I've set it. However, same error.
Full code: https://pastebin.com/raw/MYY5enG0
Thanks for your help! @gorhom

you need to set icon components like this
component: props => <Feather {...props} name="activity" size={24} color="black" />,

@gorhom, I have made the change to no avail. Consider reopening. Thanks.

you need to set icon components like this
component: props => <Feather {...props} name="activity" size={24} color="black" />,

@gorhom, I have made the change to no avail. Consider reopening. Thanks.

repo: gorhom/react-native-animated-tabbar


text:
Some kind of testing for elements

Currently, I test just by hand, by clicking on all the important functionalities, and I check whether the frontend works in this way. However as the library is getting bigger it gets much more tedious and it is possible that I forget some functionality.
Frontend tests:

whether the elements that should be displayed are really displayed
whether the components that should be displayed are really displayed
whether the elements that should be focused are really focused

Integration tests:

whether clicking on the elements with endpoints triggers exactly what should be triggered

Resolved in #6

repo: gortibaldik/visuallm


text:
Setup GoReleaser for Linux & macOS.

GoReleaser is setup to support releasing from Linux and macOS. For now, changelogs are off since we don't have any releases yet.

The rest of the code looks good

authors: felicianotech mibragimchayev

repo: gothamhq/gotham


text:
Actix

Hey all. I'm currently working on an Actix implementation for the realworld backend API spec. It's located here.
You can find more information about actix at their website here. It's one of the fastest frameworks available right now as shown on TechEmpower benchmarks, and it benefits from being relatively high-level and extensible with a number of other crates.
I also believe it would be much easier to grok and extend than the current Rust implementation provided.
This Actix implementation doesn't solely use actix, of course. In my Cargo.toml file I'm using a number of robust and community-trusted crates to provide more features and functionality.
Posting it here for exposure. If anyone would like to take a look and/or help out, that'd be great, as currently it needs to be reviewed. I think it'd also make pretty decent reference material for someone unfamiliar with the actix framework or Rust in general.
Thanks!

I've finally finished all the logic for this application and all the endpoints should work as intended, so I suppose the next step now is to put it in front of other Rust developers and get a sense of where things could be improved.

Hello we are currently moving all work in progress to Github Discussions.
I'll close this issue by now, you can find instruction to open a discussion there : https://github.com/gothinkster/realworld/discussions/633
Thanks for your contribution !

authors: fairingrey geromegrignon

repo: gothinkster/realworld

license: mit


text:
Login and Register both fail the first time

Including both the live demo and my local cloned project, every single time you try to login and register with valid credentials, it silently fails (without any errors). The second or third time,  etc.,  it works.
I suppose the problem lies somewhere in the vuex implementation.

For some reason, the first time I try to register, the POST to the /users endpoint is made before the mongoose user.insert.
POST /users - - ms - -

It seems that the first Login Or Register request doesn't even reach the server.

Listening on port 3000
Mongoose: users.ensureIndex({ username: 1 }, { unique: true, background: true })
Mongoose: articles.ensureIndex({ slug: 1 }, { unique: true, background: true })
Mongoose: users.ensureIndex({ email: 1 }, { unique: true, background: true })
Mongoose: users.findOne({ email: 'firstLoginAttempt@mail.com' }, { fields: {} })
POST /users/login - - ms - -
Mongoose: users.findOne({ email: 'secondLoginAttempt@mail.com' }, { fields: {} })
POST /users/login 200 98.776 ms - 314
Mongoose: users.findOne({ _id: ObjectId("5a9b776ae3b19508b0bb29e8") }, { fields: {} })
GET /user/ 200 10.098 ms - 314
Mongoose: users.findOne({ _id: ObjectId("5a9b776ae3b19508b0bb29e8") }, { fields: {} })
GET /user/ 304 9.706 ms - -

I solved these issues by changing v-on:submit="onSubmit" to  v-on:submit.prevent="onSubmit" in the Register and Login forms.

Thanks for pointing this out!
If I understand correctly you're running the api locally and changed the frontend project to use your local api, and 'onSubmit' doesn't trigger a call to the api ?

authors: AlexanderOpran vilsbole

repo: gothinkster/vue-realworld-example-app


text:
gtk: Add Entry.SetMaxWidthChars() and Entry.GetMaxWidthChars()

See issue #153. Please merge :-)

these api are added in gtk 3.12, how about add them in another go file?

authors: ERnsTL lidaobing

license: isc


text:
Story to show tables with a 75% and 25% column

Add a story to the table component (and grid component) to show a table with a 75% and 25% column.
We would use this to ensure mobile users see appropriate content (e.g. 2 columns within viewport or stacked).

Related #567

Closed with #563

authors: penx stevesims

repo: govuk-react/govuk-react


text:
Move google analytics code to RouteActions

It doesn't fit well in the Application.js, also the title would not match since the page it's updated using an action which is async.

@gpbl Where would you put them? I wanted to avoid putting them into each and every action, but I do have each of my actions setting a title property on the route. The NAVIGATE_SUCCESS action is then handled in a custom store that now has the correct title and urls, from which I trigger analytics. Did you come up with another solution?

@samkelleher what about using the custom store handling NAVIGATE_SUCCESS?

@gpbl This is what I have ended up doing, I have a TitleStore which manages the document.title and now calling Google Analytics. It works. However it doesn't record the initial page load, since there is no in-page page navigation.  I'm working on this now to find an elegant solution. I can feed back what I end up doing. I've been using your amazing starter project as a guide. 😍

authors: gpbl samkelleher


text:
how can i check if tcmalloc work with code?

Hi, I build libtcmalloc_minimal.a in armv7a and arm64 and link it with my android project,but I don't know whether it works with calling new and delete function?Is there a way to check if it works in my porject with code?

simplest idea that came to mind is to just put __builtin_trap() somewhere in tc_malloc or something, and then see if program linked with tcmalloc actually crashes there.

@zengxianhua it works?

authors: alk gezihua123 zengxianhua

repo: gperftools/gperftools


text:
[graphql_http_link] Exception thrown in HttpLink causes app to freeze.

When a server respond with a 300 >= status code.
HttpLinkServerException will be thrown, which causes the app to freeze.
https://github.com/gql-dart/gql/blob/master/links/gql_http_link/lib/src/link.dart#L122
In the example below, I intentionally cause a typo in the query to reproduce this error.
But in real life, even though I type everything right.
Sometimes the problem might come from the backend itself, and I couldn't change that backend on my own.
So, it would be great if we could find a way to handling these errors.
import 'dart:io';
import 'package:graphql/client.dart';

const getJobsQuery = r'''
query ExampleQuery {
  getChats {
    i
  }
}
''';

void main() async {
  try {
    final graphQLClient = GraphQLClient(
      cache: GraphQLCache(),
      link: HttpLink('https://api.chat.graphql-flutter.dev/graphql'),
    );
    final result = await graphQLClient.query<dynamic>(
      QueryOptions<dynamic>(document: gql(getJobsQuery)),
    );
    if (result.hasException) {
      throw Exception(result.exception!.graphqlErrors[0].message);
    }
    print(result);
  } catch (e) {
    throw Exception(e);
  }
  exit(0);
}

When I run your sample, the query completes and has a field set that describes the error.
The app should not freeze because of that if you handle the response correctly.
What would you expect to happen instead if the server responds with an error?

You are absolutely right. I have my breakpoint on uncaught exception, which is why I thought it freeze.
Now everything works fine!

authors: knaeckeKami phetdekde

repo: gql-dart/gql


text:
Allow programmatic file deletion

The current API design supports just a single way of deleting a file
files: {
  "file/to/delete.txt"" null
}

However, it would be useful to trigger a file deletion based on specific conditions, such as the example below:
files: {
  "file/to/delete.txt": ({ exists, encoding, content }) => {
    // do not create the file if it does not exist
    if (!exists) return null;

    const fileContent = Buffer.from(content, encoding).toString("utf-8")

    if (fileContent.includes('abc')) {
      // trigger file deletion
      return ???
    }

    // do not alter file content
    return null;
  }
}

Since both null and undefined already have different functionalities, it is unclear what return value could be used to instruct the library to initiate a file deletion. What are your thoughts?

Since both null and undefined already have different functionalities, it is unclear what return value could be used to instruct the library to initiate a file deletion. What are your thoughts?

I think the correct way to do this is to use Symbols. See how mapObjectSkip is implemented in map-obj. I don't mind releasing a breaking change for this.
What do you think?


text:
Creation UMBRELLA unit for GRM

New "UMBRELLA" unit in GRM (Grabz Radioactivity Mode) will protect some area of map from influence of any type of ERS (Enemy  Radioactivity Sourse).
Umbrella can be activated by supplying some amount of energy via connection to CN or by Guppy.
Setting parameters of new units:

radius of effectivity
energy amount (for activation)
Generally possible variations:

Radius of umbrella's effectivity can be changed (increasing, decreasing, non-changing) by time.
Instead of energy activation of umbrella can be made by anti-creeper (2 variants: some period of time on land under umbrella unit or by direct supplying from CN or by Guppy with Anti-Creeper).
Generally possible mixture condition for activation: energy+anti-creeper (but this seems too tricky).
Any comments appreciated :)

Interesting (if this will be possible) to create possible shape of anti-radiation zone of umbrella not only round/ring but also square.

As additional possibility for activation of Umbrella unit - to use ShieldKey system (like for "blind inhibitors" but different type/shape).

Possible image for ARU unit:

And new approach about ARU (Anti-Radiation Umbrella) unit:

small image of unit with U (not H) inside, color can be green or pls suggest any variants. As variant - red and became green after activation.
Important: any ARU units will be pair (two the same unit). If player activate  by ammo/energy any one of this ARU unit - the othe ARU unit (of pair) will be also activated.
Above unit will be visible parameters of protection zone and number such like U1 R15 (Umbrella #1, Radius - 15).

The simplest variant (from player point of view) umbrella protect some area/zone from any influence of radiation and not influence on creeper/anti-creeper etc.
Possible bunch (2-3-4) of umbrellas with the same number can be activated by supplying any one from bunch by ammo/energy only from CN.
If no one of umbrella in bunch not connected to CN - all umbrellas stop working.


text:
Expose errors

Instead of not replying, it would be better if errors were exposed

Which level of error would you like to expose ?
For instance, trying to query the stabilityai/stable-diffusion space, I get a gradio internal error :
    serialized_input = block.serialize(inputs[i])
AttributeError: 'Dataset' object has no attribute 'serialize'

But when querying the mirrored abidlabs/images space I might wait a long time to get no answer (understandable, with the current queue), or explicitely get an  asyncio.exceptions.CancelledError much sooner.
The second might be caught and sent back to the channel as a timeout, but I don't know if users should be exposed to the first one as is.

Good point @SaboniAmine! How did you see the gradio internal error when you tried to query stabilityai/stable-diffusion space?

In terms of the second error, I think we should also expose the queue ETA when people first make a request to a particular Space. However, this should probably be a separate issue. Would you like to go ahead and create it?

authors: SaboniAmine abidlabs

repo: gradio-app/gradio-discord-bot


text:
Nag user about mixing Kotlin plugin versions in a multi-project build

Configuration injection in multi-project builds involving heterogeneous Kotlin version won't be supported and it's important the user is warned to correctly identify the problem (which might surface as a "ClassLoader constraint violation" or "Task not found").

Relates to #138

This is a general problem of the PluginManager - it only checks for class equality, but not if another class of the same name was loaded in another classloader already. We should add a warning there.

authors: bamboo oehme

repo: gradle/gradle-script-kotlin


text:
Complete documentation on fine grained dependency managment APIs

In fine_grained_dm_apis.adoc:

the sections resolution-result-api and artifact-view-api need to be filled in, removed or reworked.
the sections about attributes most likely need to be removed as the content is in variant_aware_plugins.adoc.

Structuring/removing blanks are handled as part of #2726.
Follow ups for missing content: #10867, #10868

authors: jjohannes ljacomet

repo: gradle/gradle


text:
Demonstrate how to aggregate Jacoco reports in a multi-project

I've seen this question a number of times.

Does this duplicate https://github.com/gradle/gradle/issues/10708 ?

Yes, thanks.
Closing as duplicate.

authors: pioterj vlsi


text:
Demonstrate additional test suite in the same project (e.g. integration tests)

This is an extremely common use case for which we don't have higher-level abstractions and there are various examples of how to do this floating around. It's currently included in one of the init templates.

There are quite some users of the gradle-testsets-plugin. I believe that the plugin helps us greatly reduce boilerplate, and it would be nice to have something like that provided as a core feature maybe. Just a suggestion.

Thanks @rkrisztian for mentioning the gradle-testsets-plugin. It does show a lack in Gradle for that specific use case. The samples are mostly meant about showing what can be done with Gradle. We are a bit shy to mention 3rd party plugin inside the documentation for the moment they fall behind. This is a lack in the whole community plugin which is how do you promote a plugin that solve a specific use case. The samples work hard on making those use cases explicit.

authors: lacasseio pioterj rkrisztian


text:
No newlines when executing "gradle --version" (windows)

When I run gradle --version with a nightly version on windows the output is missing newlines.
If I explicitly set --console plain then the output is correct.
Expected Behavior
>gradle -version

------------------------------------------------------------
Gradle 3.6-20170309000026+0000
------------------------------------------------------------

Build time:   2017-03-09 00:00:26 UTC
Revision:     67719c34af2ccbff7add98fe659e26ada7ea2391

Groovy:       2.4.9
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_112 (Oracle Corporation 25.112-b15)
OS:           Windows 10 10.0 amd64

Current Behavior
>gradle -version
 ------------------------------------------------------------
                                                             Gradle 3.6-20170309000026+0000
                                                                                ------------------------------------------------------------

 Build time:   2017-03-09 00:00:26 UTC
                                      Revision:     67719c34af2ccbff7add98fe659e26ada7ea2391

                                                                                Groovy:       2.4.9
                                                                                Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
                            JVM:          1.8.0_112 (Oracle Corporation 25.112-b15)
                                                                                OS:           Windows 10 10.0 amd64

Your Environment
Nightly build (3.6-20170309000026+0000)
Windows Command Prompt

Thanks a lot @rbaradari for this issue. It is, in fact, a issue related to the new console. Fortunately, PR https://github.com/gradle/gradle/pull/1462 fixes this problem. We will see to merge the PR and fix your issue in the process.
Could you tell us which version of Windows are you using to get this behavior? This would help us ensure no additional issue is introduced.

This is now fixed in master and will be included in the next nightly. I will close the issue. If you see the problem again, reopen the issue so we can prioritize the work.

authors: lacasseio rbaradari


text:
@since should be used in public API

It's very common to miss @since tag in Javadoc for elementes (annotations, methods, ...) in the Gradle public API. Due to that it's quite unpleasant for a plugin author to check with which version his/her plugin is compatible using for example @CacheableTask.
Expected Behavior
Javadoc for public API (annotations, methods, ...) contains @since tag (at least for new elements adding in Gradle 4.x+)
Current Behavior
No information in which version given API element has been added.

Usually we are doing a relatively good job in adding and checking @since and @Incubating annotations. We also started to add more automation around these aspects though there's definitely room for improvement.
@lptr Could you please add the @since and @Incubating annotation to @CacheableTask?

We are actively working on improving the points you mentioned above and track this with internal issues. I am going to close this issue for now. Thanks for speaking up on these issues.

Great to hear. Probably I just had bad luck with some elements I was looking at in the past.

@szpak Certainly let us know if you find other place where @since is missing.

authors: bmuschko szpak


text:
Improve test coverage for compiler daemons

While investigating the issue related to https://github.com/gradle/gradle/pull/2505 it became apparent that we don't have a lot of test coverage for verifying that compiler daemons get the correct configuration from the Compile task they are associated with.  We should better define what is and is not expected here and pin it down with some better test coverage.  Some questions that I had while looking at this:

Should we warn when a user sets something on the Compile task that will not be honored in the compiler daemon (e.g. options.forkOptions.executable)?
Are there settings on the Compile task that we do not currently respect that should be?
There are some places where there are duplicate settings (e.g. options.forkOptions.memoryInitialSize vs groovyOptions.forkOptions.memoryInitialSize).  Right now, we merge the values - should we warn when these settings are different?
Should we better document the behavior when options.fork = true in the user guide and/or dsl reference?

@ghale Is this something you are actively working on?

Not at the moment, no.

authors: bmuschko ghale


text:
TYPESAFE_PROJECT_ACCESSORS: rootProject naming should not lead to InvalidUserDataException

Expected Behavior
The TYPESAFE_PROJECT_ACCESSORS feature (currently in preview) should not try to validate the rootProject name as it's not involved in the generated accessors.
Current Behavior
Having something like rootProject.name = "Charts.kt-samples" in the settings.gradle.kts file leads to the error below if you have enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS"):
java.lang.RuntimeException: org.gradle.api.InvalidUserDataException: Cannot generate project dependency accessors:
  - Cannot generate project dependency accessors because project 'Charts.kt-samples' doesn't follow the naming convention: [a-zA-Z]([A-Za-z0-9\-_])*
	at org.gradle.api.internal.catalog.DefaultDependenciesAccessors.generateAccessors(DefaultDependenciesAccessors.java:156)
	at org.gradle.configuration.BuildTreePreparingProjectsPreparer.generateDependenciesAccessorsAndAssignPluginVersions(BuildTreePreparingProjectsPreparer.java:92)
	at org.gradle.configuration.BuildTreePreparingProjectsPreparer.prepareProjects(BuildTreePreparingProjectsPreparer.java:55)

Context (optional)
I need the root project to include dots and dashes for branding consistency reasons, and avoid confusing users (it'll be open source).
Steps to Reproduce

Create a new empty Gradle project with Kotlin DSL and open the settings.gradle.kts file.
Remove any rootProject.name = "something" statement.
Add rootProject.name = "Charts.kt-samples".
Add enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS")
Run Gradle on the project (e.g. running the help task), or perform a Gradle sync in IntelliJ IDEA

Gradle version
8.1.1
Build scan URL (optional)
No response
Your Environment (optional)
No response

Thank you for your interest in Gradle!
This is the intended behavior, and there’s no plan to change it. This issue will be closed.

Relates to

#24295

The root project name is involved in the accessors generation and follows the same name pattern validation as intended.

authors: LouisCAD eskatos


text:
Adding group to projects causes recursive dependency resolution

Current Behavior
FAILURE: Build failed with an exception.

* What went wrong:
Circular dependency between the following tasks:
:app:something:classes
\--- :app:something:compileJava
     \--- :app:something:jar
          +--- :app:something:classes (*)
          \--- :app:something:compileJava (*)

(*) - details omitted (listed previously)

Expected Behavior
It works. The dependency is an explicit project(":absolute:path").
Context (optional)
This is the real life example where it happened:
https://scans.gradle.com/s/olto6hxhdj2ry/dependencies?focusedDependency=WzEsNSwzNjk1LFsxLDUsWzM2OTVdXV0&focusedDependencyView=details&toggled=W1sxXSxbMSw1XV0
it looks a little bit different than the repro, but the root cause seems to be the same (except not visible in repro build scan).
Based on where I found this, there's a dependency tree like this (following the repro structure):
project :app:something
\--- project :feature:something

which when adding a group to both projects becomes:
project :app:something
\--- project :feature:something -> project :app:something

i.e. the two modules become "equivalent" and substituted when it comes to Gradle dependencies.
See gradlew :app:something:dependencies, because it is not visible in the repro build scan, but is visible in the above real scan. (Could be because they're different Gradle versions).
Steps to Reproduce

Clone https://github.com/TWiStErRob/repros/tree/main/gradle/dependency_group-recursion
gradlew build → failure
Remove group = ... from root build.gradle
gradlew build → success

Gradle version
Found in 8.2, repro in 8.5
Build scan URL (optional)
https://gradle.com/s/e35g2qznofm22
Issues (these might become enhancements, depending on your response)

Dependency gets substituted just because of existence of group (this issue)
Build scan not showing dependencies in minimal repro (while it works in real/Android project)
Error message is complaining about recursive task dependencies, while in reality there's recursive project dependencies; so it's hard to figure out what's going on.
Even if dependency substitution is correct, it's impossible to see why, even dependencyInsight doesn't tell me.

Thank you for your interest in Gradle!
This issue will be closed as a duplicate of

https://github.com/gradle/gradle/issues/847

Please add your use case and 👍 to that issue.

The root cause should be addressed in the linked issue first. Other issues you pointed out might be addressed or changed depending on the final solution.


text:
Deprecation warning info should not get in the way of a build failure

Expected Behavior
When a build fails, the first thing that users should see on the console (or IDE output) is the reason for the failure
Current Behavior (optional)
When deprecation warnings are emitted, they occupy a significant chunk of the output at the very end. There is a very tiny chance that this output is actually useful at all in a case of a build failure.

Context
_

That is something we should look into once we have a plan and progress on the "Problems API console rendering" stream of work.

authors: alllex donat


text:
Remove lenient class encoding behavior

Gradle should fail immediately when the classloader of a particular serialized class is unknown.

Fixed via #30666


text:
(Runtime)Classpath normalizer should ignore jdk version backed into the module-info.class

Expected Behavior
(Runtime)Classpath normalization should normalize a module-info.class, when the only difference is the bugfix java version.
Alternatively if thats to scary: add something to RuntimeClasspathNormalization that allows a user to ignore compiled in module-versions for the jdk
Current Behavior (optional)
when 2 jars are identically, but reference different bugfix java modules (eg. 21.0.3 and 21.0.4) in their module-info.class, Gradle consideres these file different with both runtime and classpath normalizer.
https://github.com/gradle/gradle/issues/28806#issuecomment-2056998992
Is there any flag/ anything one can do to avoid getting these verions?
Context
Playing around with the remote build cache we realized that this issue forces everyone to manually setup their jdk to exactly the same jdk bugfix version the CI uses.
There are already some issues open that this can be mitigated if the toolchain setup/daemon setup would support minor versions.
However this normalization might still be usefull/needed when consuming jars from outside gradle build.

This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary.

Linking this for context..
https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8344081

@gradle/bt-execution This is related to our Java normalization, but do you have any advice on what we should do?
My gut feeling is that we should be ignoring this version. I don't know if it appears anywhere else other than module-info.

For context: There seems to be actually an JAVA-API to retreive said versions at runtime.
ModuleDescriptor#requires#compiledVersion/rawCompiledVersion.
So completly ignoring them always is technically not legal, but i cant name anything that does anything whith these versions.

It looks like different audiences have different sensitivity to Java version precision, so to say.
Some want a specific toolchain down to vendor and patch version; those probably want to keep this version number. While there are also builds where 21 is the only requirement, if that; for those builds it would make sense to filter this. Another place where this precision comes to play is the Java versions used to exec stuff, including the Gradle daemon.
I wonder if we could capture this requested precision somewhere in a single place, perhaps at the toolchain requirement, and then make the other parts of the system adopt automaticly.

authors: big-guy lptr ov7a tg-freigmbh


text:
Improve configuration cache test coverage for transform actions

Add failing test proving transform actions are re-executed upon input changes.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

OK, I've already cancelled the old build and triggered a new ReadyForMerge build for you.

authors: bamboo bot-gradle


text:
Filter generic tooling API events

Fixes https://github.com/gradle/gradle/issues/14684

@bot-gradle test this please.

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this please.

Sorry some internal error occurs, please contact the administrator @blindpirate

@bot-gradle test this please.

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test QFL please.

OK, I've already cancelled the old build and triggered a new QuickFeedbackLinux build for you.

I'm abandoning this PR. Somebody interested in filtering generic TAPI events can pick up where I left off.

authors: bot-gradle lptr


text:
Use FQCN in validation error messages

Supercedes #16926

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test and merge
@wolfs I'm proactively merging since you had said +1 on the PR which had the plugins in addition. Feel free to comment if I need to fix something.

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

Your PR is queued because #16993 is being built.

OK, I've already triggered a build for you.

authors: bot-gradle melix


text:
Replace upToDateWhen by doNotTrackState/UntrackedTask

In our built-in tasks and our own build logic.

@bot-gradle test QFL

OK, I've already triggered QuickFeedbackLinux build for you.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

OK, I've already triggered a build for you.

authors: bot-gradle wolfs


text:
Replace dependency kotlin-stdlib-jdk8 with kotlin-stdlib

kotlin-stdlib-jdk8 is merged into kotlin-stdlib since 1.8.0.
See https://kotlinlang.org/docs/whatsnew18.html#updated-jvm-compilation-target

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test this

Sorry but I'm afraid you're not allowed to do this.

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

Your PR is queued. See the queue page for details.

I've triggered a build for you. Click here to see all failures if there's any.

Pre-tested commit build failed. Click here to see all build failures.

I can not built it locally, please trigger a build.
Calculating task graph as no configuration cache is available for tasks: :plugin-development:configCacheIntegTest
Type-safe project accessors is an incubating feature.

> Configure project :build-logic-commons:code-quality-rules
Kotlin DSL property assignment is an incubating feature.

FAILURE: Build failed with an exception.

* Where:
Settings file '/Users/zhouyanming/workspace/gradle/build-logic/settings.gradle.kts' line: 24

* What went wrong:
Error resolving plugin [id: 'org.gradle.toolchains.foojay-resolver-convention', version: '0.4.0']
> A problem occurred configuring project ':build-logic-commons:commons'.
   > Dependency verification failed for configuration ':build-logic-commons:commons:classpath'
     One artifact failed verification: gradle-kotlin-dsl-plugins-4.1.0.jar (org.gradle.kotlin:gradle-kotlin-dsl-plugins:4.1.0) from repository Gradle Central Plugin Repository
     If the artifacts are trustworthy, you will need to update the gradle/verification-metadata.xml file. For more on how to do this, please refer to https://docs.gradle.org/8.3/userguide/dependency_verification.html#sec:troubleshooting-verification in the Gradle documentation.

     Open this report for more details: file:///Users/zhouyanming/workspace/gradle/build/reports/dependency-verification/at-1692751393517/dependency-verification-report.html

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test and merge

I've triggered a build for you. Click here to see all failures if there's any.

authors: bot-gradle jbartok jvandort quaff


text:
Add contributor credit for 26598

<!-- Fixes #26598

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

I've triggered a build for you. Click here to see all failures if there's any.

authors: bot-gradle tresat


text:
Fix typo on user manual

Fix a typo in the "Implementing Pre-compiled Script Plugins" section on user manual. Description didn't match snippet.

Context

In the user manual we have a snippet of code that contains:
extension.message.convention("Hello from Gradle")

And below that we have the text:

extension.message.convention(…) sets a convention for the message property of the extension. This convention specifies that the value of message should default to the content of a file named defaultGreeting.txt located in the build directory of the project.
If the message property is not explicitly set, its value will be automatically set to the content of defaultGreeting.txt.

Since there is no defaultGreeting.txt in the snippet, I'm proposing to change the text to:

extension.message.convention(...) sets a convention for the message property of the extension.
This convention specifies that the value of message should default to "Hello from Gradle".
If the message property is not explicitly set, its value will be automatically set to "Hello from Gradle".

Contributor Checklist

[x] Review Contribution Guidelines.
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team.
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective.
[ ] Provide unit tests (under <subproject>/src/test) to verify logic.
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes.
[ ] Ensure that tests pass sanity check: ./gradlew sanityCheck.
[ ] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest.

Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

sanityCheck and quickTest are failing for me even in the main branch, so, probably something with my setup. But since this is just documentation changes, I figured it was ok to create the PR


text:
Use JaCoCo 0.8.4 by default

This release is of particular interest for people

who use recently released Kotlin compiler version 1.3.30+ and coroutines
who compile into Java 11+ bytecode

Full changelog - http://www.jacoco.org/jacoco/trunk/doc/changes.html

Thanks @Godin, this will be in 5.5

@big-guy it's my pleasure

authors: Godin big-guy


text:
Non-time-series and non-component-type properties are not showing in Grafana query selection

For properties are non-time-series, if they are not declared in component type, then the won't be shown in Grafana query.
For example, KinesisVideoStreamName and CaptureStartTime  are declared in SiteWatch as entity level of property, they are not showing in Grafana selection; on the other side, sitewiseAssetId and sitewiseAssetModelId are defined in component type level, they are shown in Grafana query. Double confirmed that all these 4 properties are in getEntity response.

We support GetpropertyValue API which lists non time series properties

repo: grafana/grafana-iot-twinmaker-app