Exceptions starting notebooks x 163 REGRESSION?

When running the configuration & start notebooks exceptions similar to the following are seen
lization
Thu Jan 02 09:51:18 GMT 2020 cocoMDS5 Information OMRS-AUDIT-0106 Refreshing registration with open metadata repository cohort cocoCohort using metadata collection id 4d82b40a-c516-405c-b8ab-4cf0da9487e0 at the request of server cocoMDS3
Thu Jan 02 09:51:18 GMT 2020 cocoMDS3 Security OPEN-METADATA-SECURITY-0015 User cocoMDS3npa is not authorized to change open metadata type EmbeddedConnection (eb6dfdd2-8c6f-4f0d-a17d-f6ce4799f64f) on server cocoMDS3
Thu Jan 02 09:51:18 GMT 2020 cocoMDS3 Exception OMRS-AUDIT-9019 The type definition event processor for the cocoCohort cohort inbound service caught an unexpected exception org.odpi.openmetadata.repositoryservices.ffdc.exception.UserNotAuthorizedException with message OMAG-PLATFORM-SECURITY-403-011 User cocoMDS3npa is not authorized to change open metadata type EmbeddedConnection (eb6dfdd2-8c6f-4f0d-a17d-f6ce4799f64f) on server cocoMDS3
Thu Jan 02 09:51:18 GMT 2020 cocoMDS3 Exception OMRS-AUDIT-9019 a19b1d5a-6536-44fd-a3f1-a16f569e1ebd org.odpi.openmetadata.repositoryservices.ffdc.exception.UserNotAuthorizedException returned message of OMAG-PLATFORM-SECURITY-403-011 User cocoMDS3npa is not authorized to change open metadata type EmbeddedConnection (eb6dfdd2-8c6f-4f0d-a17d-f6ce4799f64f) on server cocoMDS3 and stacktrace of
UserNotAuthorizedException{userId='cocoMDS3npa', reportedHTTPCode=403, reportingClassName='org.odpi.openmetadata.metadatasecurity.samples.CocoPharmaServerSecurityConnector', reportingActionDescription='validateUserForTypeUpdate', errorMessage='OMAG-PLATFORM-SECURITY-403-011 User cocoMDS3npa is not authorized to change open metadata type EmbeddedConnection (eb6dfdd2-8c6f-4f0d-a17d-f6ce4799f64f) on server cocoMDS3', reportedSystemAction='The system is unable to process a request from the user because they do not have access to the necessary services and/or resources.', reportedUserAction='The request fails with a UserNotAuthorizedException exception.', reportedCaughtException=UserNotAuthorizedException{userId='cocoMDS3npa', reportedHTTPCode=403, reportingClassName='org.odpi.openmetadata.metadatasecurity.samples.CocoPharmaServerSecurityConnector', reportingActionDescription='validateUserForTypeUpdate', errorMessage='OMAG-PLATFORM-SECURITY-403-011 User cocoMDS3npa is not authorized to change open metadata type EmbeddedConnection (eb6dfdd2-8c6f-4f0d-a17d-f6ce4799f64f) on server cocoMDS3', reportedSystemAction='The system is unable to process a request from the user because they do not have access to the necessary services and/or resources.', reportedUserAction='The request fails with a UserNotAuthorizedException exception.', reportedCaughtException=null, relatedProperties=null}, relatedProperties=null}

We have 64 from cocoMDS2npa, 40 from cocoMDS3npa, 32 from cocoMDS5npa & 8 from cocoMDS6npa
All are UserNotAuthorized exceptions. As such this may be expected - the only concern is the additional stack trace information in the audit log is likely confusing for the reader. But additionally this looks like it's more of a versioning/type issue? since it relates to a type update and could be a regression

full log at https://gist.github.com/bd6ec676719de74a9eba04e429310076

There are also 2 null pointer exceptions
Thu Jan 02 09:51:34 GMT 2020 cocoMDS4 Information OMRS-AUDIT-0050 The Open Metadata Repository Services (OMRS) is about to process open metadata archive Open Metadata Types
Thu Jan 02 09:51:34 GMT 2020 cocoMDS4 Exception OMRS-AUDIT-9019 The type definition event processor for the ODPi Egeria (1.3) service caught an unexpected exception java.lang.NullPointerException with message null
Thu Jan 02 09:51:34 GMT 2020 cocoMDS4 Exception OMRS-AUDIT-9019 1e243409-55ee-470f-a09c-c27a0e75c9f3 java.lang.NullPointerException returned message of null and stacktrace of
java.lang.NullPointerException
        at org.odpi.openmetadata.repositoryservices.localrepository.repositorycontentmanager.OMRSRepositoryContentManager.processUpdatedTypeDefEvent(OMRSRepositoryContentManager.java:2646)
        at org.odpi.openmetadata.repositoryservices.archivemanager.OMRSArchiveManager.processTypeDefStore(OMRSArchiveManager.java:345)
        at org.odpi.openmetadata.repositoryservices.archivemanager.OMRSArchiveManager.processOpenMetadataArchive(OMRSArchiveManager.java:226)
        at org.odpi.openmetadata.repositoryservices.archivemanager.OMRSArchiveManager.processOpenMetadataTypes(OMRSArchiveManager.java:139)
        at org.odpi.openmetadata.repositoryservices.archivemanager.OMRSArchiveManager.setLocalRepository(OMRSArchiveManager.java:102)
        at org.odpi.openmetadata.repositoryservices.admin.OMRSOperationalServices.initialize(OMRSOperationalServices.java:419)
        at org.odpi.openmetadata.adminservices.OMAGServerOperationalServices.activateWithSuppliedConfig(OMAGServerOperationalServices.java:328)
        at org.odpi.openmetadata.adminservices.OMAGServerOperationalServices.activateWithStoredConfig(OMAGServerOperationalServices.java:149)
        at org.odpi.openmetadata.adminservices.spring.OperationalServicesResource.activateWithStoredConfig(OperationalServicesResource.java:41)

Thu Jan 02 09:51:34 GMT 2020 cocoMDS4 Exception OMRS-AUDIT-9019 The type definition event processor for the ODPi Egeria (1.3) service caught an unexpected exception java.lang.NullPointerException with message null
Thu Jan 02 09:51:34 GMT 2020 cocoMDS4 Exception OMRS-AUDIT-9019 1ee072d2-e3ba-4cc0-b327-1a2fc43bd5fa java.lang.NullPointerException returned message of null and stacktrace of
java.lang.NullPointerException
        at org.odpi.openmetadata.repositoryservices.localrepository.repositorycontentmanager.OMRSRepositoryContentManager.processUpdatedTypeDefEvent(OMRSRepositoryContentManager.java:2646)
        at org.odpi.openmetadata.repositoryservices.archivemanager.OMRSArchiveManager.processTypeDefStore(OMRSArchiveManager.java:345)
        at org.odpi.openmetadata.repositoryservices.archivemanager.OMRSArchiveManager.processOpenMetadataArchive(OMRSArchiveManager.java:226)
        at org.odpi.openmetadata.repositoryservices.archivemanager.OMRSArchiveManager.processOpenMetadataTypes(OMRSArchiveManager.java:139)
        at org.odpi.openmetadata.repositoryservices.archivemanager.OMRSArchiveManager.setLocalRepository(OMRSArchiveManager.java:102)
        at org.odpi.openmetadata.repositoryservices.admin.OMRSOperationalServices.initialize(OMRSOperationalServices.java:419)
        at org.odpi.openmetadata.adminservices.OMAGServerOperationalServices.activateWithSuppliedConfig(OMAGServerOperationalServices.java:328)
        at org.odpi.openmetadata.adminservices.OMAGServerOperationalServices.activateWithStoredConfig(OMAGServerOperationalServices.java:149)
        at org.odpi.openmetadata.adminservices.spring.OperationalServicesResource.activateWithStoredConfig(OperationalServicesResource.java:41)

May be related to #2326

It looks like thes are 3 different issues.  The NotAuth is due to the OpenMetadataSecurity sample not allowing the servers to change types.  I have changed the updateTypeDef authorization check to be the same as the newTypeDef authorization check so that the metadata architects and the metadata servers can change types.
We also discussed whether it is appropriate for this type of error to push the stack trace to the console and agreed it should not.   So I have also changed the logging of architected checked exceptions - which typically include a reasonable message - to log as an error rather than exception.
The NPE is a bug in the event processor code that occurs when there is no local repository.  I have changed the update typedef logic to handle no local repository connector.  We only see this in cocoMDS4 because all of the other servers have a local repository.
Finally we talked about these error coming out in the console

This is also a bug.  The code to cache a type is checking the new type does not have a different version number to any existing version stored - this is clearly not true in the case of a patch, so the code logs that the versions are different.  There is no need to do this validation check as the type have been validated already (if Egeria has got this far with an invalid type def then we have bigger problems :)

checked - fixed (albeit other issues we need to resolve for 1.3)


build: fix x86_64 asm detection for some compilers

I'm not familiar enough with this asm syntax, there's probably a much simpler solution here, just switching to a test that doesn't need escaping.
I Noticed this on OSX with clang, though it likely happens elsewhere as well.
The result is disabled x86_64 asm.
Due to missing escaping, this $0 was interpreted as the function name
SECP_64BIT_ASM_CHECK, causing the compile-check to be broken on some compilers.
The actual check looked like this:
int main()
{
  uint64_t a = 11, tmp;
  __asm__ __volatile__("movq SECP_64BIT_ASM_CHECKx100000000,%1; mulq %%rsi" : "+a"(a) : "S"(tmp) : "cc", "%rdx");
  return 0;
}

It seems even more odd that it compiled anywhere.

I just double-checked this to see if i needed to push for urgent merge here for Bitcoin 0.12rc1.
For reference, this does not affect the clang version currently used for Bitcoin OSX release builds. So no rush.


Add SVG asciicast

This replaces the terminal screenhot in README.md with an asciinema session rendered to an animated SVG.

