TH failed to change the attribute value for privious 2 subscribed attributes when  subscription are active for three atributes

Problem
When TH send the 3 subscription request to DUT. Each subscribe request should contain 3 different paths.
Once all subscriptions are active(all Subscription Requests succeed.),  it shouldn't cancel the previous subscription  when TH try to change the value of all the attributes that have been subscribed or trigger an action on the DUT to generate an event.but currently it is canceling   the previous 2 subscription and getting report data with appropriate attribute value for last subscription.
expected behavior:- TH should change the value of all 3 attributes that have been subscribed on DUT
*** actual behavior:-** TH  it is canceling  the previous 2 subscription and getting report data with appropriate attribute value for last subscription.
*** steps to reproduce:-**

./chip-tool interactive start
onoff  subscribe on-time  100 1000  1 1
levelcontrol  subscribe  on-level 100 1000  1 1
onoff subscribe start-up-on-off   100 1000 1 1
Once all above subscription are active try to change the attribute value by sending below commands
onoff  write on-time 1 1 1
levelcontrol  write  on-level  1  1 1
onoff write start-up-on-off  1 1 1

system configuration
Chip-tool - RPI-4, 8GB RAM
DUT - RPI - RPI-4, 8GB RAM
Platform : IP and wifi
Commit-ID : https://github.com/project-chip/connectedhomeip/commit/a1643eee5ef5534d494ae205bb586b4a9cbfee23
Dut application: all-clusters-app
Test-Plan reference:-
https://github.com/CHIP-Specifications/chip-test-plans/blob/master/src/interactiondatamodel.adoc#tc-idm-7-1-multi-fabric-subscription-test-cases-dut_server
PFA log below:-
[TC-IDM-7.1]Subscription.txt

@Rajashreekalmane Those commands are not sending --keepSubscriptions true with the subscriptions, so each one cancels all the previous ones.

@cjandhyala We may need changes to the verification steps here.


React Lesson 45

The Facebook Github React Documentation teaches that when change a property in state, based on the previous state, you should use, you should pass setState a funciton. It could look like this:

	handleClick() {
		this.setState( (prevState) => ({
			counter: prevState.counter+1// change code here
		}) );
	}

In the Results component in this lesson there is a constructor. When I use Create-React-App with this code I receive a warning - "Useless constructor".

Yeah, this is probably a more technically correct way of performing a state update like this. Also a good opportunity to introduce some of this more nuanced behavior surrounding setState. Thanks for bringing this up.
I'll leave this open to you or anyone else who wants to work on a PR to update this challenge to reflect this!

Going to close this in the interest of migrating the curriculum into FCC.


High Severity Vulnerable Nuget Package Newtonsoft.Json 9.0.1

Latest main uses Newtonsoft.Json 9.0.1 which is marked as having at least 1 High severity vulnerability: https://www.nuget.org/packages/Newtonsoft.Json/9.0.1
Latest stable version of Newtonsoft.Json is 13.0.3.

Thanks for raising this @nathom791, this is now updated in version 8.10.0 of the Mailosaur .NET client


Ref #8401. Refactor XRCE entities.

This PR refactors XRCE Entities and removes shared pointers between entities and keeps a shared pointer to the owner proxy client in order to access middleware

Build status:

Linux
Windows

Build status:

Linux
Windows

Build status:

Linux
Windows

Build status:

Linux
Windows

Build status:

Linux
Windows

Build status:

Linux
Windows

Build status:

Linux
Windows


Inline card mentions

Something like I'm building a new [[Grand Calcutron]] Commander deck.
The bot would reply with the card with the shortest Levenshtein distance to the text in the brackets. Additionally, [[SET:Card name]], where SET is a set code, could be used to only search in a single set.

This feature should also have to be explicitly enabled for each channel, to avoid conflict with the PlaneSculptor bot in the Custom Magic guild.

This has been implemented for a while now.


Add Fortran language support

@janmolnar has forked Atom Beautify and added a beautifier for Fortran. May be worth taking a look into.
See https://github.com/janmolnar/atom-beautify/commit/a7b579992306c967acfd702c64f505039e3abb33

Please tell me if there is something I should do to make this happen. The current implementation invokes emacs to format the fortran script. In this way I can format code part of legacy projects in a consistent way.

You could submit a Pull Request adding Fortran support :smiley:.
I am still working on the documentation for this. Here's a quick overview.
How to add a Language:

Create a new Language file in https://github.com/Glavin001/atom-beautify/tree/master/src/languages
Configure the new language. Example for JavaScript language: https://github.com/Glavin001/atom-beautify/blob/master/src/languages/javascript.coffee#L8

name - name of Language
namespace - used as a prefix for scoping the options, such as option indent_size becomes js_indent_size for JavaScript language with namespace js
grammars - array of supported grammars. Used with extensions to determine if this file is this language or not. Grammars are prioritized over extensions, such that the grammar JavaScript is recognized before js and the beautifier with the same grammar as the file will be used over another that does not support the grammar and only the extension.
extensions - array of extensions, without . (dot), such that .js is js. Used to determine if a file is this language. Useful if there is no supported grammar in Atom for this language.
options - I'd recommend looking at https://github.com/Glavin001/atom-beautify/blob/master/src/languages/javascript.coffee#L30 for examples.

Add the language file to the list of language names. For instance, c-sharp.coffee file becomes c-sharp. See https://github.com/Glavin001/atom-beautify/blob/master/src/languages/index.coffee#L21
Now your Language is available and can be detected and beautifiers can support it.

How to add a Beautifier for a Language

Create a new beautifier subclass in https://github.com/Glavin001/atom-beautify/tree/master/src/beautifiers directory
Implement beautifier:

See examples of beautifiers:

Prettydiff is a good example of complex options: https://github.com/Glavin001/atom-beautify/blob/master/src/beautifiers/prettydiff.coffee
PHP-CS-Fixer is a good example of a CLI beautifier with arguments: https://github.com/Glavin001/atom-beautify/blob/master/src/beautifiers/php-cs-fixer.coffee#L15-L39

options - the key represents the Language's name, so Fortran. The value could be true (supports all options), false (supports language, with no options), or an object whose keys are option keys and values are complex mappings. If you need to use these, let me know. true is probably what you want.
The beautify function should return a Promise (use @Promise as shown). The arguments passed are: text, the source code from Atom's Text Editor, language is a string of the language's name (Fortran), and options is an object of all of the options in their form as described by your Language definition (see Configure the new language above).

Add beautifier to list of beautifierNames: https://github.com/Glavin001/atom-beautify/blob/master/src/beautifiers/index.coffee#L34
Add test example files in https://github.com/Glavin001/atom-beautify/tree/master/examples

You can put your test in nested-jsbeautifyrc directory, https://github.com/Glavin001/atom-beautify/tree/master/examples/nested-jsbeautifyrc
create a new directory for your tests, named something like Fortran
original and expected directory containing files that are named the same. Prefix underscore (_) disables a test. See https://github.com/Glavin001/atom-beautify/tree/master/examples/simple-jsbeautifyrc/php/original for instance.
change any options you need in your namespace, such as fortran, in https://github.com/Glavin001/atom-beautify/blob/master/examples/nested-jsbeautifyrc/.jsbeautifyrc
Run tests in Atom with command Window: Run package spec

I have to go. Let me know if you have any questions!

Published to v0.27.10


fix: @connection when field is given

*Issue #5358
Description of changes:

added case for @coonection directive when field argument is present.

added test for the same

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Closing in favour of #6031


🐛 Compilation Issues with Newest Z3 Version

As reported by CI in #89, the newest update of Z3 seems to have broken the QMAP build as both the tests as well as the Python package build fail to compile. This might need some investigation.
If anyone is up for that, feel free to submit a PR.

This seems to have resolved itself in the meantime. Closing for now.


Customizing the Framework

Adding short bit about adding custom .less files to a project.

:+1: Thanks, @awolfe76!


Baggageclaim in Concourse 2.2.1 reaps volumes but containers live on

Symptom: Users get insufficient subnets remaining in the pool error message
Concourse version: 2.2.1
garden-runc: 0.9.0
Deployment method: BOSH
IaaS: AWS
# we're bumping along the limit of containers, despite only running a handful of pipelines
$ fly -t target workers
name                                  containers  platform  tags  team
0a04d3fd-14e2-47ae-9f80-1d05532f68ac  253         linux     none  none

$ date
Fri Oct 28 10:07:35 UTC 2016

# Find out how many containers are > 10 hours old
$ ps -ef --sort=start_time | grep "runc events" | grep Oct | wc -l
174

$ ps -ef --sort=start_time | grep "runc events"
 # pick a container that should have died already
root     21710  5544  0 Oct27 ?        00:00:12 runc events 1de8a2b3-a72d-43ef-6bd2-e1a63a4b8c2c

$ gaol shell 1de8a2b3-a72d-43ef-6bd2-e1a63a4b8c2c
error: hijack: Backend error: Exit status: 500, message: {"Type":"","Message":"unable to find user root: no matching entries in passwd file","Handle":""}

$ gaol properties 1de8a2b3-a72d-43ef-6bd2-e1a63a4b8c2c
concourse:resource-process	eae0f660-8d4c-4ec9-77eb-8d7776e53b68
concourse:volume-mounts	{"7038a25d-ce4e-427e-5980-8e82913bf990":"/tmp/build/get"}
kawasaki.dns-servers
kawasaki.host-interface	wvo2n9aol8ni-0
garden.network.container-ip	<IP_ADDRESS>
garden.network.external-ip	<IP_ADDRESS>
kawasaki.iptable-inst	vo2n9aol8ni
kawasaki.iptable-prefix	w--
kawasaki.mtu	1500
concourse:resource-result	{
  "version": {
    "digest": "sha256:a1a112f981df3f101113f299b9d29826200e0ad3f0ae3330c9066b27fbbe1a2c"
  },
  "metadata": [
    {
      "name": "image",
      "value": "sha256:6cdfa"
    }
  ]
}

garden.grace-time<PHONE_NUMBER>00
kawasaki.bridge-interface	wbrdg-0afe0100
concourse:volumes	["7038a25d-ce4e-427e-5980-8e82913bf990","612630cf-45b6-41d5-7abf-cb6515919e09"]
garden.network.host-ip	<IP_ADDRESS>
garden.state	created
kawasaki.container-interface	wvo2n9aol8ni-1
kawasaki.subnet	<IP_ADDRESS>/30
user

