text:
fix: use test credentials when connecting to the Emulator from Admin SDK

Fixes https://github.com/firebase/firebase-admin-java/issues/452

Unfortunately, we don't have any automated regressions tests that involve multiple projects. I verified with the customer's repo that their problem no longer exists and verified that our integration tests still pass against the Emulator even when the Admin SDK is not involved (well, there are two failures, but they existed prior to this change).

source: gharchive/pull-request

repo: googleapis/java-firestore

license_type: permissive

license_source: bigquery


text:
fix: send streamingConfig as a separate write before audioContent

Fixes #173.
Fixes #182.
I personally am not fan of modifying test methods generated by gapic, since the gapic tests should test the underlying (not helper-wrapped) methods.
So I tried to just require the underlying source via require('../src/v1'), the tests would pass if it's not run along with helpers.test.js (npx mocha test/gapic-{v1|v1beta1}.js). Somehow requiring helpers.js modifies the actual exports in the gapic generated libs - so when I run npm test it fails.

This one threw me for a loop as well, from what I can tell helpers main goal is to allow streamingConfig to be passed in as an argument as opposed to being written to the stream. The non-helpers usage would look like the following
const stream = client.streamingRecognize();

stream.write({streamingConfig});
fs.createReadStream('my-file.wav').pipe(stream);

as opposed to
fs.createReadStream('my-file.wav')
  .pipe(client.streamingRecognize({config}));

@callmehiphop are you taking the PR over?  That would be nice :)

@JustinBeckwith sure thing, just rebased and pushed a commit. I think we're good to go (unless we want another contributor to take a peak at it first 😄)

authors: JustinBeckwith callmehiphop kinwa91

repo: googleapis/nodejs-speech


text:
chore: make samples depend on the current version

Auto-fixing samples dependency.

@alexander-fenster I generated new lock files to get the lint task to pass, if this looks good to you, I'll generate them for the other clients that need them.

Woops, I merged before seeing your comment.

@stephenplusplus which comment? :)  Anyway, I'm totally OK and thanks for taking care of that!


text:
Getting "TypeError: The header content contains invalid characters" error for getFiles() function

Environment details

OS: Windows 10
Node.js version: v6.11.2
npm version: 3.10.10
@google-cloud/storage version:1.5.1

Steps to reproduce

Run the examples mentioned in this repo for get list of files from bucket. Don't specify any Delimiter or prefix filter and you will get this error -

ERROR: TypeError: The header content contains invalid characters
at ClientRequest.OutgoingMessage.setHeader (_http_outgoing.js:359:11)
at new ClientRequest (_http_client.js:85:14)
at Object.exports.request (http.js:31:10)
at Object.exports.request (https.js:202:15)
at Request.start (D:\XXX\XXX\node_modules\request\request.js:748:32)
at Request.end (D:\XXX\XXX\node_modules\request\request.js:1512:10)
at end (D:\XXX\XXX\node_modules\request\request.js:561:14)
at Immediate. (D:\XXX\XXXX\node_modules\request\request.js:575:7)
at runCallback (timers.js:672:20)
at tryOnImmediate (timers.js:645:5)
I want to know, am I missing something or why I am getting this error. I am not setting any header in the request and I found that it is an issue within google cloud package where it is calling request module.
@google-cloud\storage\src\bucket.js +1262
Following these steps will guarantee the quickest resolution possible.
Thanks!

Without further help, I'm unfortunately unable to reproduce. I will gladly re-open if you can provide a sample repo or gist that can demonstrate the problem.

source: gharchive/issue

authors: ils-sapnaj stephenplusplus

repo: googleapis/nodejs-storage

license_source: github-api


text:
Drop page size from 50 to 30

@dlam

@googlebot I consent

authors: florina-muntenescu tunjid

repo: googlecodelabs/android-paging


text:
[ URGENT ] ; Depricated API used; Qwiklabs not working; Relevant PRs not merged;

Hi,
There are depricated API extensions/v1beta1 being used in orchestrate-with-kubernetes/kubernetes/deployments/
There are some PRs that have solved this problem but it is not merged
Please merge it a lot of people might be facing issue including me.
People are getting demotivated in qwiklabs due to this issue

Use this repo https://github.com/DhruvSondhi/orchestrate-with-kubernetes for git clone statement, it will solve the issue you are facing and you will be able to complete the lab. I was having the same trouble, I found the fix in one of the open issue pull request.
git clone https://github.com/DhruvSondhi/orchestrate-with-kubernetes

@nitinvinayak  Thanks for the help
I wish the maintainers take care of this and stop a lot of hassle faced by students


text:
Clean up the script for building merged Noto fonts

This is still work in progress:

the blacklist of currently unmergeable shards is incomplete;

we need to find a solution for the shards whose sources do not have
the same design masters as the Latin/Greek/Cyrillic base font.
Missing Semibold masters can probably be automatically interpolated,
but this script does not do this yet.

Merging into master because nobody else uses this script yet anyway.


text:
Fix a bug, connectionLost() call the start method after stop().

I found out a problem. If there have A and B devices are communicating in the BluetoothChatRoom, When the A close this app, the Fragment will call mChatService.stop() in onDestroy method, but the connected thread also call the connectLost() after mChatService.stop(), too. So it will run the start method to run the accept thread again, even through the app is closed. It causes the B devices still can connect to A device and send message, then the A device will get a crash message because it still handling message but there is no UI.
So I think can use a variable to control the BluetoothChatService. If the Fragment call the stop method, the BluetoothChatService can't call itself to start agin in the connectionFailed() and connectionLost().

I signed it!

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

authors: codingjeremy keeweeChang

repo: googlesamples/android-BluetoothChat


text:
Running the app fails on Android Studio 3.0 Canary 4