Gives an impression of the onboarding flow
Good quality (vector graphics)
Smaller than equivalent GIF (64kb, 6kb gzipped)
Uses rawgit to avoid issues with GitHub stripping CSS from SVG

@marionebl Can you explain how to do this sorcery? Would be a nice post to share. Thanks!


idea: use syscall exec on linux or mac ?

What do you think about adding exec syscall for linux and mac, which allows users or linux distributions to directly softlink zvm, and maybe we can try to adjust zvm's config dir to compile-time settings?

Yeah that sounds great 👍

ok, I will try to implement it

What do you think about introducing external packages? I think the current command line parsing part is not complete. It would be better to introduce an external command line parsing package.

If it is completely implemented internally, it would be a waste to reinvent the wheel.

Why would we need an external package for that? Which feature do we need?

Some of the features implemented so far are indeed sufficient, but I think it is not  elegant.


Prepare skeleton to use ZF v3 releases by default

For the next minor release (1.4), we'll be using ZF v3 components by default. This patch does the followign:

Sets the minimum supported PHP version to 5.6.
Removes the zendframework/zendframework dependency entirely; zf-apigility and others bring in zend-mvc already, which gives us the MVC foundation necessary.
Adds zendframework/zend-component-installer as a requirement.
Adds zfcampus/zf-asset-manager as a development requirement.
Removes zendframework/zftool as a development requirement.
Updates all Apigility requirements, both production and development, to their latest stable versions.
Adds Composer scripts for:

enabling development mode (composer development-enable)
disabling development mode (composer development-disable)
reporting development mode status (composer development-status)

This has been tested quite a bit along with the zf-apigility-admin 1.5.0 release, but likely needs more testers. In particular, I'm curious what the "install" experience is like, and whether or not people are getting endless requests to update their module configuration, or if it "just installs".

Not sure what kind of "install experience" feed back you're looking for but I can confirm that the basic installation worked like a charm:

Download the develop branch via zipball.
Unzip.
Install dependencies with Composer composer.phar install.
Put the skeleton in development mode php public/index.php development enable.
Start the built-in web server php -S <IP_ADDRESS>:8080 -ddisplay_errors=0 -t public public/index.php.
Create new API and new Service then modify and delete.
Everything went smooth.

same here

use the code as zip
composer install
composer development-enable
composer serve

it's working!

For those interested in testing composer create-project, you can do the following:

Create a file named packages.json with the following contents:

{
    "packages": {
        "zfcampus/zf-apigility-skeleton": {
            "1.4.0": {
                "name": "zfcampus/zf-apigility-skeleton",
                "version": "1.4.0",
                "source": {
                    "url": "https://github.com/weierophinney/zf-apigility-skeleton.git",
                    "type": "git",
                    "reference": "35d47b3fec8af8df8c55273caaf0d82fcbe92eb7"
                }
            }
        }
    }
}

Run create-project, referencing the above as a repository:

$ composer create-project --repository=packages.json zfcampus/zf-apigility-skeleton apigility 1.4.0

This will create a new project in the directory apigility/.

Descend into the project:

$ cd apigility

Put it into development mode:

$ composer development-enable

Test it:

$ composer serve

and visit http://localhost:8080/
I've done this locally, and found installation "just worked". Assets were correctly copied into the application, the installer did not prompt me to add modules, and the UI worked correctly.
Please let me know if you have any issues!

@lrochas —

Put the skeleton in development mode php public/index.php development enable.

That worked? It shouldn't! With zf-development-mode v3, it should be one of:

composer development-enable
./vendor/bin/zf-development-mode enable

I'm thinking you may have tested the develop branch, and not my branch specifically. Try the example I noted above, or:
$ git clone https://github.com/weierophinney/zf-apigility-skeleton.git
$ cd zf-apigility-skeleton
$ git checkout -b feature/zf-v3-readiness origin/feature/zf-v3-readiness
$ composer install
$ composer development-enable

@webimpress — thanks for the detailed feedback; I've just pushed changes that should address each item you raised.

For those of you testing via create-project, please note that I've updated the comment now to reflect the most recent sha1 pushed; update your packages.json to test against it! :smile:

@weierophinney — right, first test was done with the develop branch. Did test with your branch twice (by cloning and by creating project with packages.json) and it works fine.

Le 10 août 2016 à 15:32, weierophinney<EMAIL_ADDRESS>a écrit :
@lrochas https://github.com/lrochas —
Put the skeleton in development mode php public/index.php development enable.
That worked? It shouldn't! With zf-development-mode v3, it should be one of:
composer development-enable
./vendor/bin/zf-development-mode enable
I'm thinking you may have tested the develop branch, and not my branch specifically. Try the example I noted above, or:
$ git clone https://github.com/weierophinney/zf-apigility-skeleton.git
$ cd zf-apigility-skeleton
$ git checkout -b feature/zf-v3-readiness origin/feature/zf-v3-readiness
$ composer install
$ composer development-enable
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/zfcampus/zf-apigility-skeleton/pull/130#issuecomment-238867405, or mute the thread https://github.com/notifications/unsubscribe-auth/AFHVgusZmAa3vWVNtu90LFbaC8B6FKyRks5qedMLgaJpZM4JgmeJ.

Before I merge, there's one last thing nagging at me: the admin UI's "About" tab has a hard-coded version constant, which is problematic.
My plan is to do the following:

Introduce a constant in the skeleton, either as an global constant or a class constant, which will contain the skeleton version. We will bump this for tagged versions, and append "dev" to the value for active master/develop branches.
Add an API endpoint to zf-apigility-admin that will look for this constant and return the value; if the constant is not found, it will return the value @dev.
Update the "about" controller in the UI to query this API endpoint in order to determine the version. If unable to query the endpoint (e.g., it returns a 404), it will return the value @dev.

This will require new releases of zf-apigility-admin and zf-apigility-admin-ui before we can merge this PR.

Version reporting is now working! Last calls for testing!

@weierophinney LICENSE.txt should be converted to .md file with year update.

Besides the instructions noted above for using create-project, you can also, once the project is created, use either docker-compose or vagrant:
# docker-compose:
$ docker-compose build # only needed the first time
$ docker-compose up
# vagrant:
$ vagrant up

Please note that the vagrant image is ubuntu/xenial64; if you are using VirtualBox, you will need vagrant 1.8.5 or higher, and VirtualBox 5.0.26 or higher.


show help topic menu when there is more than one help topic

The help topic panel provides a dropdown menu to switch between topics that are currently available. However if there is only a single topic available, this menu is of no use.
This change removes the menu unless there are 2 or more help topics.
Before:

After:

fyi @Hyperkid123

cc @CooperRedhat @jschuler

@jschuler what's the process to get a new release out?

@christianvogt we've been trying to align our extensions releases to PatternFly, but I think we could probably do a release of QuickStarts soon to include some of these more recent changes.


2024-12-11_01-36-07_master-next_aws-cli

Automatically created.

Backport failed for kirkstone-next, because it was unable to cherry-pick the commit(s).
Please cherry-pick the changes locally and resolve any conflicts.
git fetch origin kirkstone-next
git worktree add -d .worktree/backport-10719-to-kirkstone-next origin/kirkstone-next
cd .worktree/backport-10719-to-kirkstone-next
git switch --create backport-10719-to-kirkstone-next
git cherry-pick -x c0cc0984664c42e33418d00eff0af367ca500fdc

Successfully created backport PR for scarthgap-next:

#10720

Successfully created backport PR for styhead-next:

#10721


mariadb-client 3.0.5 errors

Trying to update mariadb-client to 3.0.5 but it doesn't build. I see errors like:
    35>LINK : fatal error LNK1104: cannot open file '..\mytap\Debug\cctap.lib' [C:\VC\vcpkg\buildtrees\libmariadb\x86-windows-dbg\unittest\libmariadb\view.vcxproj]
    35>Done Building Project "C:\VC\vcpkg\buildtrees\libmariadb\x86-windows-dbg\unittest\libmariadb\view.vcxproj" (default targets) -- FAILED.

Could be an upstream error.
install-x86-windows-dbg-out.txt

Related: #6562.

PR has been merged, so I close it.


Setting Fallback Paywalls is not working

Fallback Paywalls are not showing if there is no internet connection.
I tried to set fallback paywall after activating adapty and before view.present();, both didn't work.
        let fallback_paywalls;
        if (Platform.OS === "ios") {
          fallback_paywalls = require("./ios_fallback.json");
        } else {
          fallback_paywalls = require("./android_fallback.json");
        }
        const fallbackString = JSON.stringify(fallback_paywalls);
        adapty.setFallbackPaywalls(fallbackString).catch(recordAndLogError);

hi @hasanfd! For now, fallback paywalls contain only paywall data, without a visual representation


New dataset

Hi, thank you for your work! I am interested in trying this, is it possible to run on a new dataset? How to formalize it? Thank you

Hi
Thanks for your interest!
To evaluate the method on a new few-shot benchmark, you first need to have a base model which is trained on your desired set of base classes. To obtain such a base model, please refer to the Training section of the readme.
After that, you can use the newly trained model and apply our evaluation scripts on it.

Thank you!
Could you please give more details about the coco annotation, which can be generated by executing the python script data/coco/create_masks.py ( this script uses the pycocotools package):
cd data/coco python create_masks.py
Well, where is this create_masks.py?

If you are asking about where the script file is located, well obviously, it is under data folder in the coco subfolder, here.
The script is borrowed from the RePRI repo, maybe you can find more detail about it there.


Where is the picture to show?

Hello, I can run the basic_scatterplotting.py and basic_plotting_example.py, but where is the picture, it doesn't show. I run pysplit on LINUX

Just making sure you've added, plt.show() ?

PySPLIT here in github has a new kwarg (zmapbound) in MapDesign to fix issues with displaying the map, but it has not been pushed to the PySPLIT available on PyPI. I plan to release PySPLIT 0.3.5 on May 31 to PyPi and hopefully conda forge; this will contain the updated MapDesign and should fix this issue.