# Can't access either volume
$ ls /var/vcap/data/baggageclaim/volumes/live/7038a25d-ce4e-427e-5980-8e82913bf990
ls: cannot access /var/vcap/data/baggageclaim/volumes/live/7038a25d-ce4e-427e-5980-8e82913bf990: No such file or directory

$ ls /var/vcap/data/baggageclaim/volumes/live/612630cf-45b6-41d5-7abf-cb6515919e09
ls: cannot access /var/vcap/data/baggageclaim/volumes/live/612630cf-45b6-41d5-7abf-cb6515919e09: No such file or directory

# Garden thinks it should be managing this container
$ gaol list | grep 1de8a2b3-a72d-43ef-6bd2-e1a63a4b8c2c
1de8a2b3-a72d-43ef-6bd2-e1a63a4b8c2c

# No result for container GUID in logs, but both volumes have been reaped by Baggage Claim
$ grep -e 612630cf-45b6-41d5-7abf-cb6515919e09 -e 7038a25d-ce4e-427e-5980-8e82913bf990 -e 1de8a2b3-a72d-43ef-6bd2-e1a63a4b8c2c baggageclaim.std*
baggageclaim.stdout.log:{"timestamp":"1477596534.502955675","source":"baggageclaim","message":"baggageclaim.tick.reaping","log_level":1,"data":{"handle":"612630cf-45b6-41d5-7abf-cb6515919e09","session":"69393","ttl":300}}
baggageclaim.stdout.log:{"timestamp":"1477600514.502540827","source":"baggageclaim","message":"baggageclaim.tick.reaping","log_level":1,"data":{"handle":"7038a25d-ce4e-427e-5980-8e82913bf990","session":"69791","ttl":300}}

If we then bosh ssh onto the ATC...
# There are logs going back a reasonable time
$ /var/vcap/sys/log/atc# ll
total 100212
drwxr-xr-x 2 vcap vcap     4096 Oct 28 01:00 ./
drwxr-x--- 9 root vcap     4096 Oct  6 20:02 ../
-rw-r--r-- 1 vcap vcap      186 Oct 27 09:58 atc.stderr.log
-rw-r--r-- 1 vcap vcap 34032368 Oct 28 10:39 atc.stdout.log
-rw-r--r-- 1 vcap vcap 52825246 Oct 28 01:00 atc.stdout.log.1
-rw-r--r-- 1 vcap vcap  2428611 Oct 27 09:15 atc.stdout.log.2.gz
-rw-r--r-- 1 vcap vcap  2528905 Oct 26 16:00 atc.stdout.log.3.gz
-rw-r--r-- 1 vcap vcap  2771483 Oct 25 23:15 atc.stdout.log.4.gz
-rw-r--r-- 1 vcap vcap  2819258 Oct 25 07:45 atc.stdout.log.5.gz
-rw-r--r-- 1 vcap vcap  2632093 Oct 24 16:30 atc.stdout.log.6.gz
-rw-r--r-- 1 vcap vcap  2548359 Oct 24 00:15 atc.stdout.log.7.gz

# no evidence of the container GUID being mentioned
$ zgrep 1de8a2b3-a72d-43ef-6bd2-e1a63a4b8c2c * | wc -l
0

Interestingly, this seems like it might be driven by user behaviour.
When listing container processes by time, it seems a little odd that there is only a single orphan since midnight, but as soon as it gets to office hours we start getting one orphan every couple of minutes.
$ ps -ef --sort=start_time | grep "/proc/self/exe"
# SNIP!
root     30704     1  0 Oct27 ?        00:00:00 /proc/self/exe init
root      5486     1  0 Oct27 ?        00:00:00 /proc/self/exe init
root     21706     1  0 Oct27 ?        00:00:00 /proc/self/exe init
root     32505     1  0 Oct27 ?        00:00:00 /proc/self/exe init
root      1629     1  0 04:10 ?        00:00:00 /proc/self/exe init
root     20108     1  0 09:48 ?        00:00:00 /proc/self/exe init
root     20853     1  0 09:48 ?        00:00:00 /proc/self/exe init
root     22398     1  0 09:48 ?        00:00:00 /proc/self/exe init
root     31571     1  0 09:51 ?        00:00:00 /proc/self/exe init
root      1366     1  0 09:51 ?        00:00:00 /proc/self/exe init
root      8974     1  0 09:53 ?        00:00:00 /proc/self/exe init
root     10608     1  0 09:54 ?        00:00:00 /proc/self/exe init
root     13974     1  0 09:54 ?        00:00:00 /proc/self/exe init
root     24614     1  0 09:57 ?        00:00:00 /proc/self/exe init
root     27895     1  0 09:58 ?        00:00:00 /proc/self/exe init
root     30103     1  0 09:59 ?        00:00:00 /proc/self/exe init
root     30769     1  0 09:59 ?        00:00:00 /proc/self/exe init

FWIW upgrading to 2.4.0 seems to have fixed the problem. It's only been a couple of days, but we're not seeing container counts creep up.
We also added a second worker, and saw orphans only on the first worker, and not on the second.

I'm gonna go ahead and close this; if it wasn't fixed in 2.4 it'll likely be fixed in concourse/concourse#629 at least.


[stable/sonatype-nexus] Add annotation configuration in pvc

I would like to keep a pvc object when I delete my release.
I use "helm.sh/resource-policy": keep in this case

/ok-to-test

/assign @unguiculus

cc @rjkernick

/ok-to-test

miss something ?

/lgtm


Android TV build error

@lukutism is this issue still occurring? tried helloWorld and it works fine. If it is, can you give me more info about the project, like config and such?


"Wine is not supported"

I'm trying to use Cork for Roblox, But everytime I launch it, it crashes with "Wine is not supported". Is there any way that I can fix this?
Wine version: wine-8.13
Linux revision: Linux archpc 6.1.45-1-lts #1 SMP PREEMPT_DYNAMIC Fri, 11 Aug 2023 11:28:00 +0000 x86_64 GNU/Linux
Distro: Arch Linux x86_64

Set your channel in the settings to zintegration, this will use the current dev build that allows for wine

Yep. That fixed it, Although I had to use Proton for it.
Can't apply the mouse patch for Wayland though which is sad, So I resorted to using gamescope for now.
Thanks.


Minor rewording to 'Log in as guest' in CONTRIBUTING.md

This matches the user interface in builds.gradle.org and makes it easier to find the button
Signed-off-by: Jeff Gaston<EMAIL_ADDRESS>Context
If I encounter a TeamCity failure, I often give up at the login screen: sometimes I try typing "guest" into the Username field and it doesn't work. This updates the instructions to more closely match the appropriate button to press.
Contributor Checklist

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

Gradle Core Team Checklist

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

@bot-gradle test and merge

No milestone for this PR. Please set a milestone and retry.

@bot-gradle test and merge

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


MVC1000 warning due to the use of IHtmlHelper.Partial

Warning MVC1000 is triggered in the following scaffolded pages:

Identity/Account/ExternalLogins.cshtml
Identity/Account/Index.cshtml

Use of IHtmlHelper.Partial may result in application deadlocks. Consider using  Tag Helper or IHtmlHelper.PartialAsync.