Android Studio 3.0 Canary 4
Build #AI-171.4101728, built on June 15, 2017
JRE: 1.8.0_112-release-b736 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.10.5
Tried running multi-feature-module via Android Studio and it complains of having no default activity set. Editing the run configuration to include the default-url (https://multi-feature.instantappsample.com/main) brings up an interesting error:

Merging the intent filters in the manifest seem to fix the issue:
<data android:host="multi-feature.instantappsample.com"
                      android:pathPrefix="/main"
                      android:scheme="https" />
<data android:host="multi-feature.instantappsample.com"
                      android:pathPrefix="/main"
                      android:scheme="http" />

FWIW, I remember being able to run this sample on Canary 3.

We are aware of some pain points with the latest Canary version.
Please use another version from the Android Studio release archive.

Please try Canary-5 and re-open if the issue still occurs.

authors: keyboardsurfer zmdominguez

repo: googlesamples/android-instant-apps


text:
option --lang not available in hotword mode !!

--lang fr-FR option is available for
googlesamples-assistant-pushtotalk ... and i could test it in french
but apparantly not for
googlesamples-assistant-hotword
in principle if french is supported for pushtotalk there is no additional work to make it work in hotword mode so i'm surprised ! or did i miss something ?

To change the language used in the hotword sample, the setting will instead appear in the settings of the Google Assistant app for your device.

Thank you, i managed to make it work...but the answers i get through pushtotalk  on the PC seem less performant compared to those from the google home assistant on my android smartphone. May be it's just because the one on the smartphone can interact with a web browser to answer through the opening of various webpages ...
is there a documented way to achieve the same using "kind of extensions" to the assistant-sdk-python ?

You can overload commands using custom device actions if you want additional functionality.

Mmmm yes but apparantly this is designed to allow actions on hardware devices such as switches and so on ... or may be also to launch tasks (scripts, etc...) on the PC but
not really to allow the opening of web pages with info (additional to the one given orally by the answering assistant ) related to the question asked ... as does and is actually the main job of an assistant on any smartphone ...

That's currently what the library provides.
I'm going to close this issue as we've resolved the language switching.

authors: Fleker fhenryco

repo: googlesamples/assistant-sdk-python


text:
🛑 goormEDU is down

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

HTTP code: 403
Response time: 754 ms

Resolved: goormEDU is back up in 7d43118 after 5 minutes.

repo: goorm-dev/goorm-status

license: MIT


text:
🛑 goormEDU is down

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

HTTP code: 403
Response time: 665 ms

Resolved: goormEDU is back up in 8a283e7 after 6 minutes.


text:
🛑 goormIDE is down

In 57b6720, goormIDE (https://ide.goorm.io) was down:

HTTP code: 403
Response time: 481 ms

Resolved: goormIDE is back up in f37c867 after 39 minutes.


text:
Issue parsing base64/png

Was trying to work around on the following url -
https://www.missmalini.com/2017/07/13/tried-tested-dip-powder-nails/
There i found -it started failing in as the file have a background image with background:url(data:image/png;base64 .... )
article = g.extract(url=url)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/__init__.py", line 75, in extract
    return self.crawl(cc)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/__init__.py", line 91, in crawl
    raise e
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/__init__.py", line 85, in crawl
    article = crawler.crawl(crawl_candidate)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/crawler.py", line 120, in crawl
    return self.process(raw_html, parse_candidate.url, parse_candidate.link_hash)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/crawler.py", line 189, in process
    self.get_image()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/crawler.py", line 211, in get_image
    self.article.top_image = self.image_extractor.get_best_image(doc, top_node)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/extractors/images.py", line 82, in get_be
st_image
    image = self.check_large_images(topNode, 0, 0)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/extractors/images.py", line 116, in check
_large_images
    good_images = self.get_image_candidates(node)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/extractors/images.py", line 277, in get_i
mage_candidates
    good_images = self.get_images_bytesize_match(filtered_images)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/extractors/images.py", line 293, in get_i
mages_bytesize_match
    local_image = self.get_local_image(src)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/extractors/images.py", line 337, in get_l
ocal_image
    return ImageUtils.store_image(self.fetcher, self.link_hash, src, self.config)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/utils/images.py", line 64, in store_image
    data = http_client.fetch(src)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/goose3/network.py", line 52, in fetch
    response = self._connection.get(url, timeout=self.config.http_timeout, headers=self.headers)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/sessions.py", line 515, in get
    return self.request('GET', url, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/sessions.py", line 502, in request
    resp = self.send(prep, **send_kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/sessions.py", line 606, in send
    adapter = self.get_adapter(url=request.url)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/sessions.py", line 697, in get_adapter
    raise InvalidSchema("No connection adapters were found for '%s'" % url)
requests.exceptions.InvalidSchema: No connection adapters were found for 'data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAB0AAAAaCAYAA
ABLlle3AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAABSBJREFUeNrkVltPY1UY/VpaaMu1kFAiw6Wl3Nva0mHoTEAGhsgwCSTERIwTJ4Y3n3zwB/ADzPg
8Og9GzBhJxmBICI4iNShyKVIuQoGWW4FyGSiFMlCgBdfetgQYCzzpgydpetpzzl7fWutb3z6Ck5MT+rcPIf0Hh+jsj4qKytPzo6MjEolEdHx8TEKhkH+gSrzf7087ODi4he97Y
rHYGBUVlS4URjQKhYJvLy4eUtFs7goPevEQCATsS40Cbh0eHhpRgFYmkxkzM5WJhYUFpNEUUmdnJw0NDX8MiGxcjzz7rEQiQd2iafz88ipQGSrMB5Myn2+/FAw1cnmiKiMjQ6z
Xv0l6vZ6USiUpFClgL6BXr/ZoeHjEdPNmsQmsg8oIKBA4oZkZB21ubvZeCorqPgWr2wAtUKmUcq1WS7m5uWCkodTUVIqOjn6twry8XPwfQ48efUA6nY5LygTy+Q6pqamJ5ufn9
y71dH9//yOTyRTd0PAuxcbGUFSUhNRq9aVNkZ+fT3FxcTQ2NkbFxcVnCAhDvp5c2r3w7afkZAUBGLK46cmTz2lxcTEsIJOSsddqNTQ4+AckDZxeY+fh4ngOFKa3Dw9baWNjA93
rp6SkJBoYsLBiTu/xer00OjpGLS0t9PjxZ+RwzFBZWSn8m0GByxzoquyfkzcyMrLf5XJt2e0OeWZmBuQyQnIfLS8v09zcHAfY2dkhmSya2HVmQ0pKCkmlEoqIiKCnT7/gdshkU
qqpqeH/XQmK3C14PB7r+Ph4pU73HnV1ddHCwiL5/YeUmJjIG4XFRCKRopAlmp2dQ1yGqLy8nNDd5PFsgXUZW4cDnpX7ssjsQOJ+q3Wosrr6bf7w3bvllJOTzc8nJmz04sWPtLq
6yoeHXJ6A7s2n+Ph4MhiKkFl2bYUSEhJwTR7K+eWgzAssPgB5fVhUUlVVRf39/dTc/DVYeNA0MsrOzqaiIgPFxMTwj9PppOnpaW5Fc/NXAP6Z7ty5Tenp6dcDDUo8CgAnJM5h/
jF2BoMebHN4Ubu7Xt4wvb19tL6+zp8pL3+LsrJUyPIbGBrJuN/A5Q3XUK+B4mYnvBixWCw5tbW1nBmbLMxfl2sVjbXHu1qtzqIHD2q4lCxWLJdGo5FaW1uR8Viqq6vjk+lKUCY
HqvNjnP06NTX9DpgIzeZfuE8MnDG6cSOVe2i326m7uxuN5uQN8/Dh+3xEdnT8wHMeGonX8jQYnd9crpVteCW/f78a3evnBc3OzlJbWxutra3xRVUqFWfLimAdzdhjyPNma2z88
HQqXSlv8JjE9vXn+PhEmVaro+fPv+P5TE5OxtjLo/r6egwSMTxdQ3Rc1NPzO98GWW41mgKy2Wz8+rU9Dcq8D2J9o6OjZSw6paWlPDa8mslJ+GvmA4NNqpQUBaRXg3UWbFgDkIB
WVlZoe3v7esPhwkjscTjsnwQCx8K4uFh69uwbHn62o6SlpVNlZQWX1evdAbNJam9vR3TsPL/MW5TOs/1PbMOCospBt3trYWrKpmQDgA11hUKBjoygpaVFvA2YyWod5uPR7XbzY
WAylVBJSQkviv3/8uU68z7q2qDYvFdR5QD8UjLpWCxaW78n5Jc10iqkDYCJgHnJdhqxWEQjIyNksQzyxvt7BJ5Apbj1a3Vv0NcAJo65r6+/AQvtYWDYsJCVxQlgNqlU6sf9gtA
zXu/uaZeHJhHui8Cp58qcXmA7BEbtADMDpAOST7FiQnvlhSL5y1u40XcO53/z3vuXAAMAGHpywSLn9WUAAAAASUVORK5CYII='

Well how can we address the following ?

Apologies for the slow response. Have you found how to tackle the issue?

@blakdronzer try the following. feel free to submit a PR with any attempts to get this working.
https://stackoverflow.com/questions/33048636/saving-image-from-url-using-python-requests-url-type-error

New example of the issue: https://varvy.com/pagespeed/base64-images.html

authors: barrust blakdronzer lababidi


text:
change-skills

Added two skills to better reflect the list of skills I possess

sorry, wrong repo

repo: gopalbhuvana/merge-conflict


text:
fetch on server not including cookies (+page.server.ts)

Hey,
heaving the following code, the cookies on node are included.
const headers: HeadersInit = {
	contentType: 'application/json',
	Accept: 'application/json'
};

const response = await fetch(`${variables.API_URL}/dashboard`, {
	headers,
	credentials: 'include'
});

After switching to bun, the cookies are not included anymore.
I tried to set the ORIGIN and add them manually via header, but for some reason no cookies at all reaches the backend (same tld).
Is there any way to work around this?

Hey, do you use the fetch provided by the load function? If yes, you must manually inject the cookies in hooks.server.ts.
For example:
export const handleFetch: HandleFetch = async ({event, request, fetch}) => {
    if (request.url.startsWith(PUBLIC_API_URL)) {
        request.headers.set("cookie", event.request.headers.get("cookie") ?? "");
    }

    return fetch(request);
}

I'm kinda surprised it has worked for you in node tbh, it didn't for me. At least not when using the provided fetch.

@kyngs, sorry for the confusion, I am not talking about the hooks - there I needed the add the cookies manually - even on node.
I am talking about a fetch within a +page.server.ts ts (load()):

Using the node adapter my cookies are passed to the backend, via credentials: 'include'.

According to the sveltekit documentation the cookies should be passed from the client to the server fetch:
https://kit.svelte.dev/docs/load#cookies

This may be fixed now from Bun's 1.1.27 release.

authors: Cluster2a KyleFontenot kyngs


text:
ATS 20+ Slow Tuning

I flashed your firmware to my ATS 20+. There is a delay tuning with the encoder and button presses. What do I do?

Hi,
As a user of the firmware I have not noticed any unexpected delays.
For most buttons, a “short press” selects the adjustment mode.

Adjustments of the selected parameter are made using the rotary encoder.
Adjustments can be confirmed and/or cancelled with another “short press” of the button or by the rotary encoder button.
There is a 3 second timeout during adjustment mode, indicated by the “white” background for the selected parameter.

Examples below.

Hopefully, this may cover your question.
73, Dave


text:
Error: Unexpected character &

It seems this library is unable to parse XML with ampersands in it. Ampersands are used as escapes in XML. The following escapes should be supported:

&
'
"
<
>

More information here: https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references#Predefined_entities_in_XML
Thanks.

My mistake. I had & characters in my xpath query.


text:
post json 怎么写？

GuzzleHttp 是这么写的
 $response = $client->request(
            'post',
            $url,
            [
                'json' => [

                ],
            ]
        );

   下面写不行

 Http::asJson()->post($url,$postArr)->toArray();

应该怎么写？

Http::asJson()->post($url,$postArr)->toArray();这样写是对的
---原始邮件---
发件人: @.>
发送时间: 2021年8月14日(周六) 晚上9:53
收件人: @.>;
抄送: @.***>;
主题: [gouguoyin/easyhttp] post json 怎么写？ (#4)
GuzzleHttp 是这么写的
$response = $client->request(
'post',
$url,
[
'json' => [
],         ]     );          这个扩展 这么写不可以？
Http::asJson()->post($url,$postArr)->toArray();
应该怎么写？
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Http::asJson()->post($url,$postArr)->toArray();这样写是对的
…
---原始邮件--- 发件人: @.> 发送时间: 2021年8月14日(周六) 晚上9:53 收件人: @.>; 抄送: @.***>; 主题: [gouguoyin/easyhttp] post json 怎么写？ (#4) GuzzleHttp 是这么写的 $response = $client->request( 'post', $url, [ 'json' => [ ], ] ); 这个扩展 这么写不可以？ Http::asJson()->post($url,$postArr)->toArray(); 应该怎么写？ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

不行的 我试过了 要不也不请教你

这个还有问题么？

repo: gouguoyin/easyhttp


text:
[Core] Error after one page HTML generation (--save option)

Step to reproduce: slidesk --save
Expected behavior: slides fully usable
What happen:

slides are stuck on the first slide
an error appear in the browser console:

Échec du chargement pour l’élément <script> dont la source est « file:///plugins/steps/steps.js ». [index.html:1:13009](file:///Users/stef/Talks/jarvis-slides/index.html)
Uncaught TypeError: window.slidesk.prepareSteps is not a function
    onSlideChange file:///Users/stef/Talks/jarvis-slides/index.html:1
    changeSlide file:///Users/stef/Talks/jarvis-slides/index.html:1
    onload file:///Users/stef/Talks/jarvis-slides/index.html:1

Hi, thanks for your issue.
Like the assets (images, custom CSS or JS), the plugin directory must be copied in your destination with the HTML files

Ok I think I misunderstood the --save option!
The generated must be serve by a web server or can it open as is in a browser?

Without plugin and customization, no need a webserver. Else you need to host

ok thanks I understood ;), the issue can be closed.

authors: gouz philippart-s

repo: gouz/slidesk


text:
🧪  test: add run link test and Change to async execution of test

test

所有测试都改为异步
新增执行rfuses宏，允许运行在运行程序的同时执行其他代码

dev

更新 pre-commit

Pull Request Test Coverage Report for Build 10554058448
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 1.294%

Totals

Change from base Build 10539866056:
0.0%

Covered Lines:
22

Relevant Lines:
1700

💛  - Coveralls

authors: coveralls gouzil

repo: gouzil/rfuse


text:
Arkansas finally has a vaccine tracker

FWIW, the link to Arkansas' vaccine tracker is here. They don't appear to grab or store historical data, but at least it's being updated (the general dashboard doesn't have this data). Hope that helps.

@scareduck thanks! We started pulling from that dashboard on 01/07

@scareduck thanks! We started pulling from that dashboard on 01/07

Hey, thanks for fixing this. Better data is a big deal.

Hey, thanks for fixing this. Better data is a big deal.

authors: sarabertrandelis scareduck


text:
ATO-160: Update stub documentation

What?
Update the documentation for the stub
Why?
To make it easier to use and develop on

LGTM, feel free to resolve my comments if they aren't needed

repo: govuk-one-login/relying-party-stub


text:
docs: add tech specs for spike essential

I didn't find an icon for SPIKE Essential

I didn't find an icon for SPIKE Essential

Not sure there will be one it'll come under the SPIKE banner.
I created the SPIKE and Mindstorms ones in this repo myself, I liked the design of the heart and wanted a Mindstorms one to match.

oh ok.

authors: cscovino gpdaniels

repo: gpdaniels/spike-prime


text:
Comfortable define

#define endl "\n"
#define in(x) insert(x)
#define sz(x) (int)x.size()

Thanks for the patch, but something is very wrong with this pull request. How come it adds so many commits that are already merged?  Also can you please state the purpose of those defines? Those seem against the "spirit" of google c++ style guide.

Something looks very broken with this specific pull request. Not sure exactly. I apologize for not looking at it sooner. I'll close pull request. If you want to propose it again, please open new one.
Also note that if you're trying to propose just few #define-s added and used in some files, I'll have to refuse such patch. Google C++ style guide (even more liberal older version) are advising against abusing macros. And frankly most people including myself agree. No reason and no value.

authors: Scayre alk

repo: gperftools/gperftools


text:
很想学习这个源码是怎么完成

能不能出一个教程视频?很期待.收费都行

嗯，以后有时间了会写一个带图文档; 描述一下需要的openGL基础知识; 及本库的框架结构，及各类作用，可能就更容易看懂了。

@gplibs 期待....

+1

收费也行,我也很想学...找到的资料都是一些基础的东西..没啥用啊.

authors: AnswerZhao fanmingyi gplibs parcool wu464995183

repo: gplibs/android-magic-surface-view


text:
omni_gradio.py 执行错误

(omni) taozhiyu@Mac mini-omni % API_URL=http://0.0.0.0:60808/chat python3 webui/omni_gradio.py
Running on local URL:  http://127.0.0.1:7860
To create a public link, set share=True in launch().
ERROR:    Exception in ASGI application
Traceback (most recent call last):
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/type_adapter.py", line 279, in _init_core_attrs
self._core_schema = _getattr_no_parents(self._type, 'pydantic_core_schema')
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/type_adapter.py", line 121, in _getattr_no_parents
raise AttributeError(attribute)
AttributeError: pydantic_core_schema
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/uvicorn/protocols/http/h11_impl.py", line 406, in run_asgi
result = await app(  # type: ignore[func-returns-value]
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/uvicorn/middleware/proxy_headers.py", line 70, in call
return await self.app(scope, receive, send)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/fastapi/applications.py", line 1054, in call
await super().call(scope, receive, send)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/applications.py", line 113, in call
await self.middleware_stack(scope, receive, send)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/middleware/errors.py", line 187, in call
raise exc
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/middleware/errors.py", line 165, in call
await self.app(scope, receive, _send)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/gradio/route_utils.py", line 766, in call
await self.simple_response(scope, receive, send, request_headers=headers)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/gradio/route_utils.py", line 782, in simple_response
await self.app(scope, receive, send)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/middleware/exceptions.py", line 62, in call
await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/_exception_handler.py", line 62, in wrapped_app
raise exc
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/_exception_handler.py", line 51, in wrapped_app
await app(scope, receive, sender)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/routing.py", line 715, in call
await self.middleware_stack(scope, receive, send)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/routing.py", line 735, in app
await route.handle(scope, receive, send)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/routing.py", line 288, in handle
await self.app(scope, receive, send)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/routing.py", line 76, in app
await wrap_app_handling_exceptions(app, request)(scope, receive, send)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/_exception_handler.py", line 62, in wrapped_app
raise exc
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/exception_handler.py", line 51, in wrapped_app
await app(scope, receive, sender)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/starlette/routing.py", line 73, in app
response = await f(request)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/fastapi/routing.py", line 291, in app
solved_result = await solve_dependencies(
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/fastapi/dependencies/utils.py", line 639, in solve_dependencies
) = await request_body_to_args(  # body_params checked above
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/fastapi/dependencies/utils.py", line 813, in request_body_to_args
fields_to_extract = get_model_fields(first_field.type)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/fastapi/_compat.py", line 283, in get_model_fields
return [
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/fastapi/_compat.py", line 284, in
ModelField(field_info=field_info, name=name)
File "", line 6, in init
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/fastapi/_compat.py", line 109, in post_init
self._type_adapter: TypeAdapter[Any] = TypeAdapter(
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/type_adapter.py", line 266, in init
self._init_core_attrs(rebuild_mocks=False)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/type_adapter.py", line 144, in wrapped
return func(self, *args, **kwargs)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/type_adapter.py", line 286, in _init_core_attrs
self._core_schema = _get_schema(self._type, config_wrapper, parent_depth=self._parent_depth)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/type_adapter.py", line 104, in get_schema
schema = gen.generate_schema(type)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 655, in generate_schema
schema = self._generate_schema_inner(obj)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 908, in _generate_schema_inner
return self._annotated_schema(obj)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 2025, in _annotated_schema
schema = self._apply_annotations(source_type, annotations)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 2104, in _apply_annotations
schema = get_inner_schema(source_type)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_schema_generation_shared.py", line 83, in call
schema = self._handler(source_type)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 2186, in new_handler
schema = metadata_get_schema(source, get_inner_schema)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 2182, in
lambda source, handler: handler(source)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_schema_generation_shared.py", line 83, in call
schema = self._handler(source_type)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 2085, in inner_handler
schema = self._generate_schema_inner(obj)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 929, in _generate_schema_inner
return self.match_type(obj)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 1029, in match_type
return self._match_generic_type(obj, origin)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 1058, in _match_generic_type
return self._union_schema(obj)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 1378, in _union_schema
choices.append(self.generate_schema(arg))
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 655, in generate_schema
schema = self._generate_schema_inner(obj)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 929, in _generate_schema_inner
return self.match_type(obj)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 1038, in match_type
return self._unknown_type_schema(obj)
File "/Users/taozhiyu/miniconda3/envs/omni/lib/python3.10/site-packages/pydantic/_internal/_generate_schema.py", line 558, in _unknown_type_schema
raise PydanticSchemaGenerationError(
pydantic.errors.PydanticSchemaGenerationError: Unable to generate pydantic-core schema for <class 'starlette.requests.Request'>. Set arbitrary_types_allowed=True in the model_config to ignore this error or implement __get_pydantic_core_schema__ on your type to fully support it.
If you got this error by calling handler() within __get_pydantic_core_schema__ then you likely need to call handler.generate_schema(<some type>) since we do not call __get_pydantic_core_schema__ on <some type> otherwise to avoid infinite recursion.
For further information visit https://errors.pydantic.dev/2.9/u/schema-for-unknown-type

Exactly the same error occurred in my Ubuntu22.04 system. I tried to upgrade the gradio version to solve the issue and it worked out for me. You can try to upgrade yours by using the following command:
pip install --upgrade gradio

works.thanks.

repo: gpt-omni/mini-omni


text:
Null check operator used on a null value and "Bad Element"

I am trying to parse this:
all_shows.graphql
# import 'show_card_fragment.graphql'

query AllShows($countryCodes: [String!]!, $serviceNames: [String!]!, $page: Int!) {
  shows(countryCodes: $countryCodes, serviceNames: $serviceNames, page: $page) {
     ...ShowCard
  }
}

show_card_fragment.graphql
fragment NestedFragment on Show {
  title
  posterUrl
}

fragment ShowCard on Show {
  ...NestedFragment
}

But when running the build_runner I get this error:
❯ dart run build_runner build --delete-conflicting-outputs
Building package executable... (4.0s)
Built build_runner:build_runner.
[INFO] Generating build script completed, took 209ms
[INFO] Precompiling build script... completed, took 3.0s
[INFO] Building new asset graph completed, took 1.1s
[INFO] Checking for unexpected pre-existing outputs. completed, took 1ms
[INFO] Generating SDK summary completed, took 2.9s
[SEVERE] ferry_generator:graphql_builder on lib/features/show/data/graphql/show_card_fragment.graphql:

Null check operator used on a null value
package:gql_code_builder/src/operation/data.dart 152:8  buildSelectionSetDataClasses.<fn>
dart:core                                               Iterable.toList
package:gql_code_builder/src/operation/data.dart 169:5  buildSelectionSetDataClasses
package:gql_code_builder/src/operation/data.dart 58:8   buildFragmentDataClasses
package:gql_code_builder/data.dart 51:19                buildDataLibrary.<fn>
dart:core                                               Iterable.toList
package:gql_code_builder/data.dart 61:8                 buildDataLibrary
package:ferry_generator/graphql_builder.dart 104:22     GraphqlBuilder.build

[SEVERE] ferry_generator:graphql_builder on lib/features/show/data/graphql/all_shows.graphql:

Bad state: No element
dart:collection                                          ListBase.firstWhere
package:gql_code_builder/src/operation/data.dart 457:8   _getFieldTypeNode
package:gql_code_builder/src/operation/data.dart 153:24  buildSelectionSetDataClasses.<fn>
dart:core                                                Iterable.toList
package:gql_code_builder/src/operation/data.dart 169:5   buildSelectionSetDataClasses
package:gql_code_builder/src/operation/data.dart 24:10   buildOperationDataClasses
package:gql_code_builder/data.dart 36:17                 buildDataLibrary.<fn>
dart:core                                                Iterable.toList
package:gql_code_builder/data.dart 46:8                  buildDataLibrary
package:ferry_generator/graphql_builder.dart 104:22      GraphqlBuilder.build

[INFO] Running build completed, took 15.8s
[INFO] Caching finalized dependency graph completed, took 91ms
[SEVERE] Failed after 15.9s

What am I missing here?

My build.yaml was referencing the wrong schema

repo: gql-dart/ferry


text:
Promise.then does not work with a ProxyExecutable in rc13 (used to work in rc12)

As discussed on gitter with Jan Štola,
        final Value promise = (...) //obtain JS promise;
        promise.invokeMember("then", (ProxyExecutable) (arguments) -> {
            // process resolved
            return null;
        }, (ProxyExecutable) (arguments) -> {
            // process rejected
            return null;
        });

was working fine on rc12 but is currently not working anymore on rc13. There is a workaround for this issue by wrapping the ProxyExecutable's in a JS function:
        final Value promise = (...) //obtain JS promise;
        final Value wrapper = context.eval("js", "(function (f) { return function(x) { return f(x); }; })");
        promise.invokeMember("then", wrapper.execute((ProxyExecutable) (arguments) -> {
            // process resolved
            return null;
        }), wrapper.execute((ProxyExecutable) (arguments) -> {
            // process rejected
            return null;
        }));

I understood the issue is already in the works - would be nice to know into which rc version the fix could make it.

The root of the problem is in IsCallableNode.doOther(). Its guard does not exclude foreign objects. So, when this specialization is activated then it returns false incorrectly for executable foreign objects. ProxyExecutables are not used correctly by then in the mentioned test-case because of that.

Fixed by https://github.com/graalvm/graaljs/commit/73be26ee8276c20556c7843c6c7e0da8105a20e5

This fix should appear in GraalVM 1.0.0rc15.

authors: fdummert iamstolis

repo: graalvm/graaljs


text:
2303 allow the admin to edit automatic contribution link

🍰 Pullrequest
A contribution link can be changed in the admin area.
Issues

fixes #2303

https://user-images.githubusercontent.com/1324583/198882229-b023cedb-730a-4734-bcc4-1a361dadcc8e.mp4

PR title should be feat(admin): edit automatic contribution link @ogerly

authors: ogerly ulfgebhardt

repo: gradido/gradido


text:
I see no action running

I tried out this, but on an unknown reason there was no job started.
Inspired by https://github.com/ytai/ioio/pull/208 I made this changes on an other repo https://github.com/MikeOrtiz/TouchImageView/blob/master/.github/workflows/update-gradle-wrapper.yml where I expect an update from 6.6 to 6.6.1
But to action was started https://github.com/MikeOrtiz/TouchImageView/actions?query=workflow%3A"Update+Gradle+Wrapper"
Do you have an idea why nothing happens ?

I see, it uses GMT time 👍
https://github.com/MikeOrtiz/TouchImageView/pull/282.
But I guess my actions have a wrong trigger

because CI was not started on the sheduled action. This is a requirement !

I see, it uses GMT time 👍
MikeOrtiz/TouchImageView#282.

Yep, GitHub cron schedules are UTC based, see here.

But I guess my actions have a wrong trigger

because CI was not started on the scheduled action. This is a hard requirement !

It is just a matter of changing the repo-token value used, see this reply.

When I delete MikeOrtiz/TouchImageView#282 does it generate a new pull request ?

Yes, and make sure to delete the branch as well.


text:
Documentation search is extremely limited

Currently when you search anything within Gradle docs, you only get five results, no matter how many times whatever you search for is actually mentioned in documentation, and it seems that there is no way to search for all results. This is incredibly frustrating, because I can't find what I search for very often, even if I know it is there.
Expected Behavior
Searching for something in Gradle docs should give all results for a full text search of documentation. This should be available either directly in the scrollable box, or there should be a way to open a separate page with search results.
Ideally searching should prioritize narrative docs over API docs, or at the very least, provide a clear separation between them.
Current Behavior
Only five results are displayed, and it is not obvious why specifically these results are chosen. If you are looking for a particular page in the narrative docs, and for some reason whatever you search happens to be a part of some API or DSL, then you're screwed - you are very likely to see API docs first and nothing else. There is no other way for searching through documentation except using external search engines.
Context
Here is a real world example I encountered just now. I wanted to find more info about RegularFile/Directory types and their *Property counterparts. The most relevant documentation is this section in the "Lazy configuration" chapter. However, it is simply not possible to discover it through search!

Even though this page I mentioned contains 13 occurrences of the "RegularFile" word, it is not visible in search results, even though it is clearly relevant; meanwhile, whatever the search box displays is completely useless since those results point to API documentation for some obscure features of the DSL/API.

FWIW, this seems to be fixed currently - I see much more than 5 results for most of the searches.

repo: gradle/gradle


text:
Improve outputContains output for integration testing

Continuation of work on https://github.com/gradle/gradle/pull/19561.
The core team is in agreement that the AbstractIntegrationTest#outputContains() method produces output that is difficult to understand.  In particular, finding exactly where a mismatch has occurred in a large comparison leave much to be desired.
An early attempt to provide an alternative is below.  See if the spirit of this code can be added into outputContains directly to change and clarify its output and improve its usefulness.
    /**
     * Given a string containing a first line which is unique within the expected output, checks
     * if every line in the output matches the lines in the given string, reporting the failing line and number
     * within both the actual and expected outputs.
     *
     * @param string the expected output
     */
    void outputContainsLinewise(String string) {
        outputContainsLinewise(string.readLines())
    }

    /**
     * Given a collection of lines beginning with a line which is unique within the expected output, checks
     * if every line in the output matches the lines in the given string, reporting the failing line and number
     * within both the actual and expected outputs.
     *
     * @param lines the expected output
     */
    void outputContainsLinewise(List<String> lines) {
        List<String> outputLines = result.output.readLines()
        def firstIndex = outputLines.findIndexOf {lines[0] == it }
        (0..<lines.size()).each {
            def actual = outputLines[firstIndex + it].trim()
            def expected = lines[it].trim()
            if (actual != expected) {
                throw new AssertionError("Output line ${firstIndex + it}: '$actual'\ndid not match expected line $it: '$expected'")
            }
        }
    }

Naming suggestion: outputContainsUniqueLine(String) or outputContainsLineOnce(String)

Current state of output: If you edit a test which uses outputContains() in org.gradle.api.tasks.diagnostics.AbstractIntegrationSpec such as `org.gradle.api.tasks.diagnostics.OutgoingVariantsReportTaskIntegrationTest#prints explicit capabilities()" to include lines in the expected output which do not match what is produced (for example, I added "This line should NOT be here!" below the first line beginning with "Description = ") you get the following printed to the test Console:
ACTUAL TASK OUTPUT OMITTED
Condition failed with Exception:

outputContains """> Task :outgoingVariants -------------------------------------------------- Variant runtimeElements -------------------------------------------------- Description = Elements of runtime for main. This line should NOT be here! Capabilities - org.test:extra:1.0 - org.test:other:3.0 """
|
org.junit.ComparisonFailure: Did not find expected text in build output.
Expected: > Task :outgoingVariants
--------------------------------------------------
Variant runtimeElements
--------------------------------------------------
Description = Elements of runtime for main.
This line should NOT be here!

Capabilities
    - org.test:extra:1.0
    - org.test:other:3.0

Build output:
=======

REPEAT OF ACTUAL TASK OUTPUT OMITTED
Output:
=======

REPEAT OF ACTUAL TASK OUTPUT OMITTED
Error:
======
expected:<[> Task :outgoingVariants
--------------------------------------------------
Variant runtimeElements
--------------------------------------------------
Description = Elements of runtime for main.
This line should NOT be here!

Capabilities
   - org.test:extra:1.0
   - org.test:other:3.0]> but was:<[
> Task :outgoingVariants
--------------------------------------------------
Variant runtimeElements
--------------------------------------------------
Description = Elements of runtime for main.

Capabilities
   - org.test:extra:1.0
   - org.test:other:3.0

Attributes
   - org.gradle.category            = library
   - org.gradle.dependency.bundling = external
   - org.gradle.jvm.version         = 11
   - org.gradle.libraryelements     = jar
   - org.gradle.usage               = java-runtime

Artifacts
   - build/libs/myLib.jar (artifactType = jar)

Secondary variants (*)
   - Variant : classes
      - Attributes
         - org.gradle.category            = library
         - org.gradle.dependency.bundling = external
         - org.gradle.jvm.version         = 11
         - org.gradle.libraryelements     = classes
         - org.gradle.usage               = java-runtime
      - Artifacts
         - build/classes/java/main (artifactType = java-classes-directory)
   - Variant : resources
      - Attributes
         - org.gradle.category            = library
         - org.gradle.dependency.bundling = external
         - org.gradle.jvm.version         = 11
         - org.gradle.libraryelements     = resources
         - org.gradle.usage               = java-runtime
      - Artifacts
         - build/resources/main (artifactType = java-resources-directory)

(*) Secondary variants are variants created via the Configuration#getOutgoing(): ConfigurationPublications API which also participate in selection, in addition to the configuration itself.
]>
   at org.gradle.integtests.fixtures.executer.OutputScrapingExecutionResult.failOnMissingOutput(OutputScrapingExecutionResult.java:394)
   at org.gradle.integtests.fixtures.executer.OutputScrapingExecutionResult.assertContentContains(OutputScrapingExecutionResult.java:227)
   at org.gradle.integtests.fixtures.executer.OutputScrapingExecutionResult.assertOutputContains(OutputScrapingExecutionResult.java:234)
   at org.gradle.integtests.fixtures.executer.InProcessGradleExecuter$InProcessExecutionResult.assertOutputContains(InProcessGradleExecuter.java:532)
   at org.gradle.integtests.fixtures.AbstractIntegrationSpec.outputContains(AbstractIntegrationSpec.groovy:594)
   at org.gradle.api.tasks.diagnostics.OutgoingVariantsReportTaskIntegrationTest.prints explicit capabilities(OutgoingVariantsReportTaskIntegrationTest.groovy:853)

Condition failed with Exception:

REPEAT EVERYTHING BETWEEN THE FIRST TWO "Condition failed with Exception" LINES OMITTED
This is extremely noisy.

Note that `result.groupedOutput.task(":outgoingVariants").assertOutputContains("""THE EXPECTED TEXT BLOCK""") results in output that is better, but still repeats the actual output needlessly and is difficult to use to find the mismatched line.
This can be improved somewhat by overriding toString() on GroupedOutputFixture to something like:
@Override
public String toString() {
    return "GroupedOutputFixture for tasks: " + Arrays.deepToString(tasks.keySet().toArray());
}

and on GroupedTaskFixture to something like:
@Override
public String toString() {
  return "Output for: " + taskName + " " + taskOutcome;
}

and then updating GroupedTaskFixture#assertOutputContains(String...) to:
public GroupedTaskFixture assertOutputContains(String... text) {
    String output = getOutput();
    for (String s : text) {
        if (!output.contains(s)) {
            throw new RuntimeException("Line 2 in expected output: [EXPECTED LINE] did not match actual line 5: in context: [CONTEXT LINES, with mismatch highlighted]");
        }
    }
    return this;
}

yields this:
Condition failed with Exception:

result.groupedOutput.task(":outgoingVariants").assertOutputContains """> Task :outgoingVariants -------------------------------------------------- Variant runtimeElements -------------------------------------------------- Description = Elements of runtime for main. Capabilities - org.test:extra:1.0 - org.test:other:3.0 """
|      |             |                         |
|      |             |                         java.lang.RuntimeException: Line 2 in expected output: [EXPECTED LINE] did not match actual line 5: in context: [CONTEXT LINES, with mismatch highlighted]
|      |             |                         	at org.gradle.integtests.fixtures.logging.GroupedTaskFixture.assertOutputContains(GroupedTaskFixture.java:75)
|      |             |                         	at org.gradle.api.tasks.diagnostics.OutgoingVariantsReportTaskIntegrationTest.prints explicit capabilities(OutgoingVariantsReportTaskIntegrationTest.groovy:853)
|      |             Output for: :outgoingVariants null
|      GroupedOutputFixture for tasks: [:outgoingVariants]
<org.gradle.integtests.fixtures.executer.InProcessGradleExecuter$InProcessExecutionResult@2ffef644 executedTasks=[:outgoingVariants] skippedTasks=[] outputResult=org.gradle.integtests.fixtures.executer.OutputScrapingExecutionResult@223a2e4a>

which is still repeated twice, but I think could be the starting point for much clearer output.  We could find the first mismatched line, throwing a different custom exception containing this message, and a different message still if NONE of the lines in expected matched actual.

Hi @leonard84 - I was searching for a way to disable Spock’s power assertions in order provide cleaner output when testing doing large block test comparisons fail.
I couldn’t find a way to do this.  I found this Spock commit: https://github.com/spockframework/spock/issues/922 and wondered if you had any ideas?  I wanted to disable the behavior changed by this commit https://github.com/spockframework/spock/pull/928/commits/79492021985944d7d4a3f4154106d6618af1a319#diff-925956eb662970e7d2d34da347e3588870ec74dba162589013bd2250156da854 and provide a more readable custom error message which entirely replaced the power assertion output.  What we are hoping to do is isolate the mismatched lines (I’m assuming there is usually only a single line of mismatch) and provide a couple of context lines without repeating the complete expected or actual text blocks involved in the comparison.

@leonard84 - Hi Leonard, when you have a chance, I'd like to hear your thoughts on this.

Continued here: https://github.com/gradle/gradle/issues/19608

authors: DPUkyle tresat


text:
Add support for JDK19

Everything appears to be working:
https://builds.gradle.org/viewLog.html?buildId=54959159&buildTypeId=Gradle_Experimental_Check_Stage_ReadyforNightly_Trigger

Update compatibility.adoc to say Gradle can run with JDK19
Add something to release-features.txt
Add something to release notes
Update CI configuration to allow tests to run with JDK19 on master/release
Look at the current matrix of test coverage on master/release and figure out where we add JDK19 coverage

We cannot call this done without us running some tests with JDK19.

bah, I didn't see #20372


text:
Misleading "No valid plugin descriptors" is shown when running from the configuration cache

Expected Behavior
No false positive warning about "No valid plugin descriptors were found" should be shown when building a plugin jar with the configuration cache.
Current Behavior
False positive warning is shown.
Steps to Reproduce
With the reproducer project:

Run ./gradlew jar
Run ./gradlew jar one more time, reusing the configuration cache

Your Environment
Gradle 7.5.1

Forgot to add analysis in the initial issue.
The PluginDescriptorCollectorAction and PluginValidationAction share the instance of List<PluginDescriptor> collection. The first one adds descriptors to the list, and the second reads the list. When deserialized from the cache, each action gets its own instance of the list, as the configuration cache ignores the list identity.

PluginValidationAction.classes has the same issue, it's just hidden by the fact that descriptors is empty and so for(:) is never executed.

authors: TWiStErRob mlopatkin


text:
Allow convention mapping to work with ConfigurableFileCollection properties

For requirements of supporting old plugins after lazy-migration, we have to support also ConfigurableFileCollection with convention mapping in the same way as we did for properties: https://github.com/gradle/gradle/pull/24582

This is a blocker for the provider API migration right now. We can't convert AbstractCompile.classpath because of this problem.

This didn't make 8.7, but should be there in 8.8.

authors: abstratt asodja lptr


text:
AmbiguousVariantSelectionException: More than one variant of project :core matches the consumer attributes:

Hello Gradle Team,
We are the maintainers of the Gradle Artifactory Plugin. We received this issue reported to us, in which an exception is thrown, when the plugin uses the configuration.getResolvedArtifacts() API.
This is the exception thrown:
org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration ':foo:releaseCompileClasspath'.
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver.wrapException(ErrorHandlingConfigurationResolver.java:96)
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver.access$000(ErrorHandlingConfigurationResolver.java:45)
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver$ErrorHandlingResolvedConfiguration.getResolvedArtifacts(ErrorHandlingConfigurationResolver.java:298)
        at org.jfrog.gradle.plugin.artifactory.extractor.GradleBuildInfoExtractor.calculateDependencies(GradleBuildInfoExtractor.java:331)
        at org.jfrog.gradle.plugin.artifactory.extractor.GradleBuildInfoExtractor.extractModule(GradleBuildInfoExtractor.java:294)
        at org.jfrog.gradle.plugin.artifactory.extractor.GradleBuildInfoExtractor.extract(GradleBuildInfoExtractor.java:119)
        at org.jfrog.gradle.plugin.artifactory.task.DeployTask.prepareAndDeploy(DeployTask.java:148)
        at org.jfrog.gradle.plugin.artifactory.task.DeployTask.collectProjectBuildInfo(DeployTask.java:50)
        at org.jfrog.gradle.plugin.artifactory.task.DeployTask.taskAction(DeployTask.java:44)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:46)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:788)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:755)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:124)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:113)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:95)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:73)
        at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
        at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:59)
        at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
        at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:59)
        at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:101)
        at org.gradle.api.internal.tasks.execution.FinalizeInputFilePropertiesTaskExecuter.execute(FinalizeInputFilePropertiesTaskExecuter.java:44)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:91)
        at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:62)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:59)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
        at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:256)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:249)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:238)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:663)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:597)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
        at java.lang.Thread.run(Thread.java:745)
