ARMV7 NEON performance regression for ACL v21.08 vs v21.05

Output of 'strings libarm_compute.so | grep arm_compute_version': v21.05 vs v21.08
Platform: ARMv7
Operating System: Debian
Problem description:
We just drop-in replaced ACL v21.05 with the ACL v21.08 library for our NEON oriented framework, then tested a basic CNN and found the performance of ACL v21.08 significantly worse than that of ACL v21.05. Our test system is a single core Arm Cortex-A8 AM3352.
To demonstrate the issue, the results of warmup and post-warmup phases for a basic CNN that makes use of NEGEMM, and, particularly, NEConvolutionLayers and NEDepthwiseConvolutionLayers:
NEON supported - Running on ACL v21.05
Warmup pred() call duration: 2.580388 seconds
Postwarmup pred() call duration: 1.898441 seconds

versus
NEON supported - Running on ACL v21.08
Warmup pred() call duration: 3.020147 seconds
Postwarmup pred() call duration: 2.345052 seconds

Hi @robinvanemden
Would it be possible for you to share a test running the workloads that experience the slowdown in v21.08?

Hi @morgolock
I will see what I can do. It will probably take one or two weeks for me to share a relevant test. Though I suspect this issue should be easily reproducible: Running a DNN with some gemm & convolution layers will probably yield similar results.


How to reduce ERR_CONNECT_FAIL error in delayed network

ats verison： ats-9.1.3
system：centos 7.6
I want to simulate the working state of ATS in network latency scenarios。i use tc tool simulate network latency(simulate delay of back to parent ) and not use storage，when i simulate 80ms delay，i found many ERR_CONNECT_FAIL error in log。I don't think a 80ms delay can cause so many ERR_CONNECT_FAIL errors。
Is it caused by inappropriate configuration in the records.conf file？Which configuration parameter can I optimize

Supplementary Information
When setting the 80ms delay, no storage was used. I used 2000 clients for performance testing

80ms delay did not result in ERR_CONNECT_FAIL, but the delay caused the transmission speed to be particularly slow. The parent actively disconnected, and then the parent was marked down
now the problem is why does the 80ms delay cause ATS to return to the source very slowly


Changing the height and the width of the circle

Signed-off-by: Sumit Biswas<EMAIL_ADDRESS>

Signed-off-by: Sumit Biswas<EMAIL_ADDRESS>


refactor: create Table from pandas.DataFrame

Summary of Changes
Add method _from_pandas_dataframe to create a Table from a pandas.DataFrame. This can be called internally instead of the constructor (once #256 is done), so we can provide a usable constructor.

🦙 MegaLinter status: ✅ SUCCESS

Descriptor
Linter
Files
Fixed
Errors
Elapsed time

✅ PYTHON
black
5
0
0
1.06s

✅ PYTHON
mypy
5

0
2.12s

✅ PYTHON
ruff
5
0
0
0.06s

✅ REPOSITORY
git_diff
yes

no
0.03s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff
MegaLinter is graciously provided by

:tada: This PR is included in version 0.12.0 :tada:
The release is available on:

v0.12.0
GitHub release

Your semantic-release bot :package::rocket:


[Bug report] The syntax highlighter color produced by the compiler is incorrect.

Description
This one is the result of running docs:dev:

While this one is made by running docs:build:

Reproduction
(1) Clone this repository. (2) Run pnpm install. (3) Run pnpm build. (4) Run pnpm docs:dev. (5) Run pnpm docs:build.
Used Package Manager
pnpm
System Info
Binaries:
  Node: 18.11.0 - ~/.nvm/versions/node/v18.11.0/bin/node
  Yarn: Not Found
  npm: 8.19.2 - ~/.nvm/versions/node/v18.11.0/bin/npm
Browsers:
  Chrome: Not Found
  Firefox: 105.0.2
npmPackages:
  @vuepress/core: Not Found
  @vuepress/theme-default: Not Found
  vuepress: Not Found
npmGlobalPackages:
  vuepress: Not Found

We are using prism during dev and shiki on build. What's the problem?

I see, it is intended behavior then. So we need to install shiki plugin to use them in the production stage, right? Or is there any option to enable them in the config file?

See
https://github.com/vuepress/vuepress-next/blob/c63bd4a75fb61860e969e4bc229c2754b9aac0b6/docs/.vuepress/config.ts#L108
https://github.com/vuepress/vuepress-next/blob/c63bd4a75fb61860e969e4bc229c2754b9aac0b6/docs/.vuepress/config.ts#L181
You don't NEED to do this.
Shiki is more acurate (It's VSCode built-in highlighter) and prism support more language, choose it wisely yourself.


Cannot mix diff and diff-lang in one app

We ran into a problem where we couldn't get nice diff rendering for e.g. diff-js or any other language (see mainmatter/mainmatter.com#1955). 11ty would always only render a green/red diff but not apply any highlighting specific to the language.
After some debugging I realized the root cause is this:
https://github.com/11ty/eleventy-plugin-syntaxhighlight/blob/ac92151c42996faef19650f34f54a77e4ac210f2/src/PrismLoader.js#L30-L34
If the diff language is already present, the diff-highlight plugin isn't loaded. That means that if you have a codeblock
 ```diff
 + new line
 `` (GitHub doesn't render this properly with 3 `)

and then later another one
 ```diff-js
 + let val = 0:
 `` (GitHub doesn't render this properly with 3 `)

