[Help Needed] [sdformat13] new port

Add sdformat13 port:

[x] Changes comply with the maintainer guide
[x] The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
[x] Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx
[x] The versioning scheme in vcpkg.json matches what upstream says.
[x] The license declaration in vcpkg.json matches what upstream says.
[x] The installed as the "copyright" file matches what upstream says.
[x] The source code of the component installed comes from an authoritative source.
[x] The generated "usage text" is accurate. See adding-usage for context.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is in the new port's versions file.
[x] Only one version is added to each modified port's versions file.

I got this error:
CMake Error: install(EXPORT "sdformat13" ...) includes target "sdformat13" which requires target "using_parser_urdf" that is not in any export set.
CMake Error in src/CMakeLists.txt:
  export called with target "sdformat13" which requires target
  "using_parser_urdf" that is not in any export set.

logs:
sdformat13.zip

Note: I will be converting your PR to draft status. If you fixed the issue with CI, please reactivate it.

@Adela0814 Can you explain why this error is happening? Is it come from vcpkg?
I try to look on it on the internet, and I didn't any export on the sdformat repo cod side.
vcpkg make export?

@autoantwort @dg0yt @@traversaro
Can you help?

Grep for using_parser_urdf in the source code and see if it either can be added to the export set or recconstructed in the installed config file?

I think it is a bug upstream in vcpkg in the case BUILD_SHARED_LIBS is set to OFF. In https://github.com/gazebosim/sdformat/blob/38f6435e095b5d82984aa26bbeac40ce08e34229/src/CMakeLists.txt#L118 the sdformat13 links as PRIVATE the using_parser_urdf INTERFACE target. As long as  BUILD_SHARED_LIBS is set to ON, everything works fine as private linked libraries do not need to be found when find_package(sdformat13) is called, but if BUILD_SHARED_LIBS is set to OFF, then using_parser_urdf needs to be found when find_package(sdformat13) is called, and hence it should be installed. I guess the error went unnoticed upstream as there are not  a lot of users for the case when BUILD_SHARED_LIBS is set to OFF.

Grep for using_parser_urdf in the source code and see if it either can be added to the export set or recconstructed in the installed config file?

It added on the cmake:
https://github.com/gazebosim/sdformat/blob/sdformat13_13.0.0/src/CMakeLists.txt#L26

I think it is a bug upstream in vcpkg in the case BUILD_SHARED_LIBS is set to OFF

It by design. Can we compile it only with static?

I think it is a bug upstream in vcpkg in the case BUILD_SHARED_LIBS is set to OFF

To be clear, AFAIU it is a bug in upstream which becomes visible in vcpkg's static triplets.

It by design. Can we compile it only with static? Can we patch it, or make gazebo upstream changes?

I don't see how this is "by design". It should be fixed upstream, and the same patch can be applied in the vcpkg port for the current release.

I think it is a bug upstream in vcpkg in the case BUILD_SHARED_LIBS is set to OFF

To be clear, AFAIU it is a bug in upstream which becomes visible in vcpkg's static triplets.

It by design. Can we compile it only with static? Can we patch it, or make gazebo upstream changes?

I don't see how this is "by design". It should be fixed upstream, and the same patch can be applied in the vcpkg port for the current release.

I meant it by design that vcpkg turn off the shared libs in Linux compilation.

I don't see how this is "by design". It should be fixed upstream, and the same patch can be applied in the vcpkg port for the current release.

I meant it by design that vcpkg turn off the shared libs in Linux compilation.

Oh, I don't think this is by design, but just the historic choice of the "supported triplet" x64-linux. There is also a x64-linux-dynamic "community triplet".

@traversaro But it also fail on windows that have shared libs on. Why?

Make Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:73 (message):
  -- BUILD ERRORS: These must be resolved before compiling.
Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)

CMake Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:75 (message):
  -- 	Couldn't find the urdfdom >= 1.0 system installation
Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)

CMake Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:77 (message):
  -- END BUILD ERRORS

Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)

CMake Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:82 (message):
  Errors encountered in build.  Please see BUILD ERRORS above.
Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)

The new gz port are still not mature.
Make Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:73 (message):
  -- BUILD ERRORS: These must be resolved before compiling.
Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)

CMake Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:75 (message):
  -- 	Couldn't find the urdfdom >= 1.0 system installation
Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)

CMake Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:77 (message):
  -- END BUILD ERRORS

Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)

CMake Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:82 (message):
  Errors encountered in build.  Please see BUILD ERRORS above.
Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)

@dg0yt Can you fix it?

I guess for Windows, urdfdom needs https://github.com/ros/urdfdom/pull/169.

I guess for Windows, urdfdom needs ros/urdfdom#169.

ok. I will appreciate your fix.

-- Configuring done
CMake Error: install(EXPORT "sdformat13" ...) includes target "sdformat13" which requires target "using_parser_urdf" that is not in any export set.
CMake Error in src/CMakeLists.txt:
 export called with target "sdformat13" which requires target
 "using_parser_urdf" that is not in any export set.

The remaining build error is a bug in the project's files and unrelated to windows.
The build system uses custom (gz) functions instead of pure CMake.
Look/ask upstream.

The error is the one described in https://github.com/microsoft/vcpkg/pull/31280#issuecomment-1537483083 , nothing related to the use of gz_ CMake function.

The error is the one described in #31280 (comment) , nothing related to the use of gz_ CMake function.

Please create a PR in upstream, and I will make a patch from it.

The error is the one described in #31280 (comment) , nothing related to the use of gz_ CMake function.

using_parser_urdf is an interface target created in sdformat13 src/CMakeLists.txt, and linked to the main library target. This is the standard CMake stuff.
However, the export of CMake config is hidden in gz functions. This export would need to handle the interface target as well.

The error is the one described in #31280 (comment) , nothing related to the use of gz_ CMake function.

using_parser_urdf is an interface target created in sdformat13 src/CMakeLists.txt, and linked to the main library target. This is the standard CMake stuff. However, the export of CMake config is hidden in gz functions. This export would need to handle the interface target as well.

Do you know how to solve it?
Can we make a patch for it?

Do you know how to solve it?

That's the point I'm trying to make: I know how to use CMake. But once projects start to use their own language of macros and functions, it becomes tedious to find out where it breaks and how to fix it. We don't even have a CMake call stack to start from because the error shows too late.

The error is the one described in #31280 (comment) , nothing related to the use of gz_ CMake function.

using_parser_urdf is an interface target created in sdformat13 src/CMakeLists.txt, and linked to the main library target. This is the standard CMake stuff. However, the export of CMake config is hidden in gz functions. This export would need to handle the interface target as well.

Ahh, sorry I misunderstdood, that's totally correct.

@traversaro
Please create a PR in upstream, and I will make a patch from it.

I am happy to give you the hints to understand how to fix it. To be honest I am not interest at the moment in building sdformat13 as part of vcpkg and in static mode, so I prefer not to prepare the PR and submit it.
The sdformat13 library is created in https://github.com/gazebosim/gz-cmake/blob/gz-cmake3_3.1.0/cmake/GzUtils.cmake#L1540 and installed in https://github.com/gazebosim/gz-cmake/blob/gz-cmake3_3.1.0/cmake/GzUtils.cmake#L1611 , so the EXPORT used for it is sdformat13 . The target installed with that export are installed in https://github.com/gazebosim/gz-cmake/blob/88e7dc5f727e2270f206f19f558ab8f7fb5b8df1/cmake/GzPackaging.cmake#L372 . So a simple workaround is to just install the using_parser_urdf with the sdformat13 export, close to where using_parser_urdf library is defined with add_library.

Okay, I managed to add the install line. I will send a PR for this port to @talregev, adding a few more changes.

@traversaro Please stop ignore me at gazebo-classic repo, and review my PRs.
Thank you.

https://github.com/talregev/vcpkg/pull/1/files

@traversaro Please stop ignore me at gazebo-classic repo, and review my PRs. Thank you.

@traversaro I am not sure this is relevant here. More in general, do you realize that open-source mantaners you interact with with are complete strangers that do not owe you anything, and pinging them in unrelated issues you are not helping them finding the time to review PRs or work on features?

@traversaro Please stop ignore me at gazebo-classic repo, and review my PRs. Thank you.

I am not sure this is relevant here. More in general, do you realize that open-source mantaners you interact with with are complete strangers that do not owe you anything, and pinging them in unrelated issues you are not helping them finding the time to review PRs or work on features?

So I ping non relevant maintainers on my PRs. Is it a good reason to punish me and ignore me?
I ping them for low respond on that repo. I wasn't sure how I can bring it up.

@traversaro We can continue that discussion on my PRs on gazebo classic repo.

I wasn't sure how I can bring it up.

(Sorry for the OT) My tipical strategy is to comment on the relevant PR (not somewhere else) "Can I do anything to help getting this PR?" (to sound a bit proactive), and avoid commenting elsewhere.

@dg0yt It not found urdfdom on windows:
config-x86-windows-out.log.txt

yes.

yes.

How we can solve it?

@traversaro @dg0yt
Any news regarding this PR?

Aren't you working on it?

Aren't you working on it?

I don't know how to solve the problems. Should I close this PR?

@Adela0814 please review.

Note: I will be converting your PR to draft status. When you respond, please revert to "ready for review". That way, I can be aware that you've responded since you can't modify the tags.

@talregev  I'm a bit confused, does sdformat require so many different versions of ports(sdformat6, sdformat9, sdformat10, sdformat13)? Instead of updating existing ports?