(there might be other instances of this, but I didn't scaffold all pages)

Oops, looks like it has already been fixed

Can you explain how this problem was solved? I get this error on every page I get from scaffolding

Can you explain how this problem was solved? I get this error on every page I get from scaffolding

It was fix in the code but the fix has not released yet.
You can just use <partial name="_StatusMessage" for="StatusMessage" /> instead of @Html.Partial("_StatusMessage", Model.StatusMessage).


chore: move install button to the pagetools section

Moved CTA to pagetools section
Responsive on Mobile

Are you also adding in the + icon from the feather library in this PR? See my comment on the issue, we do need that + icon

changes completed

Ugh 🤦  I caught an issue with this just after I merged in this PR: the icon isn't being rendered.
I'll submit a follow-up PR to address this and some other tweaks.


upgrade babel

Move from 5.x to 6.x

<EMAIL_ADDRESS>

https://egghead.io/lessons/angularjs-updating-babel-5-to-6


Updated tests for Applications, audit logs, groups, openid connect

So one thing to keep in mind here is that removing the mocking will make it non-testable to test certain things like AD integration since it will require the full blow setup in tests to actually work, same with any other FA stuff we use like multi factor or emails that require third party integrations. Just food for thought or keep in mind to make sure these are still testable. I could be wrong and maybe they have a internal test API we can use to mimic some of these interactions?

Unfortunately we won't be able to test things like AD.  At the moment our "tests" for those aren't verifying anything and are basically for documentation. This approach at least allows us to verify that most of our functions work with the service


Need full_name() function

Need a function that will return the "full" name string with isotope and charge state included. For example, full_name(Particle("He",2)) should return "He++".
It would be nice for full_name to have the option to return the unicode string with appropriate subscripts and superscripts. For example, return "³He" instead of "#3He"

I'm going to implement this with the existing ascii format, and then I'll figure out the unicode.

Note: full_name not yet exported.

It's exported now, still working on unicode implementation


new 12004 firmware (FTL and big speed increase)

The new 12004 firmware is a very big and desirable update.
However, it requires special care for people that decide to
update their older units on their own. What you need to do
is to make sure that all the bytes in flash memory are set to
0xFF. Since previous 12003 firmware did not implement FTL,
you could just overwrite all the bytes with the use of a hex
editor or some other software. Only after this is completed
you should proceed to updating the MCU with new firmware.
For now, both 12003 and 12004 firmwares are available in /extra/
directory. Should anything go wrong, you can always flash the
old 12003 version and the device will work.
Now, this firmware update significantly increases MSD access
speeds: from 223 KiB/s to 728 KiB/s for read access,
and also from  67 KiB/s to 110-150 KiB/s for writing.
The device now implements FTL (Flash Translation Layer), and
overprovisioning, which significantly reduces flash memory wear
and prolongs it's lifetime a lot. It does, however, mean that the
usable capacity will decrease, so you will only have about 24MiB
of space available to you after the update.

This new release also opens up the road to move on to a more
modern memory chip and eventually boost the capacity to 96MiB
and further increase the write speed, likely up to 500KiB/s or more


Copy-DbaLogin fails when an AD login on source is invalid

Bug Report

General Troubleshooting steps

[X] Verified running the latest release of dbatools?
[X] Verified errors are not related to permissions?
[X] Can duplicate in new/clean PowerShell session (clean = powershell -NoProfile)?

Version Information

Operating System (Name|Version): 6.3.9600 Microsoft Windows 8.1 Enterprise
PowerShell Version: 5.0.10586.117
SQL Server (Edition|Version):  Both are  12.0.5556.0 & EnterpriseOrDeveloper

Steps to Reproduce
Source server must have a login that has been removed from AD.
Target server must not have that login.
Copy-DbaLogin -Source Server1 -Destination Server2 -EnableException

[X] Attach any screenshots (if possible/allowed)
[ ] Attach logs generated by dbatools (Get-DbatoolsLog)
[X] Attach output from PowerShell console (if possible/allowed)

@frank687 maybe I'm missing something but I see this as by design. Copy commands do not have logic included (and would be out of scope) to have it validate if any given AD login is valid. We do not handle dependencies in the copy/migration commands. I would see this needing testing before you go to copy the logins, and a normal maintenance task for security to find logins no longer valid/in use.
We do have command that let you handle that ahead of time, so you could filter the result: Test-DbaWindowsLogin.


Steamvr Pause Menu Does Not Work

Pressing the menu button on the left controller used to bring up the steamvr menu but now it brings it up but it's invisible, so you can't use it.

I have seen this error with an earlier beta of steam VR.
If you are using a beta version, please revert to the regular version of steam VR.
If you are not using the beta, please state the alvr version and your steam VR version.
Try to uninstall and reinstall streamvr

I am using Steamvr version 1.10.22 and alvr version 2.4.0-experimental v9

I just tested with ev9 and SteamVR 1.10.26 and the menu works just fine.
Please try to reinstall steamvr

Alvr has stopped working for me entirely as of Steamvr version 1.10.28 because it is blocking the alvr extension, I am going to attempt downgrading it to 1.10.26

I was able to get alvr to work on 1.10.28 by opening C:\Program Files (x86)\Steam\config\steamvr.vrsettings in a text editor and set “Disabled By Safe Mode” to false on the alvr addon, however my menu is still not working

I have tried all SteamVR versions from 1.10.28 and the betas up to 1.10.32. Steam menu is working all the time. Have you tried to completely uninstall and reinstall SteamVR?

I have tried multiple times to reinstall steamvr, the current version downloaded is 1.10.32


🎨(clearboard) cleanify code structure

cleanify code structure and documentation to allow new commers to understand the code easily
Purpose
Cleanify code structure and rework some functions to allow new comers' arrival easier

remove the unused file coord.npy in the folder named backend


Youtube Iframe embed missing playlist parameter for looped videos.

We have seen an issue with the youtube embed code that is being generated when the "loop" parameter is used. It does not include the "playlist" parameter in the URL. This is an issue because:

Currently, the loop parameter only works in the AS3 player when used in conjunction with the playlist parameter.

https://developers.google.com/youtube/player_parameters#loop
I'm not exactly sure where to incorporate this in the code so no pull request yet.

I'm not sure MEJs supports the AS3 player, it uses iframe API. So I'm not sure this is an issue with the loop parameter in the current version of the player.

Please star the project to support it. Thanks

I have seen this in the player that appeared in the iframe embed. As I understand from the linked page the iframe embed does not nescesarily load one specific type of player.
See complete note about the "loop" parameter:
https://developers.google.com/youtube/player_parameters#loop

Note: This parameter has limited support in the AS3 player and in IFrame embeds, which could load either the AS3 or HTML5 player. Currently, the loop parameter only works in the AS3 player when used in conjunction with the playlist parameter. To loop a single video, set the loop parameter value to 1 and set the playlist parameter value to the same video ID already specified in the Player API URL

At the moment the generated iframe code does not loop on certain devices. On my desktop it loops fine but on a Raspberry Pi 3 it does not loop. If I take the generated iframe code and add the playlist parameter containing the video ID it does loop on the Raspberry Pi 3.

I see I’ll add it soon and let you know so you can test again.

@janjouketjalsma Please download the master branch and confirm this is working as expected. Thanks

In master (fd0e0cd51c870a91dc4d96dc3afd1284eeeecea8) it is now working as expected. Thanks!

You are welcome. Closing this issue now. This change will be released in 4.2.7 in the next 2 weeks


Api caching

Fixes #5763
What's this PR do?
This PR creates a new API caching class, ApiCache within the dosomething_api module that we can use to cache any of the API requests to Phoenix. It creates a unique id for requests based on the set of URL parameters (if any) passed along with the endpoint request and caches it for 24 hours.
There is also a new parameter added that can be included in the request URL (/campaigns.json?cache=false) which indicates that the request should not be cached, and if it was already cached in a prior request, to go ahead and clear the cache. This will help with development purposes.
Where should the reviewer start?
Start at the campaign_resource.inc file and follow the breadcrumbs from there!
How should this be manually tested?
If you feel the desire to pull down a copy of this branch, run drush updb to get the new cache_dosomething_api table set up and then run a couple API queries on the /campaigns.json endpoint and confirm it gets cached in the database.
Any background context you want to provide?
Currently this caching only works for the /campaigns index collection endpoint, but can be expanded to the rest.
One thing I noticed was that the string booleans passed in the URL parameters are not getting properly casted to actual booleans in the resource transformers, because it casts a string... so there's a new helper function dosomething_helpers_convert_string_to_boolean() created to help properly change these string booleans to actual booleans. It will be applied to other URL param items in upcoming PR.
What are the relevant tickets?
#5763

@uy @angaither
cc: @DFurnes

SUCH OO!

VERY OBJECT

WOW

:dog2:

so... cool to merge? lol

Only minor comments. Otherwise, :dog2:

@uy you were right and I hadn't finished cleaning up the comments on the Transformer class. Should be updated now :)

:shiba inu: :shiba inu: :shiba inu:

yaaas :)


ParameterChangeProposal

hi!.
so I am trying to create a proposal (on osmo-test-4), and have struct an issue.
when I try to submit a change
[{"subspace":"staking","key":"UnbondingTime","value":"172800000000000"}]
it responds with
 queryclient.js?0f47:135 Uncaught (in promise) Error: Query failed with (18): failed to execute message; message index: 0: key: UnbondingTime, value:<PHONE_NUMBER>00000, err: invalid character -- Amino:JSON int/int64/uint/uint64 expects quoted values for javascript numeric support, got:<PHONE_NUMBER>00000.: failed to set parameter: invalid proposal content: invalid request
I am creating the field ala
value = ParameterChangeProposal.encode(
ParameterChangeProposal.fromPartial(p)
).finish();
now strangely.. if I add the value to "172800000000000"
the system accepts it,
but results in a weird proposal - https://testnet.mintscan.io/osmosis-testnet/proposals/57040

What exactly do you try to do? Only the Amino JSON representation uses JSON as far as I can tell. But in CosmJS no Amino JSON for this proposal type is implemented:
https://github.com/cosmos/cosmjs/blob/94d6583f3bba83f270a022d273dee5335947bedc/packages/stargate/src/modules/gov/aminomessages.ts#L168-L195

I'm closing this, as it could just be that It is expecting a UInt128 (string), not a number for this parameter.
a successful one looks fine here
TX - https://validator.tools/tx/osmo-test-4/A88F10992E979E1CBF50AC0DCBF58D16D28D2BD7AB3C3E48E07D2975FD75BBE3


Add cdh golang client interface

This client interface streamlines the process of connecting to CDH and leveraging its APIs. The Go version is very useful for integrating the CDH with containerd plugins, including NRI and image verifiers, where CDH operates as an independent module.
Note that this PR includes only the interface for UnsealSecret.
I think other interfaces can be implemented in the following PRs.
Fixes: #556

cc @arronwy @Xynnn007

So this will be used inside of a guest? I associate Go more with k8s on the host. Can you elaborate on the integrations that you mentioned? I am slightly wary of supporting more languages although overall this PR looks fine (with my modest understanding of Go).

Ok. I have successfully integrated CDH with NRI plugin in containerd. This allows us to unseal secrets in NRI plugin using the CDH Go client, rather than having to execute CDH binary to get unsealed values.

So this will be used inside of a guest? I associate Go more with k8s on the host. Can you elaborate on the integrations that you mentioned? I am slightly wary of supporting more languages although overall this PR looks fine (with my modest understanding of Go).

I unseal secret with NRI plugin during CreateContainer stage in k8s.
result:

pod yaml:
apiVersion: v1
kind: Pod
metadata:
  name: registry
spec:
  containers:
    - name: registry
      image: quay.io/chengyu_zhu/registry:latest
      command: [ "/bin/sh", "-c", "env && sleep 3000" ]
      env:
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: secret-sealed
              key: sealed-secret

@fitzthum @mkulke Ok. Let's could move the golang things to a separate repo if needed.
Over all, thanks @ChengyuZhu6 for the work!


Restore build-backend and remove switch to avoid pep517.

Per Paul's comment in #1644, this change restores the build backend and removes the workaround to avoid pep517.
Rather than selecting 40.0, I chose 40.8 based on the error message reported in #1923.

It appears that pip has landed support for backend-path, but it's not released. I'm not sure if tox supports it yet, so I'm not sure if that changes things.
I'm a bit torn here. I think we should probably add backend-path = ["."] to our pyproject.toml file, which is what the spec says we should do to bootstrap our backend. However, that will only work with pip >= 20.0, whereas adding setuptools >= 40.8 will work with all current versions of pip unless --no-binary :all: is specified. If we do both, we'll get the boostrapped backend behavior for recent versions of pip and fall back to the wheel in older versions. This seems like it would be a best-of-both-worlds situation, except that since we're unconditionally requiring setuptools, --no-binary :all: will fail whether or not it is actually used (sorta -  see [1]), so we'd be creating a slightly more varied build experience across versions of pip without solving the problem we were hoping to solve.
In the end, though, I think the most practical approach is still probably to add both the setuptools dependency and the backend-path key. I have still not heard a convincing argument for requiring that the entire stack be "build from source", including the pure-python setuptools wheel, which is just a zip file containing the source, so I'm inclined to let the people who are convinced of that do the extra work to make sure they never even download a wheel of setuptools.
As for why to bother with backend-path at all, the PEP specifies that cycles like this in the dependency graph are explicitly not allowed, so even though I think we need to add a cycle for the sake of practicality, eventually we will want to remove it once support for backend-path is sufficiently widely-adopted, so we might as well start using the bootstrapped backend function opportunistically so that we can suss out possible bugs.
[1] I'll note that just doing pip install --no-binary :all: . doesn't trigger this, you need to do something like PIP_NO_BINARY=":all:" pip install ., since apparently pip arguments don't propagate into the PEP 517 environment.