the second one doesn't get highlighted correctly as the diff-highlight plugin isn't loaded and thus cannot register its hooks which it needs to apply the language-specific highlighting on top of the diff highlighting (see https://github.com/PrismJS/prism/blob/master/plugins/diff-highlight/prism-diff-highlight.js#L34).
So instead of checking for the presence of the diff language, I think you want to specifically check for whether the diff-highlight plugin has been loaded or not.
A workaround of course is to never use  ```diff and always use  ```diff-js etc.

Shipping with v5.0.0


Cross-Site Scripting (svg file upload XSS) found on Cockpit-next CMS.

Description: SVG files can contain Javascript in

Any update on this. Does any fix added for this?
We look forward to your response.

Think this is a serious issue, and until we don't have a robust fix my suggestion is to limit usage of SVG uploads only to admin groups, you can limit for any other group as below example:
  editor:
    $admin: false
    $vars:
      finder.path: /storage/uploads
      finder.allowed_uploads: pdf, png, jpg, jpeg, gif, pdf
      assets.allowed_uploads: png, jpg, jpeg, gif, pdf

some interesting readings regarding svg protection: https://svg.digi.ninja/svg, in such case here a validation on the uploaded SVG (if that is possible) would be enough

as @pauloamgomes mentioned one workaround (for now) is to disallow uploading svg files.
which is not optimal. but works for now.
I'll try to implement a svg sanitizer for the next release

We would like to report this to CVE Mitre for registering it with a CVE ID.
Are you done with the patch for this vulnerability?
Looking forward to your response.

fixed in the next branch


Initial REST api for heartbeat.

Closes #14
This need a bit more work before being usefull, but I want to land/get your review now, because groundstation<->satellite comunication is important.
Core Ideas:

uplink package defines data format for this communication

Any types that need to cross the network here should be defined here.
IE we should move GPUStatsPacket into here.

fempto contains abstractions for HTTP.

To test:
go run ./cmd/groundstation/
# in another tab:
go run ./cmd/satellite/

Which will output something like:
2024/01/18 01:51:05 INFO Starting groundstation
2024/01/18 01:51:08 INFO New Request req_no=3 method=POST url=/gs-api/heartbeat/ from=<IP_ADDRESS>:60420
2024/01/18 01:51:08 INFO New Request req_no=1 method=POST url=/gs-api/heartbeat/ from=<IP_ADDRESS>:60404
2024/01/18 01:51:08 INFO New Request req_no=2 method=POST url=/gs-api/heartbeat/ from=<IP_ADDRESS>:60374
2024/01/18 01:51:08 INFO Received a heartbeat req_no=2 prev_time=0001-01-01T00:00:00.000Z cur_time=2024-01-18T01:51:08.362Z
2024/01/18 01:51:08 INFO New Request req_no=5 method=POST url=/gs-api/heartbeat/ from=<IP_ADDRESS>:60394
2024/01/18 01:51:08 INFO Received a heartbeat req_no=1 prev_time=0001-01-01T00:00:00.000Z cur_time=2024-01-18T01:51:08.362Z
2024/01/18 01:51:08 INFO New Request req_no=4 method=POST url=/gs-api/heartbeat/ from=<IP_ADDRESS>:60436
2024/01/18 01:51:08 INFO Received a heartbeat req_no=3 prev_time=0001-01-01T00:00:00.000Z cur_time=2024-01-18T01:51:08.362Z
2024/01/18 01:51:08 INFO Received a heartbeat req_no=4 prev_time=0001-01-01T00:00:00.000Z cur_time=2024-01-18T01:51:08.362Z
2024/01/18 01:51:08 INFO Received a heartbeat req_no=5 prev_time=0001-01-01T00:00:00.000Z cur_time=2024-01-18T01:51:08.362Z
2024/01/18 01:51:08 INFO New Request req_no=6 method=POST url=/gs-api/heartbeat/ from=<IP_ADDRESS>:60380
2024/01/18 01:51:08 INFO Received a heartbeat req_no=6 prev_time=0001-01-01T00:00:00.000Z cur_time=2024-01-18T01:51:08.362Z
2024/01/18 01:51:08 INFO New Request req_no=7 method=POST url=/gs-api/heartbeat/ from=<IP_ADDRESS>:60432
2024/01/18 01:51:08 INFO Received a heartbeat req_no=7 prev_time=0001-01-01T00:00:00.000Z cur_time=2024-01-18T01:51:08.362Z
2024/01/18 01:51:08 INFO New Request req_no=8 method=POST url=/gs-api/heartbeat/ from=<IP_ADDRESS>:60454
2024/01/18 01:51:08 INFO Received a heartbeat req_no=8 prev_time=0001-01-01T00:00:00.000Z cur_time=2024-01-18T01:51:08.362Z
2024/01/18 01:51:08 INFO New Request req_no=9 method=POST url=/gs-api/heartbeat/ from=<IP_ADDRESS>:60396
2024/01/18 01:51:08 INFO Received a heartbeat req_no=9 prev_time=0001-01-01T00:00:00.000Z cur_time=2024-01-18T01:51:08.362Z
2024/01/18 01:51:08 INFO New Request req_no=10 method=POST url=/gs-api/heartbeat/ from=<IP_ADDRESS>:60442
2024/01/18 01:51:08 INFO Received a heartbeat req_no=10 prev_time=0001-01-01T00:00:00.000Z cur_time=2024-01-18T01:51:08.362Z

(This probably needs to be automated)

Other than comments made above, this all looks good to me


Configurable group delimiters

In the existing code, the SHIBBOLETH_GROUP_ATTRIBUTES expects any list-based attributes to be semicolon delimited.
My project actually receives a list of comma separated groups, and a code change was required to support commas instead of semicolons.
I erred on the side of flexibility by allowing multiple delimiters to be specified (e.g. both comma and semicolon) in the off chance that more than one is needed.  Let me know if the README could be improved in any way.

Thanks.


#197 - Attachment points should be within R-Group brackets

Closing #197
How the feature works? / How did you fix the issue?
(Screenshots, videos, or GIFs, if applicable)
including the attachment points bounding box as accumulating the r-group box
Check list

[ ] unit-tests written
[ ] e2e-tests written
[ ] documentation updated
[x] PR name follows the pattern #1234 – issue name
[x] branch name doesn't contain '#'
[x] PR is linked with the issue
[x] base branch (master or release/xx) is correct

Made only for R-Group Fragment but not for S-Group

The S-Group fix please refer to this bug  https://github.com/epam/ketcher/issues/2949


gerrit: 3.3.2 -> 3.4.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/gerrit/versions.
meta.description for gerrit is: "A web based code review and repository management for the git version control system"
meta.homepage for gerrit is: "https://www.gerritcodereview.com/index.md"
meta.changelog for gerrit is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 3.4.0 in filename of file in /nix/store/h3nlbnqsf3izwx10waamffi3la6wbc7l-gerrit-3.4.0

directory tree listing: https://gist.github.com/5bd6588c9ff4daa5cbe40dc6e9da4f8e

du listing: https://gist.github.com/87b9821b9f5ba91a1b74b2dd237fae64

Rebuild report (if merged into master) (click to expand)

8 total rebuild path(s)

3 package rebuild(s)

3 x86_64-linux rebuild(s)
2 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
2 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
gerrit
nixos-install-tools
tests.nixos-functions.nixos-test

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/h3nlbnqsf3izwx10waamffi3la6wbc7l-gerrit-3.4.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A gerrit https://github.com/r-ryantm/nixpkgs/archive/5814c4b86a5c7c7a5adfef238fae76c32a1814d9.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/h3nlbnqsf3izwx10waamffi3la6wbc7l-gerrit-3.4.0
ls -la /nix/store/h3nlbnqsf3izwx10waamffi3la6wbc7l-gerrit-3.4.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

nixos-install-tools

1 package built:

gerrit

Maintainer pings
cc @flokli @jammerful @zimbatm for testing.

Result of nixpkgs-review pr 127913 at 5814c4b8 run on aarch64-linux 1

2 packages built successfully:

gerrit
nixos-install-tools


updating sdk tags for 2019-10-01 api version

Updating sdk tags for the new 2019-10-01 api version
Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[x] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ x Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[x] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Can one of the admins verify this patch?

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

@raych1, Fixed the CI warning. Please take a look.


Coalesce atomic ops for grpc_stream_unref.

Each grpc_call will execute batched ops, taking atomic refs and unrefs on the
underlying grpc_stream.
Here, we coalesce the expensive unref batch calls into a single unref performed at
call destruction.
API changes:

Unref(N) method for grpc_core::RefCount
Macros added: GRPC_CALL_STACK_UNREF_N and friends

Context: a full 2.5% or so of time spent in 62 channel 0 byte tests is spent in grpc_stream_unref(), 2/3rds of which is due to grpc_call.


Fix AppxManifest link in the PackagedComServer

While reading the sample readme, I noticed this problem with a link url. I choose a relative link instead of absolute, because it will work correctly thru renames / moves and also across git branches.

Ping


conventions: Codify use of newtypes

r? @fiveop

One thing I've wondered about is
pub struct SigSet(libc::sigset_t);

vs
pub struct SigSet {
    inner: libc::sigset_t,
}

There's also a possibility of introducing a something like the Rust project's *Inner traits: https://github.com/rust-lang/rust/blob/master/src/libstd/sys/common/mod.rs#L54-L76

Deferring choice of how to represent the newtype. @homu r=@posborne

:pushpin: Commit 6f0bcde has been approved by @posborne

:zap: Test exempted - status


[rest] add commissioner api

Added endpoints to the REST server to expose commissioner functionality over the REST API
These changes intend to implement commissioner functionality in the same style as the current rest API offering.

The /node/commissioner/state endpoint allows the user to get/set the commissioner state using GET and PUT requests respectively.
The /node/commissioner/joiner allows the user to manage joiners accepted by the commissioner, supporting POST, GET and DELETE request methods to add, get and remove a joiner respectively.

All added endpoints and their usage have been documented in the openapi.yaml
Example usage:

Please give me feedback and let me know of any required changes 😄

Will this PR be picked up as we kind of need this functionality. I also see another PR #2514 but that is really large change.

Hey @wgtdkp, I've made the requested changes, do you want resolve the comments?

Hey @wgtdkp, I've made the requested changes, do you want me to resolve the comments?

@OmegaRelay It's typically the PR author to resolve the comments if the suggests in the comment is followed. If you have different ideas on the topic, reply to the comment and leave it open, the reviewers will take a look again and close it when a consensus is reached.
I did take a glance and it seems my comments are not resolved. Could you check the comments again? thank you!

@OmegaRelay A Joiner drops from the joiner table after timeout, but also after successfully joining the network. Could your API differentiate between these two scenarios?

@OmegaRelay A Joiner drops from the joiner table after timeout, but also after successfully joining the network. Could your API differentiate between these two scenarios?

Hi @martinzi, this PR is intended to be a simple extension of the current stateless API and as such implementing this joiner status feature feels outside the scope of this PR.
On a side note, I am currently looking at implementing server-sent events which can also cover this use case and keep the API itself stateless, I do have an open feature request to discuss this but it hasn't had much interaction.


add lazily filled dict for prototype datasets

This is my proposed solution to https://github.com/pytorch/vision/pull/5187#issuecomment-1015479165. Since we only need the mapping during iteration, we can also delay its instantiation until then. Thoughts?
cc @pmeier @bjuncek

The agreed upon idiom is that we can iterate before the full pipeline is built, but we have to exhaust it completely. See #6065 for fixes to ImageNet and CUB200.


Where to get game database?

I saw db is mysql format, who can tell me how to download?

Sorry,I was negligent, I was find .sql files in the folders, these are exactly what I need!

Sorry,I was negligent, I was find .sql files in the folders, these are exactly what I need!


Doc anchor links spimanifest/commonusecases#Images-for-Linux not working

There's one issue with this: the # anchor links aren't working in my testing. They all land on spimanifest/commonusecases and not spimanifest/commonusecases#Images-for-Linux etc.
This doesn't seem to happen because we're not passing the fragment on. When I debug into this, there is no fragment on req.url when visiting these urls. Which is bizarre, because we have a test test_defaultDocumentation that tests exactly that successfully.
I haven't figured out why there's this discrepancy.
Originally posted by @finestructure in https://github.com/SwiftPackageIndex/SwiftPackageIndex-Server/issues/2089#issuecomment-1286774111

Seems to be working now, not sure what the original problem was.


[Suggestion] Vanilla OP permission node

Would it be possible to add a node to give a rank OP permissions per vanilla minecraft or allow the /op command to be used?
We have mods such as minetweaker and at least 2 others who's commands require vanilla OP permissions to run commands or interact with admin functionalities. (one example is a vault that will instakill anyone unless they are the owner or an OP)
A workaround for those of you who have not found it yet and are looking is to run /minecraft:op  to give OP to that person (or yourself)
Just looking to make things a bit easier and allow you to integrate vanilla OP perms the way you would like them rather than them being bypassed by OP.
Thanks for your time.

Any change to vanilla op functionality is done in Sponge -- PEX doesn't touch server internals. Sponge already has functionality to redirect command op checks to use permissions instead, and beyond that mod developers should be encouraged to use the forge permissions API (which Sponge plans to act as a bridge for between the forge API and sponge permissions plugins).


Move axis into side.y and side.x

We have discussed this, but a created side should have a default axis call when the side is created. If the user does an axis call that pertains to that side, it should overwrite the default values. Right now this is handled by putting axis in view instead of side and some funky logic in print to deal with it.

One thing I realized with #347 is that the pattern I used w/ a single axis call per side may be limiting.
They way that PR works, you have a template axis call by default which is only plotted if axes==TRUE, but additional calls to axis for the same side will just override parameter values. Is this a limitation we should avoid? It may remove some flexibility that is needed. For example,
this
gs <- gsplot() %>%
  points(y=c(3,1,2,4,5), x=c(1:3,8,80),
         col="blue", pch=18, legend.name="Points") %>%
  lines(c(3,4,3), c(2,4,6), legend.name="Lines",
        ylab="logged y axis", xlab="logged x axis", log='xy') %>%
  callouts(x=8, y=4, lwd=2, angle=45, labels="Not sure about this one") %>%
  title("logged axes") %>%
  axis(side=c(1,2,3,4), labels=FALSE, n.minor=4) %>%
  axis(side=c(1,2))
gs

used to produce this:

now you need to do
gs <- gsplot() %>%
  points(y=c(3,1,2,4,5), x=c(1:3,8,80),
         col="blue", pch=18, legend.name="Points") %>%
  lines(c(3,4,3), c(2,4,6), legend.name="Lines",
        ylab="logged y axis", xlab="logged x axis", log='xy') %>%
  callouts(x=8, y=4, lwd=2, angle=45, labels="Not sure about this one") %>%
  title("logged axes") %>%
  axis(side=c(3,4), labels=FALSE, n.minor=4) %>%
  axis(side=c(1,2), n.minor=4)
gs

instead for this PR (note that axis is only called once per side). Otherwise, you lose the n.minor for axes 1 and 2

I think this is limiting, and a little confusing. I think of each axis individually, so it doesn't make sense that you can do 3,4 together but not 2,3,4.

Do you have a use case? Also, note you can call all of those sides together, but there is only one draw_axis call executed per side. So the original code does this:
gs <- gsplot() %>%
  points(y=c(3,1,2,4,5), x=c(1:3,8,80),
         col="blue", pch=18, legend.name="Points") %>%
  lines(c(3,4,3), c(2,4,6), legend.name="Lines",
        ylab="logged y axis", xlab="logged x axis", log='xy') %>%
  callouts(x=8, y=4, lwd=2, angle=45, labels="Not sure about this one") %>%
  title("logged axes") %>%
  axis(side=c(1,2,3,4), labels=FALSE, n.minor=4) %>%
  axis(side=c(1,2))
gs

for this new PR

If n.minor didn't have a default of 0, we wouldn't override it with the second call to axis

Oh OK, I guess I misunderstood what you were pointing out. Thought you were saying c(1,2,3,4) was no longer allowed. So, you're saying by doing this, the new PR overrides what was specified in the first axis call. I think that makes sense. I would want this behavior
axis(side=c(1,2,3,4), labels=FALSE, n.minor=4) %>%
axis(side=c(1,2))

Correct. So because labels = TRUE and n.minor = 0 by default, the first call to axis for sides 1 and 2 would have those values overridden by the second call.


[$500] IOU - The date does not change and a message with incorrect dates is added

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.13-8
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Issue found when executing PR https://github.com/Expensify/App/pull/33174
Action Performed:

Go to staging.new.expensify.com
Navigate to the created expense details page (or create one)
Click on the date
Change it once

Expected Result:
Verify the date is changed, and a proper message is added, e.g. changed the date to 2023-12-17 (previously 2023-12-18)
Actual Result:
The date does not change and a message with incorrect dates is added
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] Windows: Chrome
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/760e093c-e8f7-4b4a-b64a-9ca463713922
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01a1217caf58eef97c
Upwork Job ID:<PHONE_NUMBER>579576832
Last Price Increase: 2023-12-18
Automatic offers:

getusha | Reviewer | 28070620
wlegolas | Contributor | 28070621

Issue is not reproducible on my account on staging

Proposal
from: @unicorndev-727
Please re-state the problem that we are trying to solve in this issue.
The date does not change and a message with incorrect dates is added
What is the root cause of that problem?
The root cause is that we didn't consider location when creating date here
formattedOldCreated = format(formattedOldCreated, CONST.DATE.FNS_FORMAT_STRING);

What changes do you think we should make in order to solve the problem?
We should use localized date here.

Hello
This issue can be reproduced for USA location

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/dhananjaypanage

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/touqeera21

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/touqeera21

Proposal
Please re-state the problem that we are trying to solve in this issue.
What is the root cause of that problem?
The problem is related to the process of creating and formatting the modified date because is created a Date object using the current local time, that way when formatting the date the timezone is applied according to the current environment.
There is a condition in the ReportActionItem component to show the modified created date:
https://github.com/Expensify/App/blob/4a9914f191473df50c13d75a433b0a9609ebe4f2/src/pages/home/report/ReportActionItem.js#L429-L431
As you can see, the message property receives the value to be displayed, this value is provide by the method getModifiedExpenseMessage from the ReportUtils, to generate the modified created data in the format YYYY-MM-DD (variable formattedOldCreated), first is created a Date object passing the oldCreated value, and after that is called the method format to apply the desired format.
https://github.com/Expensify/App/blob/4a9914f191473df50c13d75a433b0a9609ebe4f2/src/libs/ReportUtils.ts#L2123-L2130
In this case, the oldCreated information has only the date information, for example "2023-10-23", and when we create a new date passing only the date information will be created a new date with the time information according to the current environment.
For example, the oldCreated value is "2023-10-23", when creating the date using the new Date(), the date will be "Sun Oct 22 2023 21:00:00 GMT-0300 (Brasilia Standard Time)", in my case was removed 3 hours from the modified date, that's why the result is always reduced by one.
Note: people east of GMT (most non-US) may not see this bug because new Date() moves the timezone forward for their local time, so the date may not change.
What changes do you think we should make in order to solve the problem?
We should use the same approach used in this issue https://github.com/Expensify/App/issues/30303, using the method formatWithUTCTimeZone from DateUtils to format the oldCreated to avoid the issues with the time zone.
Here you can see the formatWithUTCTimeZone method logic:
https://github.com/Expensify/App/blob/4a9914f191473df50c13d75a433b0a9609ebe4f2/src/libs/DateUtils.ts#L654-L669
function getModifiedExpenseMessage(reportAction: OnyxEntry<ReportAction>): string | undefined {
    ...
    if (reportActionOriginalMessage?.oldCreated && reportActionOriginalMessage?.created) {
        const formattedOldCreated = DateUtils.formatWithUTCTimeZone(reportActionOriginalMessage?.oldCreated, CONST.DATE.FNS_FORMAT_STRING);

        return getProperSchemaForModifiedExpenseMessage(reportActionOriginalMessage?.created, formattedOldCreated, Localize.translateLocal('common.date'), false);
    }
    ...
}

Note: with this suggestion above we can improve the type checking, avoiding passing a default value (in this case Zero here at the end of the line) if the reportActionOriginalMessage?.created is undefined.
What alternative solutions did you explore? (Optional)
N/A
POC
https://github.com/Expensify/App/assets/698363/daab05af-1281-4014-b11d-2d3b140ba675

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~016d36bf11c0b5de09

@getusha mind giving an update?

Thanks everyone for the proposals.
the detailed RCA and proposal provided by @wlegolas Looks good to me.
🎀 👀 🎀 C+ Reviewed!

I'm unable to reproduce this issue. Can you try again please @lanitochka17?

Ah I see. Can you check if there other places where we could fix this as well?

I'm unable to reproduce this issue. Can you try again please @lanitochka17?

Hi @youssef-lr maybe the reason you didn't see is related to the note I put in my https://github.com/Expensify/App/issues/33248#issuecomment-1861966275

Note: people east of GMT (most non-US) may not see this bug because new Date() moves the timezone forward for their local time, so the date may not change

Ah I see. Can you check please if there are other places where we could fix this as well?

Hi, @youssef-lr I found two places with the code that could possibly have the same time zone issue.
In the file ModifiedExpenseMessage, we have the same problem related to this issue, if you see the code below, the code is using the information reportActionOriginalMessage?.oldCreated that is a date with only the date information.
https://github.com/Expensify/App/blob/4cfb8a2d7c89597289cd4e5ff3c57c0883b583d3/src/libs/ModifiedExpenseMessage.ts#L146-L160
Here in this image, we can see the value format in the reportActionOriginalMessage?.oldCreated property.

The other place is in the DateUtils file where we can see many places creating a new Date object with the statement new Date(someDateStringValue). I tried to check in the places where the methods that use the  new Date() to validate if the date string is in the correct format, and looks like these methods receive a data string with the correct format.
If you have any questions, please let me know.

@wlegolas can we please standardize using the same format function everywhere?

@wlegolas can we please standardize using the same format function everywhere?

Sure, I'll change the files to use the same function

Hi @youssef-lr, @getusha I created the PR https://github.com/Expensify/App/pull/33688 with the changes.
Note: I didn't put the evidence for "Android: Native" because I've been having problems running the application in my simulator, but I'll generate this evidence and update the PR description.
When I was fixing this issue I realized that the code to format the oldCreated information was extracted from the src/libs/ReportUtils.ts file to this src/libs/ModifiedExpenseMessage.ts file through this PRhttps://github.com/Expensify/App/pull/30603
With this change, I only need to fix the issue in the src/libs/ModifiedExpenseMessage.ts file.
If you have any questions or suggestions, feel free to bring them.

Hi @youssef-lr and @getusha I put the last evidence for Android Native.
I have a question about this implementation, in my tests, I noticed both dates created and oldCreated come from the backend in the format yyyy-mm-dd, this is the same format that I'm fixing to show the information without care about the timezone.
Do you know why we need to convert the value from the backend to a Date object and format this Date object to the format yyyy-mm-dd? Maybe there is a scenario for that, for example, old records may have an issue.

@getusha @youssef-lr mind confirming

coming up!

tomorrow!

Payment summary:

Contributor: @wlegolas $500
Contributor+: @getusha $500

Please apply or request!

payments sent!


[2023 - MP design Swag] Update designs to include new Members - Print Outside MPWG budget by Members

@rstjames,
Thank you for helping update the design on t-shirts and hoodies with the new folder2023
The designs are for MPWG usage and not a part of the project's marketing budget.

@aeiras what do you want me to do here? There is no 2023 swag created. We had the shirt and hoodie design from 2022 or 2021 not sure that elcipse said they would not print with the company logos on it

@rstjames,
please update the designs to include the new members, no changes to the design.
The print will be done outside the project’s budget, using which ever vendors each member chooses. As before. No changes.
Thank you 🙏

Please note that it’s important to check with Microsoft brand marketing before using the Microsoft logo anywhere. We have explicit permission to include the Microsoft logo on the MicroProfile site in a very limited fashion. I would not be surprised if similar approvals are needed for Oracle, IBM, etc.

Correct, Reza.
The 2023 design will be approved via a resolution by all members to enable its printing by any member. That is part of regular the design approval process once the Ryan helps with design update.

Deluxe Printing, the trusted printing USA Vendor, has received the yearly request to update the MP back of the shirt within its systems. MP swag forum email was cc'd on yearly update requests.

@rstjames,
Primeton provided the logo to update the 2022 swag in this ticket via the following comment:  https://github.com/eclipse/microprofile-marketing/issues/712#issuecomment-1342161355
Lets update the drive with their logo under Members' logos to avoid future delays. Thank you!

@aeiras yes the provided a new logo but it its a jpg (for web use) not for print. I need a "vector" logo formate for printing.
@Emily-Jiang

gotcha.
I have sent this issue via email to @mingyuehuang99.

@rstjames,
MPWG Logos also misses the MSFT logos. I created the folder to host those files. Please help update the folder. Thank you.

via swag https://drive.google.com/drive/u/0/folders/1LXgXYIYPSmUteMd0fA7lr9ZP9WE0U259 mock up

The 2023 shirt and hoody will be updated. The logos are used only for those two swag items and cover the 2023 membership listing as members change and design changes.
MPWH Members, during onboarding, provide their company's logos directly to the drive or via email or ticket (for website usage). It is written in the onboarding guidelines as a requirement upon joining the WG.
I hope this clarifies.

If this is important right now, I will ask our branding folks - explaining to them what the intended use is. I also want to clarify - so the idea is that any member company of the working group (e.g. Tomitribe) want to print these shirts with the Microsoft logo on it?

Correct, Reza. Thanks for the follow-up questions.
Any member can print the approved t-shirt for any reason, say Conference booth, sessions, workshop, etc.
Those prints are private by Members who do not need further authorization for printing. As such, it lands outside using the MPWG yearly budget.
Lastly, a member who responds with -1 or a 0 on the Resolution of 2023 design will be removed from the swag design. Only +1 voting members are a part of the yearly MP design.

OK. I will check with our branding folks. For now, I advise assuming a -1 vote from Microsoft with a clear explanation of why that is on the mailing list so that it is very visible to others that most likely will have very similar challenges with their own organizations.

While I check on this, @rstjames, I would like to suggest a much less potentially problematic design idea - how about leaving out the logos and just printing a list of member names in alphabetical (probably with a time range added for accuracy like Working Group Members - X, Y - A, B) in the back? Kind of in the style of band tour shirts: https://www.apparelsearch.com/influence/products/images/concert_tour_t-shirt-1977.jpg. Our branding folks can't really object to the name of the company with generic font listed in a factual fashion. This gets around many awkward questions probably for a lot of people that don't need the hassle within their companies.