Caused by: org.gradle.internal.component.AmbiguousVariantSelectionException: More than one variant of project :core matches the consumer attributes:
  - Configuration ':core:releaseApiElements' variant android-aidl:
      - Found artifactType 'android-aidl' but wasn't required.
      - Required com.android.build.api.attributes.BuildTypeAttr 'release' and found compatible value 'release'.
      - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
      - Found com.android.build.gradle.internal.dependency.VariantAttr 'release' but wasn't required.
      - Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
  - Configuration ':core:releaseApiElements' variant android-classes:
      - Found artifactType 'android-classes' but wasn't required.
      - Required com.android.build.api.attributes.BuildTypeAttr 'release' and found compatible value 'release'.
      - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
      - Found com.android.build.gradle.internal.dependency.VariantAttr 'release' but wasn't required.
      - Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
  - Configuration ':core:releaseApiElements' variant android-manifest:
      - Found artifactType 'android-manifest' but wasn't required.
      - Required com.android.build.api.attributes.BuildTypeAttr 'release' and found compatible value 'release'.
      - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
      - Found com.android.build.gradle.internal.dependency.VariantAttr 'release' but wasn't required.
      - Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
  - Configuration ':core:releaseApiElements' variant android-renderscript:
      - Found artifactType 'android-renderscript' but wasn't required.
      - Required com.android.build.api.attributes.BuildTypeAttr 'release' and found compatible value 'release'.
      - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
      - Found com.android.build.gradle.internal.dependency.VariantAttr 'release' but wasn't required.
      - Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
  - Configuration ':core:releaseApiElements' variant jar:
      - Found artifactType 'jar' but wasn't required.
      - Required com.android.build.api.attributes.BuildTypeAttr 'release' and found compatible value 'release'.
      - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
      - Found com.android.build.gradle.internal.dependency.VariantAttr 'release' but wasn't required.
      - Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
        at org.gradle.api.internal.artifacts.transform.AttributeMatchingVariantSelector.doSelect(AttributeMatchingVariantSelector.java:70)
        at org.gradle.api.internal.artifacts.transform.AttributeMatchingVariantSelector.select(AttributeMatchingVariantSelector.java:55)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.artifact.DefaultArtifactSet.select(DefaultArtifactSet.java:125)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.artifact.DefaultVisitedArtifactResults.select(DefaultVisitedArtifactResults.java:48)
        at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.select(DefaultLenientConfiguration.java:111)
        at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.select(DefaultLenientConfiguration.java:100)
        at org.gradle.api.internal.artifacts.ivyservice.DefaultResolvedConfiguration.getResolvedArtifacts(DefaultResolvedConfiguration.java:78)
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver$ErrorHandlingResolvedConfiguration.getResolvedArtifacts(ErrorHandlingConfigurationResolver.java:296)
        ... 56 more