Hello, I can run the basic_scatterplotting.py and basic_plotting_example.py, but where is the picture, it doesn't show. I run pysplit on LINUX

Hello, @xigrug . Have you fixed your problem? I've also encounter the problem as yours, and I tried the method of plt.show() and it doesn't work. Beside, I'm now on the latest version of Pysplit 0.3.5.


Review sharing does not work

Bug
Review sharing does not work. Gives: /review/undefined on copy.
How To Reproduce

Go to the main page
Click share
Click copy link

Expected behavior
A link for sharing the review, Either with Facebook, X (Twitter) or a valid link to the review is given.
User Specifications
OS: Windows 10
Browser: Chrome Version 131.0.6778.86

Thanks for the issue I am working on that feature rn so it doesn't work ehe


M1 14.6 installed with TrollStore cannot run VMs

Describe the issue
M1 iPad Pro running iPadOS 14.6 installed UTM with TrollStore cannot run VMs,will stuck start boot options forever
Configuration (required)

UTM Version: 4.0.6RC
OS Version: 14.6
Device Model: 5th Gen 12.9 iPad Pro
Is it jailbroken (name jailbreak used)? No
How did you install UTM? TrollStore

Crash log
No
Debug log
debug.log

Should be fixed in v4.0.7

Okay its working now thanks


Enhance dark theme UI

Is your feature request related to a problem? Please describe.
Enhance dark theme UI.
Describe the solution you'd like
NA
Describe alternatives you've considered
NA
Additional context
No response

@wasimreja I would like to work on this.

@wasimreja Please assign this to me


Add support for cocoapods installed through homebrew

When running airfoil new testApp, I am getting an error saying cocoapods must be installed. I ran brew reinstall cocoapods and tried the new command again, but I had the same error again. I uninstalled via homebrew, and I installed cocoapods with the ruby gem instead. This now made it work, but I could see others having cocoapods through homebrew and this causing potential issues.

Thanks for documenting this issue. :) Seems to be an issue with local machine config and not airfoil specifically. Closing since it there is a solid workaround in place.


feat: ACNA-1650 - Template Registry Api integration

Description
This connects with the Template Registry API so we can bootstrap App Builder apps with pre-defined templates available in the registry, and not with pre-packaged templates.
Note: this has been tested with the pre-release cli at @adobe/aio-cli-next (aio-next executable)
Features changed:

aio app init

be aware of this multiple flag oclif bug if you use --template or --extension. The appname argument must be before those flags: https://github.com/oclif/core/issues/496

aio app add extension
aio app add action

right now there is a generic filtering of categories: we need to refine the categories for this search

aio app add web-assets

right now there is a generic filtering of categories: we need to refine the categories for this search

aio app delete extension

How Has This Been Tested?

aio plugins link .
aio plugins install @adobe/aio-cli-plugin-app-templates
aio app init --help (to see options)
aio app add extension --help
aio app add web-assets --help
aio app delete extension --help

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X] I have signed the Adobe Open Source CLA.
[X] My code follows the code style of this project.
[X] My change requires a change to the documentation.
[X] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.
[X] I have added tests to cover my changes.
[X] All new and existing tests passed.

This looks good, but there is a lot here! I only looked through the code, I did not run it, try it, test it.

The pre-release will get this out in more hands to test. Will merge and get this out.

Open sourced: https://www.npmjs.com/package/@adobe/inquirer-table-checkbox and tested, so I will update the reference in package.json and code

Note: we still have this special-case for the dx/excshell/1 extension that could not be resolved: https://github.com/adobe/aio-cli-plugin-app/blob/35dd448c5a12f7a189a0243467f2db38c0d483dc/src/commands/app/deploy.js#L250-L253
It is expected that cli plugin hooks (upcoming feature) will help with this.


Fixed logic for which Razor scaffolder gets invoked.

When generating all pages, the templateName is "All". Initial code had danticipated it being null.

@seancpeters,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot


Sort and fix Spectra NetKAN Provides/conflicts/depends/suggests/rec

I updated Spectra used this time to fix its NetKAN. I moved minor mods from Recommends to Suggests (added suggests), removed PlanetShine-config from Provides (No longer providing), removed GreenSkullRevived and PlanetShine-config from Conflicts (no longer conflicting), and removed Scatterer-sunflare-default from Depends (no longer depends).
I hope this looks in order, the file did not have suggests before this change, I added it from scratch based on the NetKAN of other mods. The goal is for all the mods in "recommends" to be auto-ticked when you install, and the mods in "suggests" to not.
I also reworked x_netkan_override. This might be set up incorrectly, though it doesn't matter as much as the rest. The current release of Spectra (1.3) is backwards compatible all the way to KSP version 1.3. Is this set up correctly?

For the version compatibility, would you be interested in adding a KSP-AVC .version file to this mod? Netkan (and KSP-AVC) can parse these to get the compatibility info automatically per-version, which tends to be more maintainable than tracking it in netkan overrides. If that sounds appealing we can help with figuring out the details.