I have still not heard a convincing argument for requiring that the entire stack be "build from source", including the pure-python setuptools wheel, which is just a zip file containing the source, so I'm inclined to let the people who are convinced of that do the extra work to make sure they never even download a wheel of setuptools.

I've spent hours going back and forth on this issue with platform maintainers (@abadger, @warsaw) and other package systems like Spack (@tgamblin). The issue is that they wish to build artifacts of various packages all from source (distributions or repo), and so they demand a DAG of dependencies (keyword being Acyclic). And because all projects are built by setuptools, setuptools cannot itself have any build dependencies, including setuptools. This need stems from the principal that it should be possible to build an open-source stack entirely from source, which seems a reasonable request. Furthermore, it's a hard requirement that this platform be capable of building the entire stack offline (artifacts must be known and downloaded in advance), to maintain trust and comply with security constraints in highly regulated environments.
My instinct was the same as Paul's, that it should be possible to build even the most foundational tools (setuptools) from pre-built artifacts (wheels, specially-built bootstrapping artifacts, etc).

My instinct was the same as Paul's, that it should be possible to build even the most foundational tools (setuptools) from pre-built artifacts (wheels, specially-built bootstrapping artifacts, etc).

But the only way I see to do that in a system built from pre-downloaded sources would be for that system to include setuptools' build requirements as wheels or for setuptools itself to somehow supply its own build requirements. Presumably setuptools can do this once build-path is honored, by including its build dependencies in the sdist.

adding setuptools >= 40.8 will work with all current versions of pip unless --no-binary :all: is specified

Does this mean this change will break source-only builds for downstream packagers, or will they be unaffected because they're not using pip to build? I suspect this issue is also mitigated/masked by the fact that pyproject.toml isn't included in the sdist (#1644).

Rather than let this issue linger, I want to proceed with this potentially risky change. It may impact downstream packagers, and if it does, I want to be sure this time to capture some strict requirements in the setuptools test suite such that it will guarantee the requirements are met.

Hi @jaraco, I'm a Spack developer along with @tgamblin. Thanks for looping us into the conversation!
I'm still trying to wrap my head around the implications of this PR, so forgive me if I'm jumping to conclusions. At first glance, it looks like this PR is a step in the wrong direction.

I have still not heard a convincing argument for requiring that the entire stack be "build from source"

@pganssle See #980 for prior discussion of this issue. The problem is that there are many package managers out there aside from pip, and Spack is one of them. Spack is a Supercomputing PACKage manager, running on some of the largest supercomputers in the world. These clusters often have esoteric architectures and programming environments, like ARM, PowerPC, BlueGene Q, and Cray. Each of these systems come with various compilers, MPI libraries, and BLAS/LAPACK libraries. The goal of package managers like Spack is to allow users to build multiple different configurations of the same package with different compilers and different CPU microarchitectures. Wheels are a cute idea for the average user on their laptop, but for us, wheels simply don't exist for these architectures. This is one of many reasons why we build from source.
It seems like this PR once again makes setuptools challenging to build from source. For those of us who still need to build from source, I see the following solutions:

First install setuptools <= 42 in order to bootstrap setuptools 43+
Use pip to install setuptools only
Stop updating our setuptools package and only support setuptools <= 42 until a better solution arises

3 is the easiest solution for us, but obviously no one wants that. We don't want to be stuck in history any more than you want people using ancient versions of setuptools. 2 could work for us, although having a package manager (Spack) require a different package manager (pip) to be installed in order to install Python wheels seems like a step in the wrong direction. 1 could also work, and we do similar things for languages like Go, but once again it seems to introduce more complexity than should be necessary.
Are there any other solutions I'm missing? Or something about this change that I'm not understanding?

Wheels are a cute idea for the average user on their laptop, but for us, wheels simply don't exist for these architectures. This is one of many reasons why we build from source.

I think you are missing the point here. I'm not talking about requiring arbitrary wheels, we're saying that for universal python wheels that contain no extension code or architecture-specific information, "building from source" is a largely bureaucratic checkbox, because the wheel file is a zip file containing the source code. Allowing setuptools to bootstrap from a setuptools wheel will present none of the problems you describe.
It is not clear to me why you would require pip to install setuptools. You just need to be able to install universal wheels, which amounts to unzipping them in the right place. You should probably support that anyway, because there are lots of packages that don't have unusual edge cases that have pre-built wheels, and installing from a wheel means you don't have to execute arbitrary code in the build step - in addition to being faster, it's safer.
I think the decision to add a build-backend path was wrong in the first place, and it was motivated by the desire to generalize something that didn't need to be generalized, but it is what it is. The way forward is to support backend-path. I haven't read the spec recently, but I think it would be spec-compliant for you to detect cycles in the PEP 518 requirements graph and either throw an error or try and correct the issue. In this case you could detect that setuptools depends on itself but it specifies a build-backend path, and ignore the setuptools requirement.

I looked through this, and it's not going to cause an issue for Spack, mainly because it's a circular dependency from setuptools to itself.  To get around that, we can use setuptools within the build environment.  setuptools build dependencies  are still vendored, so we don't have to worry about setuptools not working in-tree, as we did in #980.
So, our Spack packages can install straight from git like this:
$ python ./boostrap.py
$ PYTHONPATH="." python -s ./setup.py --no-user-cfg install --single-version-externally-managed --root=/

I verified that this works fine in a Spack environment with python but not setuptools or pip.  The main differences are:

we now have to run bootstrap.py
we have to add PYTHONPATH="."

Neither of those is a big deal. We don't currently use PEP518 (because it's still provisional, right?) -- we have our own package format, so we don't really have to ignore anything.  We can just omit the setuptools dependency from its own package, which is what I think @pganssle is suggesting.
I gotta say, though, that I had to dig more than I really expected to figure this out.  I am probably not as up to date on the latest in Python packaging as I should be, but here are a few suggestions:
Docs
Given that setuptools is probably the lowest level component of the python ecosystem, I think it would be extremely helpful for distro folks if this section of the setuptools docs had some lower-level instructions, not just "use pip -U install setuptools".
Yes, you can install setuptools with pip, but what's the recommended way for other package managers to do it?  pip itself requires setuptools, so you have to dig around to figure out that you should use ensurepip to get it, and that ensurepip just unzips pip and setuptools wheels.
I think the docs should mention the two methods discussed above:

Run python bootstrap.py && PYTHONPATH="." setup.py ...
unzip the setuptools wheel (which requires the wheel)

There should probably be a caveat that these methods are really for people writing build systems or package managers, but it would sure make things more obvious.
build-backend and dependencies
RE @pganssle:

I haven't read the spec recently, but I think it would be spec-compliant for you to detect cycles in the PEP 518 requirements graph and either throw an error or try and correct the issue. In this case you could detect that setuptools depends on itself but it specifies a build-backend path, and ignore the setuptools requirement.

This was helpful.  I went and read the PEP517 spec, though, and it is not clear to me how backend-path is supposed to relate to build dependencies.  It's not clear to me why setuptools needs to define a dependency on itself if it's in its own backend-path.  Is that because pip doesn't support backend-path yet?  IMO, if you can just do PYTHONPATH="." when running setup.py, the project doesn't really have a dependency.
Also, the term build-backend isn't actually clearly defined in PEP517.  The terminology section just says that a "build backend" is whatever does the work for a "build frontend", which it says is some kind of tool.  I had to read through the spec to figure out that it was a python module with some well defined entry points.
Maybe this is stuff for @njsmith or @takluyver to clarify.
Wheels
RE @pganssle:

I'm not talking about requiring arbitrary wheels, I'm saying that for universal python wheels that contain no extension code or architecture-specific information, "building from source" is a largely bureaucratic checkbox, because the wheel file is a zip file containing the source code.

I agree that we could use universal wheels, but this goes against a very old notion in package management of relying on pristine sources.  We really want to build from the source distribution in Spack, and PEP517 seems to support that notion:

A source tree is something like a VCS checkout. We need a standard interface for installing from this format, to support usages like pip install some-directory/.
A source distribution is a static snapshot representing a particular release of some source code, like lxml-3.4.4.tar.gz. Source distributions serve many purposes: they form an archival record of releases, they provide a stupid-simple de facto standard for tools that want to ingest and process large corpora of code, possibly written in many languages (e.g. code search), they act as the input to downstream packaging systems like Debian/Fedora/Conda/..., and so forth. In the Python ecosystem they additionally have a particularly important role to play, because packaging tools like pip are able to use source distributions to fulfill binary dependencies, e.g. if there is a distribution foo.whl which declares a dependency on bar, then we need to support the case where pip install bar or pip install foo automatically locates the sdist for bar, downloads it, builds it, and installs the resulting package.