Error during extraction:
org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration ':muu:releaseCompileClasspath'.
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver.wrapException(ErrorHandlingConfigurationResolver.java:96)
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver.access$000(ErrorHandlingConfigurationResolver.java:45)
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver$ErrorHandlingResolvedConfiguration.getResolvedArtifacts(ErrorHandlingConfigurationResolver.java:298)
        at org.jfrog.gradle.plugin.artifactory.extractor.GradleBuildInfoExtractor.calculateDependencies(GradleBuildInfoExtractor.java:331)
        at org.jfrog.gradle.plugin.artifactory.extractor.GradleBuildInfoExtractor.extractModule(GradleBuildInfoExtractor.java:294)
        at org.jfrog.gradle.plugin.artifactory.extractor.GradleBuildInfoExtractor.extract(GradleBuildInfoExtractor.java:119)
        at org.jfrog.gradle.plugin.artifactory.task.DeployTask.prepareAndDeploy(DeployTask.java:148)
        at org.jfrog.gradle.plugin.artifactory.task.DeployTask.collectProjectBuildInfo(DeployTask.java:50)
        at org.jfrog.gradle.plugin.artifactory.task.DeployTask.taskAction(DeployTask.java:44)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:46)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:788)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:755)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:124)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:113)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:95)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:73)
        at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
        at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:59)
        at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
        at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:59)
        at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:101)
        at org.gradle.api.internal.tasks.execution.FinalizeInputFilePropertiesTaskExecuter.execute(FinalizeInputFilePropertiesTaskExecuter.java:44)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:91)
        at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:62)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:59)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
        at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:256)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:249)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:238)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:663)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:597)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
        at java.lang.Thread.run(Thread.java:745)