Checking the latest download, there's still a dependency on Scatterer-sunflare-default in GameData/Spectra/Spectra_scatterer/Sunflares/Phi/Sun.cg:
@Scatterer_sunflare:AFTER[scatterer]
{

Hey! If that's a cleaner solution, that's alright with me. I'm even less familiar with KSP-AVC than than CKAN, though. I recall LinuxGuruGamer's toolbar controller/click-through-blocker removing all AVC, too I think. In honesty it might be easier to just remove the compatibility flag in total.
Sent from Outlook Mobile
On Tue, May 12, 2020 at 12:24 PM -0700, "HebaruSan"<EMAIL_ADDRESS>wrote:
Checking the latest download, there's still a dependency on Scatterer-sunflare-default in GameData/Spectra/Spectra_scatterer/Sunflares/Phi/Sun.cg:
@Scatterer_sunflare:AFTER[scatterer]
{
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

It looks incompatible but it should work fine. It requires the default Sunflare to be installed and usesmodulemanager to overwrite it. The Sunflare doesn't work unlesst the default Sunflare isalso installed, same with base Scatterer.
Sent from Outlook Mobile
On Tue, May 12, 2020 at 12:27 PM -0700, "Joe Hafner"<EMAIL_ADDRESS>wrote:
Hey! If that's a cleaner solution, that's alright with me. I'm even less familiar with KSP-AVC than than CKAN, though. I recall LinuxGuruGamer's toolbar controller/click-through-blocker removing all AVC, too I think. In honesty it might be easier to just remove the compatibility flag in total.
Sent from Outlook Mobile
On Tue, May 12, 2020 at 12:24 PM -0700, "HebaruSan"<EMAIL_ADDRESS>wrote:
Checking the latest download, there's still a dependency on Scatterer-sunflare-default in GameData/Spectra/Spectra_scatterer/Sunflares/Phi/Sun.cg:
@Scatterer_sunflare:AFTER[scatterer]
{
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Confirmed that the changes for PlanetShine (the cfg patches the default config) and GreenSkullRevived (no more visor in the TextureReplacer folder) look correct.

The goal is for all the mods in "recommends" to be auto-ticked when you install, and the mods in "suggests" to not.

Yup, that's exactly how those are meant to be used! :+1:

It requires the default Sunflare to be installed and usesmodulemanager to overwrite it. The Sunflare doesn't work unlesst the default Sunflare isalso installed, same with base Scatterer.

Yeah, that's what I was saying, it requires the default Sunflare to be installed, so that dependency should probably stay.

Spectra only technically requires ModuleManager since you don't have to run all of its features if you don't want. You don't have to install Scatterer or ScattererSunflare if you want to run a lighter version.
Sent from Outlook Mobile
On Tue, May 12, 2020 at 12:37 PM -0700, "HebaruSan"<EMAIL_ADDRESS>wrote:
It requires the default Sunflare to be installed and usesmodulemanager to overwrite it. The Sunflare doesn't work unlesst the default Sunflare isalso installed, same with base Scatterer.
Yeah, that's what I was saying, it requires the default Sunflare to be installed, so that dependency should probably stay.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

You don't have to install Scatterer or ScattererSunflare if you want to run a lighter version.

True for Scatterer, but there are reasons for depending on the default sunflare.
There are alternate sunflares available (see #3950 and #6521), and if Spectra doesn't depend on the default sunflare, then the user will be prompted to choose a sunflare when they install Scatterer. If they choose the wrong one, then they would end up with a sunflare that is not compatible with Spectra's sunflare patches. Keeping the depends will ensure that only the right sunflare is installed.

Hm, that does make sense, but if you mark it as requiring scatterer-sunflare, won't that auto-install scatterer too?

I'm even less familiar with KSP-AVC than than CKAN, but recall LinuxGuruGamer's toolbar controller/click-through-blocker requiring zeroAVC, too though that might be unrelated.

That was specifically for MiniAVC, KSP-AVC is closely related but separate (and fortunately unaffected by that issue).

If that's a cleaner solution, that's alright with me, though it might be simpler to just remove it entirely?

OK, here's how a version file would look based on the current metadata:
{
    "NAME":     "Spectra",
    "DOWNLOAD": "https://spacedock.info/mod/1505/Spectra/download/1.3",
    "URL":      "<SEE NOTE BELOW>",
    "VERSION": {
        "MAJOR": 1,
        "MINOR": 3
    },
    "KSP_VERSION_MIN": {
        "MAJOR": 1,
        "MINOR": 3
    },
    "KSP_VERSION_MAX": {
        "MAJOR": 1,
        "MINOR": 9
    }
}

If you save that in a file called Spectra.version, include it the download, and update it when there's a new release, we can set up Netkan to pull the info automatically, no override pull request required.
The "URL" property is special. If you store a copy of the version file online somewhere and save its URL in the "URL" property, then any changes that you make to it can also apply to existing downloads without changing them. For example, if you someday discover that Spectra 1.3 works on KSP 1.10, just updating the online version file would make that change in CKAN (and KSP-AVC) as well. (This is also how KSP-AVC alerts the user to available upates.) Most mod authors use GitHub to host these files, although some use http://ksp-avc.cybutek.net/ (the workings of which I do not personally understand).

Nice! Yeah, I'll definitely do that. Its good to know that this is unrelated to MiniAVC too. I'm getting some things setup and I'll probably have another small commit soon.

Another strange instance, when I uninstall Scatterer, it seems to uninstall Spectra as well because of the dependency with Scatterer Sunflare. I'm not sure how to fix this yet.

Hmm, I tried installing Spectra with the current recommendations just now and then uninstalling Scatterer, and it didn't do that:
$ ckan.exe remove scatterer
About to remove:

 * scatterer 3:v0.0610
 * Scatterer Default Config 3:v0.0610

Continue? [Y/n]

Is it possible you also selected to uninstall the sunflare?

That was the culprit, many thanks. Should I close this and start a new commit, or revert the Scatterer Sunflare changes here?

I'd say it's better to keep one pull request alive and update it until everything is in order.

Looks pretty good now; I'll merge it to master, and if you need any further changes just let us know.


Searching quadrillium crashes the game

Issue with the current fabric release for 1.19.2 with the mod
crash-2022-10-07_12.47.52-client.txt

I believe that this is a incompatability with Facility.
Facility includes Frex, a library that Canvas uses for rendering.
Mythic Metals includes Canvas support when using the Lumi Lights shaderpack, but it seems that it is unconditionally loading, causing a crash if it is not present.
Will look further into the issue.

Yeah, going over it the Lumi Lights compatability is severely out of date.
It breaks if FREX is present and you are not using Canvas + Lumi Lights.
I might make a resource pack or something for this at a later date, but for now I am just going to remove it from the mod.


Remove gray rectangle

Remove the gray rectangle next to the Add a cosignatory button

Fixed in integration branch.


expose peek on IMessageConsumer

Expose the .Peek() method on the MessageConsumer to provide an easy way to interrogate the client (i.e. to validate that it can receive messages correctly)

again, taking @charlyraffellini's approval 👍


Enable editing of preset profile overrides (Draft to be revisited after 1.0 release)

Enable edit of all settings and/or name for already stored profile overrides
Swipe left to edit or delete
Get list of all settings included in the override when saving a new one or editing an existing one

Suggested solution for issue #234

Extra useful when overrides are used with shortcuts (no need to re add changed overrides in shortcuts since id remains unchanged after edit - even if you change name on the override)

NOTE! This is not an attempt to redesign the entire UI. This is just to add edit functionality with minimal changes.
Screenshots

Edit or Delete swipe
Settings summary before saving

Short video demo
https://github.com/nightscout/Trio/assets/72826201/c66fe66d-259c-4dd8-a9a2-d647594d8767

The UI on this really is not intuitive. A swipe action implies that the selected element will be edited and that an action will prompt past the point of action, here the swipe. A user would expect to swipe and tap the edit button and then be forwarded to an editing mask where the data of the preset is prefilled and the you made in the „root“ view are then done.
I like that this gets some love, but also want to urge that we held of on any UI work past 1.0.0, and well, this is UI work.

I'd say it's more UX than UI work to be able to edit stuff. But I totally agree. To make this better the settings and slider should get moved into the popup.
I guess you already have implemented all this in your upcoming UI rework (that I have not seen myself) that will take place after 1.0?
Well. Then we can close both those PRs for just mine and Auggies personal use and wait until the big UI boom after 1.0 solves all outstanding UI/UX-issues. 😊

You are totally right, it’s UX, I just always see UI/UX as a whole. Adding UX usually also involved changing the UI (here introduce a new view and swipe actions).
Also fully agree not being able to delete it at all, yes. If this can be made so that you trigger a subsequent edit mask or the current course of action is more transparent, e.g. Save or select preset to edit?
We haven’t tackled the profiles section with the specific edit functionality you have proposed here, but just moved things and are mostly working on persistence layer.
Can we leave this open as a draft and move the idea of this over once we are at that point? I really want to get something like this in, but we need to make use of design elements and HCI as intended and here the swipe action ought to trigger an edit view view or a subsequent action 😊

Closed for now. To be revisited in the future after 1.0 release.

Thanks Daniel, I’m definitely still using in my personal fork. Not being able to edit overrides/temp targets has been a nightmare for me with, creating an huge amount of toil.

Reopen and put in the "idea box" until after 1.0 release.
Will continue to push a few commits to this feature branch until then. (To move the settings adjustment inside the popup for instance)

Amazing @dsnallfot ! I proposed some changes to be more in editing mode like UX Apple. The idea is to start by choosing "editing" mode, to modify all the value and to save after. I also added a cancel button.
The example is here :

Video
Image

I currently do the update in the PR #219 but depends what the trio's community prefer !

That's a beautiful solution Pierre! Much better than my quick draft.
I knew you were working with overrides, but not this edit things (I actually checked your PR to make sure there wasn't that much conflicts in override state and root.
Very nice!

@avouspierre ‘s way of editing is great and uses the swipe action just like I would expect it to in iOS. Great job!

I think Pierres implementation is more promising (and prettier), but I at least in this draft 2.0 I fixed the backwards workflow by moving the settings inside the edit popup view
Demo
https://github.com/nightscout/Trio/assets/72826201/4d1faab6-5d82-4ae7-9e4f-e0d21e92d62e

I like the latest proposal by you, @dsnallfot , more than the version @avouspierre has proposed.
Pierre's version is equally as nice as yours, as both of you use the swipe action to toggle a subsequent action. However, your version opens a sub-view, pre-populates the values for the various inputs and options, asks the user to change something, then the user saves, view disappears, finished. It's a very nicely guided, "holding the user's hand" type approach.
Pierre's approach loads the preset values into the inputs / options in the root view, making it harder to grasp that "something" has happened or changed.
I must admit, I prefer your option and I'd even go as far as proposing that the view you use to edit a preset should actually also be the view to add a preset and/or start a non-preset profile override.
Either way, both proposals are a huge improvement over what is currently there.

Looks good. Would it be possible to add a confirmation before deleting? It’s pretty easy to accidentally delete when the intention was to edit?

Looks good. Would it be possible to add a confirmation before deleting? It’s pretty easy to accidentally delete when the intention was to edit?

Of course possible, I use it in my personal build. BUT there is an annoying UI glitch with the row disappearing and quickly reappearing when the alert is triggered. I can live with that in a personal build, but not good enough for the official fork.
If we feel that an alert is important to add, I can dig further in this later on (remember that Dan or someone fixed the exact same glitch when deleting in datable (history)
Demo of my glitchy personal implementation as of right now (Sorry for Swedis texth, didn't have my Norwegian version up n running right now)
https://github.com/nightscout/Trio/assets/72826201/682a6aff-1adf-4ef8-90d4-1d148cb25580

Nevermind! Figured it out. Just needed to set the swipebutton to 'role .none' instead of '.destructive'. See new demo.
Do we want this alert?
New glitchfree demo
https://github.com/nightscout/Trio/assets/72826201/1c6954bf-07a4-4a29-b0de-5cdceddce323

And alerts before deletion is now in. I figured its almost a no brainer to include it, and I'm pretty satisfied with this implementation (it shows the profile name you have swiped on for extra clarity when deciding to delete or not)
https://github.com/nightscout/Trio/assets/72826201/0a5ee2c5-4bc5-4682-9ad1-46581348b689

Was just about to comment that the issue is with the default onDelete modifier and can be fixed - but Daniel already figured it out 😅 It looks very similar to how we do it in the DataTable and that works great my
I really like this feature now, great job!

Revisiting this PR today and looking again at my proposal from yesterday (quoted below)

I must admit, I prefer your option and I'd even go as far as proposing that the view you use to edit a preset should actually also be the view to add a preset and/or start a non-preset profile override. So ideally the profile override root view would consist of a big Add or enact button, or a big [+] button, and the preset list. If there are no profiles stored/created yet, the list could show a little hint or simply display "No presets found. Proceed to create preset or enact profile override." This would also shrink the entire root view, getting rid of the scroll view to get to the start / add / cancel buttons. Imho, whenever a user needs to scroll, the view has potential to be refined so that they don't have to (unless it's settings, long text, lots of data displayed etc.)

I think we should make that a second PR. This PR looks very feature-complete (full editability, deletion with alert for consistency with history view) and thus should be tested, approved and merged.
In a subsequent PR we can build on this and make the creation / enactment of a profile along the lines of my proposal - if that is something we want to move forward with. I‘d vote yes (naturally, haha), as it’s an iOS-esque change to creating something and also similar behavior to how basal profiles and other types of "listed data" is created in the app.
Further more, the changes from this PR would also need to be ported over to #236 so that we have consistency there. I do have a second follow-up proposal about profiles and TTs, but let’s discuss that when the time comes 😊🙏

I checkout the code and test the new functionalities. All functions "add,edit, delete" preset profile are OK.
Some improvements for maintenance POV @dsnallfot  :

move the function populateSettings in the OverrideProfilesStateModel
use targetValue.asMmolL instead to convert manually (populateSettings func line 519)
refactor the code between populateSettings and savedSettings functions to avoid duplicate code
could be better to have a function in the StateModel to populate the edit view (profilesView - move line 399 to 413 to a statemodel function like loadProfile(idPreset: String).

Functionaly, a proposal : perhaps not apply the edited profile as a current profile ?
Example with the video :

Current Test profile
Editing the test#2 profile > Cancel
The content of the test#2 replace the test

Thanks Pierre! Will go through all your suggestions and try to adjust accordingly.

Will soon commit all changes based on all your input regarding both refactoring and improved functionality  @avouspierre , thanks again for great feedback!
And below is a demo of the improved functionality regarding what pre filled settings are used in the view.

I've made .onDisappear from the editPresetPopover back to root view  behave the same way as .onAppear in root view when coming from home screen, that is:

If ongoing override, populate settings with the ongoing override setting.
If no ongoing override, populate settings with user defaults

And when entering edit by selecting edit on any override -> populate the settings in edit mode with that selected overrides settings as starting point for the edit

Do this look ok?
https://github.com/nightscout/Trio/assets/72826201/6bd189df-43cf-40a2-a555-68b1fb0bf512

Now we-re hopefully starting to see the finish line for this commit.
Regarding refactoring and avoiding duplicate code (there are som duplicate code in state model since before that I didn't touch - and for new functions, I've tried the best I could to make the code ok and taken it as far as I can with making it pretty and maintainable. If any more adjustments regarding maintenance and code efficiency is needed, I really need help from anyone of you guys.
Well. Every change and improvement need (so far) is committed in the PR now, and you could start testing when it suits you.
And the screenshot below is the "one more thing commit" that I almost forgot to add, the slider & percentage order switcharoo @dnzxy made in iAPS after 2.3.3  😊

Looking superb. Great job.


[coin management] generalize TransferSui to PaySui

Context

The TransferSui transaction type allows you to pay directly with a single gas object (instead of using two coins)
The newly added Pay transaction type allows you to pay multiple amounts, to multiple recipients, with multiple inputs
The combination of these API's support most common payment scenarios. However, there is one requirement that is still hard to meet with a single transaction: transfer all of my coins elsewhere.

Proposed solution
(Discussed with @Jordan-Mysten): generalize TransferSui to PaySui by allowing multiple recipients and multiple amounts:
pub struct PaySui {
    /// Non-gas input coins. May be empty
    pub coins: Vec<ObjectRef>,
    pub recipients: Vec<SuiAddress>,
    pub amounts: Vec<u64>,
}

This should (hopefully) be fairly easy to implement/test as a wrapper around the existing pay function.
One conundrum is how to support the old amount: Option<u64> behavior in TransferSui. I think one good solution is:

if amounts is empty, the total value of all input coins and the gas coin is divided equally among the recipients (and can tweak Pay to do this as-well
if amounts is non-empty, it must be the same length as recipients and each recipient will receive the specified amount.

transfer all of my coins elsewhere

presumably we will call PaySui with all user owned coins as coins and only one recipient. if we follow the impl of Pay, one tricky thing is that, one existing coin is needed before executing the txn for gas payment while all owned coins are deleted for the new merged coin.
TransferSui does not have this issue bc even if the whole coin is transferred, the input coin object still exists. a code pointer. To get around this, one thing we can do is trying to reuse the input coins such that for this specific transfer all case, we can merge all coins into the first one for example and use that also as gas payment. any wisdom? @sblackshear
One remaining edge case is, if we want to transfer all coins and evenly split them among N recipients, unless we can accurately determine the cost before execution, otherwise the recipient of the gas object coin will receive a different amount depending on the estimated cost vs actual cost, this might be okay if we assume the gas should be minimal here.

I did not understand the first problem you are mentioning. I think my confusion centers on the "merged coin" part of this:

one existing coin is needed before executing the txn for gas payment while all owned coins are deleted for the new merged coin

Pay does not do any merging, which is why I am confused.

One remaining edge case is, if we want to transfer all coins and evenly split them among N recipients, unless we can accurately determine the cost before execution, otherwise the recipient of the gas object coin will receive a different amount depending on the estimated cost vs actual cost, this might be okay if we assume the gas should be minimal here.

Good point. I think the gas cost will be statically knowable here (cc @oxade to make sure). If that's right, we can deduct the gas cost from the gas coin before calling pay(), and then everything will work as expected. But we have to take care to anticipate all of the gas costs (including object creation etc.)

Pay does not do any merging, which is why I am confused.

Sry for the confusion. Today we construct tx with a gas object. Then we execute tx, in the case of "transferring all my coins" to one recipient, we delete all coins, create a coin with the total balance (this was the merging I meant but yeah it's not really a merge coin action) and transfer it to the recipient.
The problem I saw was, the newly created coin with all balance does not exist until tx execution so it cannot be used as the gas payment coin, which happens before tx exec. coins that belonged to the sender cannot either bc they are deleted after tx exec.
Thus I was thinking one way to get around this is, instead of deleting existing coins and creating new coins, we can reuse the existing coins by redistributing the total balance, and creating an extra coin for residual balance if needed. As there is at least one owned coin and at least one recipient, it is guaranteed that we will always have a coin that exists before tx exec and still exists after tx exec, such that it can be used for gas payment.
@sblackshear does that make sense? Feels like it could have been easier with a PR, I will have a quick one for this 😆

@gegaowp My understanding is that with pay you can skip the step of combining all coins, and instead just pass a vector of all of your coins, letting the pay transaction take care of it.

@Jordan-Mysten yes, Pay transaction transforms coins based on amounts, and the issue I saw was about the gas payment in PaySui, as we want to pay gas with the input coins as we do in TransferSui, other than a separate coin as we do in Pay.

I imagined for a pay-based transferSui that we'd be able to pay gas with the same coin that we pay an address with

pay-based transferSui

yes, I also wanted to implement transferSui/paySui as a wrapper of Pay, while the current pay impl approach afaict seems not working, I put up a quick draft PR with some comments to elaborate the idea https://github.com/MystenLabs/sui/pull/4803
sry for the confusion and hope this makes sense. @Jordan-Mysten @sblackshear

A few thoughts:
So the primary motivation here for PaySui is to be able to transfer away all my SUI coins. But do we anticipate a case where we want to transfer away all my SUI coins AND transfer them to different recipients AND be able to divide coins equally? Asking because when Ge was explaining the semantics of PaySui to me, it took me 20 mins before I could understand all the different ways of what it could do. I think clients/apps will have a hard time digesting how to use PaySui. The dependency on gas_budget is also going to be tricky: unless we just hardcode a gas cost for PaySui, there is no guarantee that the budget would be accurate. The algorithm seems so dynamic that there would be no way to predict gas cost around various object creation/deletion cases, not mentioning that gas price could in practice be dynamic which could impact SUI cost as well.
My recommendation is that we just generalize TransferSUI to support a list of extra SUI coins, but keep everything else the same: one sender, and optional amount (None indicating transfer all). This allows us to handle the case we want: be able to transfer away all my SUI coins in a guaranteed way. And if we discover more complex popular use cases latter, we could optimize accordingly.

Furthermore, I remember that has been asks about supporting a list of gas coins, instead of just one.
If we support that, then we don't even need a new transaction type. TransferSui could just transfer away all SUI coins by specifying all coins as gas objects and leave amount empty.

supporting a list of gas coins

yes I proposed this one, the motivation back then was to solve the problem when ppl have dusts of Sui coins. A related q is that, following the idea, do we want to split the gas cost evenly to all recipients?

The idea here, imho, is that if we want to pay gas using the input coins, we should keep it simple and have only 1 recipient

I agree with the desire to make the gas behavior of PaySui simpler.
I do suspect that there's a use-case for paying multiple recipients in SUI where some part of the payment comes out of the gas coin (or, to put it differently, where the caller doesn't have to worry about which coins are used for payment vs gas). But sticking with the simpler version of transfer SUI to start + worrying about this if/when it becomes a problem seems reasonable.

On multiple gas coins: my instinct here is that this introduces complexity that is not well motivated at this time (but I might very well be wrong!). Here's something I wrote previously

My intuition is that the answer to (1) will be "pretty small" (<= $0.10 for most tx types if we want to be competitive with other platforms)
My intuition is that the answer to (2) will be "pretty big", since an average address will likely get a coin by buying a bunch of SUI from a marketplace, receiving a chunk of SUI from staking rewards, or receiving a payment of some form (P2P, NFT sale, NFT royalties, ...). "Pretty big" is vague, but I think most of these coin values are more likely be in the ballpark of $10s-100s of dollars.
If we expect (2) >> (1), then I think we should also expect the use-case of paying for a single tx with multiple gas coins to be pretty uncommon (since an average single coin will be more than big enough). It seems unfortunate to ask wallets, clients, explorers, etc. to deal with this edge case if so.

I do suspect that there's a use-case for paying multiple recipients in SUI where some part of the payment comes out of the gas coin

I agree. Introducing multiple recipient is not too bad, just that we need to define the semantics clearly.
The way I think about implementation complexity vs expressiveness in Sui is to look at it through 4 layers:
Native Transaction -> Move Transaction -> Batch Transaction -> Multiple Transaction
The Native Transaction should be the most lean layer and we should avoid adding things to it unless we absolutely cannot do in other layers (or the cost of doing it in other layers is significantly higher).
Move Transaction is an ideal layer because it's most convenient to develop.
Down the line we could support the ability of using output objects of previous sub-transaction within a Batch Transaction, so that Batch Transaction can become much more powerful and expressive, and could potentially handle the case of sending sui to multiple recipients and etc.
Then there is the application layer (e.g. wallet) that can always send multiple transactions to achieve something complex.

a use-case for paying multiple recipients in SUI where some part of the payment comes out of the gas coin

agreed, we can still do so as long as we separate the implementation for these 2

"paying multiple recipients in SUI where some part of the payment comes out of the gas coin",  and where the amounts are specified, indicating the residual value under sender can still pay for the gas cost, maybe we can call this paySui
paying all coins to one recipient, where the amount is not specified, maybe we can this payAllSui

Implementation wise, I will implement separately for paySui and PayAllSui to avoid make pay more complex, but will try to minimize duplicate codes when possible. what do you folks think?

"paying multiple recipients in SUI where some part of the payment comes out of the gas coin", and where the amounts are specified, indicating the residual value under sender can still pay for the gas cost, maybe we can call this paySui

How is this different from the current proposal for PaySui? Once you specify amounts, and still want to drain all your SUI coins, you end up with the same problems.

How is this different from the current proposal for PaySui?

the main difference is that, the current proposed paySui was originally intended to cover the "transfer all with multiple recipients" case as well, thus gas_budget / estimated_gas_cost has to be taken into consideration to decide amounts for each recipient, it was not possible to strictly split evenly bc neither gas_budget nor estimated_gas_cost is accurate.
if we forget about the transfer all case of paySui, then what we can do is something like

create new coins under recipients per the specified amounts
put all residual SUI balance after deducting amounts into the first input coin, meanwhile deleting all other input coins
pay gas with the first input coin, if the residual SUI balance is indeed enough to pay for gas, all good; otherwise, the transaction would fail with InsufficientGas error.

yeah this is very fair question:

one case is when ppl only have one coin and wants to transfer to multiple recipients;
another is related to coin selection, with coin_selection APIs we provide, ppl can get a selected coin as a gas payment object, but they might want to use only certain coins for this transfer txn, while keeping others untouched, for example to reserve other coins for parallel txns.

Agreed that these are likely corner cases and I will start with the PayAllSui as well.

Cool. I think as starter, we could be a bit more flexible than PayAllSui.
Essentially we can generalize TransferSui, maybe call it PaySui, where we can support multiple coins in the input.

Iirc to replace TransferSui with more general version, I think we will have to separate the semantic meaning of TransferSui to paySui and payAllSui, did I miss sth about the generalization you meant?
Agreed that for all new functions I am going to implement, they should all take a vector of coins rather than one input coin.

TransferSui supports two modes: transfer a specific amount, or transfer all. But it only accepts one input coin today.
I was suggesting that we extend TransferSui to support a vector of input coins, and keep both intents: transfer a specific amount, or transfer all.

in a "transfer" flow, user can add pairs of <recipient, amount>, this can all be handled by PaySui

I don't fully understand this flow. In this case, which coin will be paying gas? And why not use a Batch transaction for this case?

It will be the first coin among coins selected by a separate "coin selection" for this whole transaction.
Re batch transaction, iiuc before batch transaction can pass / share objects among sub-txns, we want to provide a way to send to multiple recipients with the same set of input coins in one txn, instead of a sequence of transactions to do so, right?
if we want to have 2 new native transaction types to handle payment around Sui, I was proposing that PaySui + PayAllSui is cleaner than PaySui + generalized TransferSui.
However if we feel PaySui is not necessary, then it makes sense to generalize the TransferSui to take in a vector of coins.

All makes sense! Thanks for explaining.
If there ends up a lot of shared code between PaySui and PayAllSui, I think it's reasonable to combine them into one, just maybe make the recipient field of the tx an enum of two independent cases.


How to bookmark all open tabs in chrome on iPad?

On an iPad, how do I bookmark all open tabs in a chrome browser using raindrop? I know this feature works on a desktop browser. How can this be achieved on an iPad?

Not possible yet unfortunately. Add to feature requests https://better.raindrop.io/


feat(cli,api): mock build

Signed-off-by: Matej Focko<EMAIL_ADDRESS>TODO:

[x] Write new tests or update the old ones to cover new functionality.

requires mock to be present which might be a problem in the CI

[x] Update doc-strings where appropriate.
[x] Update or write new documentation in packit/packit.dev.

Fixes #1096
RELEASE NOTES BEGIN
Packit now supports automatic ordering of ☕ after all checks pass.
RELEASE NOTES END

recheck

recheck

recheck


[DO NOT MERGE] Testing HADOOP-16888

Test PR for #2012

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/1/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/2/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/3/console in case of problems.

The precommit job ran more than 10 hours and aborted.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/4/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/5/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/7/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/8/console in case of problems.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
32m 57s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
shelldocs
0m  0s
Shelldocs was not available.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
2m 12s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
21m 58s
trunk passed

+1 :green_heart:
compile
20m 57s
trunk passed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04

+1 :green_heart:
compile
18m  1s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
checkstyle
2m 55s
trunk passed

+1 :green_heart:
mvnsite
18m  2s
trunk passed

+1 :green_heart:
shadedclient
15m 30s
branch has no errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 31s
root in trunk failed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.

+1 :green_heart:
javadoc
5m 31s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+0 :ok:
spotbugs
32m 13s
Used deprecated FindBugs config; considering switching to SpotBugs.

-1 :x:
findbugs
32m  6s
root in trunk has 3 extant findbugs warnings.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 28s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
22m  2s
the patch passed

+1 :green_heart:
compile
20m 30s
the patch passed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04

+1 :green_heart:
javac
20m 30s
the patch passed

+1 :green_heart:
compile
17m 59s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
javac
17m 59s
the patch passed

-0 :warning:
checkstyle
2m 54s
root: The patch generated 1 new + 12 unchanged - 1 fixed = 13 total (was 13)

+1 :green_heart:
hadolint
0m  3s
There were no new hadolint issues.

+1 :green_heart:
mvnsite
17m 58s
the patch passed

+1 :green_heart:
shellcheck
0m  0s
There were no new shellcheck issues.

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
15m 29s
patch has no errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 30s
root in the patch failed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.

+1 :green_heart:
javadoc
5m 34s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
findbugs
34m 28s
the patch passed

_ Other Tests _

-1 :x:
unit
590m  4s
root in the patch passed.

-1 :x:
asflicense
1m 22s
The patch generated 1 ASF License warnings.

906m 53s

Reason
Tests

Failed junit tests
hadoop.yarn.client.api.impl.TestAMRMClient

hadoop.yarn.applications.distributedshell.TestDistributedShell

hadoop.hdfs.server.balancer.TestBalancerWithNodeGroup

hadoop.hdfs.server.balancer.TestBalancerWithHANameNodes

hadoop.hdfs.tools.TestDFSZKFailoverController

hadoop.yarn.sls.appmaster.TestAMSimulator

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/8/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2013

Optional Tests
dupname asflicense shellcheck shelldocs hadolint compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 63e7296a4c2b 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 52b21de1d88

Default Java
Private Build-1.8.0_252-8u252-b09-1~18.04-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_252-8u252-b09-1~18.04-b09

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/8/artifact/out/branch-javadoc-root-jdkUbuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/8/artifact/out/branch-findbugs-root-warnings.html

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/8/artifact/out/diff-checkstyle-root.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/8/artifact/out/patch-javadoc-root-jdkUbuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/8/artifact/out/patch-unit-root.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/8/testReport/

asflicense
https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/8/artifact/out/patch-asflicense-problems.txt

Max. process+thread count
2975 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common . U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-2013/8/console

versions
git=2.17.1 maven=3.6.0 shellcheck=0.4.6 findbugs=3.1.0-RC1 hadolint=1.11.1-0-g0e692dd

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.


Webpack Compilation Error

by cypress when integrate with rails application with gem "cypress-on-rails"
When cypress test run on terminal: "cypress open" generates "Webpack Compilation Error"
Error: Webpack Compilation Error
Module not found: Error: Can't resolve 'cypress-factory' in '/path/spec/cypress/support'
at Watching.handle [as handler] (/home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/@packages/server/node_modules/@cypress/webpack-preprocessor/dist/index.js:212:23)
at /home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/webpack/lib/Watching.js:303:9
at Hook.eval [as callAsync] (eval at create (/home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/tapable/lib/HookCodeFactory.js:33:10), :6:1)
at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/tapable/lib/Hook.js:18:14)
at Watching._done (/home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/webpack/lib/Watching.js:299:28)
at /home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/webpack/lib/Watching.js:213:21
at Compiler.emitRecords (/home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/webpack/lib/Compiler.js:919:5)
at /home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/webpack/lib/Watching.js:191:22
at /home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/webpack/lib/Compiler.js:885:14
at Hook.eval [as callAsync] (eval at create (/home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/tapable/lib/HookCodeFactory.js:33:10), :6:1)
at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/tapable/lib/Hook.js:18:14)
at /home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/webpack/lib/Compiler.js:882:27
at /home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/neo-async/async.js:2818:7
at done (/home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/neo-async/async.js:3522:9)
at Hook.eval [as callAsync] (eval at create (/home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/tapable/lib/HookCodeFactory.js:33:10), :6:1)
at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/tapable/lib/Hook.js:18:14)
at /home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/webpack/lib/Compiler.js:736:33
at /home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/graceful-fs/graceful-fs.js:143:16
at /home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/@packages/server/node_modules/graceful-fs/graceful-fs.js:143:16
at /home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/@packages/server/node_modules/graceful-fs/graceful-fs.js:143:16
at /home/.cache/Cypress/13.5.1/Cypress/resources/app/node_modules/@packages/server/node_modules/graceful-fs/graceful-fs.js:61:14
at FSReqCallback.oncomplete (node:fs:200:23)
When i tried to add package, normally webpack compilation error caused when package is missing or import hierarchy issue,
yarn add cypress-factory
yarn add v1.22.19
[1/5] Validating package.json...
[2/5] Resolving packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/cypress-factory: Not found".
info If you think this is a bug, please open a bug report with the information provided in "/path/Rails/my-project-name/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
i know wrong import cause webpack issue, but in my scenario there is not any wrong import

Typo?

but point is, i have use factory-bot gem of ruby on rails and i watched this npm package
01-there is nothing cypress-factory written in my code or files i double check this, from where it is orignating?


Add reference docs for routesource

Description

Added in this PR: https://github.com/projectcalico/felix/pull/2258
Related issues/PRs

Todos

[ ] Tests
[ ] Documentation
[ ] Release note

Release Note

None required

Deploy preview for calico ready!
Built with commit 8d374893375453de967bf4099aaa5132afc5f954
https://deploy-preview-3449--calico.netlify.app


Don't show the same session twice - use a unique constraint on the session ID when searching sessions

See #886. This was reported as a separate behavior but I suspect it's the same problem. When you "join" a session that was started by someone else, you get your own row for it in the various ways we retrieve sessions.


MINOR: apply Utils.isBlank to code base

apply Utils.isBlank to code base
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@tang7526 Thanks for your patch. Could you fix following code also?

https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/Plugins.java#L448
https://github.com/apache/kafka/blob/trunk/clients/src/test/java/org/apache/kafka/common/security/oauthbearer/internals/unsecured/OAuthBearerScopeUtilsTest.java#L31
https://github.com/apache/kafka/blob/trunk/connect/api/src/test/java/org/apache/kafka/connect/data/ValuesTest.java#L914
https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/network/SocketServer.scala#L642
https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/server/KafkaServer.scala#L473
https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/utils/Log4jController.scala#L74
https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/utils/Log4jController.scala#L83

@tang7526 Thanks for your patch. Could you fix following code also?

https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/Plugins.java#L448
https://github.com/apache/kafka/blob/trunk/clients/src/test/java/org/apache/kafka/common/security/oauthbearer/internals/unsecured/OAuthBearerScopeUtilsTest.java#L31
https://github.com/apache/kafka/blob/trunk/connect/api/src/test/java/org/apache/kafka/connect/data/ValuesTest.java#L914
https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/network/SocketServer.scala#L642
https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/server/KafkaServer.scala#L473
https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/utils/Log4jController.scala#L74
https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/utils/Log4jController.scala#L83

@chia7712 Done

kafka.admin.ListConsumerGroupTest.testListConsumerGroupsWithStates() unrelated error


Latest update breaks with 'Could not read "-bootstrap".'

I've just updated to 0.8.3 and now the arguments ' -c -bootstrap' are being added to PHPUnit, which seems to be incorrect. PHPUnit ends up trying to load a config file named '-bootstrap'.

+1, I just changed index.js:176 to: cmd += ' -c "' + file.path + '"';
Seems to be working now.

Thx for info, I will get this updated in release version this evening.

can confirm @VoodooPrawn solution does work

@slayerfat @VoodooPrawn
Hey guys, I have updated the plugin and submitted to npm.   Please let me know if you have any further issues.

This has been fixed in 0.9.0, please update :-)
I didnt use your PR, but I do appreacite it as it helped track down the real issue


fix: update proper error messages

Description

There were missing arguments message, as per issue #86
Updated message files to contain expected error messages

Related issue(s)
Fixes #86

@Souvikns hacktoberfest-accepted label can be skipped - repo has such an label to take participant in hacktoberfest :)

@mihirterna Please run linter (https://github.com/asyncapi/cli/pull/87/checks?check_run_id=3791303609) and push changes - npm run lint.

@mihirterna Please run linter (https://github.com/asyncapi/cli/pull/87/checks?check_run_id=3791303609) and push changes - npm run lint.

Thanks for comment, have committed formatted code.

@Souvikns I had to change PR's title so I did it for you :)


starfield trackers alliance quest

Scanner quest completion conditions are not displayed.
Scanner Quest is not progressing
Tracker Alliance mission board quest is not progressing

Details
Please note that the Japanese is translated into English at DeepL.
The point of occurrence is unknown, but at some point a glitch occurred in the scanner quests and mission board quests of the Tracker Alliance.
The clear condition (kill or live) that is displayed when scanning is no longer displayed in either case.
These NPCs do not respond at all when spoken to or when a pickpocket command is executed.
In addition, the quest does not progress even if the NPC in question is stunned by EM weapons, and killing them will force the quest to be treated as a failure.
The same problem with Hannibal, who is encountered during the Starjacker quest, can be solved by talking to him, but it is still possible to proceed with the quest. However, the dialogue was not displayed correctly and a mini-game of persuasion suddenly started.
Translated with DeepL.com (free version)
Game Version
V<IP_ADDRESS>
Language
日本語 (JA)
New Game
No
Reproduction Steps
not

Duplicate of #1034


docs(api/errors): fix syntax error in example code

Use double quotes for strings, since there is a single apostrophe
inside.

Looks like a bare except clause in an unrelated test is causing the pep8 CI check to fail. Added the fix for that to make it pass.


Required hardware?

Do you have any information on the required hardware?
I'm trying to run it on 1 GPU - 16GB - however CUDA goes out of memory.

Running the code (batch=24) may require three 16G GPUs.
Reference: https://github.com/HSLCY/ABSA-BERT-pair/issues/1


getElementsByClassName missing?

is there no auto completion for getElementsByClassName or am I doing something wrong?

Duplicate of #12212

Closing as duplicate of #12212.


Compose an image tag in the same format as GATK docker images

The default image tag of build_docker.py is the first 8 chars of the commit SHA. Following @mwalker174's suggestion, this PR updates the Docker Images action by composing an image tag that follows a similar format to the GATK nightly builds; i.e.,
{date}-{release tag}-{first eight letters of the commit sha}

For instance:
2022-03-25-v0.20.2-beta-658f92ce

@VJalili I think it's fine the way it is currently

@mwalker174 thanks for confirming that.


Try get method type from super class

Fixes #23911

@typescript-bot user test this

I have some question:

Should we handle the type check both of contextual type and declaration type?
Should we check if method name is not literal name?


bibdata refactor changes

The following changes impact this gem, as elements moved to bibdata/ext from bibitem. All elements specific to GB must be populated in bibdata/ext; please ask me if there are any changes not covered in the following.
The grammar of ext (which inherits from ISO) is:
BibDataExtensionType =
    doctype?, gbcommittee*, ics*, structuredidentifier, gbtype, gbccs+, gbplannumber?

gbccs = element ccs {
  element code {text},
  element text {text}?
}

gbplannumber = element plannumber { text }

gbcommittee =
  element gbcommittee {
    attribute type { ( "technical" | "provisional" | "drafting" ) },
    text
}

gbtype =
  element gbtype {
    gbscope, gbprefix, gbmandate, gbtopic
}

DocumentType = "standard" | "recommendation"

The type of standard, e.g. "recommendation", is no longer set in bibitem/@type. It is now set in bibdata/ext/doctype

title-main is replaced with title[@type = 'title-main']. The lang attribute is retained.

title-intro is replaced with title[@type = 'title-intro']. The lang attribute is retained.

title-part is replaced with title[@type = 'title-part']. The lang attribute is retained.

A title[@type = 'main'] shall be added, consisting of title-main, title-intro, title-part, joined by space-endash-space. The lang attribute is retained.

gbcommittee moves to bibdata/ext.

ics moves to bibdata/ext.

The structured GB identifier, using project-number and part-number attributes, is moved from bibitem/docidentifier to bibdata/ext/structuredidentifier. In bibitem/docidentifier, the ISO identifier given should be the identifier as it appears on the site, with the part numbers incorporated; e.g. <docidentifier type="ISO">ISO 631-1</docidentifier> vs <structuredidentifier><project-number part="1">ISO 631</project-number></structuredidentifier>

gbtype, gbccs, and gbplannumber all move to bibdata/ext.

@ronaldtser what is the essence of the gbplannumber element? Where we can scrape it?

@ronaldtse since we don't have a text element /bibitem/status/status anymore, where can we scrape stage and substage?
New grammar for status element:
status =
  element status {
     ( stage, substage?, iteration? )
}

gbplannumber is the project number for GB. Somehow the gb688.cn website isn't working for me...?

@opoudjis I think we don't have title-intro and title-path for GB docs

title-intro is replaced with title[@type = 'title-intro']. The lang attribute is retained.
title-part is replaced with title[@type = 'title-part']. The lang attribute is retained.
title-part is replaced with title[@type = 'title-part']. The lang attribute is retained.
A title[@type = 'main'] shall be added, consisting of title-main, title-intro, title-part, joined by space-endash-space. The lang attribute is retained.

If a document has only title-main do we need to add a main type title?

If a document has only title-main do we need to add a main type title?

Yes. "main" is the complete title; it is logically distinct from "title-main", which is the main title component. If only "title-main" is present, "main" is identical to it.
Even if there is no title-intro and title-part (which surprises me), we should retain this behaviour, for consistency with ISO.


dammit im not a collaborator

bottom text

I have invited you to be a collaborator even before I sent the link

I'm taking this issue over

nevermind I'm just gonna make another one


Setting pagerduty: namespace configs will cause provider validation to break.

Hello!

Vote on this issue by adding a 👍 reaction
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already)

Issue details
Setting pagerduty:fromEmail will conflict with pagerduty:token validation and throw errors like
  pulumi:pulumi:Stack (project):
    error: preview failed

  pagerduty:index:Service (main):
    error: Preview failed: could not validate provider configuration: 1 error occurred:
        * Invalid or unknown key

Steps to reproduce

pulumi config set pagerduty:fromEmail<EMAIL_ADDRESS>pulumi config set pagerduty:token [ACTUAL_WORKING_TOKEN] --secret
Try to import a service. pulumi import pagerduty:index/service:Service main "abc123service"
Error

Expected:
fromEmail does not conflict with provider validation, and service imports normally
Actual:
Above error. Even if you set the env var PAGERDUTY_TOKEN, it still breaks.
The UX here is poor as it should not let you set anything in the pagerduty namespace in the config.

This behavior is expected, as fromEmail is not a valid value for the config:
https://registry.terraform.io/providers/PagerDuty/pagerduty/latest/docs#argument-reference
If you need further assistance, feel free to reach out to folks in the Pulumi community slack.


Operation suggestion: cut off / cut out for splitting areas

Something I've run into a couple of times now, is the desire to split an area into multiple parts; because a part of a park was repurposed, because two halves of a parking terrain had different access rules, and so on. I don't seem to be the only one either (eg. #6988).
I feel like this class of usecases could be addressed generically through the addition of two new operations to the operations menu that are very similar to each other, which I'd therefore like to propose:

Cut off: Displayed when both an area and an unclosed polygon are selected. Selectable when the polygon fully crosses the area. This would cut the area into two parts, across the drawn polygon.
Cut out: Displayed when both an area and a closed polygon are selected. Selectable when the polygon overlaps the area; it does not need to be fully enclosed within it. This would "cut out" the specified shape from the area, making it its own area.

In both cases, the new area would initially have the tags of the 'existing area' copied into it as-is; this means that when splitting an area to apply a subtle change (eg. differing parking access, connected houses with just a different street number), all the remaining metadata is retained and does not need to be re-entered.
This approach would not require redrawing any areas, thereby avoiding potential loss of precision in doing so. It would also use the existing drawing primitives for specifying the splitting boundaries instead of introducing new UI, reducing implementation complexity and keeping the UI simple.
The process illustrated, where red lines signify the line segments / polygons used to determine the split position, and the numbers indicate the resulting area features:

Thoughts?

I share your desire to cut areas in a more-controllable way.
I would prefer a context menu option (replacing the current area-cutting action) which prompts you to draw a line (same UI as drawing a way). Whenever your line divides the area into two parts, it is removed and the area divided.
This would cover both use cases: cuttting off and cutting out.

This issue has since been superseeded by #9334.
cc: @tyrasd


Row filter support to DataSocket

DataSocket class could also support parsing row filters as it seems like common operation to many repositories
Example implementation that extends the Datasocket:
@dataclass(frozen=True)
class DataSocketContainer(DataSocket):
    """DataSocket Containing Container"""

    filters: Dict[str, Union[str, List[str]]] = field(default_factory=dict)

    def _construct_filters(self):
        """Turn filters dictionary into pyarrow expressions"""
        expressions = [
            pyarrow_field(column_name).isin(maybe_make_list(filter_values))
            for column_name, filter_values in self.filters.items()
            if not isinstance(filter_values, bool)
        ]
        constraints = [
            pyarrow_field(column_name) if filter_values else ~pyarrow_field(column_name)
            for column_name, filter_values in self.filters.items()
            if isinstance(filter_values, bool)
        ]
        #TODO: Missing comparison field(s)
        return expressions + constraints

    def get_socket_filters(self) -> Expression:
        """Returns the filters for the socket"""
        return reduce(lambda x, y: x & y, self._construct_filters(), scalar(True))

@Jupetus DataSocket is a model class, not a functionality class. Closing as duplicate of #201


concat should preallocate for FixedSizeList

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Right now, concat only pre-allocates for string, binary, dictionary and primitive arrays (IIUC):
https://github.com/apache/arrow-rs/blob/208da03979b2903c3182c20ef382b2895756380a/arrow-select/src/concat.rs#L129-L139
We use FixedSizeList<{FloatType}> as a storage type for tensor arrays, and not pre-allocating can get very expensive in plans. https://github.com/lancedb/lance/issues/1360
Describe the solution you'd like
Should provide capacities for fixed size list array. We likely need to add an entry to this enum:
https://github.com/apache/arrow-rs/blob/b46ea46aa65149fac763671b0adcb9c4e406ec11/arrow-data/src/transform/mod.rs#L323-L344
Describe alternatives you've considered

Additional context

FYI @judahrand has made a PR for this: https://github.com/apache/arrow-rs/pull/5862


how to zip with no dist prefix

 new WebpackZipPlugin({
      initialFile: './dist', //需要打包的文件夹(一般为dist)
      endPath: './dist', //打包到对应目录（一般为当前目录'./'）
      zipName: 'dist.zip' //打包生成的文件名
    })

as example ,when unzip  dist.zip there is a dist subdirectory , i donnot want keep this subdirectory
how ?

same question as above  , a big bug cause i can't use the plugin ,i dont want to change my dir

For everybody stranding here just use https://github.com/erikdesjardins/zip-webpack-plugin
    new ZipPlugin({
        filename: 'app.zip',
    })


[QUESTION] Recommended system requirements for running Hydra?

What are the recommended best-case system requirements for running Hydra on map sizes comparable to uHumans datasets with VIO enabled (such as Kimera-VIO)? Information like CPU, storage access speed, RAM and GPU in case we want to run semantic segmentation live.
In addition, what difference would running the above on bare metal, container or virtual machine make?
Thanks I advance!

I think unfortunately there's no one answer: it really depends on what you require in terms of map resolution, accuracy and latency. We've shown that the frontend of Hydra can operate at up to 5hz on an Nvidia Xavier NX, but the 3D metric-semantic reconstruction isn't included in that (and is a little slower). We've also run Hydra live at ~2hz with a 2d semantic segmentation network on the Xavier (though with a mobilenet variant instead of the HRnet model we used in the Hydra paper).  We haven't run with Kimera-VIO in the loop (we were using T265 odometry instead), but there should be enough headroom to run Kimera-VIO alongside everything else. This is to roughly say that I'd expect the minimum requirements would be something with similar CPU/GPU compute power as a Xavier, though you may have to tweak the voxel size a little to get something that remains performant. Storage access speed shouldn't matter (we don't write out much to disk until Hydra exits). Finally, the backend isn't necessarily going to run in real-time (optimizations after a loop closure will likely take a while).
More specifically:

A Xavier NX is about as small as I'd go, but other applications might want something more powerful (a typical laptop processor should be fine)
The frontend will run on an Nvidia Xavier NX at up to 5hz, and reconstruction will run at about 2hz
The backend won't output anything while optimizing after a loop-closure and isn't expected to run in real time
GPU size depends on what you need to run your chosen semantic segmentation network at 5hz
The visualization is pretty heavy-weight, and disabling it (or running it offboard) will help

It's also worth noting that we're actively working on improvements to Hydra (and additional profiling on the Xavier) that should hopefully be released soon.

In addition, what difference would running the above on bare metal, container or virtual machine make?

As far as I know, there's almost no difference between running on bare-metal linux versus running in a container. For what it's worth I ran the experiments for the paper in a lxc container and normally use them for development.  A vm will come with some sort of performance penalty (though typically very slight), but it really depends on how the virtual machine is set up.  I haven't bothered to do any detailed profiling of the difference any of these make as we're targeting bare-metal linux on all of our robots.

Great, thanks for your answer!
But let's say we want to run Hydra on synthetic data from the simulation at the original speed on the ground station with "unlimited resources". We'd want a relatively fast backend and good detail of the mesh. For example, in case I want well-detailed mesh, what I've noticed is that the rosbag often has to be played at lower rate to give Hydra enough time to do its thing. With higher playback speeds my CPU goes to 100% and I start skipping frames.
Also, we've noticed that depending on the map size, RAM usage is very high, sometimes reaching 100 GB. We just don't want to deal with hardware restrictions while we're experimenting with Hydra, so with this in mind what ideal hardware setup would you pick?

We'd want a relatively fast backend and good detail of the mesh

In the current public implementation, there are a couple things that are slowing down the backend (and Hydra in general):

We iterate in a pairwise manner over the objects and the places to merge overlapping nodes
We copy the full mesh from the frontend to the backend, which can take a while for larger meshes

I'd guess  that at least for now, that's going to limit the backend to about ~2 hz or lower. Some of the changes I mentioned in my last comment address address these two issues.

For example, in case I want well-detailed mesh, what I've noticed is that the rosbag often has to be played at lower rate to give Hydra enough time to do its thing.

I've gone down to 5cm voxel size for the tsdf/mesh/GVD before, and I certainly wouldn't try to go past that with the current implementation. If I remember correctly, 5cm was still pretty painful to run and may not have been real-time. Part of the fundamental limit is the that GVD detection is single-threaded and scales poorly with the voxel size (in general, most of the reconstruction does).  The GVD voxel size theoretically doesn't have to be set to the same as the TSDF voxel size which might help boost performance a little, but that would take a little bit of development.

Also, we've noticed that depending on the map size, RAM usage is very high, sometimes reaching 100 GB

I'd be surprised if Hydra itself was directly the culprit (at 10cm resolution for the mesh, the office scene should be about ~1.4GB of RAM usage). The typical breakdown for memory is:

windowed TSDF + mesh + GVD + semantic labels for the hydra topology node: ~100 mb (10 + 10 + 40 + 40)
3x copies of the mesh (compression, frontend and backend): ~1.2 GB
scene graphs and other book-keeping: ~100mb

It might be a little higher for the public version (like 10%) because of how we handle the mesh vertices and faces, but there shouldn't be significant differences.
That said, if the mesh resolutions is much smaller than 10cm (i.e. ~1cm) I could see significant amounts of memory being used. I still think it's more likely though that running at higher rates is causing input messages (either pointclouds or mesh updates) to be queued up because either voxblox or Hydra isn't processing the updates fast enough.

what ideal hardware setup would you pick?

I typically run on the workstation reported in the paper: a Ryzen threadripper 3960x (so 24 cores, 48 threads) and 64GB of RAM. I could see the utility of increasing the amount of RAM if you're planning on working with larger meshes than we normally do, and I could also see the utility of having multiple GPUs on the workstation if you're running with a simulator in the loop (I haven't felt constrained by my GPU though).  It's worth noting that I typically limit my container RAM usage to ~48GB, and core usage to 16 threads.  The number of threads available does help speed up the reconstruction (marching cubes and the tsdf integration both use as many threads are available), so that may help your use-case if you don't have a CPU with a lot of cores.


Sign in button for few seconds

Is your feature request related to a problem? Please describe.
when user is logged in sign in button is hidden

when user is logged out sign in button shows up for about 7 seconds

Describe the solution you'd like
We can use useEffect and  setTimeout javascript function to create this
Describe alternatives you've considered
No response
Additional context
No response

sorry @Kanika637 for not first assigning this task to self I felt like If couldn't complete I would get removed so I tried working first

That is fine @aklite , but don't repeat that again🙌


Add equator-pole temperature gradient parameters for calibration

The equator-pole temperature gradient parameters are currently hardcoded in the held-suarez tendency.
For our first calibration test, we need to calibrate on these, so they need to be modifiable parameters.
I have already added them to ClimaParameters.

bors try

bors cancel

bors try-

bors r+

bors r+