Reza,
I recommend MSFT sends the vote to the actual resolution email.   There is no rush, there is no advance printing of any form.  Avoid confusing MicroProfilers is always preferred. Thank you,

there is no email yet because there is no 2023 design.  That’s why I ask for your patience on forum communications to avoid unnecessary noise.
This ticket remains the most important source tackling the swag design.  You could point to particular comments if it helps you with internal communications.

halo, I  can provide the "ai format "of primeton logo,Is this ai format ok? ：）
primeton logo.zip

@aeiras @rstjames
halo, I can provide the  "ai format " of primeton logo,Is this ai format ok? ：）
primeton logo.zip

The Foundation just got back to me about this. Here is what they shared: https://www.eclipse.org/lists/microprofile-wg/msg01755.html. Basically the Foundation's policy is to not print member logos on swag/clothing. I was not aware of this, but it makes total sense. I will further follow-up with an official response from our branding folks.

Small issue with adding the new member logo Primeton. @mingyuehuang99
The logo provided is longer than others member logos. When sizing it to fit equals as the other logos it is very small. Unless we move the characters above the logo. I do not know if this is agains branding for Primeton or is ok to do when there is no other solution. (refer to pictures attached) I found this layout of the logo online, but I do not know if its official

@mingyuehuang99 Hi could you please look at the message above. Thank you!

@rstjames  Hi！ Move the characters above the logo is better，and i confirm that is official too.
thank you :)

All has been updated on the drive: @aeiras
shirt:
https://drive.google.com/drive/folders/10HK2v2NVrploWgl66jE1o8B6YnYVAGc2?usp=share_link
hoodie:
https://drive.google.com/drive/folders/1gfoArj7GodC97Vwy6OciLOhjhQmzha-k?usp=share_link

It looks great, @rstjames.
Thank you.
We will add the design to the Steering committee discussion next Tuesday.

It looks like we need to once again clarify that the Eclipse Foundation policy is that we do not include corporate logos on any Eclipse working group clothing or other working group swag items. This doesn't matter weather it is working group budget or individual members printing the swag. These designs are out of bounds. This has been previously addressed and resolved here:  https://www.eclipse.org/lists/microprofile-wg/msg01755.html

Can somebody please tell me the reason behind that problem? Sure Eclipse currently does not have the rights to print the company logos on the shirt but what is the general problem with collecting such rights. I can not find an answer in this issue or the mails.

I’ll provide my honest two cents personally. It’s going to be a pretty steep uphill battle for me to get Microsoft legal, marketing, and branding to allow a third party to print the Microsoft logo on clothing, etc. It’s the way branding law works in the US. Giving the brand away frivolously makes it very difficult to protect it when needed. I am honestly shocked how IBM, Oracle, etc did not raise an objection with this much earlier.
Note, I am not a lawyer. Just someone that’s spent a good deal of their career working with very large US companies with globally recognized brands.

Thx @m-reza-rahman didn't know about that. Is it the same for paper flyers? So if we at Adoptium wants to print a flyer we can not print the logos of the wg members on it? Really interesting to see that there is a difference between having a logo on a website vs having it on a physical object. Would love to get more insights in that topic. maybe you or @croundy have a good reading tip or general advice for me?

Thank you for the insights

https://github.com/eclipse/microprofile-marketing/issues/792
Some ideas for scaling printing

Let me know what you all think.
@m-reza-rahman @hendrikebbers @min

I think this is fine. I hope the vote passes.

History and tracing in MPWG channels:

[MPWG forum - [microprofile-wg] [DISCUSSION] "Self-Service" MicroProfile Shirts](https://www.eclipse.org/lists/microprofile-wg/threads.html#01956)
MPWG Marketing forum
Git issue- Simplifying/ scaling community self printing MP t-shirt #792

Awaiting informal community vote resolution summary.

From an Eclipse Foundation standpoint, we are good with the design.  This is approved with the understanding that the vote passed unanimously and that each member has received their own internal approvals. Thank you all!

Thank you for the update on this topic @croundy . Could you please supply me with the correct eclipse foundation logo that would be on the sleeve?

@rstjames sure, here is a png of the all white logo

@croundy thank you for the logo but do you have this white logo in SVG?

thank you! @croundy

Based on the consensus on the design and the granting of permission by the Eclipse Foundation, I believe the issue is resolved and as such this ticket can be closed.


Many-to-one assignment per cell

Is your feature request related to a problem? Please describe.
I have many NPCs/items/places/etc but not enough real-estate on the GM screen to place them
Describe the solution you'd like
I'd like drop-down menus to return, in a way that allows me to swap between multiple entries quickly without having to have 100 tabs.
Describe alternatives you've considered
Many many many tabs.
Additional context
None

This is tricky, it'll involve another breaking change of the data model. I'm also not super keen on the idea if I'm honest. There's a lot of complexity involved for this and it's a pretty niche use case. I didn't envision this being used as a way to hold vast quantities of information, only the little things you frequently reference. For example, I have a JE which is just links to other JEs which describe the 5e conditions.
For the fun of it, let's think some more about it though.
Providing a way to have "tabs" inside the cells would solve this. I'm not keen on the dropdown menus tbh.
The UX of populating a cell is more difficult with this. Lets think some about that.
At the moment the way to populate a cell is to drag and drop it, that isn't something I'm keen on changing as that allows supporting Compendium entries easily. But with additional "sub-panels" or "tabs in cells" the UX has to be considered.
Does dragging an entry onto a populated cell still replace the cell's contents or does it create a new tab? I am leaning towards create a new tab.
Tabs should be easy to clear. Little X in the tab makes sense.

Going to go ahead and close this as its complexity makes me believe I'm never going to actually implement this.


Prettier: failed to parse buffer

Do you want to request a feature or report a bug?
In NeoVim show error Prettier: failed to parse buffer in I save JavaScript file.
This is my init.vim configure
language en_US

" Easy split navigation
nnoremap <C-w> <C-w>w
nnoremap <C-h> <C-w>h
nnoremap <C-j> <C-w>j
nnoremap <C-k> <C-w>k
nnoremap <C-l> <C-w>l

set nocompatible
set encoding=UTF-8
filetype plugin indent on

syntax on
set termguicolors
colorscheme gruvbox
set background=dark
set guifont=Iosevka\ Slab:h16
set laststatus=2

set clipboard^=unnamed,unnamedplus
set t_RV=
set t_Co=256
set number
set showmatch
set visualbell

set hlsearch
set smartcase
set ignorecase
set incsearch

set autoindent
set shiftwidth=2
set smartindent
set smarttab
set softtabstop=2

set ruler
set undolevels=1000
set backspace=indent,eol,start

set nobackup
set nowritebackup
set noswapfile
set noundofile

set cmdheight=2
set updatetime=300
set shortmess+=c
set signcolumn=yes

" Plugins
call plug#begin('~/.config/nvim/plugged')

Plug 'morhetz/gruvbox'

" Frontend
Plug 'othree/html5.vim'
Plug 'elzr/vim-json'
Plug 'JulesWang/css.vim'
Plug 'ap/vim-css-color'
Plug 'prettier/vim-prettier', { 'do': 'npm install' }
Plug 'pangloss/vim-javascript'
Plug 'posva/vim-vue'

" Elm
Plug 'elmcast/elm-vim'

" Elixir
Plug 'elixir-lang/vim-elixir', { 'for': 'elixir' }
Plug 'slashmili/alchemist.vim', { 'for': 'elixir' }

" Svelte
Plug 'evanleck/vim-svelte'

" Themes
Plug 'itchyny/lightline.vim'

" Miscellaneous
Plug 'tpope/vim-sensible'
Plug 'tpope/vim-surround'
Plug 'tpope/vim-fugitive'
Plug 'tpope/vim-commentary'
Plug 'airblade/vim-gitgutter'
Plug 'w0rp/ale'
Plug 'scrooloose/nerdtree', { 'on':  'NERDTreeToggle' }
Plug 'mileszs/ack.vim'
Plug 'junegunn/fzf', { 'dir': '~/.fzf', 'do': './install --all' }
Plug 'junegunn/fzf.vim'
Plug 'editorconfig/editorconfig-vim'
Plug 'sheerun/vim-polyglot'
Plug 'mattn/emmet-vim'
Plug 'sbdchd/neoformat'
Plug 'neoclide/coc.nvim', {'branch': 'release'}

call plug#end()

" Python
let g:python_host_prog = '/usr/local/bin/python'
let g:python3_host_prog = '/usr/local/bin/python3'

" Nerdtree
let g:NERDTreeIgnore = ['.DS_Store', '.cache$', 'node_modules$', '.git$', 'debug$', '\~$']
let g:NERDTreeShowHidden = 1
let g:NERDTreeMinimalUI = 1
let g:NERDTreeStatusline = ''
autocmd bufenter * if (winnr("$") == 1 && exists("b:NERDTree") && b:NERDTree.isTabTree()) | q | endif
map <F2> :NERDTreeToggle<CR>

" Elm
"let g:polyglot_disabled = ['elm']
let g:elm_setup_keybindings = 0
let g:elm_detailed_complete = 1
let g:elm_format_autosave = 1

" Vue
let g:vue_disable_pre_processors = 1

" Prettier
autocmd BufWritePre *.js,*.jsx,*.mjs,*.ts,*.tsx,*.css,*.less,*.scss,*.json,*.graphql PrettierAsync
let g:prettier#autoformat = 1
let g:prettier#exec_cmd_async = 1
let g:prettier#config#parser = 'babylon'

" Ale
let g:ale_fixers = {
\  'elixir': ['mix_format'],
\  'javascript': ['prettier'],
\  'typescript': ['prettier'],
\  'vue': ['prettier'],
\  'scss': ['prettier'],
\  'html': ['prettier'],
\  'svelte': ['prettier']
\}
let g:ale_fix_on_save = 1
let g:ale_completion_autoimport = 1

" Fzf
let $FZF_DEFAULT_COMMAND = 'rg --files --hidden --follow --glob "!{node_modules/*,debug/*,.git/*}"'
nnoremap <C-b> :Buffers<CR>
nnoremap <leader><leader> :Commands<CR>
nnoremap <C-p> :Files<CR>

" Emmet
autocmd FileType html,css EmmetInstall
let g:user_emmet_install_global = 0
let g:user_emmet_leader_key=','

" Commentary
autocmd FileType apache setlocal commentstring=#\ %s

What is the current/expected behavior?
What version of vim-prettier are you using - (output of :PrettierVersion) ?
1.0.0-beta
What version of prettier are you using - (output of  :PrettierCliVersion) ?
2.1.2
What is your prettier executable path - (output of  :PrettierCliPath) ?
Users/dangvanthanh/.config/nvim/plugged/vim-prettier/node_modules/.bin/prettier

Hi, I'm receiving the same error.
.vimrc
" specify dir for plugins
call plug#begin('~/.vim/plugged')

Plug 'prettier/vim-prettier', { 'do' : 'yarn install' }

" colorschemes
Plug 'morhetz/gruvbox'

" initialize plugin system
call plug#end()

:PrettierVersion 1.0.0-beta
:PrettierCliVersion 2.0.4
:PrettierCliPath /Users/khuynh/.vim/plugged/vim-prettier/node_modules/.bin/prettier

Same here
call plug#begin('~/.vim/plugged')
Plug 'prettier/vim-prettier', { 'do': 'yarn install' }
Plug 'junegunn/fzf', { 'do': { -> fzf#install() } }
call plug#end()

More details
:PrettierVersion      1.0.0-beta
:PrettierCliVersion   2.0.4
:PrettierCliPath      home/spongebob/.vim/plugged/vim-prettier/no

I had the same issue with old versions.
It got resolved when I removed .prettierrc
After upgrading to the latest, even without a config file, I get this error leaving me unable to use the plugins.

I found the workaround.
put this in vim config
let g:prettier#config#single_quote = 'true'
" none|es5|all
let g:prettier#config#trailing_comma = 'all'

I found the workaround.
put this in vim config
let g:prettier#config#single_quote = 'true'
let g:prettier#config#trailing_comma = 'all'

Thanks @zirho
I was removed
let g:prettier#config#parser = 'babylon'

then put your config. It's working for me.

i can confirm that @zirho 's solution works for me!

I too confirm @zirho 's solution worked for me!

this might be related to error
[error] Invalid --trailing-comma value. Expected "all", "none", "php5" or "php7.2", but received "es5".

possibly related to NVM and the default version of node being set in the system.
Prettier is being run with the default version and that could lead to this error.

I can confirm that @zirho's solution also worked for me :), really enjoying this plugin, thank you to the devs for creating this it is wonderful to get Prettier support inside of Neovim!

FWIW and in case it's a clue for the root cause, I only needed one line:
let g:prettier#config#trailing_comma = 'all'

from @zirho's solution to get rid of Prettier: failed to parse buffer. That was with vim-prettier 1.0.0-beta and prettier installed by the plugin at version 2.0.4.

It is potentially an issue with the php plugin, though I've no idea. Maybe it is overwriting the available trailing comma options? I'm getting the same issue on my Mac setup. If I remove the plugins from the package.json file (as I don't need any of them) then delete node_modules and yarn install again then it starts working.
I would also deeply appreciate some way of getting more information out of prettier when seeing the "failed to parse buffer" error. I didn't see any option but is there some kind of verbose logging mode to help debug this? I ended up adding echom join(a:errors, "\n") to the onError function in job/runner.vim.

Possibly also because the package.json specifies 0.10.2 for the php plugin and that was released back in February 2019. There have been a number of fixes (probably including this) since then.
It might make sense to specify a much looser constraint.
https://github.com/prettier/vim-prettier/blob/bc7ae99c38a1d0f58380347515b212f93df5e68e/package.json#L16-L19

I found the workaround.
put this in vim config
let g:prettier#config#single_quote = 'true'
let g:prettier#config#trailing_comma = 'all'

Thank you so much – this finally fixed my issue!

This is indeed related to prettier-php version being too old. The problem was fixed:
https://github.com/prettier/plugin-php/issues/964
Updating to a newer version than plugin-php 0.11.1 should solve the problem.

This is indeed related to prettier-php version being too old. The problem was fixed:
prettier/plugin-php#964
Updating to a newer version than plugin-php 0.11.1 should solve the problem.

Not fixed

possibly related to NVM and the default version of node being set in the system.
Prettier is being run with the default version and that could lead to this error.

I stumbled across this issue after searching for the Prettier: failed to parse buffer error and my issue was indeed my Node version. My shell was running version 8 via nvm rather than my default version 16 when I started vim. After exiting, switching and trying again it worked.

I found the workaround.
put this in vim config
let g:prettier#config#single_quote = 'true'
let g:prettier#config#trailing_comma = 'all'

This works for me but I want to run prettier with the defaults so it's not an ideal solution.

possibly related to NVM and the default version of node being set in the system.
Prettier is being run with the default version and that could lead to this error.

I stumbled across this issue after searching for the Prettier: failed to parse buffer error and my issue was indeed my Node version. My shell was running version 8 via nvm rather than my default version 16 when I started vim. After exiting, switching and trying again it worked.

What's the best way to check which version of node vim-prettier is running and is there a way to configure a version for vim-prettier? NVM is currently set to current LTS v14.17.4

This is causing me issues for me now :(
Solutions I tried:

I tried to use the prettier config mentioned (though I don't see how it affects the parser!)

My versions:

PrettierVersion: 1.0.0-beta
PrettierCliPath: ~/.vim/plugged/vim-prettier/node_modules/.bin/prettier
PrettierCli: [error] No parser and no file path given, couldn't infer a parser.^@

In my experience this issue is caused by me renaming the root directory of a directory containing node packages.
My fix has been to delete the node_modules folder and run npm or yarn to refresh it:
rm -rf node_modules
yarn

I found the workaround.
put this in vim config
let g:prettier#config#single_quote = 'true'
let g:prettier#config#trailing_comma = 'all'

Thanks @zirho
I was removed
let g:prettier#config#parser = 'babylon'

then put your config. It's working for me.

This fixed it for me.

I am having this problem when using with Lazy.nvim, thanks to the answer above, I put together with this solution:
return {
  'prettier/vim-prettier',
  build = function()
    os.execute("yarn install --frozen-lockfile --production")
    vim.g.prettier.config.single_quote = true
    vim.g.prettier.config.trailing_comma = 'all'
  end
}

I found the workaround.
put this in vim config
let g:prettier#config#single_quote = 'true'
let g:prettier#config#trailing_comma = 'all'

I tried this but it did not work for me on my _vimrc file on windows,
surprisingly enough :prettier or my map <Leader><Leader>p works just fine
and .ts/tsx files work just fine on save!
autocmd BufWritePre *.js,*.jsx,*.mjs,*.ts,*.tsx,*.css,*.less,*.scss,*.json,*.graphql,*.md,*.vue,*.svelte,*.yaml,*.html PrettierAsync
I don't face this issue on my linux machine however


Regression in segment time calculation - presentationTimeOffset is added when it should not be

https://github.com/google/shaka-player/commit/20750504fecd4855f2997dcd2eb92a7024dc2bdc appears to have introduced a regression, with the key line in question being https://github.com/google/shaka-player/blame/master/lib/dash/segment_template.js#L324. Possibly more of the logic is suspect - I did not dig deeper beyond finding why the first numbers with my video were off.
As far as I can tell, the function find appears to be there to determine the ~MPD start time in seconds~ segment position of the segment containing periodTime, which is an offset from the start of the period in seconds.
Using presentationTimeOffset in this calculation is incorrect. PTO does not determine anything about the MPD timeline, it says what media timestamp (PTS) corresponds to periodTime = 0. You should only use it for aligning the media timeline with the MPD timeline.
The referenced commit causes any segmentTemplate-using streams with presentationTimeOffset to have segments scheduled at the wrong moments in time.
Still working on getting playable URL for you but I thought I would post immediately as it seemed pretty clear cut to me. Let me know if you want more supporting material and evidence and I am happy to provide.
Example MPD:
<MPD type="dynamic" availabilityStartTime="1970-01-01T00:07:00Z" profiles="urn:mpeg:dash:profile:isoff-live:2011,http://dashif.org/guidelines/dash264" timeShiftBufferDepth="PT15M" minimumUpdatePeriod="PT15S" minBufferTime="PT2S" publishTime="2018-01-17T14:49:04.237755Z" xmlns="urn:mpeg:dash:schema:mpd:2011">
  <!--availabilityStartTime is adjusted to add a delay of 00:07:00 to the availability timeline compared to the authoring timeline. Timestamps in period/segment paths indicate authoring time (UTC), not availability time (UTC+delay). Playback uses availability time.-->
  <Period id="p_1516198946762" start="P17548DT14H22M26.762S">
    <!--Starts 2018-01-17 14:21:59.762Z (1,516,198,946,762 ms from epoch) on the authoring timeline.-->
    <!--Starts 2018-01-17 14:28:59.762Z (1,516,199,366,762 ms from epoch) on the availability timeline.-->
    <AdaptationSet segmentAlignment="true" group="1">
      <SegmentTemplate timescale="1000" duration="4000" media="p_1516198946762/$RepresentationID$/$Number%06d$.m4s" initialization="p_1516198946762/$RepresentationID$/init.mp4" presentationTimeOffset="1516198946762" />
      <Representation id="Track0" mimeType="audio/mp4" startsWithSAP="1" bandwidth="64000" audioSamplingRate="48000" codecs="mp4a.40.2" />
    </AdaptationSet>
    <AdaptationSet segmentAlignment="true" group="2" par="16:9" maxHeight="720" maxWidth="1280" frameRate="30">
      <SegmentTemplate timescale="1000" duration="4000" media="p_1516198946762/$RepresentationID$/$Number%06d$.m4s" initialization="p_1516198946762/$RepresentationID$/init.mp4" presentationTimeOffset="1516198946762" />
      <Representation id="Track1" mimeType="video/mp4" startsWithSAP="1" bandwidth="3000000" sar="1:1" width="1280" height="720" codecs="avc1.640032" />
    </AdaptationSet>
  </Period>
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="Manifest.mpd" />
</MPD>

The period starts at some point on 2018-01-17. Both the MPD timeline zero point and the media timeline zero point are in 1970. The latter is indicated by presentationTimeOffset. The first segment to be played at period start is number 1.
However, because of the problematic commit, Shaka adds PTO to the first segment, trying to play back something from 2066 instead (it tries to play segment number 379054268 as I post this).

This should be working now in the nightly build:  https://nightly-dot-shaka-player-demo.appspot.com/demo/
Can someone please confirm?

Doesn’t work for me. My stream still shows the same problems as before.
Jacob

On 1 Feb 2018, at 16.51, Joey Parrish<EMAIL_ADDRESS>wrote:
This should be working now in the nightly build: https://nightly-dot-shaka-player-demo.appspot.com/demo/
Can someone please confirm?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@TheModMaker, can you please take a look?

I confirm the stream I posted appears to work with the nightly build.

@stroemlund Can you give us a manifest URL?

https://dmpe12-4dash.akamaized.net/dash/live/594304/DPME12-4/index.mpd

On 1 Feb 2018, at 18.16, Jacob Trimble<EMAIL_ADDRESS>wrote:
@stroemlund Can you give us a manifest URL?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@stroemlund  That manifest doesn't use presentationTimeOffset, so the issue is unrelated.
When I fetch the manifest at 2018-02-01T17:50:49Z, the availabilityStartTime is 2018-01-29T07:43:30Z, which puts the live edge at 295639 seconds.  The first segment in the manifest is at<PHONE_NUMBER>0 / 90000 or 295672 seconds, which is in the future.  It looks like your stream is suffering from drift.  See #999.
Since this is unrelated I'm closing the issue.  If you have problems with another stream, you should probably file a new issue.

Sure makes sense! Well we are running elemental encoders according to standards and we see no reason for it to drift as this is a problem even at the very first segment of the stream. So it doesn’t happen over time but immediately from the start.

On 1 Feb 2018, at 18.58, Jacob Trimble<EMAIL_ADDRESS>wrote:
Closed #1232.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Cherry-picked for v2.3.3.  The correctness of the fix was still being debated while I was preparing v2.3.2.  Sorry for any inconvenience caused by delaying this fix for one more release.

So 2.3.3 the drift fix should be included?

On 1 Feb 2018, at 22.23, Joey Parrish<EMAIL_ADDRESS>wrote:
Cherry-picked for v2.3.3. The correctness of the fix was still being debated while I was preparing v2.3.2. Sorry for any inconvenience caused by delaying this fix for one more release.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

No, we are still working on fixes for drift, which you can fallow in #999.  The fix for SegmentTemplate with duration will appear in 2.3.3.

Just funny the streams are playing in 2.2.x

On 2 Feb 2018, at 19.55, Jacob Trimble<EMAIL_ADDRESS>wrote:
No, we are still working on fixes for drift, which you can fallow in #999. The fix for SegmentTemplate with duration will appear in 2.3.3.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Referring to the analysis above in https://github.com/google/shaka-player/issues/1232#issuecomment-362349850, if the segment times are in the future, it sounds like it's not drift, but rather a clock sync or encoder clock issue.  Is the clock on your encoder correct?  Do you have clock sync set up on the content?

The clock is spot on. And how can the same encoder set different time on segments and manifest start?

On 2 Feb 2018, at 20.17, Joey Parrish<EMAIL_ADDRESS>wrote:
Referring to the analysis above in #1232 (comment), if the segment times are in the future, it sounds like it's not drift, but rather a clock sync or encoder clock issue. Is the clock on your encoder correct? Do you have clock sync set up on the content?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I don't know, but it could be a bug in the Elemental encoder.  Have you talked to Elemental support?

Yes plenty of times. And they simply refers to the stream working in every other players except shaka due to shaka handling the timestamps differently.

On 12 Feb 2018, at 19.46, Joey Parrish<EMAIL_ADDRESS>wrote:
I don't know, but it could be a bug in the Elemental encoder. Have you talked to Elemental support?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

As far as we can tell (analysis above), the segment times are in the future.  Since we are already planning a general approach to ignore availabilityStartTime (#999), I don't think there's anything more specific we can do for you right now.  I expect your problem will be solved once #999 is implemented.  In the mean time, you are always welcome to customize Shaka Player sources however you need to for your deployment.
Sorry we couldn't do more for you directly.  If you subscribe to #999, you will be notified when we close the issue.


Error when installing container: Warning: docker.utils.create_host_config() is deprecated.

I'm experiencing this issue:
failed: [orchestra_vm] => {"failed": true, "parsed": false}
BECOME-SUCCESS-jvspektsacgiiafyvmwdbucorbumxbth
/usr/local/lib/python2.7/dist-packages/docker/utils/utils.py:486: UserWarning: docker.utils.create_host_config() is deprecated. Please use Client.create_host_config() instead.
  'docker.utils.create_host_config() is deprecated. Please use '
Killed
OpenSSH_6.9p1, LibreSSL 2.1.7
debug1: Reading configuration data /Users/matias/.ssh/config
debug1: /Users/matias/.ssh/config line 12: Applying options for orchestra_vm
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: auto-mux: Trying existing master
debug1: mux_client_request_session: master session id: 2
Shared connection to <IP_ADDRESS> closed.

When using this configuration:
- name: redis containers
  docker:
    name: myredis
    image: redis
    command: redis-server --appendonly yes
    state: started
    expose:
    - 6379
    volumes_from:
    - mydata

Also, after receiving that error, my ssh connection breaks.
Looks like a problem with the version of docker-py and docker-compose. As a temporary solution, I've noticed there are variables that can be passed to use a specific version: pip_version_docker_py, pip_version_docker_compose. I've tried passing version '1.5' for both items but didn' t help. Any suggestion?

Issue solved. The problem was that I was including 'volumes_from: mydata' parameter and there wasn't another container with that name.
Sorry for the noise, but It was tough to figure it out, since ansible output wasn't logging this error.


feature request || idea

How about a change or watch event that fires on object changes, like described here:
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/watch
http://stackoverflow.com/questions/1759987/detect-variable-change-in-javascript
That would really complete sugar.js.
sugar.js gives a lot more functionality than backbone.js models. Only the change binding is missing.
Correct me, if this idea is way off. Its 6am in the morning and I have to go to bed :)

OK! This feature is now in v1.0 of Sugar. The method is Object.watch, like the non-standard Mozilla method of the same name (re: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/watch). Unlike other Sugar methods, watch WILL overwrite the native method, as they have different implementations and intentions (despite having identical syntax). It is unfortunate to have to lose < IE8 support in this one method only, but I think the benefits justify it here.


Feature: Added image dimentions in hover-over summary

Resolved / Related Issues
To prevent extra work, all changes to the Files codebase must link to an approved issue marked as Ready to build. Please insert the issue number following the hashtag with the issue number that this Pull Request resolves.

Closes #14975

Steps used to test these changes
Stability is a top priority for Files and all changes are required to go through testing before being merged into the repo. Please include a list of steps that you used to test this PR.

Open Files app
Hover over an image file
See if it is corrupt image or dimention property is unavailable it wont be shown

Works fine on my end.
Ready for review again.

I noticed that it's not returning values for webp files, it would be nice to resolve this but it's not a blocker.


[SPARK-8774] [ML] Add R model formula with basic support as a transformer

This implements minimal R formula support as a feature transformer. Both numeric and string labels are supported, but features must be numeric for now.
cc @mengxr

Merged build triggered.

Merged build started.

Test build #37166 has started for   PR 7381 at commit fb0826b.

Test build #37166 has finished for   PR 7381 at commit fb0826b.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Merged build triggered.

Merged build started.

Test build #37167 has started for   PR 7381 at commit 1f361b0.

Merged build triggered.

Merged build started.

Test build #37170 has started for   PR 7381 at commit 5765ec6.

Test build #37170 has finished for   PR 7381 at commit 5765ec6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test build #37167 has finished for   PR 7381 at commit 1f361b0.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Merged build triggered.

Merged build started.

Test build #37282 has started for   PR 7381 at commit dc3c943.

Test build #37282 has finished for   PR 7381 at commit dc3c943.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class RModelFormula(override val uid: String)

Merged build finished. Test PASSed.

@ericl I make another pass. The major issue is actually that RModelFormula should be an Estimator instead of a Transformer in order to handle String columns. It requires some changes to the current implementation. So I would suggest removing the support for string labels in this PR and address it in a follow-up PR, since we already reviewed most of the code. It is okay to just comment out the test. Does it sound good to you?

Merged build triggered.

Merged build started.

Test build #37425 has started for   PR 7381 at commit 2db68aa.

@mengxr That makes sense, I'll do that in a followup PR. I also addressed the comments.

Merged build triggered.

Merged build started.

Test build #37426 has started for   PR 7381 at commit d1959d2.

Test build #37425 has finished for   PR 7381 at commit 2db68aa.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class RFormula(override val uid: String)

Merged build finished. Test PASSed.

Test build #37426 has finished for   PR 7381 at commit d1959d2.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class RFormula(override val uid: String)

Merged build finished. Test PASSed.

LGTM except some minor comments, which we can fix in the next PR. Merged into master. Thanks! As the next step, we can create a wrapper for RFormula + LinearRegression on the Scala side and then call it in R. Independently, we can add features to RModelParser. I'd recommend the former first in order to have some working MLlib + SparkR features in 1.5.

Sounds good, I'll look at the R integration next.


Please invite me to the GitHub Community Organization

Name
Ikko Eltociear Ashimine
Discord Username (if applicable)
No response
Additional Context
for learning

It's great having you contribute to this project
If you would like to continue contributing to open source and would like to do it with an awesome inclusive community, you should join our Discord Server and our GitHub Organisation - we help and encourage each other to contribute to open source little and often 🤓 . Any questions let us know.

Invitation sent for the GitHub Organisation. Welcome to the community 🎉#
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see, you can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/jaidevstudio/people
Like this

Tips for practising:
Remember contributing to open source is not just about code, its about collaboration, communication and adding value
I hope that helps

Please check your email or organisation page 🙏


Unregister metrics when closing broker

@slaunay @mihasya @lday0321 this should hopefully solve #897? I don't know if I've covered all the cases.

This will reduce most of the memory leak as it is mostly tied to metrics.Meter created by non seed Broker.
That being said the following meters would still leak when closing a Client (or an AsyncProducer/Consumer) and then creating a new one (not sure if this is a common use case):

incoming-byte-rate
outgoing-byte-rate
 request-rate
record-send-rate
record-send-rate-for-topic-<topic>

Also if a custom metrics.Registry is provided in the Config, those metrics will still exists in the registry after the Client has been closed. This can be used to contain such memory leak by reusing that custom metrics.Registry but it's abusing a side effect.
If we want to add more metrics in the future (e.g. per topic and partition) this can become problematic.
I can provide a similar PR for unregistering broker metrics when a Broker is closed (as done here) plus unregistering global ones when a Client is closed.
Ensuring backward compatibility will make such a fix more convoluted that the current one.
Here is a benchmark that can be used with pprof to check if memory is still leaking:
func BenchmarkNewClientWithMeterMetric(b *testing.B) {
    setupFunctionalTest(b)
    defer teardownFunctionalTest(b)

    for i := 0; i < b.N; i++ {
        client, err := NewClient(kafkaBrokers, nil)
        if err != nil {
            b.Fatal(err)
        }
        safeClose(b, client)
    }
}

And the pprof bits to see what was not garbage collected at the end of the benchmark  (-memprofile triggers a GC before profiling the heap):
$ go test -bench=NewClient -benchmem -memprofilerate=1 -memprofile mem.prof -run=^$ -v -benchtime=10s
BenchmarkNewClientWithMeterMetric-8         5000           2679507 ns/op           69010 B/op        185 allocs/op
PASS
ok      github.com/Shopify/sarama       13.682s
$ go tool pprof -top sarama.test mem.prof | grep metric
         0     0% 98.99%  6400.19kB 96.87%  github.com/Shopify/sarama/vendor/github.com/rcrowley/go-metrics.(*StandardRegistry).GetOrRegister
         0     0% 98.99%     6400kB 96.86%  github.com/Shopify/sarama/vendor/github.com/rcrowley/go-metrics.GetOrRegisterMeter
$ go tool pprof -list metric sarama.test mem.prof
Total: 6.45MB
ROUTINE ======================== github.com/Shopify/sarama/vendor/github.com/rcrowley/go-metrics.(*StandardRegistry).GetOrRegister in /.../github.com/Shopify/sarama/vendor/github.com/rcrowley/go-metrics/registry.go
         0     6.25MB (flat, cum) 96.87% of Total
         .          .     82:   defer r.mutex.Unlock()
         .          .     83:   if metric, ok := r.metrics[name]; ok {
         .          .     84:           return metric
         .          .     85:   }
         .          .     86:   if v := reflect.ValueOf(i); v.Kind() == reflect.Func {
         .     6.25MB     87:           i = v.Call(nil)[0].Interface()
         .          .     88:   }
         .          .     89:   r.register(name, i)
         .          .     90:   return i
         .          .     91:}
         .          .     92:
         .          .     93:// Register the given metric under the given name.  Returns a DuplicateMetric
         .          .     94:// if a metric by the given name is already registered.

Why? Is this PR not backwards-compatible in some way I'm missing?
Does it make sense to merge this PR and open another one to unregister metrics on Client.Close or would you prefer to tackle it all at once?

Sorry for the confusion.
What I meant is that unregistering all the metrics (including the meters that leak memory) in a backward compatible way (e.g. not introducing breaking changes or requiring calling a new method for cleaning up) is not trivial as they are created in various places.
Of course backward compatibility is mandatory like it is the case in the current PR.
I can submit such a PR for unregistering all the metrics in the next few days but because they will touch the same lines it probably make sense to keep this one till you decide which solution is more sensible.

So I dug through the metrics a bit more and IIUC they fall in three categories:

per-broker metrics (which this PR fixes)
global broker metrics (which can't be automatically unregistered since they're not scoped to anything at all)
global produce-request metrics (which can't be automatically unregistered since they're not scoped to anything at all)

Have I missed a set or do you have a clever idea for the latter two?

The common scope of all the metrics is the Config struct as it references a local metrics.Registry but such struct does not provide a method for closing or releasing resources and it probably does not make sense to add one in there.
Metrics are never global per say as you can have two AsyncProducer with their own Config and the metrics would not collide (referenced by their own metrics.Registry).
The Client interface is a common component used by high level components (AsyncProducer, Consumer) and is often stored with a flag (ownClient) in order to decide when to clean up resources.
In order to unregister metrics, we need to keep track of them potentially with a scope (per broker or "global") and choose when it is safe to proceed with the unregistration.
One solution would be to expose a struct implementing metrics.Registry as a wrapper against the one configured in the Config struct for registering metrics and differentiate the broker metrics from the "global" ones through the name (-for-broker-).
Another solution would be to have a struct referencing the metrics.Registry from the Config struct with explicit methods to register a broker or a "global" metric.
I do prefer the second one as it is explicit.
Then whenever we close a Client (directly or through a higher level component like AsyncProducer) we would also cleanup the metrics.
We could also do that in the AsyncProducer or Consumer too but that seems redundant.
So the idea would be to tie the life cycle of the metrics to the life cycle of the Client with some abstraction to register/reference metrics so that we can clean them up.
This is more convoluted that the current PR but as long as the user closes the Client or the AsyncProducer (which he must already) we should be able to unregister any metrics that was added to the configured metrics.Registry (keep in mind that it could be a custom one) and therefore fix the memory leak.
Also, one other use case that comes to mind would be to have producer metrics like record-retry-rate (meter 😢) that would be fed by the AsyncProducer.
I believe the internal Client is closed once the AsyncProducer is shutdown so we should be able to support such metrics too.
It is actually already the case in a way for metrics created when building a ProduceRequest.
The PR implementing such behavior should clear things up I hope and provide good material for discussion.

The common scope of all the metrics is the Config struct as it references a local metrics.Registry

Right

but such struct does not provide a method for closing or releasing resources

The registry itself provides a UnregisterAll method... I'm tempted to just tell people they should call that when they're done with a registry.
Ugh, this is messy.
Thanks for the detailed explanation - I'm gonna merge this PR and leave the rest of it well enough alone. This fixes the majority of the realistic issues and as you mentioned everything else gets super-complicated because we don't have anything which precisely matches the right scopes. Not worth spending time on right now as long as it's just hypothetical.

👍 Fair enough, keeping it simple.
The broker meters were the ones mainly leaking memory although it never really impacted our applications.
The only drawback of using registry.UnregisterAll is that when using the PrefixedRegistry it does not behave as expected (at least from my perspective):
package main

import (
        "fmt"
        "os"

        "github.com/Shopify/sarama"
        "github.com/rcrowley/go-metrics"
)

func main() {
        appMetricRegistry := metrics.NewRegistry()
        appGauge := metrics.GetOrRegisterGauge("m1", appMetricRegistry)
        appGauge.Update(1)

        config := sarama.NewConfig()
        // Use a prefix registry instead of the default local one
        config.MetricRegistry = metrics.NewPrefixedChildRegistry(appMetricRegistry, "sarama.")

        // Simulate a metric created by sarama without starting a broker
        saramaGauge := metrics.GetOrRegisterGauge("m2", config.MetricRegistry)
        saramaGauge.Update(2)

        fmt.Println("App metrics before:")
        metrics.WriteOnce(appMetricRegistry, os.Stdout)

        // Unregister all the sarama metrics
        // but will unregister the parent registry metrics too...
        config.MetricRegistry.UnregisterAll()

        fmt.Println("App metrics after:")
        metrics.WriteOnce(appMetricRegistry, os.Stdout)
        // Output:
        // App metrics before:
	// gauge m1
	//   value:               1
	// gauge sarama.m2
        //   value:               2
        // App metrics after:
}

But this is a bug in go-metrics and one can easily build a different implementation of PrefixedRegistry.


CASMPET-6898 update CSM only upgrade to set CFS on storage nodes

Description
Storage nodes have their own CFS configuration when products are installed. Our previous procedure assumed that there was only one management node configuration. Our documentation needs to be updated so that storage nodes are configured with the correct CFS configuration. This was found and tested on a Drax upgrade.

Checklist

[x] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[x] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[x] My commits or Pull-Request Title contain my JIRA information, or I do not have a JIRA.

/backport release/1.5

/backport release/1.4


[W4.4b][W15-A2]Ho Bing Xuan

Implemented simple classes under Address.java. Updated help, UserGuide, expected.txt and input.txt

Some minor issues with the framing of commit messages. Please refer to this link https://chris.beams.io/posts/git-commit/.


Logged user can enter board with any url

Product: Contriboard
Build Version: v1.2.3
Description: Logged user can enter to a boardview with an url like this: "http://lankku.n4sjamk.org/boards/AnythingYouWantToWrite"
Reported By: Mikko Kemppinen
Steps:
1.Log in to Contriboard as an user
2.Enter "http://lankku.n4sjamk.org/boards/AnythingYouWantToWrite" as an Url.
3.Press enter
Expected result: If the url is wrong, user is noticed that the board does NOT exist and user is taken back to workspace.

We should probably create a 404 page, and on any requests that return the 404 we redirect to that page... I think this is how GitHub does it!

Fixed in this commit: https://github.com/melonmanchan/teamboard-client-react/commit/dd7d206938f7fe5b67f52de3e907941a903228bd
We just send the user back to workspace if the board id is nonexistent. However the 404 is only returned if the boards/url could possibly be a valid MongoDB ObjectID. Otherwise the API automatically respons with 400 bad request. Currently the commit handles bothh cases by returning you to the workspace

Close this issue when the referenced commit gets merged here.


Please add the DOI of the new publication to the README

A publication that covers the primary features of this project just came out, see https://doi.org/10.3389/fbinf.2023.1214074. It would be good to add it prominently to the README file, possibly in addition to the ZENODO link as a badge.

[x] Badge in README for publication in Frontiers

I added a badge for the publication in Frontiers to the README and changed the badge for the Zenodo DOI. This badge was changed for two reasons: (a) the design is now the same for both DOI badges and, more importantly, (b) to reduce confusion as the label of the Zenodo DOI badge was only DOI. These changes are currently only on the development branch dev. The reasoning is that the README shown in PyPI is only updated if a new release is made. Thus, adding the new badge in the README on the main branch makes only sense with a new release.
@cb-Hades and @f3rryman, we should see if the changes currently on dev would already be enough for a tiny release to add the README changes. Maybe we can turn the setup.py into the pyproject.toml and use this as a reason for a new release? 🤔


ENH: Allow Stairs.fillna to take a Stairs parameter

Is your feature request related to a problem?
We want the value parameter in Stairs.fillna to be able to take a staircase.Stairs parameter
current definition https://github.com/staircase-dev/staircase/blob/cb0265d1b182ad3a8452f544c197ce54aef6feea/staircase/core/ops/masking.py#L160
docstring https://github.com/staircase-dev/staircase/blob/cb0265d1b182ad3a8452f544c197ce54aef6feea/staircase/core/ops/docstrings.py#L459
Describe the solution you'd like
See https://www.staircase.dev/en/latest/user_guide/cookbook.html#fill-undefined-intervals-of-one-step-function-with-another for an implementation

take

Hi - whilst implementing the suggested approach is straightforward - it has the side effect of leaving zeros in the mutated SC object if the replacing SC also has nans that overlap.
I would expect this case to leave those nans as nans, replacing only those nans where the replacing SC has values
The logic for this is straightforward - but I'm still to fully understand the data structure to implement it.  A few attempts aren't yet working.
aka - I'm still plugging away

Hi @ChristopherShort, good catch!
Will certainly have to be one of the tests!
I have a solution which builds on the original one liner, without having to delve into the internals of staircase.  Don't want to ruin it for you if you're enjoying figuring out so I'm happy to either give you the fix, give you a hint, or neither.  It's up to you.


[SPORK] sporkkey/privkey/pubkey

Under testing I have populated chainparams.cpp with a valid Spork PubKey from a valid keypair.
However, upon adding the PrivKey of the pair to dash.conf; sporkkey=[privkey] and attempting to start the wallet, this message pops up: "Unable to sign spork message, wrong key?"
The key is definitely valid. I am testing this on a closed network, new chain.
This is the same with the master branch of Dash and I am worried that you guys cannot broadcast Spork messages i.e. Masternode Payment Enforcement, or is there something I am missing?

Make sure [privkey] is in WIF format

Ah ha. Thank you UdjinM6, btw can you email me your Skype contact details please -<EMAIL_ADDRESS>

No, I'm not sharing my Skype, sorry.

I have tried with a WIF format privkey and it has the same error message. Is there a problem with CheckSignature in spork.cpp?

Sporks are known to work in dash so must be an issue with your code base.

It is your codebase.

I have a feeling that Evan or another Dash dev did something to Sporks, to not make it easy to screw the network. This isn't just a feeling. It is what I heard.

Hi, I have the exception.
I used process detailed in below URL to generate WIF key. Here in place of 80 I used different random 2 digit number like 20,FF for version byte.
https://gist.github.com/t4sk/ac6f2d607c96156ca15f577290716fcc
Is that the right of generating WIF key? Is your problem resolved?
Would be grateful if you can help me out in this.

Instead of manually serializing your key, I'd recommend using something like masternode genkey to generate the key. You will have to ensure the compression of the WIF format key matches the compression of the hard-coded spork public key (or spork address, if using the develop branch).
This has been working in Dash for years, I've verified this myself on testnet.

thanks @nmarley
Actually I have a different problem and hence working around spork keys.
I cloned the source code , generated all around a new genesis block set up my vps nodes and other VM is with linux qt wallet. when my wallet is connected to the VPS which have my private working model, it is stuck at syncing sporks data (syncing additional data 25% phase). When i start mining using "setgenerate true", blocks are also getting generated. But the sporks data is still at 25%.
I thought of generating my own spork pub & private key(it is in WIF format) and succeeded now. able to use my new spork key pair. Still the wallet is at "Synchronising sporks data" .
Would be grateful if someone can advise to get me out of this problem!

What does the debug.log file say?

Qt is not able to fund the spork data from existing local spork db and
failing to get it from connected peer which is my own VPS on which daemon
running.
I have entered spork private key in qt contained VM machine and not on VPS
on which daemon running.
below is the snippet from debug log related to spork
2018-05-01 21:57:20 ProcessMessage(getsporks, 0 bytes) FAILED peer=1
2018-05-01 21:57:21 asking peer for sporks
2018-05-01 22:21:40 CSporkManager::SetPrivKey - Successfully initialized as
spork signer
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_2_SWIFTTX found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_3_SWIFTTX_BLOCK_FILTERING found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_5_MAX_VALUE found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_7_MASTERNODE_SCANNING found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_9_MASTERNODE_BUDGET_ENFORCEMENT found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_10_MASTERNODE_PAY_UPDATED_NODES found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_13_ENABLE_SUPERBLOCKS found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_14_NEW_PROTOCOL_ENFORCEMENT found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_15_NEW_PROTOCOL_ENFORCEMENT_2 found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_16_ZEROCOIN_MAINTENANCE_MODE found in database
thanks in advance. Would you mind to ping me on discord? 'cryptogeek'
On Wed, May 2, 2018 at 5:49 AM, Nathan Marley<EMAIL_ADDRESS>wrote:

What does the debug.log file say?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dashpay/dash/issues/1378#issuecomment-385864080, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AfRwaWHrm0C7r3DOunzPZf-5IyO_iz72ks5tuTragaJpZM4MSLCT
.

Qt is not able to fund the spork data from existing local spork db and
failing to get it from connected peer which is my own VPS on which daemon
running.
I have entered spork private key in qt contained VM machine and not on VPS
on which daemon running.
below is the snippet from debug log related to spork
2018-05-01 21:57:20 ProcessMessage(getsporks, 0 bytes) FAILED peer=1
2018-05-01 21:57:21 asking peer for sporks
2018-05-01 22:21:40 CSporkManager::SetPrivKey - Successfully initialized as
spork signer
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_2_SWIFTTX found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_3_SWIFTTX_BLOCK_FILTERING found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_5_MAX_VALUE found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_7_MASTERNODE_SCANNING found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_9_MASTERNODE_BUDGET_ENFORCEMENT found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_10_MASTERNODE_PAY_UPDATED_NODES found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_13_ENABLE_SUPERBLOCKS found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_14_NEW_PROTOCOL_ENFORCEMENT found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_15_NEW_PROTOCOL_ENFORCEMENT_2 found in database
2018-05-01 22:21:40 LoadSporksFromDB : no previous value for
SPORK_16_ZEROCOIN_MAINTENANCE_MODE found in database
thanks in advance. Would you mind to ping me on discord? 'cryptogeek'
On Wed, May 2, 2018 at 5:49 AM, Nathan Marley<EMAIL_ADDRESS>wrote:

What does the debug.log file say?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dashpay/dash/issues/1378#issuecomment-385864080, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AfRwaWHrm0C7r3DOunzPZf-5IyO_iz72ks5tuTragaJpZM4MSLCT
.

I agree that Discord (or the Dash forum) is probably a better support channel for this -- let's continue discussion elsewhere. But for this ^, you'll want to make sure you set spork defaults, as well as ensure the spork signatures validate. So you'll need to make sure the public key that's hard-coded in chainparams.cpp matches network spork signatures and that the private key you set is the correct one (matches the hard-coded public key).
Since this is for a fork of Dash, it's getting a bit off-topic, so gonna close discussion here.


UUIDType fields within StructType[AsList] fields do not get saved on mutation

If I have the following field definition:
horses: StructTypeAsList({
  tsType: 'CompetitionEventHorseEntry',
  fields: {
    horseID: UUIDType({
      nullable: true,
      foreignKey: {
        schema: 'Horse',
        column: 'ID',
      },
    }),
    horseName: StringType({
      nullable: true,
      maxLen: 200,
    }),
  },
}),

Then in a create, the horseName field will be saved to the ent, but not the horseID field. Setting the same ID value on a field in that ent that is not part of a StructType works correctly.

I'm gonna try to do some digging on this one, since it's actually quite blocking for me. I was surprised this was the first time I'd actually put a UUID field on a StructType.

Found the problem.
https://github.com/lolopinto/ent/blob/d5cd985ea38c9d06695e08940187ccbd9950b328/ts/src/schema/struct_field.ts#L84
Here camelKey comes back as horseId so val = obj[camelKey] always sets val to undefined.


implement storage memorizer

implement online/zkvm mode both working. Refer to how transaction memorizer handled state_root -> verify mpt proof

resolved by #11


Store should only store one state per turn number

https://github.com/statechannels/monorepo/issues/1555 asserts that the store should only support one state per turn number, within a given channel.
The store has no control over what state a peer sends for turn n. If one of my workflows subsequently want to support a different state at turn n, what should the store do?
Right now, some store logic depends (might depend?) on the fact that there's only one state per turn number.
See https://github.com/statechannels/monorepo/issues/1456#issuecomment-615520101

Duplicate of #1555

This is similar to, but not exactly a duplicate 😛 I'll edit the description to make it more clear.

I think we ran into this with #1729 where the store accepts a state from pushMessage without checking that a state with the same turn number has been added.

I think for the immediate future we should throw an error if the store receives a state with the same turn number. @andrewgordstewart  does that sound good to you?


PLC MOS API access problem v1

Hi, Is there any certificate (.pem) file as we still getting same error when processing on our cloud platform ?
Hi,
the token was not active yet. It is now active (or will be in a few minutes). Please be aware that the API is, unfortunately, currently somewhat slow. We're working on getting the onnx model released for PLCMOS so you could run it yourself, but this may still take a bit.
Best,
Lorenz
Originally posted by @halcy in https://github.com/microsoft/PLC-Challenge/issues/2#issuecomment-1060486208

If you have pasted in your username and token, it should work - nothing additional is required. Alternatively, we have now released our current PLCMOS as an onnx model, so you can try using it locally - please have a look, maybe that helps you do the evaluations you need to do!


pad layer only works for float32

Padding is a core structural op that should work for all array types, but fails for any type that is not float32:
import numpy as np
import mxnet as mx

s=mx.sym.pad(mx.sym.Variable("data", dtype="float64"), mode="edge", pad_width=(0,0,0,0,1,1,1,1))
d=mx.nd.ones((1,2,6,6), dtype="float64")
s.bind(mx.cpu(), {'data': d})

MXNetError: Error in operator pad13: [15:30:33] include/mxnet/operator.h:228: Check failed: in_type->at(i) == mshadow::default_type_flag || in_type->at(i) == -1 Unsupported data type 1

Hello Sebastian,
thanks a lot for noting. Do you think you're able to provide a patch for this?

@sandeep-krishnamurthy Can you please add label: Operator, FeatureRequest

@marcoabreu: yes, I will by next week.

Great! Looking forward to it, thank you.

@sandeep-krishnamurthy please close this issue.


FIXING IDENTITY-3844

Please review and merge

Have we checked putGroup and patchGroup ?

Tested on both, in putGroup it works as expected. Only change is in patchGroup


[ISSUE #2144] Add unit test for ShenyuClientRegisterTarsServiceImpl

// Describe your PR here; eg. Fixes #issueNo
Fixes #2144
About #2420

Make sure that:

[ ] You have read the contribution guidelines.
[ ] You submit test cases (unit or integration tests) that back your changes.
[ ] Your local test passed mvn clean install -Dmaven.javadoc.skip=true.

Codecov Report

Merging #2461 (f13fd1d) into master (31304d8) will decrease coverage by 0.22%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #2461      +/-   ##
============================================
- Coverage     59.29%   59.07%   -0.23%
+ Complexity     4055     4034      -21
============================================
  Files           639      639
  Lines         18127    18127
  Branches       1689     1688       -1
============================================
- Hits          10748    10708      -40
- Misses         6534     6572      +38
- Partials        845      847       +2

Impacted Files
Coverage Δ

...che/shenyu/sync/data/http/HttpSyncDataService.java
61.38% <0.00%> (-19.81%)
:arrow_down:

...henyu/plugin/grpc/resolver/ShenyuNameResolver.java
51.57% <0.00%> (-12.64%)
:arrow_down:

...a/org/apache/shenyu/common/utils/VersionUtils.java
67.85% <0.00%> (-10.72%)
:arrow_down:

.../apache/shenyu/admin/model/dto/BatchCommonDTO.java
50.00% <0.00%> (-7.15%)
:arrow_down:

...apache/shenyu/admin/model/dto/AuthPathWarpDTO.java
57.14% <0.00%> (-7.15%)
:arrow_down:

...org/apache/shenyu/admin/model/dto/AuthPathDTO.java
58.82% <0.00%> (-5.89%)
:arrow_down:

...in/response/strategy/NettyClientMessageWriter.java
69.56% <0.00%> (-4.35%)
:arrow_down:

...che/shenyu/admin/model/vo/DashboardUserEditVO.java
62.50% <0.00%> (-4.17%)
:arrow_down:

...ache/shenyu/admin/model/dto/DataPermissionDTO.java
59.25% <0.00%> (-3.71%)
:arrow_down:

...yu/plugin/grpc/resolver/ShenyuServiceInstance.java
96.29% <0.00%> (-3.71%)
:arrow_down:

... and 23 more

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 71310a5...f13fd1d. Read the comment docs.


[Feature] support Oracle jdbc catalog (#30061)

 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.pengbo seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.