Caused by: org.gradle.internal.component.AmbiguousVariantSelectionException: More than one variant of project :core matches the consumer attributes:
  - Configuration ':core:releaseApiElements' variant android-aidl:
      - Found artifactType 'android-aidl' but wasn't required.
      - Required com.android.build.api.attributes.BuildTypeAttr 'release' and found compatible value 'release'.
      - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
      - Found com.android.build.gradle.internal.dependency.VariantAttr 'release' but wasn't required.
      - Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
  - Configuration ':core:releaseApiElements' variant android-classes:
      - Found artifactType 'android-classes' but wasn't required.
      - Required com.android.build.api.attributes.BuildTypeAttr 'release' and found compatible value 'release'.
      - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
      - Found com.android.build.gradle.internal.dependency.VariantAttr 'release' but wasn't required.
      - Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
  - Configuration ':core:releaseApiElements' variant android-manifest:
      - Found artifactType 'android-manifest' but wasn't required.
      - Required com.android.build.api.attributes.BuildTypeAttr 'release' and found compatible value 'release'.
      - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
      - Found com.android.build.gradle.internal.dependency.VariantAttr 'release' but wasn't required.
      - Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
  - Configuration ':core:releaseApiElements' variant android-renderscript:
      - Found artifactType 'android-renderscript' but wasn't required.
      - Required com.android.build.api.attributes.BuildTypeAttr 'release' and found compatible value 'release'.
      - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
      - Found com.android.build.gradle.internal.dependency.VariantAttr 'release' but wasn't required.
      - Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
  - Configuration ':core:releaseApiElements' variant jar:
      - Found artifactType 'jar' but wasn't required.
      - Required com.android.build.api.attributes.BuildTypeAttr 'release' and found compatible value 'release'.
      - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
      - Found com.android.build.gradle.internal.dependency.VariantAttr 'release' but wasn't required.
      - Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
        at org.gradle.api.internal.artifacts.transform.AttributeMatchingVariantSelector.doSelect(AttributeMatchingVariantSelector.java:70)
        at org.gradle.api.internal.artifacts.transform.AttributeMatchingVariantSelector.select(AttributeMatchingVariantSelector.java:55)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.artifact.DefaultArtifactSet.select(DefaultArtifactSet.java:125)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.artifact.DefaultVisitedArtifactResults.select(DefaultVisitedArtifactResults.java:48)
        at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.select(DefaultLenientConfiguration.java:111)
        at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.select(DefaultLenientConfiguration.java:100)
        at org.gradle.api.internal.artifacts.ivyservice.DefaultResolvedConfiguration.getResolvedArtifacts(DefaultResolvedConfiguration.java:78)
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver$ErrorHandlingResolvedConfiguration.getResolvedArtifacts(ErrorHandlingConfigurationResolver.java:296)
        ... 56 more