@talregev I'm a bit confused, does sdformat require so many different versions of ports(sdformat6, sdformat9, sdformat10, sdformat13)? Instead of updating existing ports?

we already have this discussions on gz-ports:
https://github.com/microsoft/vcpkg/pull/28656
The conclusion was to add new gz-port while maintain all the old other port with their version number.

The error is the one described in #31280 (comment) , nothing related to the use of gz_ CMake function.

using_parser_urdf is an interface target created in sdformat13 src/CMakeLists.txt, and linked to the main library target. This is the standard CMake stuff. However, the export of CMake config is hidden in gz functions. This export would need to handle the interface target as well.

Ahh, sorry I misunderstdood, that's totally correct.

@traversaro
Please create a PR in upstream, and I will make a patch from it.

I am happy to give you the hints to understand how to fix it. To be honest I am not interest at the moment in building sdformat13 as part of vcpkg and in static mode, so I prefer not to prepare the PR and submit it.
The sdformat13 library is created in https://github.com/gazebosim/gz-cmake/blob/gz-cmake3_3.1.0/cmake/GzUtils.cmake#L1540 and installed in https://github.com/gazebosim/gz-cmake/blob/gz-cmake3_3.1.0/cmake/GzUtils.cmake#L1611 , so the EXPORT used for it is sdformat13 . The target installed with that export are installed in https://github.com/gazebosim/gz-cmake/blob/88e7dc5f727e2270f206f19f558ab8f7fb5b8df1/cmake/GzPackaging.cmake#L372 . So a simple workaround is to just install the using_parser_urdf with the sdformat13 export, close to where using_parser_urdf library is defined with add_library.

@traversaro Will you consider the next version of sdformat will support vcpkg in static mode?

@Adela0814 adding unofficial- as a prefix, create to build failure:
CMake Error: install(EXPORT "sdformat13" ...) includes target "sdformat13" which requires target "using_parser_urdf" that is not in any export set.
CMake Error in src/CMakeLists.txt:
  export called with target "sdformat13" which requires target
  "using_parser_urdf" that is not in any export set.

Please read comments here:
https://github.com/microsoft/vcpkg/pull/31280#issuecomment-1546619308
I want to revert this change.

@traversaro Will you consider the next version of sdformat will support vcpkg in sperate static and dynamic mode?

I am not a mantainer of sdformat, but I guess that if you submit a PR based on https://github.com/microsoft/vcpkg/pull/31280#issuecomment-1546619308 explaining in which case it is useful I guess the mantainers would be happy to review it.

@traversaro Will you consider the next version of sdformat will support vcpkg in sperate static and dynamic mode?

I am not a mantainer of sdformat, but I guess that if you submit a PR based on #31280 (comment) explaining in which case it is useful I guess the mantainers would be happy to review it.

If I knew how to solve it, I was create a PR and a patch. I am lacking the knowledge how to do it.

@Adela0814 adding unofficial- as a prefix, create to build failure:
CMake Error: install(EXPORT "sdformat13" ...) includes target "sdformat13" which requires target "using_parser_urdf" that is not in any export set.
CMake Error in src/CMakeLists.txt:
  export called with target "sdformat13" which requires target
  "using_parser_urdf" that is not in any export set.

Please read comments here: #31280 (comment)
I want to revert this change.

@Adela0814 I will happy to hear your comment about the build fail.

@Adela0814 It now compile also on windows.
Please review it again.

@Adela0814 Thank you for your approve.
I see this PR didn't get in the previous batch.
Are we waiting for more review?

Thank you!


Git revision information incomplete in nightly version

This is a follow-up to #251. No urgent matter, but I was actually looking at *.dll.git files inside some nightly build JARs.

lwjgl itself contains the correct Git hash
for lwjgl-glfw, the .dll.git files contain just one character
for lwjgl-bgfx, the .dll.git files are there, but empty

Thanks! The next nightly (3.1.2 build 16) should contain correct revisions.


database/sql: query("now() + ?", time.Hour) is surprising

Today I learned two fun facts:

in MySQL, although now() is a datetime, now() + 0 is an integer formed from all of the decimal digits in the date. e.g. 2021-05-27 17:00:26 vs<PHONE_NUMBER>0026. (I'm not sure why one would ever want that.)
in Go's database/sql API for prepared statements, "?" applied to a duration value treats the duration (thanks to reflection on the underlying type) as an integer number of nanoseconds, not an interval. I don't know why one would ever want that either, since nanoseconds are not really useful in SQL.

The combination of these two facts means that the behavior of query("now() + ?", 1*time.Hour) isn't remotely close to what one might expect:
mysql> select now(), now() + interval 1 hour, now() + 60*60*1e9;
+---------------------+-------------------------+-------------------+
| now()               | now() + interval 1 hour | now() + 60*60*1e9 |
+---------------------+-------------------------+-------------------+
| 2021-05-27 17:13:53 | 2021-05-27 18:13:53     |<PHONE_NUMBER>1353 |
+---------------------+-------------------------+-------------------+
1 row in set (0.00 sec)

If database/sql were to treat durations specially, they could be mapped to interval 1 hour, avoiding this pitfall.

😱
CC @kardianos via https://dev.golang.org/owners
Based on the OP this looks like a problem in older versions of Go as well, but could you please confirm that?

database/sql passes the arguments for drivers to process, specifically, drivers may implement database/sql/driver.NamedValueChecker to handle types outside the default list. Given the varying representations of durations in different databases (as noted in #4954), it doesn't make sense to do this in database/sql or database/sql/dirver and should instead be handled by individual drivers instead.

I see. If it's impossible to support meaningfully on a range of databases, and if none support it today, then we should consider specifically disallowing it with a good error.

returning an error would prevent drivers from ever supporting this, and validation was specifically removed as part of the introduction of NamedValueChecker. CL 38533 / #18417
Closing there's nothing to do for the stdlib and requests should instead be filed with the drivers.


Support for bootstrap in Horizon

I wanted to ask about bootstrap and icons. There are some fi-* icons uses which come from foundation. If we have a bootstrap version of the html file, should that use icons from http://glyphicons.bootstrapcheatsheets.com/ ?
I see a .glyphicon-filter and .glyphicon-remove that would work.

Yes, that's how it works. Look at this file to see what I'm doing:
https://review.openstack.org/#/c/151386/14/openstack_dashboard/static/dashboard/scss/horizon.scss
You can see that .fi-filter is defined to .fa-filter, and .fi-x
is .fa-times.
Another reasonable approach would be to specify both styles, and let the
inappropriate one get ignored.
Suggest you look through all these styles, and see if you have better
ideas.
Do you have an account on PyPI? If not, can you get one? I will make you a
co-owner of the XStatic patch.
Randy Bertram
STSM - UI Architect
Cloud Systems Software Development
Phone:<PHONE_NUMBER> | Tie-Line: 441-8715
E-mail<EMAIL_ADDRESS>3039 E Cornwallis Rd
Research Triangle Park,
NC 27709-2195
United States
From:	David Kavanagh<EMAIL_ADDRESS>To:	eucalyptus/magic-search<EMAIL_ADDRESS>Cc:	Randy Bertram/Raleigh/IBM@IBMUS
Date:	02/13/15 08:55 AM
Subject:	Re: [magic-search] Support for bootstrap in Horizon (#4)
I wanted to ask about bootstrap and icons. There are some fi-* icons uses
which come from foundation. If we have a bootstrap version of the html
file, should that use icons from
http://glyphicons.bootstrapcheatsheets.com/ ?
I see a .glyphicon-filter and .glyphicon-remove that would work.
—
Reply to this email directly or view it on GitHub.

I've created an account as "dkavanagh" on pypi

The thought I had with bootstrap icons right in the html was that the widget would be more quickly useful to another project using bootstrap without pulling in some css from horizon.

you're an owner
Randy Bertram
STSM - UI Architect
Cloud Systems Software Development
Phone:<PHONE_NUMBER> | Tie-Line: 441-8715
E-mail<EMAIL_ADDRESS>3039 E Cornwallis Rd
Research Triangle Park,
NC 27709-2195
United States
From:	David Kavanagh<EMAIL_ADDRESS>To:	eucalyptus/magic-search<EMAIL_ADDRESS>Cc:	Randy Bertram/Raleigh/IBM@IBMUS
Date:	02/13/15 10:05 AM
Subject:	Re: [magic-search] Support for bootstrap in Horizon (#4)
I've created an account as "dkavanagh" on pypi
—
Reply to this email directly or view it on GitHub.

I have updated xstatic and the pull-request with your suggestion to include the bootstrap styles directly in the html. You should try the result, and make sure it still works in Eucalyptus.

Looks good. I pulled in the updated html and js files and did some testing in Eucalyptus with good results.


Zap never works for me

Hi,
Zap never works for me. See the video:
https://github.com/PrimalHQ/primal-android-app/assets/1178856/df47d348-bceb-45e2-9fe0-2c02d959c5f3

This message is shown if following statement is true:
if (userRelays.isNullOrEmpty() || nostrZapper == null || zapAmountInSats == null) {
    throw InvalidZapRequestException()
}

Could you try to zap with long-click and pick one of the predefined amounts? Please let me know what happens in this case.
If doesn't work again, then it could be that some other client has wiped your relays from contacts list (kind 3) and the statement fails on first check.

Could you try to zap with long-click and pick one of the predefined amounts? Please let me know what happens in this case.

Same problem.

Can you try to post or reply from the app? Does it work or complains that Network is not configured?

Will test now

Can you try to post or reply from the app? Does it work or complains that Network is not configured?

Didn't work reply

Now it's working


About the color difference between the generated image and ground truth

I trained this generative model with my own data, using the same MSEloss and vbloss as in the code you provided, and after 100 generations of training the network can correctly generate the content of the image, but the color of the image deviates a lot, and I'd like to ask if you've encountered a similar problem.

i got the same problem，but i didnot solve it


Hash returned is of zero length, fails to curl cov tar file

It only errors. I've tried about 7 times over the last 4 days. I've generated 3 different tokens from the coverity dashboard and updated the secret each time. I have another project using this action and never had a problem with it.
I've tried the steps from the command line. The hash returned is zero-length and the file is 0 bytes. I tried from the command line with my other project, and it worked as expected.
I assume no problem with this action and would have posted in the coverity community on Black Duck, but they require a new registration separate from my coverity account. I wanted to post here and see if anyone has experienced this or if they knew of a solution.
Coverity.yml workflow is at https://github.com/netpanzer/netpanzer/blob/e7ce65e102a37faa2286b645ad35371579f47f0f/.github/workflows/coverity.yml
Log
2024-10-17T21:37:18.5905275Z ##[group]Run vapier/coverity-scan-action@v1
2024-10-17T21:37:18.5905836Z with:
2024-10-17T21:37:18.5906330Z   token: ***
2024-10-17T21:37:18.5906716Z   email: ***
2024-10-17T21:37:18.5907126Z   build_language: cxx
2024-10-17T21:37:18.5907505Z   build_platform: linux64
2024-10-17T21:37:18.5907887Z   command: ninja -C builddir
2024-10-17T21:37:18.5908343Z   project: netpanzer/netpanzer
2024-10-17T21:37:18.5908904Z   working-directory: /home/runner/work/netpanzer/netpanzer
2024-10-17T21:37:18.5909432Z   version: a1a0998cc1f671f769201ae7b1b68aaaa74c5f69
2024-10-17T21:37:18.5910141Z   description: coverity-scan-action netpanzer/netpanzer / refs/pull/255/merge
2024-10-17T21:37:18.5910726Z ##[endgroup]
2024-10-17T21:37:18.6106993Z ##[group]Run echo "project=netpanzer/netpanzer" | sed -e 's:/:%2F:g' -e 's/ /%20/g' >> $GITHUB_OUTPUT
2024-10-17T21:37:18.6108053Z echo "project=netpanzer/netpanzer" | sed -e 's:/:%2F:g' -e 's/ /%20/g' >> $GITHUB_OUTPUT
2024-10-17T21:37:18.6168025Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2024-10-17T21:37:18.6168527Z ##[endgroup]
2024-10-17T21:37:18.6329138Z ##[group]Run hash=$(curl https://scan.coverity.com/download/cxx/linux64
2024-10-17T21:37:18.6329913Z hash=$(curl https://scan.coverity.com/download/cxx/linux64 \
2024-10-17T21:37:18.6331087Z          --data "token=${TOKEN}&project=netpanzer%2Fnetpanzer&md5=1"); \
2024-10-17T21:37:18.6331750Z echo "hash=${hash}" >> $GITHUB_OUTPUT
2024-10-17T21:37:18.6387336Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2024-10-17T21:37:18.6387850Z env:
2024-10-17T21:37:18.6388418Z   TOKEN: ***
2024-10-17T21:37:18.6388746Z ##[endgroup]
2024-10-17T21:37:18.6549883Z   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2024-10-17T21:37:18.6551252Z                                  Dload  Upload   Total   Spent    Left  Speed
2024-10-17T21:37:18.6551745Z
2024-10-17T21:37:18.6831619Z   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
2024-10-17T21:37:19.1082281Z   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
2024-10-17T21:37:19.1083382Z 100    64    0     0  100    64      0    141 --:--:-- --:--:-- --:--:--   140
2024-10-17T21:37:19.1161019Z ##[group]Run actions/cache@v4
2024-10-17T21:37:19.1161391Z with:
2024-10-17T21:37:19.1161895Z   path: /home/runner/work/netpanzer/netpanzer/cov-analysis
2024-10-17T21:37:19.1162424Z   key: cov-build-cxx-linux64-
2024-10-17T21:37:19.1162918Z   enableCrossOsArchive: false
2024-10-17T21:37:19.1163386Z   fail-on-cache-miss: false
2024-10-17T21:37:19.1163782Z   lookup-only: false
2024-10-17T21:37:19.1164296Z   save-always: false
2024-10-17T21:37:19.1164650Z ##[endgroup]
2024-10-17T21:37:19.3834750Z Cache not found for input keys: cov-build-cxx-linux64-
2024-10-17T21:37:19.3937962Z ##[group]Run curl https://scan.coverity.com/download/cxx/linux64
2024-10-17T21:37:19.3938658Z curl https://scan.coverity.com/download/cxx/linux64 \
2024-10-17T21:37:19.3939307Z   --no-progress-meter \
2024-10-17T21:37:19.3939783Z   --output cov-analysis.tar.gz \
2024-10-17T21:37:19.3940421Z   --data "token=${TOKEN}&project=netpanzer%2Fnetpanzer"
2024-10-17T21:37:19.3997808Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2024-10-17T21:37:19.3998427Z env:
2024-10-17T21:37:19.3998900Z   TOKEN: ***
2024-10-17T21:37:19.3999238Z ##[endgroup]
2024-10-17T21:37:19.6118764Z ##[group]Run mkdir cov-analysis
2024-10-17T21:37:19.6119246Z mkdir cov-analysis
2024-10-17T21:37:19.6177212Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2024-10-17T21:37:19.6177957Z ##[endgroup]
2024-10-17T21:37:19.6301535Z ##[group]Run tar -xzf cov-analysis.tar.gz --strip 1 -C cov-analysis
2024-10-17T21:37:19.6302214Z tar -xzf cov-analysis.tar.gz --strip 1 -C cov-analysis
2024-10-17T21:37:19.6354414Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2024-10-17T21:37:19.6354942Z ##[endgroup]
2024-10-17T21:37:19.6458930Z
2024-10-17T21:37:19.6459463Z gzip: stdin: unexpected end of file
2024-10-17T21:37:19.6460196Z tar: Child returned status 1
2024-10-17T21:37:19.6460884Z tar: Error is not recoverable: exiting now
2024-10-17T21:37:19.6473728Z ##[error]Process completed with exit code 2.
2024-10-17T21:37:19.6614141Z Post job cleanup.

are you sure you set project correctly ?
please verify the name via your dashboard as the documentation says.
https://scan.coverity.com/projects/netpanzer

It was set incorrectly. Thank you!


fix(symbol): fix square icon is not being respected

Brief Information
This pull request is in the type of:

[x] bug fixing
[ ] new feature
[ ] others

What does this PR do?
square is one of the built-in icons. But it seems this icon is not being respected, which behaves like rect.
Fixed issues
N.A.
But it's related to apache/echarts-doc#256
Details
Before: What was the problem?
The square icon behaves like rect because of the [symbol scale strategy.

chart/helper/Symbol.ts#L85-L86
chart/helper/Symbol.ts#L170-L171

After: How is it fixed in this PR?

Misc

[ ] The API has been changed (apache/echarts-doc#xxx).
[ ] This PR depends on ZRender changes (ecomfe/zrender#xxx).

Related test cases or examples to use the new APIs
test/scatter.html
Others
Merging options

[ ] Please squash the commits into a single one when merging.

Other information

But it's enough to use rect and symbolSize to do this. So is it necessary to support this icon type?

In my opinion, I don't think it may not be necessary since symbolSize can be an array like [10, 10] to make a square. Maybe we should first find a case where rect is not enough for it.

So far, I also think it's not necessary to do something extra for this case. Using rect & symbolSize is enough. I'm going to close this PR and keep the square icon invisible in the documentation as before.

Thanks @plainheart . There are some other undocumented APIs (mostly because they are not meant to be used by developers) so I think it's OK to have square being undocumented.


nit: Use nil pointer pattern to check for interface compliance.

Description

Reference: https://github.com/cosmos/ibc-go/pull/3437#issuecomment-1504975870
To use a consistent style between creating an empty struct and taking its reference vs. casting a nil pointer to the type.
For types implementing interfaces using value receivers this works in exactly the same way since a pointer to that type is also considered as implementing the interface.
I'm hopeful I got most of them.
closes: #XXXX
Commit Message / Changelog Entry
nit: Use nil pointer pattern to check for interface compliance.

see the guidelines for commit messages. (view raw markdown for examples)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[x] Provide a commit message to be used for the changelog entry in the PR description for review.
[x] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

Codecov Report

Merging #3439 (40a49bf) into main (b562f24) will decrease coverage by 0.06%.
The diff coverage is n/a.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3439      +/-   ##
==========================================
- Coverage   78.59%   78.54%   -0.06%
==========================================
  Files         181      181
  Lines       12546    12581      +35
==========================================
+ Hits         9861     9882      +21
- Misses       2252     2265      +13
- Partials      433      434       +1

Impacted Files
Coverage Δ

...7-interchain-accounts/controller/ibc_middleware.go
70.96% <ø> (ø)

...nterchain-accounts/controller/keeper/grpc_query.go
100.00% <ø> (ø)

...nterchain-accounts/controller/keeper/msg_server.go
92.10% <ø> (ø)

...ps/27-interchain-accounts/controller/types/msgs.go
91.11% <ø> (ø)

...s/27-interchain-accounts/host/keeper/grpc_query.go
100.00% <ø> (ø)

modules/apps/27-interchain-accounts/module.go
54.54% <ø> (ø)

modules/apps/29-fee/ibc_middleware.go
94.56% <ø> (ø)

modules/apps/29-fee/keeper/grpc_query.go
75.93% <ø> (ø)

modules/apps/29-fee/keeper/keeper.go
92.30% <ø> (ø)

modules/apps/29-fee/keeper/msg_server.go
97.14% <ø> (ø)

... and 30 more

... and 3 files with indirect coverage changes


"All Trades" endpoint

Just streams all the trades happening regardless of orderbook.

This is not a "Cleaning and fixing" ticket.  As mentioned the last time we discussed this, trades are currently only expressed as effects, which mean they are attached to a specific account.  This requires non-trivial software and API design to build.

Merged in #384


build error with support library version of 23.2.0

If version 23.2.0 of support libraries are used then I get some errors like:
Error:(2) Attribute "preferenceStyle" has already been defined
Error:(2) Attribute "checkBoxPreferenceStyle" has already been defined
Error:(2) Attribute "dialogPreferenceStyle" has already been defined
Error:(2) Attribute "editTextPreferenceStyle" has already been defined
Error:(2) Attribute "ringtonePreferenceStyle" has already been defined
Error:(2) Attribute "switchPreferenceStyle" has already been defined
Error:(2) Attribute "seekBarPreferenceStyle" has already been defined
Error:(2) Attribute "preferenceScreenStyle" has already been defined
Error:(2) Attribute "preferenceFragmentListStyle" has already been defined
Would it be resolved if you updated your library with these support libraries? If so, can you please do that?

Yeah, there are more incompatibilities than this. Stick to 23.1.1 support libs for now and stay tuned for 0.5.5 release of this lib.

Do you happen to have any estimates on when could you prepare the 0.5.5 release? I'd really need to use the new support lib for other reasons and it'd help to know this.
Thanks for the awesome lib.

It should be out by now. Sadly it won't be compatible with older versions of the support lib.

Thanks

Is it normal that with this version I can see a different bg color for each preference item and there is also a divider among the prefereneces?

Can you post a screenshot?
I think the dividers are now provided by preference-v7 by default. Didn't hear anything about a background.

Indeed, it seems that the divider has been there with 0.5.3 as well.
Previously with 0.5.3:

Now with 0.5.5:

I'd prefer the old one.

Dividers
I just added this to README.md section about dividers:

Looks like this is not necessary in 0.5.5 as preference-v7 r23.2.0 provides a default divider. If you want to customize how this divider looks you can call setDivider(...) and setDividerHeight(...). Preference-v7 divider will be drawn just between items and at the bottom of the list. It will not be drawn before the end of category. You can disable this default divider with setDivider(null) and continue using what I described above.

You have two options:
1) Disable the divider provided by preference-v7 by calling
setDivider(null)

2) Disable my divider by removing
list.addItemDecoration(new PreferenceDividerDecoration(getContext()).drawBottom(true));

Background
As for the background I got nothing, it does not happen on my phone.
The light theme gives me some clues. You're testing in an emulator. Press Tab, the focus changes and from there everything should be ok. Don't know why this happens, it's not my fault, report Android bug if you feel this shouldn't be happening.

Thanks for the update.
Indeed, on a physical device I can't see the blueish bg color, however I can still see the bg color that is different from the rest of the screen.
It must be related to this library or the 23.3.2 version of the support one as nothing else has changed in my code.
So you have checked it and you can't see the change in the bg color?
One more question:
If you check the screenshots you can see that the bottom preference has a different margin around the icon. That one is a listpreference while the other ones are preferencescreen items. Is this intentional?

I dunno. Review your theme attributes. Nothing changed on my part besides depending on preference-v7 23.2.0. Did you change selectableItemBackground?
About the other question read this https://github.com/consp1racy/android-support-preference#handling-preferencescreen-icons

Thanks for your help. Indeed it seems that the background comes from selection. On emulator by pressing TAB confirms this. What's strange is that I can also see this on physical devices. Except that I can't press TAB there so I can't confirm this. Any ideas?

I've got nothing. Must be from overriding some theme attribute, no other ideas come to mind.

Hi, I'm using your library and its great but I'm getting the background color problem on all the devices I try it on, just wondering if you've had any ideas on what's causing it?

@PaulNeesham @dirkam Ok, I've looked into it; it's caused by RecyclerView bringing focus to itself. We can disable this while having its child views behave correctly.
Symptoms are holo blue background on Android 4 and grey background on Android 5 when the fragment starts.
Solution is to disable focusability on the RecyclerView itself.
@Override
public void onViewCreated(View view, @Nullable Bundle savedInstanceState) {
    super.onViewCreated(view, savedInstanceState);
    final RecyclerView listView = getListView();

    // We don't want this. The children are still focusable.
    listView.setFocusable(false);
}

Wow fast response! Tried it on few device and solves it. Cheers!

Hi Eugene, any chance to get this code in the library itself?

@JoseGD Technically it is possible in multiple ways but let's keep it opt-in. The original works as the support library developers intended (I hope) and you as the product developer now have the tools to alter that behavior. Agreed?
It's a couple of lines, it's documented in README and you can apply it in this wording to either PreferenceFragment or XpPreferenceFragment one of which you have to extend.

Ok, not problems at all to add just a couple of lines, I asked that because I've seen similar tricks have been applied in the past and future versions of this library made them unnecessary.
By the way, thanks for keeping the readme updated, didn't notice that addition


Highlights are being cleared by colorscheme

Hello!
I am currently beginning to use carbon.nvim and it seems that my colorscheme (wuelnerdotexe/vim-enfocado) is clearing the highlights used by carbon.nvim.

I created an small reproduction repository using Docker here.
Edit: one possible fix could be using highlight default as can be seen in :hi-default. I once had to use it for my plugin corpus.vim. With it you don't need to use after/syntax or the like.

Hello again @datwaft,
I just pushed another patch which follows your suggestion of using highlight default. This is again another good sane default to set as well so that is a nice bonus 👍
I'm leaving this one open for you to first confirm whether this patch does in fact fix your issue. Thanks again for the feedback from both issues!

Specifically, this is related to plugins which are loaded through the plugin folder as opposed to the ftplugin folder. I do not think it is an issue with the vim.api.nvim_buf_add_highlight API but rather I think that no other plugin which applies highlights in the plugin directory will "work" though this is just an admittedly naive assumption 😅

Will mark this one resolved. If anyone reading this is experiencing this issue I doubt I can be of much help for reasons explained above however, I will remain open for potential solutions :)

Thanks for you help! At the same time I opened this issue I also opened an issue on vim-enfocado that you can see here: https://github.com/wuelnerdotexe/vim-enfocado/issues/5.
Thanks for your help!
Btw, as a workaround I can set the highlights manually using what can be seen here, so it's not much of a problem.

Cheers for the reference link and repros @datwaft, much appreciated 👍 if enfocado does not want to add support I will add some enfocado specific section to the helpfile and add a note about it in the README.


Set custom locale used by Translatable

In some cases we want the default locale used by translated models to be different than the App's current locale.
To solve this we should add a locale configuration, with default to null. If this value is set, then translatable should use this as locale instead of App::make('translator')->getLocale().
cc @sdebacker

Also add documentation for the new config.


feature(command-functions): support netlify/functions in all functions related commands

Is your feature request related to a problem? Please describe.
Related to https://github.com/netlify/cli/pull/2270#discussion_r627293512
The ntl functions:build and ntl functions:list command don't have support for the default functions directory.
See https://github.com/netlify/cli/blob/e5f1c848ed587a1fa053b4331170d8ec83149d3c/src/commands/functions/list.js#L49 and https://github.com/netlify/cli/blob/e5f1c848ed587a1fa053b4331170d8ec83149d3c/src/commands/functions/build.js#L25
We should default to netlify/functions if no directory exists, and possible print a message to the user if the directory doesn't contain any functions
Describe the solution you'd like
Default to netlify/functions instead of failing when a functions directory is not configured
Describe alternatives you've considered
Keep current state of failing the command
Can you submit a pull request?
Yes

I believe the --inlineConfig flag of @netlify/config could be used there.
When the CLI resolves the configuration by calling @netlify/config, it could pass --inlineConfig.build.functions=path with path being the return value of https://github.com/netlify/cli/blob/e5f1c848ed587a1fa053b4331170d8ec83149d3c/src/utils/functions/index.js#L1
The value of --inlineConfig is a config object. It the same as if the config was specified in netlify.toml, except it has higher priority. This would allow the CLI to benefit from the logic already in @netlify/config: not only the default netlify/functions value, but also validation, etc.


Add iheartradio icon re: issue #282

Adds the requested iHeartRadio icon following the required contribution guidelines.

It's close. Could you please follow the template at https://github.com/edent/SuperTinyIcons/blob/master/CONTRIBUTING.md


Option to choose which hotbar slots use autotool

Tweakeroo has a similar "toolSwitch" tweak, but you can specify which slots let you do autotool, and which don't, by range or list of hotbar numbers.
e.g, I only want to use the first slot as my autotool slot, with similar behaviour to AutoTool's existing "keep selected slot"

here's what it looks like in game:

If I had set toolSwitchIgnoredSlots to 3-9, and tried to use the second slot to mine wood, it would swap to the first slot, and swap the tool to be put into slot 1 if necessary.
I hope that it explains the feature thoroughly enough, it'd be a great addition to the mod, and would replace tweakeroo for me entirely, since I really only use it for this one little feature. Thanks in advance for your consideration.

I'm using Tweakeroo for 1.21 as well, just as a temporary replacement for my slightly buggy AutoTools. This would be a nice feature to have, and just like zelythia, this feature would allow me to get rid of Tweakeroo.

Hiya, just writing to let you know that I've tried out the implemented feature in game, and it works beautifully. Thanks so much for implementing it!


Search isn't indexing the index page of nested pages in htmldir builder

You can test with this project
https://anymail.readthedocs.io/en/latest/search/?q=Sending+email&check_keywords=yes&area=default
There aren't results from this page https://anymail.readthedocs.io/en/latest/sending/
This is kind of related to the doctype that we want to remove https://github.com/rtfd/readthedocs.org/issues/4638 and kind of the same as https://github.com/rtfd/readthedocs.org/issues/5254
In a more minimal example this is more visible, our search returns 0 results and fallback to sphinx.
The explanation is that we try to index the file sending.fjson but that file doesn't exists, what we want is to index sending/index.fjson

Hrm, I thought we fixed this here: https://github.com/rtfd/readthedocs.org/blob/e4966e51a521a5cae44842aa87bb870f59b13b36/readthedocs/projects/models.py#L1149-L1159

We shouldn't use doctype anymore :).
I think basename is sending only, that's why.

How do you figure out if you should check for an HTMLDir path without doctype? I guess we could just try both, but that feels like it would lead to other bugs.

That's what I want I figure out now. If there isn't a clean way, we have the doctype from the config module in the database (old projects don't have this, but we could create a migration).

Seems like this should work?
In [6]: for p in HTMLFile.objects.filter(project__slug='anymail', version__slug='latest', path='sending/index.html'):
   ...:     print(p.json_file_path)
   ...:
readthedocs.projects.models:1154[6212]: INFO Adjusted json file path: sending/index -> sending
/home/docs/checkouts/readthedocs.org/media/json/anymail/latest/sending.fjson

Oh, the filename is /home/docs/checkouts/readthedocs.org/media/json/anymail/latest/sending/index.fjson -- that's the issue.

Seems like the logic is broken, and without it it would work 😢

Seems like this logic works for everything except the index file... There's some weird edge case here:
In [1]:
   ...: import os
   ...: for p in HTMLFile.objects.filter(project__slug='anymail', version__slug='latest', path__startswith='sending'):
   ...:     print(p.json_file_path)
   ...:     print(os.path.exists(p.json_file_path))
   ...:
   ...:
readthedocs.projects.models:1154[9789]: INFO Adjusted json file path: sending/templates/index -> sending/templates
/home/docs/checkouts/readthedocs.org/media/json/anymail/latest/sending/templates.fjson
True
readthedocs.projects.models:1154[9789]: INFO Adjusted json file path: sending/tracking/index -> sending/tracking
/home/docs/checkouts/readthedocs.org/media/json/anymail/latest/sending/tracking.fjson
True
readthedocs.projects.models:1154[9789]: INFO Adjusted json file path: sending/django_email/index -> sending/django_email
/home/docs/checkouts/readthedocs.org/media/json/anymail/latest/sending/django_email.fjson
True
readthedocs.projects.models:1154[9789]: INFO Adjusted json file path: sending/signals/index -> sending/signals
/home/docs/checkouts/readthedocs.org/media/json/anymail/latest/sending/signals.fjson
True
readthedocs.projects.models:1154[9789]: INFO Adjusted json file path: sending/exceptions/index -> sending/exceptions
/home/docs/checkouts/readthedocs.org/media/json/anymail/latest/sending/exceptions.fjson
True
readthedocs.projects.models:1154[9789]: INFO Adjusted json file path: sending/anymail_additions/index -> sending/anymail_additions
/home/docs/checkouts/readthedocs.org/media/json/anymail/latest/sending/anymail_additions.fjson
True
readthedocs.projects.models:1154[9789]: INFO Adjusted json file path: sending/index -> sending
/home/docs/checkouts/readthedocs.org/media/json/anymail/latest/sending.fjson
False

Yeah, index is the only one affected.

It's because sending.rst or sending/index.rst both lead to the same file :/

There isn't a sending.rst file, just sending/index.rst https://github.com/anymail/django-anymail/blob/master/docs/sending/index.rst

Right, but both files could lead to the same output file, so there's no way to know which it came from :/


Finish clean up

Codecov Report

Merging #215 (7ce049f) into main (f402e08) will decrease coverage by 0.2%.
The diff coverage is 0.2%.

:exclamation: Current head 7ce049f differs from pull request most recent head 741d581. Consider uploading reports for the commit 741d581 to get more accurate results

@@           Coverage Diff           @@
##            main    #215     +/-   ##
=======================================
- Coverage   15.2%   15.0%   -0.2%
=======================================
  Files         27      27
  Lines       6194    6287     +93
=======================================
+ Hits         942     943      +1
- Misses      5252    5344     +92

Impacted Files
Coverage Δ

src/farcasterd/runtime.rs
0.0% <0.0%> (ø)

src/swapd/runtime.rs
0.0% <0.0%> (ø)

src/walletd/runtime.rs
0.0% <0.0%> (ø)

src/rpc/request.rs
14.4% <50.0%> (+0.2%)
:arrow_up:

Continue to review full report at Codecov.

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

multiple swaps are functional here, as far as multiple identical offers arent used in parallel
for maker, can't make 2 identical offers, while the first one of them is not taken
for taker, 2nd swap taken must be different than 1st, unless the 1st one is finished

attaching some logs of multiple swaps running in parallel
node0.log
node1.log

I'm getting a panic on swapd if I run two swaps in parallel on Bob's side:
thread 'main' panicked at 'signature is not the decryption of our original encrypted signature', /home/drgrid/.cargo/registry/src/github.com-1ecc6299db9ec823/farcaster_core-0.4.0/src/swap/btcxmr.rs:381:21

I did manage to run 2 parallel swaps with Alice as maker. Will try know Bob as maker to se if I can reproduce.


Roll engine 97807b534122..b16eab6affb7 (1 commits)

git@github.com:flutter/engine.git/compare/97807b534122...b16eab6affb7
git log 97807b534122..b16eab6affb7 --no-merges --oneline
2019-10-30<EMAIL_ADDRESS>Remove usage of yaml module from CIPD script (flutter/engine#13444)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

Auto-roller completed checks. About to merge.


Feat: add Bool.compl_singleton_* and Set.range_in{l,r}

Backported in leanprover-community/mathlib#18332

I had to rewrite a proof about Sums because I failed to quickly fix it, and I used these lemmas in the new proof.

Thanks :tada:
bors merge


Support images larger than 2GiB in docker_session.upload()

This library has been extremely useful for jobs that run docker commands!
One such job recently started failing with OverflowError: string longer than<PHONE_NUMBER> bytes when it tried to copy a 2.6GB image.
I'm sure that there are reasons behind the 2GiB limit, but would it be possible to increase this limit? (e.g. to 4GiB or 8GiB)

It looks like the root cause of the library failure is the limitation of the SSL wrapped HTTP client - a similar issue discussed at https://github.com/psf/requests/issues/2717

When I upload an image larger than 2GiB, I see that the reason is that zlib.crc32() does not support more than (2^32-1) bytes in python version 2.7.5, resulting in an error.zlib.crc32() is called here https://github.com/google/containerregistry/blob/8a11dc8c53003ecf5b72ffaf035ba280109356ac/client/v2_2/docker_image_.py#L461
$ python2 -c "import zlib;zlib.crc32('a'*(1<<31))"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OverflowError: size does not fit in an int

This means that the size of the uploaded image should not exceed 2GiB per layer. We should upgrade python2 to 2.7.18 or python3

We should upgrade python2 to 2.7.18 or python3

You're saying this is fixed with just a version bump?


JQuery v1.8.2 tests not working

When testing against all jquery versions the test against JQuery v1.8.2 has to be disabled as it causes errors.

Taking a second look at this and can see that tests is working in both
FoBoJQSpec and FoBoJQResSpec but not in FoBoSpec
The problem was using JQuery182 as initial value in
  object InitParam extends FoBoToolkit with FoBoJQuery {
    var JQuery: FoBoJQuery = JQuery182
    var ToolKit: FoBoToolkit = _
  }

removing it fixed the problem.


Add ci/cd pipeline using GitHub actions

Add GitHub action files for tests, lint check and coverage report.

are these issues open for contributions?

All issues tagged GSoC 2024 will be completed by @anga4, this year's GSoC contributor


 But after this, let it be known that we have liftoff.
~/w/s/s3-tests java -jar quasar-repl-assembly-38.2.3-f3f05e7.jar --backend:quasar.physical.s3.S3LineDelimited\$=plugins/quasar-s3-assembly-0.0.1.jar
Configuration file '/home/nope/.config/quasar/quasar-config.json' not found, using default configuration.
log4j:WARN No appenders could be found for logger (com.zaxxer.hikari.HikariConfig).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Using metastore: jdbc:h2:/home/nope/.config/quasar/quasar-metastore.db
(v38.2.3-f3f05e7) 💪 $ cd s3test
(v38.2.3-f3f05e7) 💪 $ select * from `extraSmallZips.data`
QScript (Optimized):
Subset(Take)
├─ Unreferenced
├─ From
│  ╰─ ShiftedRead(/extraSmallZips.data, ExcludeId)
╰─ Count
   ╰─ Map
      ├─ Unreferenced
      ╰─ Constant(Int(10))

Query time: 1.0s
 city           | state | pop    | _id    | loc[0]      | loc[1]     |
----------------|-------|--------|--------|-------------|------------|
 AGAWAM         | MA    |  15338 | 01001  |  -72.622739 |  42.070206 |
 CUSHMAN        | MA    |  36963 | 01002  |   -72.51565 |  42.377017 |
 BARRE          | MA    |   4546 | 01005  |  -72.108354 |  42.409698 |
 BLANDFORD      | MA    |   1240 | 01008  |  -72.936114 |  42.182949 |
 BRIMFIELD      | MA    |   3706 | 01010  |  -72.188455 |  42.116543 |
 CHESTER        | MA    |   1688 | 01011  |  -72.988761 |  42.279421 |
 WESTOVER AFB   | MA    |   1764 | 01022  |  -72.558657 |  42.196672 |
 CUMMINGTON     | MA    |   1484 | 01026  |  -72.905767 |  42.435296 |
 MOUNT TOM      | MA    |  16864 | 01027  |  -72.679921 |  42.264319 |
 FEEDING HILLS  | MA    |  11985 | 01030  |  -72.675077 |   42.07182 |
(v38.2.3-f3f05e7) 💪 $
Exiting...

@edmundnoble it's not particular to this PR more than any others, but we should probably have unit tests and integration tests for the individual lwc's as well. One thing to think about is if there is any sort of lwc test framework that we want to expose for people implementing lwc's.

We could have laws for exists and children. I also see us being able to make generic laws, as long as we force the user to specify a data upload mechanism while instantiating them.

@edmundnoble were you going to push the changes we discussed to this branch? Or should merge this and you'll push them later?


README: build instructions test target is executed but tests are not built

Hi there,
There is minor issue in the build instructions:
https://github.com/wetadigital/USDPluginExamples#building
The test target is executed but it is not built.
Thanks

Thanks for the report, @splashyin!  This has been fixed and pushed to the main branch.


[R] [ci] R linters are not being run in CI

I tried to pick up part of #5779 tonight, and realized something...I believe that the R linting tests are not being run in CI.
I confirmed this by copying those linters used in test_lint.R into the following script
lintr script (click me)
library(lintr)

args <- commandArgs(
    trailingOnly = TRUE
)
SOURCE_DIR <- args[[1L]]

FILES_TO_LINT <- list.files(
    path = SOURCE_DIR
    , pattern = "\\.r$"
    , all.files = TRUE
    , ignore.case = TRUE
    , full.names = TRUE
    , recursive = TRUE
    , include.dirs = FALSE
)

LINTERS_TO_USE <- list(
    absolute_paths_linter=lintr::absolute_paths_linter
    , assignment_linter=lintr::assignment_linter
    , closed_curly_linter=lintr::closed_curly_linter
    , commas_linter=lintr::commas_linter
    , infix_spaces_linter=lintr::infix_spaces_linter
    , line_length_linter=lintr::line_length_linter
    , no_tab_linter=lintr::no_tab_linter
    , object_usage_linter=lintr::object_usage_linter
    , object_length_linter=lintr::object_length_linter
    , open_curly_linter=lintr::open_curly_linter
    , spaces_inside_linter=lintr::spaces_inside_linter
    , spaces_left_parentheses_linter=lintr::spaces_left_parentheses_linter
    , trailing_blank_lines_linter=lintr::trailing_blank_lines_linter
    , trailing_whitespace_linter=lintr::trailing_whitespace_linter
    , true_false=lintr::T_and_F_symbol_linter
)

cat(sprintf("Found %i R files to lint\n", length(FILES_TO_LINT)))

results <- NULL

for (r_file in FILES_TO_LINT) {

    this_result <- lintr::lint(
        filename = r_file
        , linters = LINTERS_TO_USE
        , cache = FALSE
    )

    print(
        sprintf(
            "Found %i linting errors in %s"
            , length(this_result)
            , r_file
        )
        , quote = FALSE
    )

    results <- c(results, this_result)

}

issues_found <- length(results)

if (issues_found > 0L) {
    print(results)
}

quit(save = "no", status = issues_found)

And then running it like this
Rscript lintr_r_code.R $(pwd)/R-package

I think the issue is that test_lint.R includes a skip_on_cran()
https://github.com/dmlc/xgboost/blob/b47b5ac771919f32e26c8259c060f6b1930682c8/R-package/tests/testthat/test_lint.R#L3
And R tests are run by building a package and using R CMD check --as-cran
https://github.com/dmlc/xgboost/blob/b47b5ac771919f32e26c8259c060f6b1930682c8/tests/ci_build/build_test_rpkg.sh#L22
https://github.com/dmlc/xgboost/blob/b47b5ac771919f32e26c8259c060f6b1930682c8/appveyor.yml#L106
When I run the script above, it finds 900+ linting issues.
First 100 R linter issues (click me)
Found 55 R files to lint
[1] Found 30 linting errors in R-package//demo/basic_walkthrough.R
[1] Found 7 linting errors in R-package//demo/boost_from_prediction.R
[1] Found 9 linting errors in R-package//demo/caret_wrapper.R
[1] Found 21 linting errors in R-package//demo/create_sparse_matrix.R
[1] Found 15 linting errors in R-package//demo/cross_validation.R
[1] Found 21 linting errors in R-package//demo/custom_objective.R
[1] Found 9 linting errors in R-package//demo/early_stopping.R
[1] Found 8 linting errors in R-package//demo/generalized_linear_model.R
[1] Found 5 linting errors in R-package//demo/gpu_accelerated.R
[1] Found 73 linting errors in R-package//demo/interaction_constraints.R
[1] Found 15 linting errors in R-package//demo/poisson_regression.R
[1] Found 17 linting errors in R-package//demo/predict_first_ntree.R
[1] Found 13 linting errors in R-package//demo/predict_leaf_indices.R
[1] Found 0 linting errors in R-package//demo/runall.R
[1] Found 7 linting errors in R-package//demo/tweedie_regression.R
[1] Found 0 linting errors in R-package//inst/make-r-def.R
[1] Found 22 linting errors in R-package//R/callbacks.R
[1] Found 14 linting errors in R-package//R/utils.R
[1] Found 23 linting errors in R-package//R/xgb.Booster.R
[1] Found 26 linting errors in R-package//R/xgb.create.features.R
[1] Found 13 linting errors in R-package//R/xgb.cv.R
[1] Found 4 linting errors in R-package//R/xgb.DMatrix.R
[1] Found 4 linting errors in R-package//R/xgb.DMatrix.save.R
[1] Found 14 linting errors in R-package//R/xgb.dump.R
[1] Found 33 linting errors in R-package//R/xgb.ggplot.R
[1] Found 37 linting errors in R-package//R/xgb.importance.R
[1] Found 0 linting errors in R-package//R/xgb.load.R
[1] Found 0 linting errors in R-package//R/xgb.load.raw.R
[1] Found 48 linting errors in R-package//R/xgb.model.dt.tree.R
[1] Found 31 linting errors in R-package//R/xgb.plot.deepness.R
[1] Found 2 linting errors in R-package//R/xgb.plot.importance.R
[1] Found 21 linting errors in R-package//R/xgb.plot.multi.trees.R
[1] Found 9 linting errors in R-package//R/xgb.plot.shap.R
[1] Found 26 linting errors in R-package//R/xgb.plot.tree.R
[1] Found 14 linting errors in R-package//R/xgb.save.R
[1] Found 0 linting errors in R-package//R/xgb.save.raw.R
[1] Found 1 linting errors in R-package//R/xgb.serialize.R
[1] Found 6 linting errors in R-package//R/xgb.train.R
[1] Found 1 linting errors in R-package//R/xgb.unserialize.R
[1] Found 0 linting errors in R-package//R/xgboost.R
[1] Found 0 linting errors in R-package//tests/testthat.R
[1] Found 61 linting errors in R-package//tests/testthat/test_basic.R
[1] Found 44 linting errors in R-package//tests/testthat/test_callbacks.R
[1] Found 13 linting errors in R-package//tests/testthat/test_custom_objective.R
[1] Found 22 linting errors in R-package//tests/testthat/test_dmatrix.R
[1] Found 2 linting errors in R-package//tests/testthat/test_gc_safety.R
[1] Found 4 linting errors in R-package//tests/testthat/test_glm.R
[1] Found 38 linting errors in R-package//tests/testthat/test_helpers.R
[1] Found 29 linting errors in R-package//tests/testthat/test_interaction_constraints.R
[1] Found 57 linting errors in R-package//tests/testthat/test_interactions.R
[1] Found 16 linting errors in R-package//tests/testthat/test_lint.R
[1] Found 13 linting errors in R-package//tests/testthat/test_monotone.R
[1] Found 2 linting errors in R-package//tests/testthat/test_parameter_exposure.R
[1] Found 7 linting errors in R-package//tests/testthat/test_poisson_regression.R
[1] Found 11 linting errors in R-package//tests/testthat/test_update.R
[[1]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:6:29: style: Put spaces around all infix operators.
data(agaricus.train, package='xgboost')
                           ~^~

[[2]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:7:28: style: Put spaces around all infix operators.
data(agaricus.test, package='xgboost')
                          ~^~

[[3]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:29:80: style: Trailing whitespace is superfluous.
bst <- xgboost(data = dtrain, max_depth = 2, eta = 1, nrounds = 2, nthread = 2,
                                                                               ^

[[4]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:49:54: style: Trailing whitespace is superfluous.
# you can put in Matrix, sparseMatrix, or xgb.DMatrix
                                                     ^

[[5]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:61:51: style: Put spaces around all infix operators.
print(paste("sum(abs(pred2-pred))=", sum(abs(pred2-pred))))
                                                 ~^~

[[6]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:64:5: style: Use <-, not =, for assignment.
raw = xgb.save.raw(bst)
    ^

[[7]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:69:51: style: Put spaces around all infix operators.
print(paste("sum(abs(pred3-pred))=", sum(abs(pred3-pred))))
                                                 ~^~

[[8]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:73:47: style: Put spaces around all infix operators.
dtrain <- xgb.DMatrix(data = train$data, label=train$label)
                                             ~^~

[[9]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:74:45: style: Put spaces around all infix operators.
dtest <- xgb.DMatrix(data = test$data, label=test$label)
                                           ~^~

[[10]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:77:24: style: Put spaces around all infix operators.
watchlist <- list(train=dtrain, test=dtest)
                      ~^~

[[11]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:77:37: style: Put spaces around all infix operators.
watchlist <- list(train=dtrain, test=dtest)
                                   ~^~

[[12]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:79:79: style: Trailing whitespace is superfluous.
# watchlist allows us to monitor the evaluation result on all data in the list
                                                                              ^

[[13]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:81:22: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                    ~^~

[[14]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:81:40: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                      ~^~

[[15]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:81:47: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                             ~^~

[[16]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:81:58: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                                        ~^~

[[17]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:81:71: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                                                     ~^~

[[18]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:85:22: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                    ~^~

[[19]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:85:40: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                      ~^~

[[20]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:85:47: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                             ~^~

[[21]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:85:58: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                                        ~^~

[[22]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:85:71: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                                                     ~^~

[[23]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:93:22: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain2, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                    ~^~

[[24]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:93:41: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain2, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                       ~^~

[[25]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:93:48: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain2, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                              ~^~

[[26]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:93:59: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain2, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                                         ~^~

[[27]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:93:72: style: Put spaces around all infix operators.
bst <- xgb.train(data=dtrain2, max_depth=2, eta=1, nrounds=2, watchlist=watchlist,
                                                                      ~^~

[[28]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:96:7: style: Use <-, not =, for assignment.
label = getinfo(dtest, "label")
      ^

[[29]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:98:56: style: Put spaces around all infix operators.
err <- as.numeric(sum(as.integer(pred > 0.5) != label))/length(label)
                                                      ~^~

[[30]]
/Users/jlamb/repos/xgboost/R-package/demo/basic_walkthrough.R:102:11: style: Use <-, not =, for assignment.
dump_path = file.path(tempdir(), 'dump.raw.txt')
          ^

[[31]]
/Users/jlamb/repos/xgboost/R-package/demo/boost_from_prediction.R:3:29: style: Put spaces around all infix operators.
data(agaricus.train, package='xgboost')
                           ~^~

[[32]]
/Users/jlamb/repos/xgboost/R-package/demo/boost_from_prediction.R:4:28: style: Put spaces around all infix operators.
data(agaricus.test, package='xgboost')
                          ~^~

[[33]]
/Users/jlamb/repos/xgboost/R-package/demo/boost_from_prediction.R:14:24: style: Put spaces around all infix operators.
param <- list(max_depth=2, eta=1, nthread = 2, objective='binary:logistic')
                      ~^~

[[34]]
/Users/jlamb/repos/xgboost/R-package/demo/boost_from_prediction.R:14:31: style: Put spaces around all infix operators.
param <- list(max_depth=2, eta=1, nthread = 2, objective='binary:logistic')
                             ~^~

[[35]]
/Users/jlamb/repos/xgboost/R-package/demo/boost_from_prediction.R:14:57: style: Put spaces around all infix operators.
param <- list(max_depth=2, eta=1, nthread = 2, objective='binary:logistic')
                                                       ~^~

[[36]]
/Users/jlamb/repos/xgboost/R-package/demo/boost_from_prediction.R:18:44: style: Put spaces around all infix operators.
ptrain <- predict(bst, dtrain, outputmargin=TRUE)
                                          ~^~

[[37]]
/Users/jlamb/repos/xgboost/R-package/demo/boost_from_prediction.R:19:43: style: Put spaces around all infix operators.
ptest  <- predict(bst, dtest, outputmargin=TRUE)
                                         ~^~

[[38]]
/Users/jlamb/repos/xgboost/R-package/demo/caret_wrapper.R:2:51: style: Trailing whitespace is superfluous.
devtools::install_github("topepo/caret/pkg/caret")
                                                  ^

[[39]]
/Users/jlamb/repos/xgboost/R-package/demo/caret_wrapper.R:16:5: style: Commas should always have a space after.
df[,AgeDiscret:= as.factor(round(Age/10,0))]
    ^

[[40]]
/Users/jlamb/repos/xgboost/R-package/demo/caret_wrapper.R:16:15: style: Put spaces around all infix operators.
df[,AgeDiscret:= as.factor(round(Age/10,0))]
             ~^

[[41]]
/Users/jlamb/repos/xgboost/R-package/demo/caret_wrapper.R:16:37: style: Put spaces around all infix operators.
df[,AgeDiscret:= as.factor(round(Age/10,0))]
                                   ~^~

[[42]]
/Users/jlamb/repos/xgboost/R-package/demo/caret_wrapper.R:16:41: style: Commas should always have a space after.
df[,AgeDiscret:= as.factor(round(Age/10,0))]
                                        ^

[[43]]
/Users/jlamb/repos/xgboost/R-package/demo/caret_wrapper.R:19:5: style: Commas should always have a space after.
df[,AgeCat:= as.factor(ifelse(Age > 30, "Old", "Young"))]
    ^

[[44]]
/Users/jlamb/repos/xgboost/R-package/demo/caret_wrapper.R:19:11: style: Put spaces around all infix operators.
df[,AgeCat:= as.factor(ifelse(Age > 30, "Old", "Young"))]
         ~^

[[45]]
/Users/jlamb/repos/xgboost/R-package/demo/caret_wrapper.R:22:5: style: Commas should always have a space after.
df[,ID:=NULL]
    ^

[[46]]
/Users/jlamb/repos/xgboost/R-package/demo/caret_wrapper.R:22:7: style: Put spaces around all infix operators.
df[,ID:=NULL]
     ~^~~

[[47]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:9:66: style: Trailing whitespace is superfluous.
# Sometimes the dataset we have to work on have categorical data.
                                                                 ^

[[48]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:12:47: style: Trailing whitespace is superfluous.
# In R, categorical variable is called Factor.
                                              ^

[[49]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:35:5: style: Commas should always have a space after.
df[,AgeDiscret:= as.factor(round(Age/10,0))]
    ^

[[50]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:35:15: style: Put spaces around all infix operators.
df[,AgeDiscret:= as.factor(round(Age/10,0))]
             ~^

[[51]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:35:37: style: Put spaces around all infix operators.
df[,AgeDiscret:= as.factor(round(Age/10,0))]
                                   ~^~

[[52]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:35:41: style: Commas should always have a space after.
df[,AgeDiscret:= as.factor(round(Age/10,0))]
                                        ^

[[53]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:38:5: style: Commas should always have a space after.
df[,AgeCat:= as.factor(ifelse(Age > 30, "Old", "Young"))]
    ^

[[54]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:38:11: style: Put spaces around all infix operators.
df[,AgeCat:= as.factor(ifelse(Age > 30, "Old", "Young"))]
         ~^

[[55]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:41:5: style: Commas should always have a space after.
df[,ID:=NULL]
    ^

[[56]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:41:7: style: Put spaces around all infix operators.
df[,ID:=NULL]
     ~^~~

[[57]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:45:18: style: Commas should always have a space after.
print(levels(df[,Treatment]))
                 ^

[[58]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:55:15: style: Use <-, not =, for assignment.
sparse_matrix = sparse.model.matrix(Improved~.-1, data = df)
              ^

[[59]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:55:47: style: Put spaces around all infix operators.
sparse_matrix = sparse.model.matrix(Improved~.-1, data = df)
                                             ~^~

[[60]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:61:48: style: Trailing whitespace is superfluous.
# 1. Set, for all rows, field in Y column to 0;
                                               ^

[[61]]
/Users/jlamb/repos/xgboost/R-package/demo/create_sparse_matrix.R:62:41: style: Trailing whitespace is superfluous.
# 2.
I think it would make sense for me to do that and only include the linters that can impact code correctness (like T_and_F_symbol_linter), and leave it to maintainers to do the ones that will touch a lot more lines for style things like commas, whitespace, etc.

@jameslamb Thanks!  That would be great.  You don't have to address linting error on the PR, we can follow up by pushing to your branch or open another PR.

I opened a PR for fixing existing linting rules: https://github.com/dmlc/xgboost/pull/5911

oh nice!

#5911 added lintr in CI.

A better script is still needed.  Currently I think on github action it shows only you have errors, but not line number.

@trivialfis I actually noticed this too. I wonder if running lintr in Ubuntu would fix the issue.

I think we need to call lint package explicitly.

Sure, let me prepare a pull request. I'd like to see clear lintr warnings without having to run it manually.

it seems that the R linters are not running in CI right now. This is from the most recent build on master (https://github.com/dmlc/xgboost/runs/948472542):

I wanted to try fixing some issues found by other linters tonight. Without adding any new linters, I ran this
cd R-package
Rscript tests/run_lint.R

A lot of linting issues were found, and echo $? returns 1

@jameslamb It looks like GitHub Actions job timed out. I restarted the test. As for the issues, make sure to install XGBoost R package first by running R CMD INSTALL .. Otherwise you will see some bogus issue because R linter won't recognize symbols from XGBoost.

ohhhhh I see! I should have looked at the GitHub Actions config, I see that now. Thank you


Is it possible to use cretonne to create a sandboxed plugin system?

client code (rust) -> MIR -> wasm?
will generated binary code can call FFI functions (from hosted process, no link needed)?

It possible, but non-trivial. It will be possible to call FFI functions.
Cretonne is only the code generator. It doesn't provide a sandbox or VM environment, and it doesn't help you figure out how to share memory between your sandbox and main application.


Consider using lifecycle for Policy Set Definition updates

Issue
Prerequisites

[x] I am running the latest version
[x] I checked the documentation and found no answer
[x] I checked to make sure that this issue has not already been filed

Context
When updating Policy Set Definitions I often have problems like:
│ Error: updating Policy Set Definition "corp_monitoring": policy.SetDefinitionsClient#CreateOrUpdateAtManagementGroup: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidPolicySetParameterUpdate" Message="The existing policy has '68' parameter(s) which is greater than the count of parameter(s) '3' in the policy being added. Policy parameters cannot be removed during policy update."

│ Error: updating Policy Set Definition "corp_monitoring": policy.SetDefinitionsClient#CreateOrUpdateAtManagementGroup: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidPolicySetParameterUpdate" Message="The existing policy set parameter(s) 'logsEnabled' type is being updated which is not allowed."

Error: updating Policy Set Definition "corp_monitoring_diagnostic_settings": policy.SetDefinitionsClient#CreateOrUpdateAtManagementGroup: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidPolicySetParameterUpdate" Message="The policy contains new parameter(s) 'rgName,storagePrefix' which are not present in the existing policy and have no default value. New parameters may be added to a policy only if they have a default value."

Expected Behavior
If update of the Policy Set Definition is not possible, it should be replaced.
Current Behavior
Errors mentioned above.
Possible Solution
Consider adding replace_triggered_by lifecycle meta-argument to module:
https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle?optInFrom=terraform-io#replace_triggered_by
The only hesitation I have is that maybe this should be solved on azurerm provider level.

Unfortunately, the lifecycle meta-argument is not supported for modules yet. There is a feature request open for it, but who knows when that will be implemented...

@toby-p9 totally right, no lifecycle in modules
@gettek I also considered replace/taint, using it in pipeline is not very convenient though, so I choose the change then name of the initiative to recreate it as workaround if needed.
Good hint about defaultValue when I have a choice. Usually I use builtin policies and there it's not possible.
Thanks for the good work!

@toby-p9
Ran some tests using the time_rotating resource and the following functionality will help when adding/removing parameters, however maybe you can tweak to trigger a replacement when updating parameter names or their metadata...
modules/initiative/main.tf
resource azurerm_policy_set_definition set {
#...
  lifecycle {
    replace_triggered_by = [
      time_rotating.tst.rotation_rfc3339
    ]
  }
}

resource "time_rotating" "tst" {
  rotation_years = length(local.parameters)
}

@gettek
Interesting hack, I will try this, thanks.


High CPU usage

After a while of running I'm seeing incredibly high CPU usage from trayscale.  This is on Fedora 37 using the latest flatpak, 0.9.7.
    PID USER      PR  NI    VIRT    RES  %CPU  %MEM     TIME+ S COMMAND
1045194 jonathan  20   0 3994.4m  34.2m 194.0   0.1   2307:21 S trayscale

It's eating approximately 2 cores of a Ryzen 9 7950x.
According to strace it's not doing very much...
$ strace -p 1045194
strace: Process 1045194 attached
restart_syscall(<... resuming interrupted read ...>

) = 1
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="U\2\203\334v\374$]\3\21\1\0\20\0\0\0\0\0\0\21\21\21\21\21\0\0\3\37>\2\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=14, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=14, revents=POLLOUT}])
writev(14, [{iov_base="\203-\2\0\0\0\0\0", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
poll([{fd=14, events=POLLIN}], 1, -1)   = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1-\204\334\0\0\0\0\1\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=14, events=POLLIN}], 2, -1) = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="U\2\204\334\16\375$]\3\20\0\0\20\0\0\0\0\0\0\20\20\20\20\20\0\0\3\37>\3\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=14, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=14, revents=POLLOUT}])
writev(14, [{iov_base="\203-\2\0\0\0\0\0", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
poll([{fd=14, events=POLLIN}], 1, -1)   = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1-\205\334\0\0\0\0\1\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=14, events=POLLIN}], 2, -1) = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="U\2\205\334~\23%]\3\21\1\0\20\0\0\0\0\0\0\21\21\21\21\21\0\0\3\0372\2\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=14, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=14, revents=POLLOUT}])
writev(14, [{iov_base="\203-\2\0\0\0\0\0", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
poll([{fd=14, events=POLLIN}], 1, -1)   = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1-\206\334\0\0\0\0\1\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=14, events=POLLIN}], 2, -1) = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="U\2\206\334\356\24%]\3\20\0\0\20\0\0\0\0\0\0\20\20\20\20\20\0\0\3\0372\3\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=14, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=14, revents=POLLOUT}])
writev(14, [{iov_base="\203-\2\0\0\0\0\0", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
poll([{fd=14, events=POLLIN}], 1, -1)   = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1-\207\334\0\0\0\0\1\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=14, events=POLLIN}], 2, -1) = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="U\2\207\334\226\30%]\3\21\1\0\20\0\0\0\0\0\0\21\21\21\21\21\0\0\3\0372\2\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=14, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=14, revents=POLLOUT}])
writev(14, [{iov_base="\203-\2\0\0\0\0\0", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
poll([{fd=14, events=POLLIN}], 1, -1)   = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1-\210\334\0\0\0\0\1\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=14, events=POLLIN}], 2, -1) = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="U\2\210\334\216\31%]\3\20\0\0\20\0\0\0\0\0\0\20\20\20\20\20\0\0\3\0372\3\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=14, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=14, revents=POLLOUT}])
writev(14, [{iov_base="\203-\2\0\0\0\0\0", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
poll([{fd=14, events=POLLIN}], 1, -1)   = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1-\211\334\0\0\0\0\1\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=14, events=POLLIN}], 2, -1) = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="U\2\211\334\3675%]\3\24\4\0\20\0\0\0\0\0\0\24\24\24\24\24\0\0\3\37%\2\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=14, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=14, revents=POLLOUT}])
writev(14, [{iov_base="\203-\2\0\0\0\0\0", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
poll([{fd=14, events=POLLIN}], 1, -1)   = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1-\212\334\0\0\0\0\1\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=14, events=POLLIN}], 2, -1^Cstrace: Process 1045194 detached
 <detached ...>

I know this is a bit vague but I'm not sure what else to provide.

Strange. I'll see if I can replicate it on my machine.

I can not replicate it. Even when I'm actually actively using the app, the CPU usage never reaches even 1% for me on either my 12 core desktop or my 4 core laptop. Is there any other information that you can provide? How long is 'a while'?

I can not replicate it. Even when I'm actually actively using the app, the CPU usage never reaches even 1% for me on either my 12 core desktop or even my 4 core laptop. Is there any other information that you can provide? How long is 'a while'?

I tend to notice it after a couple of days.  I can recreate it on 2 machines consistently so far.  The Ryzen 7950x I mentioned earlier where I tend to not notice because what's 2 cores out of 32...
But my laptop does it was well, also Fedora 37 using latest Flatpak.  It causes the fans to ramp up so I tend to notice it quicker there.

Hmmm... I haven't tried running it continuously for more than a day. I rarely leave my computers running overnight at all, actually. I'll see what I can do.

Still able to recreate it on Fedora 37.

Out of curiosity, have you tried to disconnect from the server (while keeping the application open) while this is happening, and if so, does the CPU usage persist?

@jonathanspw
Not yet. I'm trying to find a good few days to leave my computer running. It's very much outside of my normal workflow, but I may have some days that'll work coming up.
@codyro
If you're talking about disconnecting the Tailscale daemon from the tailnet, that probably won't help, unless the problem is happening with the connection between Trayscale and the daemon. The daemon is a completely separate process that isn't even started by Trayscale, so high CPU usage on its side won't show up as high CPU usage by Trayscale.

I left Trayscale running continuously for over 60 hours. This is the result:

The memory usage is quite high, possibly related to a number of potential memory leaks that I've been trying to track down for a bit now, but the CPU usage is completely normal. I'm not sure why you're seeing abnormal CPU usage. When you left it running, was the window displayed most or all of the time, or was it hidden with just the tray icon visible?


Add access to interpolation fraction for fixed timestep interpolation

Addresses #30068
This is a prerequisite for allowing proper support for fixed timestep interpolation, exposing the interpolation fraction to the engine, modules and gdscript.
The interpolation fraction is the fraction through the current physics tick at the time of the current frame.
Note: I hope I have the format correct for putting the function in the docs, I haven't done this before.

All changes requested have been done, I've also run the doctool and moved the help xml item into alphabetical order. Should be good to go now.
Just to make clear it shouldn't affect any engine functionality, just exposes an extra variable. Smoothing nodes are nearly ready for testing as a module (both 3d and 2d versions) once this is merged.

Thanks!


Usage question

as a consumer, can you highlight the minimum config that needs to provided while running moxy?
I saw the sample as "mockWorker" but not very clear intuitively what is needed in order to mock service APIs
#question #ducumentationRequest

PR #4  address both usage and minimum requirement asks in README