I would be surprised if the Debian folks would accept a build that build a package straight from a wheel and not from the main repo (only mention I could find was here).  I suspect most distros would be ok with using wheels if one could use tooling to generate the wheels from the source distribution.  This seems to be something that PEP517 wants to support (as it's one of the build-backend endpoints), so that's cool.
But practically speaking, that puts me in the position of relying on the wheel tool for the build, which requires setuptools, and that leads to yet another bootstrapping problem.
Summary
RE @jaraco:

It may impact downstream packagers, and if it does, I want to be sure this time to capture some strict requirements in the setuptools test suite such that it will guarantee the requirements are met.

As I said above, I don't think this change will impact downstream packagers, but that's only because setuptools still vendors its dependencies, and because it does not require a wheel to bootstrap.
As long as setuptools is its own, self-hosted build backend, things are good, but it should not un-vendor the other build dependencies (which themselves require setuptools), or we're back to an un-resolvable cycle and the ecosystem can't be bootstrapped from scratch.  setuptools is unique in this regard, as it's the deepest dependency in the python tree.  If other stuff wants to always build through a wheel, I think that is fine, but setuptools at least needs to be bootstrappable from pristine source if it doesn't want to make things hard for distros.
Documenting this would help.  I also think PEP517 should be clearer about whether self-hosted dependencies really need to be specified when there is a backend-path, but that's a separate issue.

This was helpful. I went and read the PEP517 spec, though, and it is not clear to me how backend-path is supposed to relate to build dependencies. It's not clear to me why setuptools needs to define a dependency on itself if it's in its own backend-path. Why does pip need the backend-path and the dependency? IMO, if you can just do PYTHONPATH="." when running setup.py, the project doesn't really have a dependency.

backend-path is a very obscure thing that is only useful for self-bootstrapping backends. There is basically no reason to write more than one self-bootstrapping backend, though probably at least flit and setuptools will both become self-bootstrapping.
By defining a dependency on setuptools, we're deliberately breaking the spec because no front-ends actually supported build-backend when I made my comment, and there is no other reasonable way to support pip < 20.0 and pip >= 20.0. The only thing it will break is people who want to use pip install --no-binary :all:, which to me is acceptable in the medium-term. The kind of person who does that generally also knows how to patch their setuptools as appropriate.

I would be surprised if the Debian folks would accept a build that build a package straight from a wheel and not from the main repo (only mention I could find was here). I suspect most distros would be ok with using wheels if one could use tooling to generate the wheels from the source distribution. This seems to be something that PEP517 wants to support (as it's one of the build-backend endpoints), so that's cool.

This is not a good reason not to use wheels to bootstrap things, it's just Debian's convention. I don't really care to argue the point, I already lost this battle a while ago, and it is already unnecessary for people to build from wheels. We will eventually come back into compliance with the spec when support for the full spec is widespread enough that it won't break too many things to do so.

I think the docs should mention the two methods discussed above:

Run python bootstrap.py && PYTHONPATH="." setup.py ...
unzip the setuptools wheel (which requires the wheel)

Our documentation is not well-organized and out of date in many ways. There are many things in the wish list.
I would not recommend documenting either of these, since I don't consider either of these to be the right way to produce a setuptools wheel / installation.
Once we are able to ship a pyproject.toml file without it breaking everything (which is what this PR does), the right thing to do is to implement or use a PEP 517 front-end and then invoke a  PEP 517 build to build a wheel, then install that wheel. The only part that is setuptools-specific is that our pyproject.toml is not currently spec-compliant, which means you have to know that if you've implemented backend-path, you can ignore the setuptools dependency. The documentation for the other stuff either does live or should live in packaging.python.org.

Neither of those is a big deal. We don't currently use PEP518 (because it's still provisional, right?) -- we have our own package format, so we don't really have to ignore anything.

This is probably a mistake. PEP 517 and 518 are provisional in the same sense that pandas is still in the 0.x series. By and large they won't change at this point unless some serious show-stopper occurs. I would recommend moving towards the PEP 517/518 world early, because it was explicitly designed for people like you - because for ages Python build behavior was "whatever distutils does" and "whatever pip does", requiring all alternate build systems to be bug-compatible with setuptools and pip. PEP 517 and 518 are a move towards standardizing a model for builds that doesn't assume that setuptools is doing the builds (allowing individual projects to specify their back-ends) or that pip is doing the installation (allowing individual users to specify the front-ends).

There is basically no reason to write more than one self-bootstrapping backend, though probably at least flit and setuptools will both become self-bootstrapping.

This is good.

I already lost this battle a while ago, and it is already unnecessary for people to build from wheels.

👍🏻

We will eventually come back into compliance with the spec when support for the full spec is widespread enough that it won't break too many things to do so.

Ok.

I would not recommend documenting either of these, since I don't consider either of these to be the right way to produce a setuptools wheel / installation.
Once we are able to [...]. The documentation for the other stuff either does live or should live in packaging.python.org.

I don't think that makes a whole lot of sense, since the two ways I mentioned are the only ways that actually work without pip, and setuptools devs are the ones who actually control and guarantee that setuptools can be installed a certain way.  How is that not "setuptools-specific"?.  Yes, PEP517 specifies how things "should" be installed one day when everything is not broken, but it takes two lines to describe how things can work well right now.  I'd be willing to submit a PR, but y'all are in charge.

This is probably a mistake. PEP 517 and 518 are provisional in the same sense that pandas is still in the 0.x series.

I didn't mean to say that we would not be moving towards them.  Yes, they look promising.  At the very least PEP517 can help us, and it would be great to mine dependency specs when things support PEP518.
I do not think it is a "mistake" for us to have our own package format and our own dependency specification, beyond what PEP518 prescribes.  Spack supports many more types of packages than pip is ever going to -- we build with different compilers/build options/optimized architectures/etc.  PEP517 and PEP518 solve some python packaging problems, but there is still a ton of work to be done on the compiled side (which is our focus).

I don't think that makes a whole lot of sense, since the two ways I mentioned are the only ways that actually work without pip, and setuptools devs are the ones who actually control and guarantee that setuptools can be installed a certain way.

This is not true at all. Any PEP 517-compatible front-end can install setuptools using only PEP 517. There's even a library that does it for you, pep517. I am saying that the correct thing to do is to either build a PEP 517 front-end or use a PEP 517 front-end (of which pip is one).

How is that not "setuptools-specific"?. Yes, PEP517 specifies how things "should" be installed one day when everything is not broken, but it takes two lines to describe how things can work well right now. I'd be willing to submit a PR, but y'all are in charge.

PEP 517 specifies how PEP 517-compliant things can be installed. setuptools is a valid PEP 517-backend capable of installing itself. We don't need to wait for anything to be "not broken". If we're documenting anything, we should document that the supported way forward is to install setuptools via PEP 517.

I do not think it is a "mistake" for us to have our own package format and our own dependency specification, beyond what PEP518 prescribes. Spack supports many more types of packages than pip is ever going to -- we build with different compilers/build options/optimized architectures/etc. PEP517 and PEP518 solve some python packaging problems, but there is still a ton of work to be done on the compiled side (which is our focus).

I'm saying it's a mistake to wait for PEP 518 to no longer be provisional before implementing it. It's essentially done now, and you probably want to understand how it fits into your workflow before it stops being provisional, so you still have an opportunity to get it changed (though as time goes on it will become harder to change PEP 518 for backwards-compat reasons).
My overall point is this: for many packages, you already need a PEP 517/518 front-end to install the package correctly. Sometimes it is possible to make ad-hoc modifications to the build system to avoid this, but you'll have a much easier time if you actually make use of the pyproject.toml file, which provides you all the information you need to build a python package.

If we're documenting anything, we should document that the supported way forward is to install setuptools via PEP 517.

This would be extremely helpful.  I did not know this because it is not documented.  I tried looking at packaging.python.org, but the only thing there that seems relevant is:

The accepted style of source distribution format based on pyproject.toml, defined in PEP 518 and adopted by PEP 517 has not been implemented yet.

I will look into reworking our python support to use pep517.  I actually do not think this will be too hard -- we will need to add some logic to our PythonPackage class, but I do not think there is much more to it than that.

you'll have a much easier time if you actually make use of the pyproject.toml file, which provides you all the information you need to build a python package.

At the moment, we do get most of the version information that goes into a package.py from pyproject.toml (assuming the project has one).  @adamjstewart can say more about that, but it would be nice if everything started moving that way and generating constraints for most of our pure python packages.  It would be extremely cool if we grew a front-end to PyPI that understood most packages (though this is likely a long way off).  We would likely still have native spack package.py descriptions of things like numpy, pandas, tensorflow, etc. -- anything with a compiled component.

At the moment, we do get most of the version information that goes into a package.py from pyproject.toml (assuming the project has one). @adamjstewart can say more about that, but it would be nice if everything started moving that way and generating constraints for most of our pure python packages.

I love Python as a language, but its lack of a consistent build system leaves a lot to be desired. I realize that this is one of the reasons setuptools was created. Once upon a time, if I needed to know what modules a Python library depends on, I could check in requirements.txt. Then setuptools came along, and allowed you to programmatically specify dependencies via install_requires in setup.py. Then more recently, I started noticing people using setup.cfg to specify dependencies. I just learned about pyproject.toml recently, and I think it's great as it allows us to see dependencies without actually running the setup.py script, but now we're at the point where I need to manually check 4 different files in order to determine what modules a library depends on.
For comparison, the R language has an incredibly uniform and robust build system, where every package is required to use a DESCRIPTION file listing their dependencies. CRAN (the equivalent of PyPI) automatically tests installation of these packages, and if a dependency is missing, the build fails and the package is not allowed on CRAN. This forces R developers to conform to a single standard if they want to distribute their software.
I think PEP 517/518 look great, but until someone drops backwards compatibility and forces packages to use pyproject.toml, we'll just end up with a 4th competing standard.

@adamjstewart: I do think people are moving in the pyproject.toml direction -- thanks to the efforts of folks like @pganssle and others on this thread.  It'll be awesome once that happens!


unit tests broken since 220788730f87efe2f606be677a6d663eea2dc307

commit 220788730f87efe2f606be677a6d663eea2dc307

the "FAILING" icon on the master branch is related to arroseur being down and a cron job launched 3 days ago. I deactivated cron jobs (since arroseur is frequently down and thus wrongly indicates a broken master branch). So the "unittests broken" only concerns the development branch, of course.


Unit tests proto discovery

Extend unit test coverage through discovery protocol

Codecov Report

Merging #316 into master will increase coverage by 0.16%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #316      +/-   ##
==========================================
+ Coverage   88.69%   88.85%   +0.16%
==========================================
  Files         236      236
  Lines       11084    11084
==========================================
+ Hits         9831     9849      +18
+ Misses       1253     1235      -18

Aw heck, somehow I've mashed ledger content into this imperfect PR. I will resubmit.


Render todo items as checkboxes instead of the radio button look

At the moment, the checklist plugin renders checkboxes looking like radio buttons, as if from a list of items it was possible to pick only one. It would be great if the plugin would follow the standard and use a checkbox visual.

I personally like the look. I modeled it after iOS Reminders which also use the circular toggle aesthetic.  Unless I hear a lot of complaints about the look I'm going to stick with it for now. I may release optional themes in the future that could include that look. If so I'll update this issue.


addresses ： update Go version from 1.18 to 1.20

Please add a meaningful description for your change here
update the go version from 1.18 to 1.20
https://go.dev/dl/

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] I agree that my contributions are licensed with both Apache ASL2 and MIT.
[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the CONTRIBUTING.md guide for more information.

Thanks for the change! I agree that the starter go.mod should simply track the latest go version.


Edit user form update

:tada: This issue has been resolved in version 1.11.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


update requiring pip script is unreliable

After I updated to the latest version, I get this once once i update again. It seems froster requires the 'pip' script. This is unreliable as per python best practices, one should use python3 -m pip instead of pip as pip my belong to another python3 install and not the one in the current path
[peterdir@loginnode2 ~]$ froster update
Backing up older froster installation (if any)...
Data back up at /home/users/peterdir/.local/share/froster_20240604120731.bak
Config back up at /home/users/peterdir/.config/froster_20240604120731.bak
...older froster installation backed up
Uninstalling existing froster installation...
using pip with /usr/bin/python3 ...
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
Please note that packages are installed in /home/users/peterdir/.local/lib/python...
If you share 'HPC Toys' with others use 'htypip install ...' instead.
...froster uninstalled
Error: pipx: exit code 1
Rolling back installation...
...done
Installation failed!
Error: The update failed with exit code 1.

I tried several approaches for updating Froster at running time (i.e., using the "froster update" command), but I faced several issues due to venv collisions with itself.
The final update implementation, which is already available in your repo and PyPi, works as follows:

The same installation script is in charge of updating Froster; therefore, it is updated outside running time.
"froster update" only checks if a new Froster version is published at the PyPi repository.

If an update is available, it prompts the same "curl ... install.sh | bash" script command to update Froster.

If a week has passed since the last update check, "froster update" is automatically executed at the next froster command.

if an update is available, then prompt the update command.
if don't, do not print anything.
In either case, store the current timestamp to support next automatic update check.

rclone is downloaded and installed (i.e. updated) everytime froster is installed or updated.

This is done this way because rclone does not have a cli command to check for updates.

Also, "git" has been removed as installation dependency as the installation script installs the latests PyPi release (not the github's one)
The PyPi release is automatically published once the github release is deployed, BUT the github release has to manually be released. We can discuss why I took this approach next meeting.

Actually this issue is still happening, there is a 'pip uninstall' in the install.sh script. This should be replaced with 'python3 -m pip' as  people who use many different versions of python often have inconsistencies in the path and pip and python don't always belong to the same install. I was hoping pipx does not have the same problem
[peterdir@fff ~]$ curl -s https://raw.githubusercontent.com/dirkpetersen/froster/main/install.sh?$(date +%s) | bash

Backing up older froster installation (if any)...
    Config back up at /home/users/peterdir/.config/froster_20240614101553.bak
...older froster installation backed up

Uninstalling existing froster installation...
 using pip with /usr/bin/python3 ...
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.

 Please note that packages are installed in /home/users/peterdir/.local/lib/python...
 If you share 'HPC Toys' with others use 'htypip install ...' instead.

...froster uninstalled

Installing latest version of froster...
  Installing from PyPi package repository
...froster installed

Installing third-party dependency: pwalk...
    Downloading pwalk files
    Compiling pwalk
    Moving pwalk to froster's binaries folder
    Cleaning up pwalk installation files
...pwalk installed

Installing third-party dependency: rclone...
    Downloading rclone files
    Extracting rclone files
    Moving rclone to froster's binaries folder
    Cleaning up rclone installation files
...rclone installed

froster v0.12.31 has been successfully installed!

The pip install command installed Froster locally for development and Github Actions testing.
When uninstalling older Froster versions, it checks if it was installed under pip or pipx environment.
The message you see is due to the pip installation check, which makes no sense for production.
I updated the local installation method to also use pipx, so no more pip command.
This change is available in the already deployed Froster v0.12.32 release


Add orientation property do PositionComponent

What could be improved
New property double orientation; will keep track of where the component is "looking at": is it naturally pointing up, or down, or left, or right? It's easier (and more flexible) to have this as a double and not enum.
Maybe there is a better name for it too.
Why should this be improved
The PositionComponent currently consists of size, anchor, and transform (where transform has position, rotation, and scale). What it's missing is the notion of a natural direction.
Use cases:

allow PositionComponent.angleTo() method which computes the angle between this component's natural direction and another given component;
allow RotateEffect.towards() which can rotate the component so that it would "look at" another component.

Any risks?
No.

Sounds like a very good addition!
The orientation needs to be defined from some point too right, would this be up or right defined, like where is 0?
Since this wouldn't be a breaking change it could be done post v1.

Isn't that the same as angle?

angle measures rotation from the original position. This property tells you what the original orientation is (relative to the screen).

I wonder what we could name this, I feel that orientation might be a bit confusing.
Maybe one of these (not completely convinced by any of them though so please add more suggestions if you have any):

initialAngle
initialOrientation
startAngle
...

As this new property is just going to offset the actual angle, calling it angularOffset would be appropriate. Words like initial and start make it seem like it gets applied only at the beginning and not throughout the lifetime of the component.

nativeAngle
intrinsicAngle

I think it's best to stick to the naming pattern "*Angle", to make it clear that this property is a kind of angle and not anything else.

nativeAngle is the best one so far I think.


[iOS only] get the list of output devices in iOS only return speaker and not the earpiece also

I'm making an app with IP calls, so I'm using the method 'Hardware.instance.enumerateDevices()' to get all the input/output devices of the phone, then I filter the result with 'outputDevices = devices.where((devices) => devices.kind == 'audiooutput') .toList();' to only get the output devices, but in iOS this methods only return me the speaker and not the earpiece also.
I'm implementing in this way like the example inside the library. If someone can help me I really appreciate it.
Thank you so much.

Due to the particularity of iOS audio management, the speaker and earpiece can only be displayed when publish and subscription are enabled at the same time. This is because the iOS audio route allows the selection of audio route when WebRTC native starts AudioUnit.

How can I enable those parameters?


Cannot find article data in papers-PubMed.jsonl

It is great to see you have done an open-source Medical LLM with SOTA performance. When I ran "python load.py --dataset papers --key_path keys.json". It outputs papers-PubMed.jsonl. But I cannot find any paper in this dataset. Only some basic info of each article. Anyone knows what's wrong?
Thank you!

Are articles of papers-PubMed.jsonl  in s2orc_*.jsonl file?
Thank you!

Hi, thanks for your interest!
Running the first step of the Pubmed pipeline should download three separate datasets from the Semantic Scholar API then merge them together.
The three datasets should be downloaded:

pubmed contains article metadata
s2orc contains full-text articles
abstracts contains abstracts for these articles

They are then merged into two separate files:

Abstracts with metadata are stored in /data/abstracts-PubMed_metadata.jsonl
Full-text articles with metadata are stored in /data/s2orc-PubMed_metadata.jsonl

Did you run the pipeline with download.sh and can you locate these files?

Thanks! I ran download.sh and found these. It is a great repo as you also provided the way of getting source training data.


Fix no longer implicitly refresh the cached TBSCertificate for 3.0+

…call was successful"
This reverts commit 9249a34b076df9a9d55ab74ab465d336980cae6a. Fixes #19388

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

It would be nice if we had some tests covering the expected behaviour so that it doesn't regress again, and maybe some comments to explain the variable.

Thanks @slontis for the test, and I added comments about modified variable. Please let me know if there are any content or grammatical errors.

ping for second review.

This pull request is ready to merge

Looks like this wasn't closed. I believe this has now been merged to master and 3.0. Thank you.


[azservicebus] Memory leak when receiving messages

Bug Report

Package in question azure-sdk-for-go/sdk/messaging/azservicebus
SDK version v1.6.0
go version 1.21

What happened?
This is a continuation of https://github.com/Azure/azure-sdk-for-go/issues/22157.  Trying to move out of https://github.com/Azure/azure-service-bus-go. Same usage of azservicebus but this time with higher load in production setup.
We are noticing a memory leak as you can see on the screenshots below.

Service running for a bit more than a day, we can see there is a an increase of memory happening periodically.  Looking at profiling data looks like the culprit is (*Session).mux

Our Service Bus instance was affected with a huge increase of memory consumption jumping from a steady 17%  up to 86% and would kept raising if we hadn't rolled back.

even though there was a noticeable improvement in reducing number of active connections

What did you expect or want to happen?
I would expect the new SDK to have a different memory footprint (either higher or lower memory consumption) but after some time i was expecting the memory usage of the service to be stable as before and not increasing time over time.
Also it was not expected that the Service Bus instance will be affected.
How can we reproduce it?
Not sure how easy it is to be reproduced as we needed production load to notice this. But outlining the setup here so it might make troubleshooting easier.

We have a fixed number of producer goroutines that are receiving messages and a number of consumer goroutines that process messages and communicate via a go channel. At the start of the service we create a pool of receivers client.NewReceiverForQueue for receiving messages in parallel.
A message will never be received and settled by the same receiver (this was causing the issues before)
Senders/receivers are long lived
Typical message size is ~3Kib and max message can be up to 256Kib.

Anything we should know about your environment.

Per discussion with @richardpark-msft we need to apply a similar, cross-receiver settlement fix, like we did in go-amqp.

@gkampitakis, got the PR out for this. Once it's merged will you be able to try it out before we tag it?

@richardpark-msft I can probably try testing on staging but not on production 🫤

@richardpark-msft Hey sorry for the delay. We have been running this commit on staging for a week now and
a. the memory footprint looks much better than before
b. we don't see any indications of memory leaks 🎉

Awesome! Thank you for testing that, and thanks for coming along on this journey :)
Closing this issue now, and the official package will ship next week, provided no other roadblocks pop up.


Fun with sockets, part 2

This is an extension of #1, which I initially assumed was caused by the socket quietly  dying. After adding measures to revive the socket if it's closed, it's now clear that the problem is that it quietly dies on Stack's side, while still being kept alive. Effectively, the socket becomes a zombie socket.
 It's probably a good idea adding a way to detect if messages still appear.
During periods of inactivity, the socket still ends empty messages with no content, so checking if there have been any socket messages in the past X minutes, and restarting otherwise should do the trick.

This was fixed in 1dc32a8a4efef6a077d26b25af3e4bc92727f501.
TL;DR: the socket quietly dies on Stack's side, and fails to disconnect or otherwise alert the socket. The client therefore has to make sure messages are received, and restart if those don't appear.
Empty messages (or occasionally one with some garbage parameters) are sent every 30 seconds, so a 5 minute wait is excessive, but ensures there isn't a misfire.
The patch has been verified to work for this particular type of socket death. One of the interesting artefacts with whatever this bug is, is that all sockets drop out at once. This also spreads across chat servers. No clue why, but the patch works and that's good enough for me


MetroUI with Blazor

Hi, have you experimented with MetroUI on Blazor (more precisely, server side Blazor)?
Because of Blazor specific JavaScript processing I see a lot of side effects - eg. sidebar toggler and sidebar close button won't work as expected. Clicking on sidebar close button I see the following message: "Element not contain role sidebar! Please add attribute data-role="sidebar" to element #sb1", although I checked twice that HTML markup does contain div with such a data-role attribute.

What is the Metro 4 version you use?

The latest one. And I've managed to resolve that issue by moving sidebar close button click event handler to a standalone .js file as follows:
$(document).ready(function () {
$(document).on("click", "#sb1-close", function () {
Metro.sidebar.close('#sb1');
return false;
});
});


Some questions about mmoe implementation

https://github.com/drawbridge/keras-mmoe/blob/09bb267cb4f38d624286bf7b68961b3610f0c082/census_income_demo.py#L177
Hi, thx for your code, and i wanna confirm some questions,
both the mmoe and tower layers are single-layer?
and the size of mmoe hidden layer is 4 , the size of tower layer is 2 ?

Hi @Nicholasyc ! Both MMoE and tower layer s are single layers in this example. There are 8 experts and 4 hidden units per expert and the number of task here is basically defining how many gate kernels I need to use to weight all of the experts. Of course, the tower layers are just standard Dense layers in Keras and you can modify it pretty easily.

Thx @alvin319 , and i found you use K.tf.tensordot in experts_output while K.dot in gate_output, i wonder if they do the same thing？
https://github.com/drawbridge/keras-mmoe/blob/09bb267cb4f38d624286bf7b68961b3610f0c082/mmoe.py#L180

Here are the documentations of these two functions.
https://www.tensorflow.org/api_docs/python/tf/tensordot
https://github.com/keras-team/keras/blob/master/keras/backend/tensorflow_backend.py#L1306
Tensordot allows performing dot product along specific axes which is what I need for the expert kernel.

Got that, infact, tensordot equals to matmul when axes=1 (in your code) which is the same as K.dot

hi, have you ever encounter this error when compute the auc:
ValueError: Input contains NaN, infinity or a value too large for dtype('float32')
i found that the prediction from sigmoid function contains nan value ...

What is num_task here.


Application crash (EXC_BAD_ACCESS, code=2) when panScrollable view has top inset.

Description
Hi.
When i using PanModal, i faced strange issue that application crash with "EXC_BAD_ACCESS(code=2)".
I guess cause is that current PanModal logic doesn't handle - offset by contnetInsets.top.
If panScrollable has contentInsets.top, haltScrolling set 0 even if scroll view can has - offset.
It occur infinity loop of scrollObserver's block.

What type of issue is this? (place an x in one of the [ ])

[x] bug
[ ] enhancement (feature request)
[ ] question
[ ] documentation related
[ ] testing related
[ ] discussion

Requirements (place an x in each of the [ ])

[x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've searched for any related issues and avoided creating a duplicate issue.

Bug Report
Filling out the following details about bugs will help us solve your issue sooner.
Reproducible in:
PanModal version: 1.2.7
iOS version: 15.0
Steps to reproduce:

Set panScrollable view's contentInsets.top over 0.
Set scroll view content less than PanModalHeight.maxHeight. 👈 I don't understand this step. maybe to make allowsExtendedPanScrolling option could be false.
Update pan modal height in runtime.

Expected result:
Pan modal settings should be updated correctly.
Actual result:
Infinity loop occurred and crash with BAD_ACCESS.
Attachments:
https://user-images.githubusercontent.com/11141077/136014466-a2162557-a950-4cfa-9e6d-d22d45c853e2.mov
Logs, screenshots, screencast, sample project, funny gif, etc.

I modified some codes that using contentOffset.y and 0 to handle contentInsets.top.
It seems to be alright. but i don't ensure this approach is fine.

hi，Any progress about this bug?


iOS 10.2 Safari 10 fails on Array.prototype.iterator with is not a function

As a means of re-opening #1019:
This is still an issue. To reproduce:
<script src="https://cdn.polyfill.io/v2/polyfill.min.js?features=default,Symbol,Symbol.iterator,Array.prototype.@@iterator"></script>
<script>
const a = [1,2,3]
const it = a[Symbol.iterator]()
let x
while((x = it.next(), !x.done)) {
  document.write("<div>" + x.value + "</div>")
}
</script>

From the features you have requested, ios safari 10.2 only gets served the URL polyfill. Should we be serving other polyfills to it from your list?
https://cdn.polyfill.io/v2/polyfill.js?features=default,Symbol,Symbol.iterator,Array.prototype.@@iterator&ua=ios_saf/10.2
/* Polyfill service v3.17.0
 * For detailed credits and licence information see https://github.com/financial-times/polyfill-service.
 *
 * UA detected: ios_saf/10.2.0
 * Features requested: Array.prototype.@@iterator,Symbol,Symbol.iterator,default
 *
 * - URL, License: CC0 (required by "default") */

@jonashaag Our Array.protype.@@iterator tests are passing in iOS 10.2 with no polyfill.  I also copied your repo code into a JSBin:
http://jsbin.com/binuzotehe/
This runs without error in desktop and iOS safari 10.  Feel free to reopen if you can provide a JSBin with a reproducible test case.


Set dark/light mode based on user/browser preferences

you can see an implementation of this here https://github.com/DenverCoder1/github-readme-streak-stats/pull/91/files

Ok , thanks but I think other frontend developers would work on this cause I'm yet to know Javascript.

you can see an implementation of this here https://github.com/DenverCoder1/github-readme-streak-stats/pull/91/files

Okay, thanks @schmelto I'll be working on it

So can I close the issue?

I would also add a listener on how the preference is set in the browser

I would also add a listener on how the preference is set in the browser
window.matchMedia("(prefers-color-scheme: dark)").matches == true

okay, I'll do that soon

@namangupta1399 @jomefavourite @Evavic44 please review this

Update done by @ManuSquall . Closing the issue

Ok thanks guys


Todoist.com integration has stopped working

The Toggl button doesn't appear next to Todoist tasks since Todoist's version 1006 (updated 2020/06/08)
Environment details

Operation system: Windows 10
Extension version: 1.60.13

Expected behavior
There should be a Toggl button next to each task.
Actual behavior
No Toggle button shown
Steps to reproduce the behavior

Turn on todoist.com integration for Toggl Button.
Go to https://todoist.com/app/ (while signed in).
Hover over any task.
Observe that the is no Toggl button.

Additional details
Similar to #1723 but not duplicate, this is a different update

Hi @mclois we recently merged and released a fix for the Todoist integration
(https://github.com/toggl/toggl-button/pull/1748)
It's deployed in version 1.62.1, which we rolled out earlier today.
Could you check it after you receive the update and let us know if the problem still persists?

Hey @mclois a fix was merged in #1748.
Could you please close your browser and restart? This should grab the updated version of the extension and allow you to use it on Todoist again. :)

I have just update the extension and the Toggl button is back. Thanks!


Add a github action to run the ginkgo tests on each PR

Depends on #50

@garethjevans would you mind merging this in so I can open A pr with my changes ?

@ctlong would you mind merging this for @garethjevans ?
Ive got another PR for ginkgo v2 (and slight improvements) I'd like to create but I based it off @garethjevans fork.

@KevinJCross I would not advise basing your PR off of this branch. The go mod changes here were superseded by https://github.com/cloudfoundry/cf-test-helpers/pull/54, which I imagine is what you care about.

Closing for lack of activity


compass icon fires onPress - android

Is this a bug report?
Yes
Environment

Environment:
OS: Windows 10
Node: 8.1.2
Yarn: 0.27.5
npm: 5.3.0
Watchman: Not Found
Xcode: N/A
Android Studio: Version  <IP_ADDRESS> AI-171.4443003
Packages: (wanted => installed)
react: 16.0.0 => 16.0.0
react-native: 0.51.0 => 0.51.0
Target Platform: Android (7.1.1)

Report

by changing map direction with two fingers, compass icon appears top-left to reset map direction to North.
When i press the compass icon, it fires onPress event of an external TouchableOpacity that has nothing related

Exact same issue here, touching the compass fires a navigation event, which quits the current screen

Same as @numez. Touching compass fires onPress of a TouchableOpacity that is outsite MapView. It happens even if compass is not showing (map facing north). It doesn't happen with showCompass={false}.
"react": "16.5.1",
"react-native": "0.57.1",
"react-native-maps": "0.21.0",

Is this still an issue?

This has been open for a long time with no update.  Any attempt to fix it coming?

@rborn Can you push this into a priority? Open for almost a year and no feedback. Broken feature.

@richardbumm I don't set priorities, I don't even publish to npm, I just help with sorting issues 😞
This is a community repo and issues are solved when somebody from it fixes something and participate back.


/config: Added Copy to clipboard button for /config

Allows easy copying of /config to clipboard via button click because drag-selecting is boring.
/cc @juliusv

Would you be able to resolve the conflicts? It seems like a useful addition to me.

@simonpasquier done

👍 thanks!


powerai - which package messes up mpicxx and how to fix it?

I frequently get this issue either due to spectrum-mpi or gcc conda package "leftovers" in powerai environment. When uninstalling these packages some mpi commands still point to the conda environment. How do I fix this or at least troubleshoot? Why MPI variables are modified?
For example:
module load gcc ompi
conda activate powerai.1.6.1
mpicxx -show
Cannot open configuration file /users/da/powerai/powerai.1.6.1/share/openmpi/mpicxx-wrapper-data.txt
Error parsing data file mpicxx: Not found

The MPI packages included in PowerAI / WML CE provide activation / deactivation scripts that (intend to) set MPI_ROOT and OPAL_PREFIX when the conda environment is activated, and to restore those variables to their original values when the environment is deactivated.
Unfortunately, that's less straightforward than it sounds due to various edge cases (nesting of activations, unbalanced activate/deactivate calls when packages are installed, and others). We're looking at that code now to see if we can improve the behavior.
In the short-term, though, it's those 2 MPI_ROOT and OPAL_PREFIX variables that you'll want to watch across activate / deactivate / install / uninstall.

@hartb how about resetting $PATH and $LD_LIBRARY_PATH?
IMO, conda remove spectrum-mpi should unset all environment variables for MPI.

I don't see anything in WML CE that adjusts $PATH, though conda itself adjusts it during activate / deactivate.
There are a couple of WML CE packages that adjust $LD_LIBRARY_PATH: cudatoolkit and tensorflow. Those aren't setting things up for MPI, but are touching the library path. (Incidentally, you can find all the scripts that run during activate / deactivate in $CONDA_PREFIX/etc/conda/{de}activate.d/.)
We agree that removing a package (or just deactivating the environment the package was installed in ) should undo any environment changes the package had made.


SwiftUI support

Is there any support for SwiftUI?

For now not plan to do it. But if you ready - you can create PR


Linux fixes

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/consume-packages/Configuring-NuGet-Behavior.md
:white_check_mark:Succeeded

docs/includes/install-cli.md
:white_check_mark:Succeeded

docs/install-nuget-client-tools.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

@kraigb - Does the CI build stage these PRs for review somewhere?  Like in the other repos?

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/consume-packages/Configuring-NuGet-Behavior.md
:white_check_mark:Succeeded

docs/includes/install-cli.md
:white_check_mark:Succeeded

docs/install-nuget-client-tools.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

@CamSoper You can use review.docs.microsoft.com/nuget/...?branch=helping-out.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/consume-packages/Configuring-NuGet-Behavior.md
:white_check_mark:Succeeded

docs/includes/install-cli.md
:white_check_mark:Succeeded

docs/install-nuget-client-tools.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Set up CI with Azure Pipelines [skip ci]

Very much WIP. I have no idea what I'm doing.

[command]"C:\Program Files\Git\bin\bash.exe" --noprofile --norc /d/a/_temp/d466a021-323d-4622-b377-6f20d771d97d.sh
golangci/golangci-lint crit uname_os_check 'MINGW64_NT-10.0' got converted to 'mingw64_nt-10.0' which is not a GOOS value. Please file bug at https://github.com/client9/shlib
/d/a/_temp/d466a021-323d-4622-b377-6f20d771d97d.sh: line 2: golangci-lint: command not found
##[error]Bash exited with code '127'.

Looks related to https://github.com/client9/shlib/issues/13

(we were just discussing Azure Pipelines yesterday to investigate if it would be something for https://github.com/moby/moby, and noticed your work here 👍 😄)

Honestly, Matt, the series of your commit messages here is a bit of comic relief 🤣 though I completely understand how frustrating it could be

:flushed: Ya'll are watching this? I'm embarrassed.
@thaJeztah Yep, that was a bummer of an issue, so I'm just using "go get" for now. Opened a separate issue here since I don't see why it can't just be fixed in the golangci-lint repo: https://github.com/golangci/golangci-lint/issues/472
Even though it has taken all afternoon, I'm... quite pleased with Azure Pipelines! Documentation is decent, but in general I still have no idea what I'm doing. :roll_eyes:
Think I got it working. Am gonna merge and rip out AppVeyor and Travis. Azure Pipelines gives us tests on all 3 platforms, and it's super fast in comparison to what I'm used to.
Might still want to add GitLab CI as a redundant CI system, but doesn't need to happen right now.

I think running golangci-lint should be in a separate step than running the tests. Currently, if the lint fails but tests pass, then the entire step is marked as having passed. That is unless the golangci-lint is complementary and its failures are tolerated. What do you think?

@Mohammed90 I tried that, but with how flaky golangci-lint is right now, I think I want it to be optional until the install is rock-solid.
Gonna merge this now, but PRs welcome to make improvements!

Can I create an issue to serve as a reminder to fix all the issues reported by golangci-lint? It should be good and easy for good first issue for newcomers.

😳 Ya'll are watching this? I'm embarrassed.

haha, no worries! I think most developers can relate 👍

@Mohammed90 Yes, that would be great! I could tweet it then.

@mholt done at #2541

CodeShip has Go 1.12 preinstalled - Open source projects will always be free.
https://documentation.codeship.com/basic/languages-frameworks/go/

100 BUILDS/MONTH

@tullo I believe that's too low!

It might be enough if the PR-only trigger is used. OTOH I have not monitored the caddy project enough to know the actual build needs
@elcore

@mholt Azure Pipelines gives us tests on all 3 platforms and a rich test reporting interface too. Suggest you publish the test results either using the Go task https://docs.microsoft.com/en-us/azure/devops/pipelines/languages/go?view=azure-devops#test or Publish test results @ https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/test/publish-test-results?view=azure-devops&tabs=yaml


[TEST CASE] Incorrect WHERE clause s generated for child-objects in an inheritance hierarchy that share a field of the same name

Summary
Incorrect WHERE clause is generated for child-objects in an inheritance hierarchy that share a field of the same name
Included is a test case which demonstrates this bug.
Detail
I encountered this bug when trying to workaround #2055.
Given a this entity hierarchy:

Customer - base type

using @Inheritance(strategy = InheritanceType.JOINED)

CRMCustomer & BillingCustomer - implementations of Customer
CustomerMatch - Represents a possible "match" between two Customer entities (of any specific type!)

Note: The two customer implementations each have 2 fields, one of which happens to be named the same, that is the field name.
Goal: The goal is to query for CustomerMatch entities where the firstSource.name contains a string.
        String firstName = "acme";
        JPQLQuery<CustomerMatch> searchQuery = this.getQuerydsl().createQuery()
                .select(qCustomerMatch)
                .from(qCustomerMatch);

        BooleanBuilder bb = new BooleanBuilder();

        QCustomer firstSource = qCustomerMatch.firstCustomer;

        // ONE - Query crmcustomer
        QCRMCustomer crm = new QCRMCustomer("crm");
        searchQuery.leftJoin(firstSource, crm._super);
        bb.or(crm.name.containsIgnoreCase(firstName));

        // TWO - Query billing_customer
        QBillingCustomer billing = new QBillingCustomer("billing");
        searchQuery.leftJoin(firstSource, billing._super);
        bb.or(billing.name.containsIgnoreCase(firstName));

        searchQuery.where(bb);
        searchQuery.fetchResults();

Doing a log.info(searchQuery.toString()); outputs the JQPL:
select customerMatch
from CustomerMatch customerMatch
  left join treat(customerMatch.firstCustomer as CRMCustomer) as crm
  left join treat(customerMatch.firstCustomer as BillingCustomer) as billing
where lower(crm.name) like ?1 escape '!' or lower(billing.name) like ?1 escape '!'

 ESCAPE '!' OR lower(‡‡‡customer2_1_.name) LIKE ? ESCAPE '!'

The problem:
Notice the †††  and ‡‡‡ in the sql above. Both of those aliases refer to the billing_customer table, which is totally wrong. Only the second (‡) should refer to billing_customer.
Even more wrong, is if we leave out the // TWO - Query billing_customer part of the query from above, then we get the JPQL
select customerMatch
from CustomerMatch customerMatch
  left join treat(customerMatch.firstCustomer as CRMCustomer) as crm
where lower(crm.name) like ?1 escape '!'

 ESCAPE '!'

The where clause is once again using the alias for billing_customer, which was joined despite there being no mention of BillingCustomer in the Java or JPQL. And the joined crmcustomer alias (§) sits unused.
Now for the big finale: This behavior only occurs when I query on the name field, a field which both Customer implementations happen to share. If I query instead for a field that is unique to CRMCustomer, that is account_manager, the query works as expected.
            bb.or(crm.accountManager.containsIgnoreCase("sales"));

select customerMatch
from CustomerMatch customerMatch
  left join treat(customerMatch.firstCustomer as CRMCustomer) as crm
where lower(crm.accountManager) like ?1 escape '!'

 ESCAPE '!'

This works as expected. There is still an unexpected join on billing_customer (††), but this time the WHERE clause references the correct crmcustomer alias (§).
TESTED with Environment:

querydsl 4.1.4
spring-boot 1.4.2
hibernate 5.0.11  AND 5.1
database drivers:

postgresql
mysql
h2

Testcase
Here is a minimal spring-boot + QueryDSL application that demonstrates this bug.
There are two test cases  that follow the same situation outlined above:

querying CustomerMatch.firstCustomer.name
querying CustomerMatch.firstCustomer.accountManager

The interesting code is in:

querydslbug.TestcaseApplicationTests
querydslbug.repository.CustomerMatchRepositoryImpl

@timowest Any thoughts on this? It's been over a month since the report, understandably the holidays were there, so I figure there's a big backlog. But any idea what is going on here?
Is the explanation unclear? Or are you having trouble running the test case?

The produced JPQL seems to be correct. This is where the responsibility of QueryDSL ends. From there it is up to the JPA provider to produce the correct SQL. So this seems to be a bug in Hibernate instead.
There are several open issues in Hibernate regarding TREAT support:

https://hibernate.atlassian.net/browse/HHH-10561
https://hibernate.atlassian.net/browse/HHH-10759
https://hibernate.atlassian.net/browse/HHH-10767
https://hibernate.atlassian.net/browse/HHH-10768
https://hibernate.atlassian.net/browse/HHH-11062

A quite extensive list of JPA providers and their support for various use cases of the treat operator can be found at https://github.com/beikov/jpa-treat-variations

I no longer work with QueryDSL nor Hibernate, so I've no reason to followup with this issue.
Feel free to leave open or close this issue as you would like.


[FLINK-13724][docs] remove unnecessary whitespace from the generated pages

What is the purpose of the change
Code like the following in the side navigation before this PR creates quite some unnecessary whitespace as each line will have only the code removed:
    {% if parent_id %}
    {% assign parent_id = current[0].nav-parent_id %}
    {% else %}
    {% break %}
    {% endif %}

Starting command tags with {%- will drop all whitespace to the left and ending with -%} will drop all whitespace to the right (including newlines!).
Next PR in this series: #9441
Brief change log
Building on top of #9439, this PR adds:

use {%- and -%} as appropriate in basic includes and layouts which will be included into all/most pages

Verifying this change
This change is a trivial rework which I verified in the generated HTML pages.

Looks good, merging this...


Edit offset types so number instead of booleans

Type errors for boolean when using in our React/typescript/nextjs project, as the offset value is a number, changing the type to number fixes the type error so that project is now compiling normally and pass tests.

:+1:


Command not found after installing

After the install through the cmd, I got :
sudo : box: command not found
Also, if I try to go to the link given after the install in the prompt I got a Forbidden Access page, through my own ubuntu appboxes.co URL.

Looks like it didn't install properly.
Can you try again?