We're not yet sure in which scenario this exception is thrown and what we need to do differently in the plugin code to avoid it. We were hoping to get some guidance from you guys about this.
Here's the code which uses the API in the org.jfrog.gradle.plugin.artifactory.extractor.GradleBuildInfoExtractor class:
    private List<Dependency> calculateDependencies(Project project) throws Exception {
        Set<Configuration> configurationSet = project.getConfigurations();
        List<Dependency> dependencies = newArrayList();
        for (Configuration configuration : configurationSet) {
            if (configuration.getState() != Configuration.State.RESOLVED) {
                log.info("Artifacts for configuration '{}' were not all resolved, skipping", configuration.getName());
                continue;
            }
            ResolvedConfiguration resolvedConfiguration = configuration.getResolvedConfiguration();
            Set<ResolvedArtifact> resolvedArtifactSet = resolvedConfiguration.getResolvedArtifacts();

There are more details and a project sample which reproduces this issue in https://github.com/JFrogDev/build-info/issues/139
Thank you!

Any news about this? I'm having the same issue

Any news about this , I go same issue too .

I'm having troubles reproducing this locally (I downloaded one of the linked projects but I don't have Artifactory to try out, nor do I have the proper Android SDKs installed). Gradle 6.4 will include nicer error messages when resolution fails, so if anyone can try out, it would be great. This won't fix this issue, which I think is inherently a consequence of how Android internally resolves artifacts. I don't think anyone is supposed to reuse the result of the resolution of the *Classpath configurations directly, because all configurations in Android are resolved using the artifact query API, which sets additional attributes (in particular the artifact type) that Android can use to resolve. We don't have the context here.

I'm having troubles reproducing this locally (I downloaded one of the linked projects but I don't have Artifactory to try out, nor do I have the proper Android SDKs installed). Gradle 6.4 will include nicer error messages when resolution fails, so if anyone can try out, it would be great. This won't fix this issue, which I think is inherently a consequence of how Android internally resolves artifacts. I don't think anyone is supposed to reuse the result of the resolution of the *Classpath configurations directly, because all configurations in Android are resolved using the artifact query API, which sets additional attributes (in particular the artifact type) that Android can use to resolve. We don't have the context here.

