benchmark repetition problem

Hi, I am currently using the Carla benchmark to test my algorithm. My Carla version is 0.7.1.
I modified on 'CoRL2017.py'. I changed the start-end points in function 'def _poses_straight():'. Then, I found that if, for example, I set the point pairs as [[36, 40], [36, 40], [36, 40], [36, 40]], the first episode and the second are always different. From the second episode to the rest, they are the same. I printed out the world location of these points pairs and they are the same.
The command I used to launch the Carla is:

./CarlaUE4.sh /Game/Maps/Town01 -carla-server -benchmark -fps=15 -windowed -ResX=800 -ResY=600

Any idea how can I fix it? Thanks a lot.
BTW, this happened only when I run my script before launching Carla.

Hey @TairuiWang
Thanks for the issue.
I will try to reproduce it soon !
Seems that it may be a bug.
Cheers.

Please check issue #310
The episodes positions change after the first reset.
We wont fix this for now ( There is a turnaround when running the benchmark),
but this problem wont exist in the next CARLA major version, since we are going to change the API.


How to use TTA for mmrotate1.x?

Hi, When I use the TTA in mmdet for the test in mmrotate1.x, I found that the function merge_aug_bboxes need a input tensor like  aug_bboxes (list[Tensor]): shape (n, 4#class) .
However, for now, mmrotate1.x only support the output fomat like  (x, y, w, h, theta),  so i have no way to convert it.
Is there any tips for me to use TTA in mmrotate1.x correctly? Maybe I miss some document.
Thanks for help.

Hi, I use the change in https://github.com/open-mmlab/mmrotate/pull/771.
tta works, but the result is bad. I don't know why tta produce a lot of  wrong bboxes. I don't know why.

@Haru-zt Please to mmrotate create a issue


Result<T, E> should support reference-type T and E

This requires using storage as a pointer (like Option's StoragePointer) and a lot of care to preserve references instead of copying/moving the underlying types.
It's plausible to not support reference types in the E parameter. But returning a static string reference should also be okay?

https://github.com/chromium/subspace/pull/161 adds helpers to construct Option and Result, Result can copy the way Option did this to support references, and should test the same way.


Extract SectionFactory

This allows me to remove the DocumentFactoryRegistry#section_factory_factory and, in my opinion, leaves the code in a more understandable state.

Thanks @floehopper. I've rebased on master and force pushed in preparation for merging.


MIC-625 /update-plan/update-intervention-details screen

MIC-625

Codecov Report
Attention: Patch coverage is 70.73171% with 12 lines in your changes missing coverage. Please review.

Project coverage is 90.52%. Comparing base (8990724) to head (a5f37d3).

Files with missing lines
Patch %
Lines

...ate-plan/update-intervention-details/controller.ts
50.00%
8 Missing and 1 partial :warning:

server/routes/journeys/base/patchPlanController.ts
33.33%
2 Missing :warning:

...update-plan/update-intervention-details/schemas.ts
87.50%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #254      +/-   ##
==========================================
- Coverage   90.77%   90.52%   -0.25%
==========================================
  Files         275      278       +3
  Lines        4130     4171      +41
  Branches      638      642       +4
==========================================
+ Hits         3749     3776      +27
- Misses        379      392      +13
- Partials        2        3       +1

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


Publish a new version to fix #179

I am waiting for a new version to be published on NPM, because we highly need the fix of #179.
Please publish a new version with this fix ASAP.

v4.4.1 is released.


Implement ChildCount, LeafCount Aggregation

Useful when we need to provide this data for rendering in Tree Grids, especially the Label Column
Another option is to just build this into the Cube API, such that a "childCount" and a "leafCount" will always  be available on view data (and automatically loaded into Store Fields with the same name).  In that case would just need to be careful about triggering more store/grid updates than are actually need if user does not actually want to use the counts.

It looks like we already have such aggregators in our admin package: https://github.com/xh/hoist-react/tree/develop/admin/tabs/activity/aggregators - should we promote these?

Hah -- and only a year ago -- I knew we had done that several times
before,  but had not realized it was in the context of hoist-react.
Great find -- yes, I think we should, with documentation.
On Fri, Jul 30, 2021 at 5:38 PM Petra Laohakul @.***>
wrote:

It looks like we already have such aggregators in our admin package:
https://github.com/xh/hoist-react/tree/develop/admin/tabs/activity/aggregators

should we promote these?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/xh/hoist-react/issues/2562#issuecomment-890167107,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARTL2PGD62Z6432EE5AYC3T2MLTVANCNFSM5BHN3JWQ
.


Fixing spring-boot integration by excluding slf4j-nop from the transi…

…tive dependencies

Coverage remained the same at 100.0% when pulling bcd9c8d51f13cafc0d4dadd96c18b27c22f4d151 on lyncodev:master into fc40fe7041aab70880cf60f3c1efd404f488a112 on jtwig:master.


Does this bot like comments or videos? I will send paypal donation if it works.

I'm looking for a bot that likes comments on youtube videos even if they are from a real person or someone else. Does this bot like videos, comments or both?

You can both like and comment videos.


Correct typo in error message

[ ] Tests added / passed
[ ] Passes black dask / flake8 dask

I see this is your first time contributing @tmct -- welcome and thank you!


[cf-core] Remove calls to sortBySignerAddress

Describe the bug
Signers should be sorted by initiator, responder in all cases -- make sure this is enforced throughout all commitments and this method is not used in the protocol (fine for contract tests).

Closing, completed!


JAX dtype conversion seems incorrect

Description
for a floating point number -1.6171875.
x=jax.numpy.asarray([-1.6171875],dtype=jax.numpy.float32)
if you use astype bf16:
x.astype(jax.numpy.bfloat16)
DeviceArray([-1.61719], dtype=bfloat16)
or astype fp16:
x.astype(jax.numpy.float16)
DeviceArray([-1.617], dtype=float16)
Both of them seem incorrect for IEEE754 floating point format. For -1.6171875, both fp16 and bf16 truncation should result in the same float as the extra mantissa bits in fp32 are all zeros: -1.6171875 in binary is '10111111110011110000000000000000'
Of course, it is possible that I was not using the correct way to do dtype conversion in Jax. If someone could point me in the right direction?
What jax/jaxlib version are you using?
No response
Which accelerator(s) are you using?
No response
Additional system info
No response
NVIDIA GPU info
No response

Interestingly, this appears to be even worse in Torch.
I just tested this with these versions:

jax==0.4.14
jaxlib==0.4.14+cuda12.cudnn89
numpy==1.23.1
torch==2.1.0.dev20230819+cu121
torchaudio==2.1.0.dev20230820+cu121
torchvision==0.16.0.dev20230820+cu121

jax.devices(): [gpu(id=0)] # An NVIDIA 3090, CUDA 12.1
x: [-1.6171875]
jnp.float32(x): [-1.6171875]
jnp.bfloat16(x): [-1.61719]
jnp.float16(x): [-1.617]
np.float32(x): [-1.6171875]
np.float16(x): [-1.617]
torch.float32(x): tensor([-1.6172])
torch.float16(x): tensor([-1.6172], dtype=torch.float16)
torch.bfloat16(x): tensor([-1.6172], dtype=torch.bfloat16)

However, the issue only appears to affect the bf16 datatype, when x is not an array.

x: -1.6171875
jnp.float32(x): -1.6171875
jnp.bfloat16(x): -1.61719
jnp.float16(x): -1.6171875
np.float32(x): -1.6171875
np.float16(x): -1.6171875
torch.float32(x): -1.6171875
torch.float16(x): -1.6171875
torch.bfloat16(x): -1.6171875

I think the conversion is working as expected, but the default decimal representation is misleading. Taking a look at the bits, it's clear that bf16 maintains the original bit pattern as expected (i.e. chopping off the extra mantissa bits compared to f32):
import jax

x = jax.numpy.asarray([-1.6171875],dtype=jax.numpy.float32)
print(jax.numpy.unpackbits(x.view('uint8')))
# [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1 1 1 1 0 1 1 1 1 1 1]

x_bf16 = x.astype('bfloat16')
print(jax.numpy.unpackbits(x_bf16.view('uint8')))
# [1 1 0 0 1 1 1 1 1 0 1 1 1 1 1 1]

x_f16 = x.astype('float16')
print(jax.numpy.unpackbits(x_f16.view('uint8')))
# [0 1 1 1 1 0 0 0 1 0 1 1 1 1 1 0]

You can confirm that the casts do not lose precision by casting back to the original type and finding that it is bitwise equal:
print(x_bf16.astype('float32') == x)
# [ True]

print(x_f16.astype('float32') == x)
# [ True]

Thank you for confirming the behaviour. Is there a way to change the default decimal representation? Since I would like to compare intermediate results with torch, but I found it difficult this way.

JAX printing is outsourced to NumPy, so it can be controlled using numpy's printoptions.


drawerAction dissapears after clicking "< Back" on iOS

tabris.ui.drawer.enabled = true; and drawerActionVisible: true on NavigationView is set and Drawer works perfectly (drawerAction is visible) until I open any page and click "< Back". After this, drawerAction icon is diapered.
If I close page using page.dispose(), there is no problem and drawerAction is still visible. Only problem is with "< Back" button and only on iOS.

Thanks, we're looking into this

@bev-on I tried to reproduce the issue you described with the snippet I post below, and I'm unable to. Any additional configuration or actions are required?
tabris.ui.drawer.enabled = true;

var pageId = 0;

var navigationView = new tabris.NavigationView({
  left: 0, top: 0, right: 0, bottom: 0,
  drawerActionVisible: true,
}).appendTo(tabris.ui.contentView);

var appendNewPage = function() {
	var page = new tabris.Page({
	  title: 'Page ' + pageId
	}).appendTo(navigationView);

	new tabris.Button({
		text: 'Append new page'
	}).on('select', function() {
		appendNewPage();
	}).appendTo(page);

	new tabris.Button({
		text: 'Dispose this page',
		top: 'prev() ' + 20,
	}).on('select', function() {
		page.dispose();
	}).appendTo(page);

	pageId++;
}

appendNewPage();

@karolszafranski your code works fine for me as well...
After some tests, finally find what causes this behavior. I have tabris.Action added on main page, but this action should be active only on main page and not on another pages.
My solution was to set visibility: true when home page appeared and  visibility: false when home page disappeared on this Action.
Looks like if you set visibility: false to other actions, it doesn't affects drawerAction visibility, but when you set visibility: true again to this hidden action, drawerAction disappears  for some weird reason.
If you run following code, you can simulate this behavior:
tabris.ui.drawer.enabled = true;

var navigationView = new tabris.NavigationView({
    left: 0, top: 0, right: 0, bottom: 0,
    drawerActionVisible: true
}).appendTo(tabris.ui.contentView);

function loginPage(){
    return new tabris.Page({
        title: "Login",
        topLevel: false
    });
}

var testAction = new tabris.Action({
    id: "test_action",
    title: "test",
    placementPriority: "high"
}).appendTo(navigationView);

var homePage = new tabris.Page({
    title: "Home Page"
}).on("appear", function() {
    testAction.visible = true;
}).on("disappear", function() {
    testAction.visible = false;
});

new tabris.Button({
	text: 'Login Page',
    layoutData: {left: 20, top: 50}
}).on('select', function() {
	loginPage().appendTo(navigationView);
}).appendTo(homePage);

homePage.appendTo(navigationView);

Current workaround is to hide and show drawerAction as well with other action and it will fix this issue:
var homePage = new tabris.Page({
    title: "Home Page"
}).on("appear", function() {
    testAction.visible = true;
    navigationView.drawerActionVisible = true; // drawerAction visibility fix
}).on("disappear", function() {
    testAction.visible = false;
    navigationView.drawerActionVisible = false; // drawerAction visibility fix
});

if someone have same problem they can use this workaround temporarily.

@review-squirrel is this issue solved? Changing visibility of another Action shouldn't be affecting Drawer Action. I can't see any reason why you closed this issue.

@bev_on: review-squirrel is a bot.  Best to check with @karolszafranski

@bev-on the issue has been fixed in ios. could you try the latest nightly build to see if it works our for you?

@mpost @karolszafranski Thanks guys, this issue is fixed in latest nightly.


run script build failed  - UglifyJs

The library is working properly in development but when am trying to create build it is getting failed with following error
static/js/main.5310c3fe.js from UglifyJs
SyntaxError: Unexpected token: punc ()) [./~/react-image-crop/dist/ReactCrop.min.js:1,263]
i am using "react-image-crop": "^8.6.6"

Uglify has been deprecated for a long time and doesn’t support ES6+ syntax well, it’s probably choking on some. You should be using Terser but more importantly you shouldn’t be running minification or probably anything else on files inside node_modules (and the file is already minified)

I am running this commond only "npm run-script build"

On which package? You don’t need to run the build command manually when installing the package as an NPM module

On which package? You don’t need to run the build command manually when installing the package as an NPM module

on dev environment it is working. but when I try to create a build it gives uglify error

I have the same issue in a 3-year-old CRA project. It had already been ejected so I could access the webpack.config.prod file where you need to replace the deprecated uglifyjs package with terser package.
I am listing the steps I took below;

Install "terser-webpack-plugin-legacy": "^1.2.5" package.
Import const TerserPlugin = require('terser-webpack-plugin-legacy'); into the webpack.config.prod file.
Comment the code for webpack.optimize.UglifyJsPlugin object.
Place new TerserPlugin(), right below the commented code.
Build the app as normal and it works 🎆

It sounds as though you are running webpack on node_modules which is generally not a good idea, it should work ok if you exclude your rules from running on node_modules e.g
{
  test: /\.tsx?$/,
  exclude: /node_modules/,
  use: 'ts-loader',
}


Implementation of Singly Linked List in Python Folder

Please review this.

Task assigned to me in issue (#120 )
Kindly review now @geekquad


Kustomize Support

👋 Hello, folks! I noticed the explicit check (and failure) for kustomize resources. Would you be open to PRs to support that side of the house?

Hey bud! For sure, PRs are always welcome.

While putzing around with this, I cant help but feel that declaring this as an ArgoCD tool is quite limiting. This could very well support any tree of helm files.
Interestingly, the kustomize implementation is quite trivial, since it supports traversing trees (via successive kustomization.yaml files) natively. The value that I see in this repo is bringing that same walking behavior to helm.
Wdyt about rebranding things a bit? I don't think there'd be much to change, code wise. For helm, you give it a dir and let it walk. For kustomize you give it a dir (or several) and punt to kubectl apply -k dir --dry-run=client (and which actually walks backwards, itself).


vimPlugins.sqlite-lua: fix patching of sqlite3 cpath

Motivation for this change
With the rename, also came some configuration changes
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Duplicate of #136942
IMO, the other PR looks better

Duplicate of #136942
IMO, the other PR looks better

Merging this as it fixes an regression. We can improve the code for darwin in the other PR.


Fix 114 Unclear/non-standard response for post api/v1/pit/pid

This will change the API responses a little, making them more consistent. Merging and releasing these changes must result in a new major release. The PR is comparatively large because of a refactoring that has been postponed for some time, but is now necessary.

[x] Design more flexible validation strategy structure
[x] Make use of it on create & validate
[x] Fix #114

[x] Test: 201 created on successful creation:
https://github.com/kit-data-manager/pit-service/blob/9f51d87395dce353175a387f86bc99877875746e/src/test/java/edu/kit/datamanager/pit/web/RestWithLocalPidSystemTest.java#L431
[x] Test: 400 on validation errors with details in body (with different issues in records)

Implementation: https://github.com/kit-data-manager/pit-service/pull/125/commits/ecef206d8e1f0eb8ada9b23b3b0fa3078bf22db6#diff-c84a84ccca36a22aa39ea8ff3ed594df2d34dc16f675ee19996e44d305bf4c83L13
Tests: (example) https://github.com/kit-data-manager/pit-service/pull/125/commits/ecef206d8e1f0eb8ada9b23b3b0fa3078bf22db6#diff-a611995f9031d8f10caea3eaf1ed9e8150899f129453a916429554360d7046c7L127

[x] Test: 415/406 on issues with given content/accept types: https://github.com/kit-data-manager/pit-service/pull/125/commits/4a03dea773b1b50a50d395656228b8dfc50765dc#diff-a06b401ed68f6d4a634622208d1ff88320b6caa2bdf9d9bdc73cabf4b9fa1b6b
[x] Test: 412/428/304/200 on ETAG comparison. (Consider https://www.baeldung.com/etags-for-rest-with-spring): https://github.com/kit-data-manager/pit-service/pull/125/commits/435807f45b47a0a89aca5a502d5c771cc8dc0337
[x] Test: 409 if an explicitly given PID already exists (might happen if we support custom PIDs soon) https://github.com/kit-data-manager/pit-service/pull/125/commits/906cac2ac776077bd2bd65ccf67793eba50d3e4c
[x] Impl: 500 on unexpected errors in the Typed PID Maker: Used Validation Exception (http 400) where applicable. https://github.com/kit-data-manager/pit-service/pull/125/commits/14fcecfb7ac7aace302dd9465919dff27fa94638
[x] Impl: 503 on unavailability of DTR or other external services we need to use.
[x] Check if 409 should be applicable in more cases does not seem to be the case

[x] Wait for #128 and #127 to be merged, then merge master in here.
[x] Update Documentation in javadoc / openapi with the correct/extended return codes.
[x] double-check the error messages, e.g. from validation errors, are fully contained in the body response (message header). Currently, they are not. Here are some approaches which should solve this: https://www.baeldung.com/spring-response-status-exception
[x] See if we still return the wrong error code (400/409) here and how we can change this: https://github.com/kit-data-manager/pit-service/issues/135 --> fixed, returns 500 now. We now have a class which can override exception to response conversion on the basis of the exceptions classes.

Seems like we need to catch org.h2.jdbc.JdbcSQLDataException, which is not thrown directly from our code, but in some background thread. It could be done using this Spring feature: https://www.baeldung.com/exception-handling-for-rest-with-spring#controlleradvice
To cause the issue for testing, in PidDatabaseObject change @Column(length = $largeNumber) to @Column(length = 255) and run the createExtensiveRecord test for the Local PID system. Remember master needs to be merged in beforehand (done), in order to get the required changes there.

[x] Remove HandleSystemRESTAdapter as we can not test it, and it is not fully implemented anyway. It may be added again in the future, but then with support for key/certificates only. Preferably with an official handle client implementation for the REST interface.
[ ] Write tests for the other APIs to ensure the openapi definition is correct

Breaking changes/fixes

Validation error changed from 409 to 400
Inconsistencies are now considered a validation error and changed from 500 to 400 as above.
Unavailable services are now indicated by 503 instead of the generic 500
Etag implemented, breaking usage of update calls
Removes legacy REST support for Handle until we have an implementation that supports certificates/keys

At least the ETag implementation can be considered a breaking change. Therefore, it will be added to the new major release milestone.

Before testing the other endpoints, I'd like to evaluate which ones we do actually need. As we have a new major release anyway, this would be a good point to remove (and add) new ones. This should happen with better validation tooling in mind. Some thoughts:

(keep) search API for Elasticsearch (if enabled)
(keep) Resolve the record of the given PID.
(keep) Update an existing PID record
(keep) Create a new PID record
(keep) Check if the given PID exists.
(keep) Return known PIDs (two endpoints)
(remove) Resource matching type?

current documentation: "Check if a certain resource with a given PID is matching a type. The type is identified by its PID provided as path segment(s), whereas the resource is identified via its PID as request parameter."
currently basically does validation, which is handled using the functions below. Remove if other use stays unclear.

(improve) Get a profile (resolve + redirect)

evolve to generic "getDownloadUrl(pid) ⇾ URL"?

(improve) PID matching profile? (validation)

evolve to call like: validate(PID, optional-profile, optional-strategy)
if a profile is given, only check this profile. No matter if the profile is specified in the PID record. Else validate the record with its given profiles.
if strategy is given, use it. Else use the service default.

(add) Validate hypothetical PID content against profile (validate before registration manually or even without the intention to register yet)

similar to validation above, but with record content which does not have to be registered yet.
like: validate(record-content, optional-profile, optional-strategy) ?

Two of the three points to change/remove have to do with validation. How would a proper validation rest interface look like? Currently, it is like this:

HEAD /api/v1/pit/type/$profile_identifier

header "identifier" for PID to validate
intended function: deep validation against a single profile
implemented function: deep validation against a single profile, assuming to additional attributes allowed

HEAD /api/v1/pit/profile/$profile_identifier

header "identifier" for PID to validate
intended function: "mandatory attributes are present" validation
implemented function: "mandatory attributes are present" validation

Analyse non-sound components in the current method:

Is HEAD the right operation? "The HEAD method asks for a response identical to a GET request, but without the response body."

-> probably not

does it make sense that /type means deep validation and /profile only checks for mandatory attributes?

I do not think so. In both cases, it is the profile being the entity: type/$profile-pid does not make a lot of sense.

How would a more REST-like interface for validation look like?

For registered PIDs, this could be valid:

GET api/v1/pit/pid/**/validate

issue: not sure if we can make this /**/validate part
using headers for optional parameters like specific profile(s) or validation method(s)
like in the HATEOAS example on Wikipedia:"links": {
    "deposit": "/accounts/123abc/deposit",
    "withdraw": "/accounts/123abc/withdraw",
    "transfer": "/accounts/123abc/transfer",
    "close": "/accounts/123abc/close"
 }

This could replace all the current validation endpoints due to the flexibility with parameters.

For content which is not (yet) registered, this could be valid:

POST api/v1/pit/validator

body for content to validate
using headers for optional parameters like specific profile(s) or validation method(s)

I did a small draft (parameters missing etc) of how this may look like on swaggerhub.

In my opinion, there is a certain conceptual conflict of using a RESTful interface to perform actions that are actually Remote Procedure Calls. Furthermore, using sub-endpoints like GET api/v1/pit/pid/**/validate for actions, that are actually used to access sub-resources in REST, may lead to some confusion. Also the approach of using HEAD controlling the result by request headers seems to be a bit too creative assuming that HEAD is just meant to be used to request resource-related information without transferring data, e.g., to obtain a resource's content length.
In my humble opinion I would utilize the POST endpoint including a request parameter, e.g., POST api/v1/pit/pid?dryrun=true (or something comparable) to allow using the create endpoint also in the validation-only scenario. Additional parameters may control the validation type, e.g., basic or deep. All other arguments, i.e., profile and digital object type, should be sent in the body the same way as a PID Record will be send in the create-scenario.
I'm also aware that you'll find articles which say, that POST should not require query parameters, but as they are optional I see not a huge problem here compared to the other options that are on the table.

using sub-endpoints like GET api/v1/pit/pid/**/validate for actions, that are actually used to access sub-resources in REST, may lead to some confusion

I would not send a resource, I would simply trigger an action on an existing resource (the PID), similar to the HATEOAS example. All these examples are RPCs in some regard, aren't they?

POST api/v1/pit/pid?dryrun=true (or something comparable)

I like it. The query parameter could also be a header (checking both), to satisfy those blog articles :). But it would only make sense to new records. What about validation of existing ones? Do people need to resolve it, or should they be able to resolve via PID? As this is the create endpoint, would validation fail if there is a PID given which is already registered? I can imagine this one, based on resolving, which could be handy for existing PIDs:

GET api/v1/pit/pid/**?validation=true/strict/none(default)/$other (or something comparable)

While I like them, both kind of hide the validation capabilities behind the CRUD ones. Is this desired?

I would not send a resource, I would simply trigger an action on an existing resource (the PID), similar to the HATEOAS example. All these examples are RPCs in some regard, aren't they?

True, I was just referring to the use of sub-paths in a URL. They typically point to sub-resources and not to functionalities. Functionalities I would rather address by query parameters (see last point)

I like it. The query parameter could also be a header (checking both), to satisfy those blog articles :). But it would only make sense to new records. What about validation of existing ones? Do people need to resolve it, or should they be able to resolve via PID? As this is the create endpoint, would validation fail if there is a PID given which is already registered? I can imagine this one, based on resolving, which could be handy for existing PIDs:

Header would also be fine, but makes it harder to be included somewhere, e.g., only as link. If both options are supported, that's also fine, but you should be aware of conflicting parameters in header AND query.

While I like them, both kind of hide the validation capabilities behind the CRU~D~ ones. Should I still go with it?

Well, as I said...to main focus of a RESTful interface is CRUD to documents aka. resources. Therefore, I would expect all functionality to be kind of hidden in request parameters, whereas the default remains the CRUD on resources.

Okay good. Sounds like a plan :). I'll see if I can somehow reasonably include the PID record in the error message somewhere (for the GET validation, at least). If this does not work, I'll check for other options.

Update: The responses are all fine using a rest client, but the mockMvc response bodies are empty if it is an error. So everything is working fine.
The pid-record is also included in the body response, but currently falsely serialized due to the optional type. Will fix this.

[ ] fixed the record serialization in error cases

We are done :) The last commit somehow did not trigger the tests, so I triggered them manually here and everything looks good: https://github.com/kit-data-manager/pit-service/actions/runs/6131983116


Changing the quantity of the product in the cart doesn't change its price (offline mode)

Current behavior

In offline mode, changing the quantity of the product in the cart does not change its price. Grand total is changing properly.
Gif:  https://drive.google.com/file/d/1nxMzu9E0AOw-knQF3EGhUqCfjqlOI6I3/view?usp=sharing
Expected behavior

In offline mode, changing the quantity of the product in the cart change its price as well.
Steps to reproduce the issue

Go to branch develop
Add any product to cart
Change the Qty and look at how Product price and Grand total are changing
Go to offline mode
Change the Qty and look at how Product price and Grand total are changing

Can you handle fixing this bug by yourself?

[ ] YES
[x] NO

Which Release Cycle state this refers to? Info for developer.
Pick one option.

[x] This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
[ ] This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
[ ] This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

Browser: Chrome73
OS:Ubuntu 18.04 LTS

Additional information

This issue doesn't appear on demo. Maybe related to #2828

Change the Microcart/Product.vue and how it handles the offline mode

@pkarw Here, I have also forgotten about the order summary in the checkout - the quantity of the product is correct but the price is not.

Thanks! Fixed on branch https://github.com/DivanteLtd/vue-storefront/pull/2887


fix: use dynamic components in root.svelte instead of svelte:component for svelte 5

Closes #12573
Again i'm not really sure if and where i should add a test for this. Also for the moment i did not rename constructors to something else in svelte 5 because there was still the possibility to share some code but i'm willing to completely split the two branches if we feel like.
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

[x] Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

/ecosystem-ci run


Add large communities decoder and fix local pref attribute flag validation

I'm evaluating corebgp for use in a small project. When I last looked at this package maybe a year ago I noticed that it had no native ability to decode update messages so i resolved this by pulling in some functions/types from gobgp. Thank you for adding native decoding! For my use case I need to be able to decode large communities so this change adds that since it appears it was missing. Additionally I observed that the local preference decoder was not correctly validating attribute flags. Local pref is a well-known attribute which means the transitive flag must be set to 1 and all other flags are 0:

It looks like this was incorrectly set to expecting the optional flag as 1 (true) and transitive as 0 (false) so I fixed this and added some test cases.
Lastly, I added some simple changes to the example decoder to show how to decode/display MED, Local Pref and Large Communities.

@jwhited Any thoughts on this? Thanks again!


Update node

Update the version of node available on most of the machines, but leave the performance platform on the older version as they are still dependant on it.
Closes https://github.com/alphagov/govuk-puppet/issues/5942
Trello Card Trello Card

Tested on integration, seems to be working:
❯ ssh jenkins-1.integration
Last login: Fri Aug 18 13:12:21 2017 from jumpbox-1.management.integration.publishing.service.gov.uk
thomasleese@integration-jenkins-1:~$ node --version
v6.11.2

❯ ssh performance-frontend-1.integration
Last login: Fri Aug 18 13:14:55 2017 from jumpbox-1.management.integration.publishing.service.gov.uk
thomasleese@integration-performance-frontend-1:~$ node --version
v0.10.37

cc @surminus @nickcolley

I think the only place we current use Node.js on the main machines is in Sprockets JavaScript uglification, so we'd want to check the JavaScript output potentially for an application.

Just checked the digests of the assets in integration and production, and they match.

Plus performance platform still seems to be working fine in integration.

Looks good to me 👍
(Will await someone who knows how Puppet works :))

Couple of comments but it looks good! I think we install statsd with npm, so please check that's OK (which I'm sure it is).

@surminus Thanks, I've addressed your comments. Regarding statsd, I saw that it installed correctly, and the following command returns something good:
thomasleese@integration-jenkins-1:~$ sudo service statsd status
statsd start/running, process 785

Anything more I could check?

We use statsd for counters like number of status codes appearing in nginx for example, so I guess just check that graphite for these metrics don't disappear.

@surminus Just checked in graphite, and there does appear to be data for the last hour in there.


fix(checkout): INT-5543 [CKO] Update to 3DS on Google Pay

What? INT-5543
Add Checkout.com's GooglePay to the list of providers that require a redirect but are not a Hosted Payment Method.
Why?
So the Prompt for leaving the page does not interfere with the offsite redirection that Google Pay requires.
Testing / Proof
Demo Video
@bigcommerce/checkout @bigcommerce/apex-integrations

💚  Tested
QA Details:
CHKO with GPay using MC 3ds, Tested and working as expected...
Unfortunately, GPay doesn't have MC 3ds's CC.  We tested with all CCs included in Gpay...
Evidence
Waiting for Roll out in order to verify everything going well...


2023-02-09 20:28:49.554 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:49 +0100 "}'
2023-02-09 20:28:49.601 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:49.604 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:49.605 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:49 +0100 "}'
2023-02-09 20:28:49.653 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:49.655 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:49.655 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:49 +0100 "}'
2023-02-09 20:28:49.704 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:49.705 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:49.706 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:49 +0100 "}'
2023-02-09 20:28:49.778 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:49.786 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:49.787 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:49 +0100 "}'
2023-02-09 20:28:49.834 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:49.836 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:49.837 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:49 +0100 "}'
2023-02-09 20:28:49.885 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:49.887 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:49.887 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:49 +0100 "}'
2023-02-09 20:28:49.936 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:49.936 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:49.937 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:49 +0100 "}'
2023-02-09 20:28:49.990 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:49.997 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:49.997 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:49 +0100 "}'
2023-02-09 20:28:50.050 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.057 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.100 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.148 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.157 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.157 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.207 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.218 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.219 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.266 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.268 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.268 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.316 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.318 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.319 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.367 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.367 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.368 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.416 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.420 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.421 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.469 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.470 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.471 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.518 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.522 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.522 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.568 - info: influxdb.0 (31913) No Data
2023-02-09 20:28:50.571 - info: influxdb.0 (31913) No Data
2023-02-09 20:28:50.571 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.571 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.572 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.607 - info: influxdb.0 (31913) No Data
2023-02-09 20:28:50.609 - info: influxdb.0 (31913) No Data
2023-02-09 20:28:50.614 - info: influxdb.0 (31913) No Data
2023-02-09 20:28:50.617 - info: influxdb.0 (31913) No Data
2023-02-09 20:28:50.622 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.622 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.623 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.635 - info: influxdb.0 (31913) No Data
2023-02-09 20:28:50.637 - info: influxdb.0 (31913) No Data
2023-02-09 20:28:50.654 - info: influxdb.0 (31913) No Data
2023-02-09 20:28:50.657 - info: influxdb.0 (31913) No Data
2023-02-09 20:28:50.670 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.672 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.673 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.720 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.724 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully
2023-02-09 20:28:50.765 - debug: apcups.0 (27542) UPS state: '{"APC":"001,049,1189","DATE":"2023-02-09T20:27:50+01:00","HOSTNAME":"Unraid","VERSION":"3.14.14 (31 May 2016) slackware","UPSNAME":"Unraid","CABLE":"Ethernet Link","DRIVER":"SNMP UPS Driver","UPSMODE":"Stand Alone","STARTTIME":"2023-02-05T04:40:03+01:00","MODEL":"Smart-UPS 750","STATUS":"ONLINE ","LINEV":237,"LOADPCT":11,"BCHARGE":100,"TIMELEFT":81,"MBATTCHG":10,"MINTIMEL":10,"MAXTIME":0,"MAXLINEV":"239.0 Volts","MINLINEV":"236.0 Volts","OUTPUTV":"237.0 Volts","SENSE":"High","DWAKE":"1000 Seconds","DSHUTD":"20 Seconds","DLOWBATT":"2 Minutes","LOTRANS":208,"HITRANS":253,"RETPCT":"0.0 Percent","ITEMP":"21.0 C","ALARMDEL":"5 Seconds","BATTV":27,"LINEFREQ":"50.0 Hz","LASTXFER":"Automatic or explicit self test","NUMXFERS":1,"XONBATT":"2023-02-08T12:33:12+01:00","TONBATT":0,"CUMONBATT":5,"XOFFBATT":"2023-02-08T12:33:17+01:00","LASTSTEST":"2023-02-08T12:33:12+01:00","SELFTEST":"OK","STESTI":"OFF","STATFLAG":"0x05000008","MANDATE":"10/19/2011","SERIALNO":"AS1143110662","BATTDATE":"07/15/2022","NOMOUTV":"230 Volts","EXTBATTS":"0","BADBATTS":"0","FIRMWARE":"UPS 05.0 / COM 02.1","END APC":"2023-02-09 20:28:50 +0100 "}'
2023-02-09 20:28:50.838 - debug: apcups.0 (27542) Disconnected from apcupsd '<IP_ADDRESS>:3551'
2023-02-09 20:28:50.843 - debug: apcups.0 (27542) Connected to apcupsd '<IP_ADDRESS>:3551' successfully`

According to logs - you set interval to 10. Actually, it is 10 ms. Try to change to 10000 because 10 ms it is very often for polling.

Thanks very much! That was it...
had set it to 50 before. wasn't really any better...
milliseconds why didn't I think about it


protobuf: format

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Should we add an entry in .git-blame-ignore-revs ?

Should we add an entry in .git-blame-ignore-revs ?

Usually we don't bother.


Fix erroneous behaviour when combining host and relative path

Fixes #531

Thanks.

This is wrong and must be reverted. How can this be accepted changing an explicit test without referencing the lenghty discussions we already had about this and the RFC ammendments that were proposed.

There is even a deprecation in 1.x about this: https://github.com/guzzle/psr7/blob/e98e3e6d4f86621a9b75f623996e6bbdeb4b9318/src/Uri.php#L801-L807

There was a discussion in Slack about this (unfortunately no longer accessible because of the 90 day retention). It was decided that both the previous and updated implementation were wrong, since the previous implementation disallowed too much, and the new implementation allows too much, and that we'd rather allow too much where it's not too harmful to do so. I don't remember the specific cases I'm afraid.

If you feel strongly about this, I don't oppose reverting this. I am pretty neutral either way.

Yes I feel strongly about it because it violates RFC 3986 by not forming a valid URI. The workarounds mentioned in PSR-7 are only artifacts e.g. due to old PHP version not supporting throwing exceptions in __toString. But those workarounds have already been deprecated in 1.x. It does not make any sense to revert this again. Then the whole deprecation is pointless.

Then we could revert this and say this was a bug we introduced in 1.4.2, and we're fixing it again in 1.4.5.


Ensure TestModel handles result retries correctly

The TestModel only handled retries in function tools, not final tools.

thanks so much.


Update userscript

Hi there. This is my attempt to update userscript. I prefer the userscript over extension.
The update code seems to work fine, dunno if there're (big) problems to iron out, but at least it's working.
This is similar to version 1.17.0, not 1.17.1. I tried to integrate latest commit, but after that Instagram website becomes very laggy and unresponsive. Also, my JavaScripts skills aren't that great, still learning JS :)

Sorry for the late reply.
Thanks your PR, But I don't want to maintain this UserScript :(
You can fork the code and push it on Greasy Fork. It's OK. 😄


Add auto height and width to detail.css

As noted in #36, I have added the required css.
Anything more?

Tested using the scatterplot and additional css for wrap:
<style type="text/css">
	.rickshaw_graph .detail .item.active {
		white-space: pre-wrap;
	}
</style>


🐞 Adapt scripts to src directory

Good idea to de-clutter the project root ;)
I adapted the shell scripts where it was needed to work with that new change. Did I miss something?

You can ignore this PR - the change is incorporated in #71 as well.


Make Phone & Email of Contact optional. Simplify some functions in ParserUtil

Codecov Report

Merging #181 into master will decrease coverage by 0.47%.
The diff coverage is 55.81%.

@@             Coverage Diff              @@
##             master     #181      +/-   ##
============================================
- Coverage     49.62%   49.14%   -0.48%
+ Complexity      573      568       -5
============================================
  Files           125      125
  Lines          2632     2639       +7
  Branches        318      324       +6
============================================
- Hits           1306     1297       -9
- Misses         1217     1223       +6
- Partials        109      119      +10

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/trackitnus/model/task/Task.java
75.75% <ø> (-0.72%)
13.00 <0.00> (-1.00)

...c/main/java/trackitnus/ui/contact/ContactCard.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

.../main/java/trackitnus/logic/parser/ParserUtil.java
57.14% <18.18%> (-5.49%)
23.00 <4.00> (ø)

...in/java/trackitnus/storage/JsonAdaptedContact.java
83.78% <60.00%> (-16.22%)
7.00 <0.00> (-2.00)

...rc/main/java/trackitnus/model/contact/Contact.java
94.73% <81.81%> (-5.27%)
20.00 <2.00> (ø)

...nus/logic/commands/contact/EditContactCommand.java
96.72% <100.00%> (ø)
12.00 <0.00> (ø)

.../logic/parser/contact/AddContactCommandParser.java
100.00% <100.00%> (ø)
5.00 <0.00> (ø)

...logic/parser/contact/EditContactCommandParser.java
91.66% <100.00%> (ø)
10.00 <0.00> (ø)

Continue to review full report at Codecov.

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

Hi @simonteozw . In this PR I have made the following changes:

made Email & Phone to be optional (this took quite a lot of time but I have done some manual testing and it seems to be working well)
replaced the Task.isValidString by a simple call to String.isBlank (because I think your intention is to check if a string is blank or not)
Please help me review this PR! Thanks a lot (x100)!


Empty window trust: should not mention workspace settings

Testing #124984
In an empty window, workspace settings do not apply:

Similar on the left hand side:


Publish 09/29/2021, 10:30 AM

Docs Build status updates of commit e44d8dc:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/New-ApplicationAccessPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/New-Label.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/New-TenantAllowBlockListSpoofItems.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Set-EventsFromEmailConfiguration.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Set-Label.md
:white_check_mark:Succeeded
View (exchange-ps)

skype/skype-ps/skype/Set-CsOnlineEnhancedEmergencyServiceDisclaimer.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Change item deletion to a dialog on the character sheet.

It is much too easy to accidentally delete an item on the character sheet, given the size of the buttons and the controls being grouped with the Edit button which is used very frequently.
Changing the function on it to a confirmation dialog would go a long way, especially for users with bad eyesight (or fat fingers).
Also being able to shift-click to quick-delete would align well with core behavior of rolls.

This needs to be a thing, please let it be a thing. Too often happens that I delete something and don't even notice it.


Fix for Issues 812 prevent creation of dashboard with same name.

https://github.com/capitalone/Hygieia/issues/812

LGTM

LGTM. :+1:

LGTM


Increase items displayed per page for a given search string in Registry

From the screenshot we can see that when searched "busybox"  in Registry, the page displayed only 3 rows though 50 matches were found.
Displaying only three matched entities is too less. 10 would be optimal.
Same is the case with Projects(only 5 matched entities are displayed and 10 would be optimal).
Please consider this UI enhancement.

@lgayatri
Thanks for raising issues, we'll carefully consider your comments and find proper time to put the fix in.

Fixed in PR #2601, increase page size to 15


Dev

@abellahoz,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla2.dotnetfoundation.org.
It will cover your contributions to all .NET Foundation-managed open source projects.
Thanks,
.NET Foundation Pull Request Bot

What's this PR for?

Hello Allen,
You can cancel it, it´s a mistake.
I´m sorry for the inconvenience.
[image: FHIOS | SMART KNOWLEDGE] http://www.fhios.es/
Abel Lahoz Gargallo
Analista/Programador
902 889 441 (ext. 407)
[image: blog] http://www.fhios.es/blog/
[image: linkedin] https://www.linkedin.com/company/fhios-smart-knowledge
[image: twitter] https://twitter.com/fhiosmart
[image: facebook] https://www.facebook.com/FHIOS
[image: google_maps]
https://www.google.com/maps/preview?ll=41.397855,2.190264&z=15&t=m&hl=es-ES&gl=US&mapclient=embed&q=Carrer+de+Badajoz,+145+08005+Barcelona+España
De: Brock Allen<EMAIL_ADDRESS>Enviado el: miércoles, 19 de abril de 2017 4:40
Para: IdentityServer/IdentityServer3.Samples
CC: abellahoz; Author
Asunto: Re: [IdentityServer/IdentityServer3.Samples] Dev (#338)
What's this PR for?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/IdentityServer/IdentityServer3.Samples/pull/338#issuecomment-295046719,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AacSAof3gXQ68tbbdHh2NTzSPT-srNRoks5rxXQNgaJpZM4NAJbs
.[image: Imagen quitada por el remitente.]


Special attacks

Please add a special attack handler so we can use it as a precedent. Thanks.

Addressed in https://github.com/Tomm0017/rsmod/commit/fb12f5fa97ef3b5ca6d2f5ddddcab2261d8ff251
Example: https://github.com/Tomm0017/rsmod/commit/930c9a42c7f687a0afe30c5d548e3c393d341583


Fix CI

Move from macos-latest to macos-13

If we think it's okay to go ahead and merge this, it should solve the test issues on dev and we can merge into main


colors not working as of March 20th 2024

Chrome Version 123.0.6312.58 does not show colors anymore

working once again thanks @yfuruyama !


Fail to create a collection to the attached Core(SQL) server which created using the "Serverless" capacity model

OS: Win10
Build Version: 20210923.1
Regression: Not a regression
Repro Steps:

Create a Core(SQL) server with "Serverless" capacity model -> Right click the Core(SQL) server -> Select "Copy Connection String".
Click "Attach Database Axccount..." icon -> Paste the copied connection string.
Create a collection to the attached Core(SQL) server.
Check whether succeed to create a collection to the attached Core(SQL) server.

Expect:
Succeed to create a collection to the attached Core(SQL) server.
Actual:
Fail to create a collection to the attached Core(SQL) server.

More Info:
Create a collection to the Core(SQL) server -> Expand the attached Core(SQL) server -> There is a collection and can create a document for it successfully.

Attached Accounts scenario for Azure is not a typical scenario as the database account is already available under the subscription tree. I don't see a value is fixing this issue as a priority.
Is there a use case we might be missing?

This issue does't reproduce for the attached Mongo DB server which created using the "Serverless" capacity model or the attached Core(SQL) server which created using the "Provisioned Throughput" capacity model. It would be better to keep the attached Core(SQL) server consistent with other servers.
From the user's point of view, creating a collection is a basic function, so it would be better if the collection can be created successfully.

This error is occurring because when create a collection with an attached serverless SQL(Core) account, we don't stifle the prompt for throughput like we do with the remote experience.
Entering a value in throughput is what is causing the error to occur. The workaround is to just type some bogus value in the prompt (it's not being validated, probably another bug we could file 😅)


MicrosoftAzureInformationProtection does not work anymore

`Get-Nevergreenapp -Name MicrosoftAzureInformationProtection
get-nevergreenapp : Error retriving results for 'MicrosoftAzureInformationProtection': Cannot validate
argument on parameter 'Uri'. The argument "" does not match the "^(http|https)://" pattern. Supply an
argument that matches "^(http|https)://" and try the command again.
At line:1 char:1

get-nevergreenapp -Name MicrosoftAzureInformationProtection

  + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
  + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-NevergreenApp`

I believe this is probably because Microsoft are in the process of rebranding this product as Microsoft Purview Information Protection, so the old URL has now changed.
The old url 'https://docs.microsoft.com/en-us/azure/information-protection/rms-client/unifiedlabelingclient-version-release-history' (which the version number was previously gathered), now redirects to the new Microsoft Purview Information Protection release notes url:
'https://learn.microsoft.com/en-us/purview/information-protection-client-relnotes'
So to correct the Nevergreen script ('Get-MicrosoftAzureInformationProtection.ps1'), I'd suggest renaming to 'Get-MicrosoftPurviewInformationProtection.ps1', As the download is now combined as a single .exe, the script should be changed as follows:

Changing the URL queried, and the Pattern
Removing the $URLMsi line and modifying the $URLExe Pattern (remove the _UL)
Have just a single New-Nevergreenapp line for the exe with the new name 'Microsoft Purview Information Protection'

This (IMO) will result in a script as below:
# Get-MicrosoftPurviewInformationProtection
$Version = Get-Version -Uri 'https://learn.microsoft.com/en-us/purview/information-protection-client-relnotes' -Pattern '>Version\s(\d+\.\d+\.\d+\.\d+)'
$URLExe = Get-Link -Uri 'https://www.microsoft.com/en-us/download/confirmation.aspx?id=53018' -MatchProperty href -Pattern '\.exe'
New-NevergreenApp -Name 'Microsoft Purview Information Protection' -Version $Version -Uri $URLExe -Architecture 'x86' -Type 'Exe'

When are you publishing the new version?
Thank you for your work and effort!

@DanGough The above should fix / replace the earlier script due to Microsoft rebranding the product

Purview is already staged in Dev.


Handling duplicates on iCloud - Core Data sync

Hi,
What would be best approach to handle duplicates in case on sync of Core Data with iCloud.
After data are coming from iCloud and they are merging with default local data there are duplicates there, so any good approach to handle this please?
Currently I'm doing in the Stack.swift at persistentStoreCoordinatorStoresDidChange but wanted any suggestion for a better approach maybe.
Thanks

Hello. I hoped someone else had answered your question
Anyway, to the latest version of Core Data (from Apple, not the AlecrimCoreData) there was not a safe way to do this. There are some workarounds, but until today I have not seen one that really be the solution to all cases.
In the last version of Core Data (still in beta) there are constraints for uniqueness, but I have not had chance to test them in practice.


Add CI flag to cmake and enable on Travis and Appveyor

WIP, I'll try to fix any warnings in this PR as well.

What's the best way to replace the function argument to RunIndexTests with a define?

What do you mean?

Also, in text_document_definition.cc line 155 and line 163 the expressions -pos is used twice while pos is unsigned. Is this intended? Simply making pos an int might change behaviour if pos was actually intended to be unsigned

Unfortunately I'm not sure :(

If the --ci cli arg is set we pass true to RunIndexTests instead of false. Is there any preferred way to do this when we use a CI define instead of the --ci arg?

Ah, we can just have
bool is_ci = false;
#ifdef CI
is_ci = true;
#endif

Going to try this again in a new pr


Refactor/chat sequence

In a side by side comparison comparison I'm getting more answers from prod from this branch. How can we verify?

In a side by side comparison comparison I'm getting more answers from prod from this branch. How can we verify?

Yeah I noticed it too. We keep hitting the max token limit from open ai and that returns a 403 error.
So we return a fallback error message

You are saying we are hitting this limit just in the streaming branch?

Still not performing as well:

@adamjonas after extensive debugging there are no differences between the final prompt text passed to chat on this branch and that on prod. Retrying the same prompt on prod locally failed to produce any results and prod on live didn't as well.
I used the same base query for all tests: what are the most important functions in bitcoin core, and disabled caching and reading cached answers so I only get chat responses.
I'll chalk it up to chatgpt not being exactly reproducible.
This branch did give an answer in one of my tests but that was 1 in about 8 instances of the same query so that isn't really usable.

IMG_01: one time answer from this branch
IMG_02: prod branch on local failing the same query
IMG_03: prod on live failing a reworded query (if not reworded it uses the cached no answer found message)
cc: @Extheoisah @urvishp80

Payments aren't working

This isn't a blocker to merge but i'd like to unify the payment options rather than have 2 tabs:

We should present 3 options and just drop the 6-hour one


TVPaint: Use Publisher tool

Brief description
Use Publisher tool and new creation system in TVPaint integration.
Description
Using new creation system makes TVPaint integration a little bit easier to maintain for artists. Removed unneeded tools Creator and Subset Manager tools. Goal is to keep the integration work as close as possible to previous integration. Some changes were made but primarilly because they were not right using previous system.
All creators create instance with final family instead of changing the family during extraction. Render passes are not related to group id but to render layer instance. Render layer is still related to group. Workfile, review and scene render instances are created using autocreators instead of auto-collection during publishing. Subset names are fully filled during publishing but instance labels are filled on refresh with the last known right value. Implemented basic of legacy convertor which should convert render layers and render passes.
Additional info
Because of special subset name template for render families I had to add option to filter subset name templates by different family than is family to fill the subset name, which is kind anti-pattern -> fill family is render but for filtering is used renderLayer, renderPass or renderScene family. It can be kept as is now but it probably should be changed.
One option is to have same subset name template for all render families in TVPaint, which could work but could block other implementations of possible TVPaint render families -> this would break backwards compatibility for subset name templates.
TODOs
Update documentation.
Testing notes:

Start TVPaint
Make a scene
Open Publisher
Create a Render Layer/s (you can create it out of selection)
Reset publisher (this is to update Render Layers combobox)
Create a Render Pass/es - Based on selected TVPaint layers in scene
Enable/Disable instances
Publish

Legacy convertor

Open TVPaint file with legacy created instances
Run Convert
All instances should be converted to new creators

Get this when launching the publisher;
Traceback (most recent call last):
  File "C:\Users\tokejepsen\OpenPype\openpype\tools\publisher\window.py", line 456, in _on_show_timer
    self.reset()
  File "C:\Users\tokejepsen\OpenPype\openpype\tools\publisher\window.py", line 462, in reset
    self._controller.reset()
  File "C:\Users\tokejepsen\OpenPype\openpype\tools\publisher\control.py", line 1746, in reset
    self._reset_plugins()
  File "C:\Users\tokejepsen\OpenPype\openpype\tools\publisher\control.py", line 1764, in _reset_plugins
    self._create_context.reset_plugins()
  File "C:\Users\tokejepsen\OpenPype\openpype\pipeline\create\context.py", line 1615, in reset_plugins
    self._reset_creator_plugins()
  File "C:\Users\tokejepsen\OpenPype\openpype\pipeline\create\context.py", line 1695, in _reset_creator_plugins
    creator = creator_class(
  File "C:\Users\tokejepsen\OpenPype\openpype\pipeline\create\creator_plugins.py", line 204, in __init__
    self.apply_settings(project_settings, system_settings)
  File "C:\Users\tokejepsen\OpenPype\openpype\hosts\tvpaint\plugins\create\create_workfile.py", line 21, in apply_settings
    self.active_on_create = plugin_settings["active_on_create"]
KeyError: 'active_on_create'

Get this when launching the publisher;

Had swapped code in workfile and review creators. Thanks

Getting this when launching the publisher now.

Small update to include openpype\hosts\tvpaint\plugins\publish\validate_scene_settings.py: scene_data["resolutionWidth"] > scene_data["resolutionHeight"]
                "current_height": scene_data["resolutionWidth"],

Publishing all seems to work well. Further thoughts:

what is the reason for having a separate Scene Render instance? As far as I can see, we could just auto create an instance which includes all (enabled) layers in the scene, and include in the name something like All_Layers.
is the token supposed to be replace here?

too many entries to the group selection?

think the client asked for a way to create passes from layers. Will this be included in this PR? We had to implement something similar for our last production (on Pype v2), where the artist gets asked whether they wanna create render passes for each tvpaint layer when creating a render layer.

As far as I can see, we could just auto create an instance which includes all (enabled) layers in the scene, and include in the name something like All_Layers.

That's what Scene Render is for.

is the token supposed to be replace here?

No, it could change on change of Render Layer on the instance.

too many entries to the group selection?

I though I fixed that, will look into that.

Will this be included in this PR?

No, this is just conversion for publisher. That will be next PR.


test to ensure that we all out json-serialization is snake-case

A way to handle https://github.com/fedimint/fedimint/issues/3332 going forward. Can we tell serde to do this as a global default? Perhaps a semgrep rule? JSON schema?

Was looking around to see if there was a way to have serde do snake_case by default on enums and doesn't look like it's available.

No one has any ideas and this just rots in a backlog. Closing.


Make sure that errors and warnings are written to stderr

The Problem/Issue/Bug:
Warnings and errors are not written to stderr consistently.
Apart from a general unpredictability, warnings can disturb automatically evaluated output.
How this PR Solves The Problem:
To make the output more predictable all warnings and errors, I was able to find, are now written to stderr.
Manual Testing Instructions:
Executing any ddev commands on the command line should still show exactly the same result.
To test if warnings are written to stderr you can run the command outputting the error / warning to show stdout only by adding 2>/dev/null.
For example ddev describe 2>/dev/null should now show a clean output.
Automated Testing Overview:
N/A
Related Issue Link(s):
This will help to improve stability when using the DDEV Integration plugin.
Release/Deployment notes:

Wouldn't it be better to fix output.UserOut.Fatal() and output.UserOut.Error() and warning?
Also, note

https://github.com/drud/ddev/issues/2839

Wouldn't it be better to fix output.UserOut.Fatal() and output.UserOut.Error() and warning?

You mean using output.UserErr.Fatal() instead?
I think there should be a consistent way for writing output.
I thought there is a reason why someone created the util.* wrapper functions, they also seem to do some coloring, so I prefered that one.

Also, note

app.Exec() doesn't properly split stdout and stderr, can result in data corruption (ddev drush sql-dump) #2839

That doesn't sound good... I had no issues when manually testing with the "Instrumentation is opted in" warning for example.

Hmm... util.Warning and friends are just wrappers on the other... https://github.com/drud/ddev/blob/0aa4e1d27cd77d73c06b026a0ff0629dac61603d/pkg/util/utils.go#L43-L50
So not sure what this would accomplish.
And the reason that we're using the output wrapper is explicitly so that json consumers can be notified... using json.

We can use whatever function call you like, but there should be some rule like:

Whenever there is a warning use util.Warning() to output it.

I would advise against using output.UserErr.Warn without a wrapper directly in your buisiness logic, so you segerate your code from logrus logger, as it is a 3rd party dependency.
Using a wrapper makes it easier to react on changes of the dependency or add functionality like verbosity or a quite mode later on.

The util.Warning stuff predated the logrus adoption (which was done to support json output). So that's why you'll see a mix. Still interested in why this PR satisfies the needs of the plugin... I don't see a problem in it, but not sure I see the benefit either. The one big problem is using util.Failed() when it shouldn't be used, because it immediately terminates the app, which shouldn't usually be done during internal logic (like in test infrastructure).

Still interested in why this PR satisfies the needs of the plugin...

It makes it easyer to distinguish between relevant content and warnings / errors / infos that should be reported to the user executing it.
While stdout is expected to contain the acutal result of the command, warnings are expected to be in stderr.
Currently DDEV does write warnings sometimes to stderr, and sometimes to stdout which makes error handling hard to handle, without redirecting stderr to stdout which you obviously don't want to do.
This does not solve an actual problem, it is more an improvement to be more compliant to the unix output standards and will be neccessary for another pull request I am planning.

The one big problem is using util.Failed() when it shouldn't be used, because it immediately terminates the app, which shouldn't usually be done during internal logic (like in test infrastructure).

For context: util.Failed is a wrapper for logrus fatal
func (logger *Logger) Fatal(args ...interface{}) {
	logger.Log(FatalLevel, args...)
	logger.Exit(1)
}

Yes, I also noticed this exit and dind't like it much, because it is a bit unexpected and can make things hard to test.
I didn't change aynthing regarding this behavior as this pull request just aims to tidy up the error streams.

Another comment on the wrapper topic:
I am not saying that we should use util. I am just suggesting any wrapper. Something like logger.warning() would allow you to have one single point to change the logging behavior later on. For example if you like to swtich the warnings back to stdout (please don't do ;) ) you only have to edit one line in logger.warning() instead of editing all places where a warning is caused.
Just tell me which wrapper to use or if I should create a new one. I will adjust my pull request accordingly.

Sometimes you just have to keep the conversation going long enough until the other person understands! 😄

Haha, yes, if you have any further concerns, I'm happy to clarify misunderstandings! ;)

Thanks, and thanks for the patience!


Add examples ported from wasmtime

btw, I'm planning to add the remaining examples from wasmtime/examples, and move the ones in doc_test.go to separate files when I have some time.


fix CustomElementConstructor - https://github.com/microsoft/TypeScript/issues/36965

fixes https://github.com/microsoft/TypeScript/issues/36965

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: jogibear9988 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Deprecated by #838


[libiconv] Build error

Host Environment

OS: Windows 10
Compiler: MSVC

To Reproduce
Steps to reproduce the behavior:
./vcpkg install glib
Failure logs
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:158 (message):
Command failed: C:/vcpsf/vcpkg/downloads/tools/msys2/803521c5733336c9/usr/bin/make.exe -j 7 --trace -f Makefile all
Working Directory: C:/vcpsf/vcpkg/buildtrees/libiconv/x86-windows-dbg/
See logs for more information:
C:\vcpsf\vcpkg\buildtrees\libiconv\build-x86-windows-dbg-out.log
C:\vcpsf\vcpkg\buildtrees\libiconv\build-x86-windows-dbg-err.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_build_make.cmake:187 (vcpkg_execute_build_process)
scripts/cmake/vcpkg_install_make.cmake:26 (vcpkg_build_make)
ports/libiconv/portfile.cmake:38 (vcpkg_install_make)
scripts/ports.cmake:145 (include)
package: libiconv[core]:x86-windows -> 1.16#11
vcpkg-tool version: 2022-02-11-dac008bf9b55ef48e10bcc81e273b97a82bbf72d
vcpkg-scripts version: c93faafe6 2022-02-13 (3 hours ago)
Additional context

Building is ok in another clean env.