Hi Cedric,
I was able to reproduce the error following the steps from this project https://github.com/plackemacher/BugArtifactory. I also had the latest version of the artifactory gradle plugin downloaded (https://www.jfrog.com/confluence/display/JFROG/Gradle+Artifactory+Plugin)
you also mentioned that you did not have an artifactory to test this on. Here is the link to sign up for a free trial of Artifactory (https://jfrog.com/artifactory/free-trial/#saas). If you can sign up for the trial and test this using the steps from the provided link, that would be most appreciated. Please let me know if you have any questions.

It seems like cradle gets confused if you declare your dependencies like this
implementation project(":my-project")instead of declaring them like this implementation project(path: ":my-project")`
Adding the path label solves this issue

This may still be a problem, but it looks like it's an "expected" issue where there are multiple compatible variants and Gradle cannot choose between them for the given resolvable's attributes.

authors: Ezekiel-Knox MarcPoggiWiko alexandru1208 big-guy eyalbe4 juanchosaravia melix


text:
Use volatile in DefaultClassLoaderScope

Context
This is an attempt to fix https://github.com/gradle/gradle-private/issues/1903
A field should be volatile when used in multithread environment, otherwise there might
be visibility issues - which might be the cause of gradle-private#1903
This commit fixes this issue by using volatile correctly.

Fixes https://github.com/gradle/gradle-private/issues/1903

@ldaley Can you please take a look at this? It's a pretty small change.

@blindpirate is this something we still need?

I think so, would you mind taking a quick look?

@blindpirate DefaultClassLoaderScope is fundamentally not threadsafe.
What is the requirement here?

At the context of https://github.com/gradle/build-tool-flaky-tests/issues/16 I thought that might be an visibility issue. Unfortunately, the original error reports are cleaned up by TeamCity, so I'm closing it now, unless we see any further failure report.

authors: big-guy blindpirate ldaley


text:
Let Gradle 6.0 work with Zinc 1.3.0

The current implementation of org.gradle.api.internal.tasks.scala.ZincScalaCompilerFactory#getCompiler calls ZincUtil#getDefaultBridgeModule,
which is an internal class, but more importantly, it's been removed in Zinc 1.3.0.
There is probably a better way to prevent the use of Zinc internal classes, but moving the functionality to determine the bridge module name
feels good enough and not too intrusive given the short time left for Gradle 6.0.
A quick try to pull in zinc 1.3.0 via the zinc configuration works with the patch, but fails without it.
Signed-off-by: Robert Stupp snazy@snazy.de
Context

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] 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 locally: ./gradlew <changed-subproject>:check

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in release notes

I haven't had the time to let the existing tests exercise against Zinc 1.2.5 and 1.3.0. Sorry.

Thanks @snazy - I had tried 1.3.0 earlier and saw compilation failures and thought it would be too much trouble to make it work for 6.0.   Your PR made it clear that it was pretty straightforward, so I've merged this and tweaked it a bit for 6.0.

authors: big-guy snazy


text:
Update tested AGP versions

from 4.2.0-alpha13 to 4.2.0-alpha15
bump 4.2 nightly

@bot-gradle test RFN

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

@bot-gradle test RFN

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

authors: bot-gradle eskatos


text:
Add publishing of dependency constraints to Gradle module metadata

See #3551. Follow up to #3588.

Thanks for the review and the very good suggestions on test coverage @bigdaz.
I addressed the comments and merged. We now have test that show the issue with not publishing constraints to maven/ivy when the version is missing. I created this follow up to address this at a later point: https://github.com/gradle/gradle/issues/3655


text:
Play application plugin: Migrate integration tests

Migrate existing integration tests as much as possible
Excludes integration testing for functionality that uses continuous build & running an application (TestKit does not provide proper support to easily implement scenarios)
Multi-version testing is not supported
All tests should pass

Implementation:

https://github.com/gradle/play/tree/master/src/integTest/groovy/com/lightbend/play/application

This test currently fails with a compilation issue: https://github.com/gradle/play/blob/master/src/integTest/groovy/com/lightbend/play/application/advanced/PlayBinaryAdvancedAppIntegrationTest.groovy

repo: gradle/play


text:
Document wildcards in attributes.select

Document the feature from PRs https://github.com/grafana/beyla/pull/991 and https://github.com/grafana/beyla/pull/995

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 66.35%. Comparing base (58de56a) to head (fe745e2).

:exclamation:  There is a different number of reports uploaded between BASE (58de56a) and HEAD (fe745e2). Click for more details.
HEAD has 2 uploads less than BASE

Flag
BASE (58de56a)
HEAD (fe745e2)

k8s-integration-test
1
0

integration-test
1
0

Additional details and impacted files
@@             Coverage Diff             @@
##             main     #996       +/-   ##
===========================================
- Coverage   80.75%   66.35%   -14.41%
===========================================
  Files         134      134
  Lines       10721    10721
===========================================
- Hits         8658     7114     -1544
- Misses       1558     3116     +1558
+ Partials      505      491       -14

Flag
Coverage Δ

integration-test
?

k8s-integration-test
?

oats-test
36.41% <ø> (ø)

unittests
50.81% <ø> (+<0.01%)
:arrow_up:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter mariomac

repo: grafana/beyla


text:
Error 400 after upgrading grafana from 10.2.2 to 10.2.3

After upgrading grafana from 10.2.2 to 10.2.3, existing dashboards using zabbix-grafana plugin return error 400 in Metrics panels
When changing again to 10.2.2 the dashboards are working fine. Looking for the error it seems that the query is malformed because executing the query in the database gives an error

Software versions

Grafana
Zabbix
Grafana-Zabbix Plugin

10.2.3
6.0.14
4.4.4

I can confirm this reproducible on the latest version of Zabbix server 6 LTS - 6.0.25
offending queries comparison between Grafana 10.2.2 and 10.2.3 :
10.2.2 (working):
SELECT to_char(itemid, 'FM99999999999999999999') AS metric, clock / 15 * 15 AS time, AVG(value) AS value FROM history_uint WHERE itemid IN (42243) AND clock > 1704181979 AND clock < 1704203579 GROUP BY 1, 2 ORDER BY time ASC
10.2.3 (broken):
SELECT CAST(itemid AS CHAR) AS metric, clock DIV 15 * 15 AS time_sec, AVG(value) AS value FROM history_uint WHERE itemid IN (42243) AND clock > 1704179801 AND clock < 1704201401 GROUP BY clock DIV 15 * 15, metric ORDER BY time_sec ASC

Further investigation shows that "Direct DB connection" setting has been emptied after upgrade onto grafana v 10.2.3
Zabbix data source cannot see any Postgres DB anymore (however can see mysql ones)
finally, grafana-zabbix is getting confused by the code grafana-zabbix-main\src\datasource\zabbix\connectors\sql\sqlConnector.ts:
loadSQLDialect() {
if (this.datasourceTypeId === supportedDatabases.postgres) {
this.sqlDialect = postgres;
} else {
this.sqlDialect = mysql;
}
}
which explains the malformed query

related to https://github.com/grafana/grafana-zabbix/issues/1764

+1
Grafana: 10.2.3
Zabbix: 6.4.10
Grafana-Zabbix Plugin: 4.4.4

this seems to be duplicate of https://github.com/grafana/grafana-zabbix/issues/1764 , closing this one.

authors: daFlo gabor jmhg2 maxtymchenko

repo: grafana/grafana-zabbix


text:
Grafana throws ExpiredTokenException after a certain period

After setting up Sitewise plugin on Grafana it works for a while and then starts throwing "failed to fetch query data: ExpiredTokenException: status code: 403, request id: a9c25a27-c012-488d-a65a-18fc21a1939f" The error is gone after restarting the the ec2 running grafana. After a while the error comes back again.

likely need a refresh hook in the credentials logic, to attempt to reload the file/re-request the assume role

Perhaps related to:
https://github.com/grafana/timestream-datasource/issues/11
And hopefully can be fixed with shared code.  Hopefully:
https://github.com/grafana/grafana-aws-sdk/tree/main/pkg/awsds
(This is copied from how core is doing cloudwatch)

@sounavo can you try again?  this is most likely fixed
See the instructions on: https://github.com/grafana/iot-sitewise-datasource#aws-iot-sitewise-datasource-development-guide for how to get the latest dev build

@ryantxu I still seem to be getting this issue after installing the new build. Happy to screenshare over slack if that helps

Hey @sounavo, I'm working to repro this in my own environment.
Quick question - can you confirm your auth type setup? Are you using the ec2 instance role to assume the Assume Role ARN? See below:

If so, what is the maximum session duration for your ec2 and assume role arn roles?

I am using ec2 instance role with max session 1 hour.

Yes deleted the unzip line by mistake. But restoring it didn't fix the issue

the unzip path there is for darwin. Are you running the grafana server on an OSX machine? or ec2 instance?

@sounavo can you add more details if you are still having errors.  I assume this is fixed now with recent releases

@sounavo can you add more details if you are still having errors.  I assume this is fixed now with recent releases

I can confirm that this issue is now fixed on the main branch.

I can confirm that this issue is now fixed on the main branch.

authors: bymattoa ryantxu sounavo

repo: grafana/iot-sitewise-datasource


text:
OpenSearch: Creating new client on each query

What happened:
Hello,
When using the "OpenSearch Grafana Data Source" plugin, we found "Creating a new client" entries in the Grafana debug logs. These entries appear with every index query, including when alert rules are used (every minute). As far as I understand, a new session is created for each opensearch index request. Is this a normal condition?
We are currently working with only 2 opensearch indexes, but if their number increases to 100, will this cause problems with the availability of free sockets on the OpenSearch side?
What you expected to happen:
Is it possible to configure the grafana plugin to reuse the connection to opensearch?
Anything else we need to know?:
There were no such entries when using Elasticsearch Data Source - Native Plugin.
Environment:

Grafana version: 10.3.1
OpenSearch version: 2.2.0
Plugin version: 2.14.3

Hi @borichevsky, when we query data, we are reusing the datasource's httpclient, which should be reusing the underlying connections to OpenSearch.
The message you're seeing is referring to our own client which we use internally to build up the query that we send to OpenSearch. See the following:
https://github.com/grafana/opensearch-datasource/blob/c4af356acd57b28aa43874d261daf39f0feb5b7a/pkg/opensearch/client/client.go#L160-L176
Note that the httpclient is the datasource's httpclient that's passed in here:
https://github.com/grafana/opensearch-datasource/blob/c4af356acd57b28aa43874d261daf39f0feb5b7a/pkg/opensearch/opensearch.go#L62

There were no such entries when using Elasticsearch Data Source - Native Plugin.

The Elasticsearch data source does this as well. See the following https://github.com/grafana/grafana/blob/484106eb04025b77a8eb7b32afa2e02b8377c9ae/pkg/tsdb/elasticsearch/client/client.go#L71
The OpenSearch data source logs it at an info level while the Elasticsearch data sources logs it at a debug level. You'd have to set the log level to debug to see it.

closing due to inactivity

authors: borichevsky kevinwcyu sarahzinger

repo: grafana/opensearch-datasource


text:
match Add() and AddRepos() and correct typos

Supersedes https://github.com/grafana/tanka/pull/640 (adding unit tests)

@julienduchesne thx for helping out my lazy ass with the tests here ;)

authors: julienduchesne redradrat

repo: grafana/tanka


text:
Fix build with LibreSSL

Same approach as for BoringSSL

As applied for HardenedBSD (FreeBSD derivative, default LibreSSL in base)
https://github.com/HardenedBSD/hardenedbsd-ports/commit/9b7ec1cd853bdab3da253c529fc125cf8773e197

Does this actually work?
LibreSSL 2.5.1 (the latest version) doesn't provide SSL_CTX_set_signed_cert_timestamp_list or SSL_CTX_add_server_custom_ext.

I'd be happy to merge this if LibreSSL does provide the required functions, but I don't think it does. Closing for now but feel free to re-open if I'm mistaken (e.g. does HardenedBSD use a fork of LibreSSL which adds the required functions?)

repo: grahamedgecombe/nginx-ct

license: ISC


text:
Fix release notes template

@toolchains_llvm should be @llvm_toolchain in the final load().

Latest release note has been edited.

authors: mikebauer siddharthab

repo: grailbio/bazel-toolchain


text:
MD5SUM the same for all Grails Changes

Task List

[ x ] Steps to reproduce provided
[ x ] Stacktrace (if present) provided
[ x ] Full description of the issue provided (see below)
[ x ] Link to the code that is causing this

Steps to Reproduce

Run a migration script with multiple grails changes
Look at the DB change log:
SELECT * FROM tdstm.DATABASECHANGELOG where DESCRIPTION='Grails Change'  order by ORDEREXECUTED desc
Note the MD5SUM values are all the same

Expected Behaviour
All the MD5SUM values should be different even for grails changes and should be based off the content of the change script.
Actual Behaviour
All the MD5SUM values are the same for grails changes.
Environment Information

Operating System: MAC
Grails Version: 2.5.5, 3.3.10, 4.0.1
Plugin Version: any including the latest
Database: MYSQL
JDK Version: 1.8

The line of code responsible for this is:
https://github.com/grails-plugins/grails-database-migration/blob/master/src/main/groovy/org/grails/plugins/databasemigration/liquibase/GroovyChange.groovy#L179

@virtualdogbert I am not able to replicate this.  All the md5sum values are different as expected for me.

Are those md5sums for SQL change or Grails changes, because the md5 for all the grails changes I have are all the same... Actually,  if I go back in time some of the MD5SUMs for grails changes are null.

@bobbywarner  just coming back to this wondering are you setting the checksum in all of your migrations?
in the docs it says:
checkSum

The checksum for the change will be generated automatically, but if you want to override the value that gets hashed you can specify it with the checkSum(String value) method.

But the code does this
 @Override
    CheckSum generateCheckSum() {
        CheckSum.compute checksumString ?: 'Grails Change'
    }

So if you're not setting it manually, the check some become "Grails Change" for all Grails migrations, rendering the checksum essential useless for Grails changes.

authors: bobbywarner virtualdogbert


text:
Use release version of tracing

What is the goal of this PR?
To fix a dependency issue where a snapshot version of grabl tracing was being used rather than a release version, requiring the user to add our snapshot repo. This release version was not available at the time but the snapshot repo was already in the maven test pom, which meant the issue was not noticed when the snapshot version was used.
What are the changes implemented in this PR?

Removed snapshot repo from maven test application
Changed version of grabl tracing to 0.1.0

This PR has an empty diff, @adammitchelldev @lolski. Is this expected? Should we close it?

authors: adammitchelldev haikalpribadi

repo: graknlabs/client-java


text:
License

Could you specify the license for View? Thanks.

Algo

repo: grantland/android-autofittextview


text:
Switch README etc from iris to penguins?

The four examples in the README work quite well with one added pp <- palmerpenguins::penguins.  Here for example is the fourth as I just put it together for a slide:

Thanks @eddelbuettel. I thought about it a while back, but would prefer to stick with datasets in the base package for the quickstart example. Maybe once/if https://github.com/r-devel/r-svn/pull/154 is merged....
Plot looks good, though! One minor suggestion would be call par(las = 1, lab = c(10,10,7)) beforehand to get better coverage across the axes. I hope to roll this kind of aesthetic automation into a tinytheme() function---no relation---at some point.

authors: eddelbuettel grantmcdermott

repo: grantmcdermott/tinyplot


text:
Support for PackageType 'Image

AWS recently added a new PackageType Image, here is an example:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      PackageType: Image
      # ImageConfig:
        # Uncomment this to override command here from the Dockerfile
        # Command: ["app.lambdaHandler"]
      Events:
        HelloWorld:
          Type: Api
          Properties:
            RestApiId: !Ref Api
            Path: /hello
            Method: get
    Metadata:
      DockerTag: nodejs12.x-v1
      DockerContext: ./src/hello-world
      Dockerfile: Dockerfile

aws-sam-webpack-plugin currently does not support image type and throws Error: Error: HelloWorldFunction has an unsupport Runtime. Must be nodejs10.x or nodejs12.x

@derdeka I'm going to need to roll this change back. I rushed and misunderstood the PackageType: Image. I don't think this can be supported.

authors: buggy derdeka

repo: graphboss/aws-sam-webpack-plugin


text:
USAGE.md for all templates

next steps
permission setup

mention https://github.com/graphcool/templates/blob/master/templates.json

see https://github.com/graphcool/templates/blob/master/auth/facebook/USAGE.md

repo: graphcool/templates


text:
Fix typo in the Mailgun README.md

This just caught me off guard, tiny fix but might save people that 10 seconds of confusion when copy and pasting.

You don't need to specify graphcool/templates. Running gc add-template messaging/mailgun should work for you. If it does not, then it's a bug

authors: iamclaytonray jhalvorson