allow helix index changing in batch

Allow both the index of each helix in the list of all helices to be altered, and also the view order specified in DNADesign.helices_view_order.
Furthermore, now that helices are not constrained to be consecutive (#172), allow to change helix indices to be any integers.

This was partially addressed by commit 2eab946, but I'm leaving it open to allow a faster way to re-index all helices at once. Currently they can only be changed one at a time. Swapping two is particularly annoying since one needs to assign one of them a temporary index not belonging to any helix to avoid collision.

Unlike helices_view_order, which has a meaning that does not depend on the old helices_view_order, re-numbering helices requires that you know the old helix numbers when assigning new ones. So entering it the same way as helices_view_order would be harder to use, since, after erasing the old list of indices, one would have to remember what order they appeared in for the new indices to make sense.
So, it seems best to implement this in a more structured way, where the hold indices are displayed read-only, with each of them next to a text field where the new index can be chosen.


Ikelaiah rev12

Hi @gcarreno ,
Here is my latest update.
Still featuring 😄

1 thread. Keeping it simple for now.
No external deps. No longer using LGenerics and it cannot compile against FPC trunk. The author is a bit busy with other commitments.
No memory map. I couldn't find a cross platform lib to make this happen.

Rev 1.12

Revision release - Sequential approach. 2-5 mins on my Inspiron 15 7510 laptop, around 2m40s (small improvement on speed).
Called TStreamReader.ReadLn, twice in the while..do loop. This saves approx 5-10 seconds.
Updated the Acknowledgments section. Added Benibela.

Thanks,
Iwan

@ikelaiah mORMot2 has a memory map. Doesn't work on Delphi Linux x64, but works fine for your FPC or Delphi Windows

Oh really? I'm going to check it out now!
Thanks @georges-hatem.

It's a huge speedup from line by line reading :)


angular#1.5.8 - alert not working

**I'm submitting a bug report
Current behavior:
TypeError: object is not a function - when using alert in angularjs script
Expected / new behavior:
alert should work as it was before
Minimal reproduction of the problem with instructions:
var solutionsModule = angular.module('com.lexec.Reports', []);
solutionsModule.controller('ReportsController', function ($scope, $http){ // , $mdDialog) {
$scope.report = new Object();

$scope.saveReport = function(){
	$http.post("../rest/reports/post", $scope.report).
        then(function (response) {
        	alert('Report has been saved succesfully');
			$scope.report = '';
        }, function (response) {
        	alert('Unexpected failure occurred');
			console.log(response);
        });
}

});
For above code, alert('Report has been saved succesfully') creates and error - "TypeError: object is not a function" in the console.
Angular version: 1.5.8

Browser: [Chrome 39.0.2171.99]

Hi, your issue reads like a support question. This github repo is only for bug reports and feature requests. Please try one of the listed Support Channels. Thanks!


Fix issue with ko/docs/concepts/workloads/controllers/job.md

Closes #23719

/assign @seokho-son

Looks nice!
/lgtm
/approve


Add containerd command

k3s allows users to connect to an existing container runtime via socket.
This is fine for Docker or CRI-O. However, if you want to use
containerd in this way, you need to install a separate containerd binary
even though k3s already contains it. Therefore I added an option to run
just containerd from k3s binary.
Signed-off-by: Peter Pulik<EMAIL_ADDRESS>

Proposed Changes

Types of Changes

Verification

Linked Issues

Further Comments

@peter-pulik can you describe the use case that you have that requires you to run the containerd supplied with k3s as an external service instead of as a sub-process managed by k3s?
Additionally, have you seen /var/lib/rancher/k3s/data/current/bin/containerd --help:
NAME:
   containerd -
                    __        _                     __
  _________  ____  / /_____ _(_)___  ___  _________/ /
 / ___/ __ \/ __ \/ __/ __ `/ / __ \/ _ \/ ___/ __  /
/ /__/ /_/ / / / / /_/ /_/ / / / / /  __/ /  / /_/ /
\___/\____/_/ /_/\__/\__,_/_/_/ /_/\___/_/   \__,_/

high performance container runtime

USAGE:
   containerd [global options] command [command options] [arguments...]

VERSION:
   v1.4.0-k3s1

DESCRIPTION:

containerd is a high performance container runtime whose daemon can be started
by using this command. If none of the *config*, *publish*, or *help* commands
are specified, the default action of the **containerd** command is to start the
containerd daemon in the foreground.

A default configuration is used if no TOML configuration is specified or located
at the default file location. The *containerd config* command can be used to
generate the default configuration for containerd. The output of that command
can be used and modified as necessary as a custom configuration.

COMMANDS:
   config    information on the containerd config
   publish   binary to publish events to containerd
   oci-hook  provides a base for OCI runtime hooks to allow arguments to be injected.
   help, h   Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --config value, -c value     path to the configuration file (default: "/etc/containerd/config.toml")
   --log-level value, -l value  set the logging level [trace, debug, info, warn, error, fatal, panic]
   --address value, -a value    address for containerd's GRPC server
   --root value                 containerd root directory
   --state value                containerd state directory
   --help, -h                   show help
   --version, -v                print the version

@dweomer  I use Linuxkit which runs everything as a container. I need to run containerd first so that I can run some prerequisite containers and then I can start kubernetes.
The binaries in /var/lib/rancher/k3s/data/current/bin/ get extracted only after the k3s has been started. Running k3s ctr --help >/dev/null to extract them is a neat trick, I didn't think of that. However, I think running k3s containerd directly is a more elegant solution.

Does the --container-runtime-endpoint flag cover this use case?

Ah, sorry you already mentioned that you want to use the built-in.
Do kubelet static pods cover your need?
It seems like this PR as is will cause confusion, I am guessing you can't run k3s containerd and k3s agent at the same time as is.

@erikwilson static pods won't help me, since I want to do stuff before starting k3s and static pods require running kubelet. With my PR you can run k3s containerd ... and later k3s server --container-runtime-endpoint=/var/run/k3s/containerd.sock ... (or similarly for the agent). So basically you can use k3s containerd the same way as k3s ctr, k3s crictl... I'm not sure what's confusing about it.

@peter-pulik this should not be necessary (and as @erikwilson mentioned is confusing). If you need to run the embedded containerd as an external CRI, you can unpack it from the k3s binary by invoking sudo /usr/local/bin/k3s kubectl --help after installation which will make it accessible at /var/lib/rancher/k3s/data/current/bin/containerd

Also @peter-pulik if you want to do stuff with static pods you might look at RKE2; it is much like K3s but runs all the control-plane components as static pods instead of in-process. It might be easier to accomplish what you're trying to do.

@peter-pulik thank you for this contribution. As per the discussion above this is not something that we want to carry and as per this comment specifically, https://github.com/k3s-io/k3s/pull/2322#issuecomment-740954621, you should have a viable work-around for your use-case.


FPN Upsample problem

❓ Questions and Help
I noted the FPN code:
inner_top_down = F.interpolate(last_inner, scale_factor=2, mode="nearest")
inner_lateral = getattr(self, inner_block)(feature)
TODO use size instead of scale to make it robust to different sizes
inner_top_down = F.upsample(last_inner, size=inner_lateral.shape[-2:],
mode='bilinear', align_corners=False)
the FPN paper said that nearest upsample, the code use mode="nearest" or mode='bilinear'.

normally upsample use bilinear check follows
https://github.com/kuangliu/torchcv/blob/master/torchcv/models/fpnssd/fpn.py
https://github.com/kuangliu/pytorch-fpn
https://github.com/jwyang/fpn.pytorch/blob/master/lib/model/fpn/resnet.py
https://github.com/cutehuahua/FPN-pytorch


Updated to gulp 4.

The dev dependencies contained multiple packages with known security
vulnerabilities reported by 'npm audit'. The respective issues are fixed in
version 4.0.0 of gulp, which required some changes in the configuration.

@severinstrobl thanks! any idea why the minified CSS is now larger than before?

The default configuration of clean-css seem to be somewhat conservative with respect to the applied optimizations. The updated pull request solves the problem of the minified CSS growing in size.


[Feature] Support SiliconFlow API

@fanqiNO1
Can we access siliconflow from outside of the china ? with Europe mobile number ? Is there any way. ?

@fanqiNO1
Can we access siliconflow from outside of the china ? with Europe mobile number ? Is there any way. ?

Sorry, I am not sure about that. Maybe you can refer to https://siliconflow.cn/ for help.

Cant successful any Europe number.
it says its "The mobile number format is incorrect!”

On 19 Aug 2024, at 14:02, fanqiNO1 @.***> wrote:
@fanqiNO1 https://github.com/fanqiNO1
Can we access siliconflow from outside of the china ? with Europe mobile number ? Is there any way. ?
Sorry, I am not sure about that. Maybe you can refer to https://siliconflow.cn/ https://siliconflow.cn/ for help.
—
Reply to this email directly, view it on GitHub https://github.com/InternLM/MindSearch/pull/169#issuecomment-2296301376, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFRZHYX5S6HXKBTRVKJC7TZSHGC7AVCNFSM6AAAAABMW44Z7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWGMYDCMZXGY.
You are receiving this because you commented.


Xcode Project Generation

@swift-ci Please test.

@swift-ci Don’t you like me anymore?

The command will be swift dump?

The command will be swift dump?

No, I imagine it will be swift build --generate-xcodeproj or something.
@ddunbar thanks will address these.

Overall this seems like a great start and I'm sure will be immediately useful to people.
We should probably also update the README.md to explain how to start developing with it?

We should probably also update the README.md to explain how to start developing with it?

Indeed, will amend. Expect a few more patches before this is merged.

Fresh review please, no nit-picking, let's merge this.

@swift-ci Please test

Will squash history and merge later today unless there are objections.

Squashed.

Looks good, lets merge asap :dancer:

@swift-ci Please test

tap tap tap… come on CI.

😍😍👍👍

Hmm, looks like xcrun --find swiftc is giving the path to default toolchain instead of the development one causing swift-build to fail.
PS: I have exported the toolchain to PATH
$ export PATH=/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin:"${PATH}"

which swiftc gives correct path

At this point I'm not exactly sure yet what to do here.
xcrun probably is doing the right thing.
You should set TOOLCHAINS as documented in the README (since yesterday). This is really the proper way to have the active toolchain set for swift-build to use.
I think maybe the solution is to just use swiftc unless TOOLCHAINS is set, but I don't know how sensible that is for the imminent future where swift build is bundled with OS X properly.

I think it needs the 7.3 beta for TOOLCHAINS to work, can't confirm right now as on slow internet can't download 4GB 😔

This is all a hack anyway since Xcode shouldn't need to be told which swift-* to use, it is already configured with a toolchain. I'd like to push some kind of workaround tonight. I'd hate for something that doesn't work to go into the next snapshot.

Actually this will work if it's in a toolchain since it looks next to itself first.
So this only affects people trying to use a self built copy of swift-build against a previously published toolchain who cannot set TOOLCHAINS, so I hate to say it, but I think we are working as intended.

A workaround for now is:

Build the new swift-build
Overwrite the latest toolchain copy with the one you built

As a temporary work around, I got things running by exporting SWIFT_EXEC as:
export SWIFT_EXEC=/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin/swiftc

Best part, it is even setting LD_RUNPATH_SEARCH_PATHS correctly (https://github.com/apple/swift-package-manager/pull/174#discussion_r55320463)
I'm still on Xcode - 7.2 btw

@kostiakoval you need to clean the build for swiftpm, this is a separate issue caused by the swift-3-api-guidelines merge. Though I do not know what happened there, it broke our incremental build. Which is worrying.


Make confirmation page once applicant finishes applying

Gives them feedback that their application went through. Give them a confirmation code too (a unique ID for their application that they can share with the program admin).

Is this to replace the confirmation toast after submission?

Good question. Main thing we have to ensure is that the applicant sees that they successfully submitted the form, and that they get their confirmation code. So we have two options:

Offer a persistent toast that includes a confirmation code (ideally with a "Copy" CTA); can only be dismissed by hitting X.
Offer a standalone confirmation page that includes a "congrats" message and a confirmation code.

Not sure which one's easier to implement -- up to you!

Nathan just put this in --

Looks good, only hitch is that there's still a toast (and it looks like an error message) -- can we get rid of it?


⚠ ClamAV has degraded performance

In d38cf8c, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 497 ms

Resolved: ClamAV performance has improved in 0fff70a after 5 minutes.


HDFS-17578: ShellCommandFencer#setConfAsEnvVars should also replace '-' with '_'.

JIRA: HDFS-17578.
When setting configuration into environment variables, '-' should also be replaced with '_'.

Sorry I didn't get what this PR want to do, do you meet any issues here? Thanks.

Using the shell fencing method.
dfs.ha.fencing.methods=shell(/path/fence.sh)
Environment variables with "-" cannot be used in /path/fence.sh.
@Hexiaoqiao, Thanks.

Got it. We should update both logic (include javadocs) of replace special character at ShellCommandFencer. Another one, we should move module from HDFS to COMMON. Thanks.

@Hexiaoqiao Thank you for your review. The code has been updated. Please review it again. Thanks.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 54s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
45m 45s

trunk passed

+1 :green_heart:
compile
17m 34s

trunk passed with JDK Ubuntu-11.0.23+9-post-Ubuntu-1ubuntu120.04.2

+1 :green_heart:
compile
16m 19s

trunk passed with JDK Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

+1 :green_heart:
checkstyle
1m 19s

trunk passed

+1 :green_heart:
mvnsite
1m 46s

trunk passed

+1 :green_heart:
javadoc
1m 17s

trunk passed with JDK Ubuntu-11.0.23+9-post-Ubuntu-1ubuntu120.04.2

+1 :green_heart:
javadoc
0m 54s

trunk passed with JDK Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

+1 :green_heart:
spotbugs
2m 37s

trunk passed

+1 :green_heart:
shadedclient
35m 47s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 56s

the patch passed

+1 :green_heart:
compile
16m 52s

the patch passed with JDK Ubuntu-11.0.23+9-post-Ubuntu-1ubuntu120.04.2

+1 :green_heart:
javac
16m 52s

the patch passed

+1 :green_heart:
compile
16m 10s

the patch passed with JDK Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

+1 :green_heart:
javac
16m 10s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m 13s

the patch passed

+1 :green_heart:
mvnsite
1m 43s

the patch passed

+1 :green_heart:
javadoc
1m 11s

the patch passed with JDK Ubuntu-11.0.23+9-post-Ubuntu-1ubuntu120.04.2

+1 :green_heart:
javadoc
0m 55s

the patch passed with JDK Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

+1 :green_heart:
spotbugs
2m 47s

the patch passed

+1 :green_heart:
shadedclient
36m  0s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
19m 40s

hadoop-common in the patch passed.

+1 :green_heart:
asflicense
1m  5s

The patch does not generate ASF License warnings.

223m 15s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6936/2/artifact/out/Dockerfile

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

JIRA Issue
HDFS-17578

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 48d7d4926fc3 5.15.0-106-generic #116-Ubuntu SMP Wed Apr 17 09:17:56 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / ca48b8f1ad6081f6cc32b40f8d749e1ebb680e64

Default Java
Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.23+9-post-Ubuntu-1ubuntu120.04.2 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6936/2/testReport/

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

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

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6936/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

Committed to trunk. Thanks @fuchaohong for your works.


fix(auth): ownerfield as sort key field of GSI

Description of changes

CDK / CloudFormation Parameters Changed

Issue #, if available

Description of how you validated changes
Checklist

[ ] PR description included
[ ] yarn test passes
[ ] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies
[ ] Any CDK or CloudFormation parameter changes are called out explicitly

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

Codecov Report

Merging #1457 (10b25c4) into main (63da24a) will decrease coverage by 1.75%.
The diff coverage is 69.53%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main    #1457      +/-   ##
==========================================
- Coverage   63.56%   61.81%   -1.75%
==========================================
  Files         295      358      +63
  Lines       18573    21393    +2820
  Branches     4487     5089     +602
==========================================
+ Hits        11805    13225    +1420
- Misses       6150     7403    +1253
- Partials      618      765     +147

Impacted Files
Coverage Δ

...fy-category-api/src/category-utils/context-util.ts
21.62% <ø> (ø)

...es/amplify-category-api/src/force-updates/index.ts
28.57% <ø> (ø)

...i/src/graphql-transformer/directive-definitions.ts
38.46% <ø> (ø)

...api/src/graphql-transformer/transformer-version.ts
30.00% <0.00%> (ø)

...ation/api-input-manager/appsync-api-input-state.ts
77.77% <ø> (ø)

...utils/awscloudformation/cdk-stack-builder/types.ts
100.00% <ø> (ø)

...scloudformation/default-values/appSync-defaults.ts
28.57% <ø> (ø)

...awscloudformation/utils/get-appsync-auth-config.ts
100.00% <ø> (ø)

...loudformation/utils/get-appsync-resolver-config.ts
42.85% <ø> (ø)

...ry-api/src/provider-utils/supported-datasources.ts
100.00% <ø> (ø)

... and 71 more

... and 70 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Allow to access indicator instance

There might be some Rust knowledge I don't have that fixes this problem and if so, I apologize but a bit of help would be great.
I was trying to create an Historyobject that would store various indicators for specific timeframes (1min, 5min, ..). And at each trade event I would get from the exchange feed, I could simply update the candle of the specific timeframes I'm tracking and for each timeframe, update the indicator accordingly with the next() method (a bit of a "rolling indicator" idea where the indicator is always with the latest data).
However, it appears that one must .init() the indicator with a first candle in order to get an indicator instance object (which is not publicly available, deriving the IndicatorInstance trait).
And so this is a problem because it means that every time I want to compute let say the RSI of a specific timeframe, I need all 14 historical candle and next() them all which is a bit of a waste considering an indicator in the first place can just keep the rolling value.
Would it be possible to have something like:
pub struct History {
  rsi: RelativeStrengthIndexInstance,
}

and so one can simply update the rsi has trade events occur taken from the exchange feed. Or even better, simply having the RSI objectbe able to initialize itself at the first next() ?
Note that I tried to use rsi: Box<dyn IndicatorInstance<Config = RSI>> but that fail to build due to a trait requirement (Sized).
Wondering your thought here or if I'm missing something. Thanks!

Hello!
I don't think I understood your problem correctly. Do you mean you need to update the state of indicators in between two candles (at every tick)?
Then you just need to hold a clone of the IndicatorInstance with the last complete candle performed to be able to "rollback" instance's state:
pub struct History {
  rsi: RelativeStrengthIndexInstance,
}

impl History {
  pub fn next_tick(&mut self, candle: &MyCandle) -> yata::core::IndicatorResult {
    if candle.is_complete() { // if it is the very last tick in this candle
      self.rsi.next(candle)
    } esle {
      let mut rsi = self.rsi.clone();
      rsi.next(candle)
    }
  }
}

You need to implement MyCandle and is_complete method for it. If it is a realy candle, then is should return true. If it is just a tick between, then it should return false.

Note that I tried to use rsi: Box<dyn IndicatorInstance<Config = RSI>> but that fail to build due to a trait requirement (Sized).

I don't understand how DST can help you, but you can use special object-safe traits in prelude::dd

Hello!
If I understood correctly, you need to save intermediate state of IndicatorInstance. Well for now it is actually possible only for indicators without dynamically selected methods. They simply implement Clone.
I have some ideas about general solving your issue, but I need some time for checking.

Hello!
If I understood correctly, you need to save intermediate state of IndicatorInstance. Well for now it is actually possible only for indicators without dynamically selected methods. They simply implement Clone.

Maybe? :)
Basically, if I take this crate as an example: https://github.com/greyblake/ta-rs/blob/master/src/indicators/relative_strength_index.rs#L74
One can simply instantiate the RSI object and over the course of the application lifetime, simply update it with market data values.
In the case or yata, one needs to keep all historical candles that are needed for the computation of the RSI, start with a init and then iterate over the candles (well object implementing OHLCV trait).

I have some ideas about general solving your issue, but I need some time for check.

Awesome. Thanks!

I think there is some kind of mistake in your description. You can't simply instantiate RSI at any time because every indicator/method must be evaluated over historical data before produce correct values.
The difference between this implementation of RSI and ta-rs is in flexibility. There is hard-coded EMA inside RSI in ta-rs. That's why RSI itself may be cloned at any time, so you can hold it state as long as you want.
In yata implementation you can change methods inside RSI at runtime, that's why it holds DST inside. That's why this RSI cannot be cloned simply.
I'm working on this issue right now. I found the solution very similar to this discussion: https://github.com/amv-dev/yata/issues/16 . You can try this branch https://github.com/amv-dev/yata/tree/window-T-ref . You can clone any instance of any indicator at any time in this implementation. But it is WIP still .

I think there is some kind of mistake in your description. You can't simply instantiate RSI at any time because every indicator/method must be evaluated over historical data before produce correct values.
The difference between this implementation of RSI and ta-rs is in flexibility. There is hard-coded EMA inside RSI in ta-rs. That's why RSI itself may be cloned at any time, so you can hold it state as long as you want.

Correct, that is what I meant to say! Sorry for the confusion.

I'm working on this issue right now. I found the solution very similar to this discussion: #16 . You can try this branch https://github.com/amv-dev/yata/tree/window-T-ref . You can clone any instance of any indicator at any time in this implementation. But it is WIP still .

This is great. Thank you so much! I'll start testing this and hopefully providing any useful feedback.

@dgoulet as late as is it, but you can use this: <RelativeStrengthIndex as IndicatorConfig>::Instance as an indicator instance type definition.

I think this issue was resolved due v0.5 release. So it might be closed.
You are free to re-open it, if you see some other problems.


Initial Symfony 4.0 support

While we are waiting for https://github.com/ChessCom/chess/pull/24602#issuecomment-374308713...

Merged since https://github.com/ChessCom/chess/pull/25194 passed QA.

@kalifg It's strange that this caused:
PHP Fatal error:  Class 'Nelmio\Alice\Loader\Yaml' not found in /www/sites/chess.com/workspace/Pull_Request/src/Chess/WebBundle/Loader/AliceLoader.php on line 9

https://ci.devchess.com/job/Pull_Request/84828/consoleFull in https://github.com/ChessCom/chess/pull/25194
@ikonic89 Can it be some CI specific issue? It works locally and the file is there.

No idea, tbh.

It happens to me locally.  The steps I follow:

Checkout the SS/CV-60699-Symfony-4-0-Upgrade branch
Run bin/c backend -v '--memory=1250M'

I'll dig in and see what I can find.  It might be related to the Alice fork bump that it's installing.

If you step through the autoloader code you can see that no references to the Alice classes are stored for either PSR0 or PSR4, and it's not on the include path so the autoloader returns false.
Is it possible that SF4 changed the autoloader in a way that we need to update the Alice fork to support it?

Some time during the composer process, it writes the file vendor/composer/installed.json.  When you run php composer.phar dump-autoload it reads the list of installed packages from that.  This file does not contain Alice on my system, and so Alice never makes it to the autoloader.
I'm still attempting to isolate the creation of this file to see why it doesn't make it into there.

And here's the crazy thing.  I re-ran composer and it installed Alice and everything looks fine.

I am able to reproduce this error by doing the following:

Check out develop
Run c composer
Check out SS/CV-60699-Symfony-4-0-Upgrade
Run c composer. You will see

      - Removing nelmio/alice (dev-master 581ae45)
      - Installing nelmio/alice (dev-master 534d232): Loading from cache

Run php -d memory_limit=1250M app/console --env=test --ansi -vvv --no-debug alice:fixtures:load --no-interaction --em=root --quiet.  You will then get the error:

PHP Fatal error:  Class 'Nelmio\Alice\Loader\Yaml' not found in /www/sites/chess.com/current/src/Chess/WebBundle/Loader/AliceLoader.php on line 9

Fatal error: Class 'Nelmio\Alice\Loader\Yaml' not found in /www/sites/chess.com/current/src/Chess/WebBundle/Loader/AliceLoader.php on line 9

Then if you:

Run c composer. You will see:

      - Installing nelmio/alice (dev-master 534d232): Loading from cache

php -d memory_limit=1250M app/console --env=test --ansi -vvv --no-debug alice:fixtures:load --no-interaction --em=root --quiet.  Everything now works as normal.

I think there is some issue with composer.  Attempting to trace an install is difficult because of how much everything is slowed down.  I'll see what I can do, but maybe in the mean time someone can come up with a work-around?  Should we just add a second run of composer to our tasks?

After ChessCom/chess#26529 is merged into develop I will re-run CI on ChessCom/chess#25194


Facebook Bridge | Main Site failed with error 0

Bridge encountered an unexpected situation! (18727)
Error message: Call to a member function children() on null
Query string: action=display&bridge=Facebook&context=User&u=https%3A%2F%2Fwww.facebook.com%2Flinuspage%2F&media_type=all&limit=-1&format=Html
Version: dev.2020-11-10
I deployed the application on a web hosting service.
Given the error, I tried to do the following:

I enabled all error/warnings. I received this message:
Notice: Undefined offset: 0 in rss-bridge/bridges/FacebookBridge.php on line 587

So I echoed the content of $html variable, in line 582 of bridges/FacebookBridge.php
and the content shown is attached

Does this patch work for you?
diff --git a/bridges/FacebookBridge.php b/bridges/FacebookBridge.php
index c03de4e..74ea665 100644
--- a/bridges/FacebookBridge.php
+++ b/bridges/FacebookBridge.php
@@ -559,6 +559,7 @@ EOD;
                        } else {
                                $header = array();
                        }
+                       $header[] = 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0';

                        $html = getSimpleHTMLDOM($this->getURI(), $header)
                                or returnServerError('No results for this query.');

Perfect! It did the trick.
It works now
Thanks

Isn't this bug caused by Rss-Bridge's default user agent not having a space, so Facebook does not detect it as Firefox?
https://github.com/RSS-Bridge/rss-bridge/blob/47dc26c775a2158950cffe085c1781b6e6a71e26/index.php#L20-L26
Changing [...]Firefox/72.0(rss-bridge[...] to [...]Firefox/72.0 (rss-bridge[...] might fix the issue without a custom user agent.
If it does on your side, I can open a pull request that adds the missing space.

Hi, thanks for the reply.
After this last comment I dug more into it, and I discovered that the problem was caused by my web hosting service.
In fact it doesn't allow to use the function ini_set().
So I deployed the rss-bridge on a different server, and it actually works fine without any fixes needed (even without the patch suggested by em92).
I'm REALLY sorry.

No offence taken. Retrieving data from Facebook is not very reliable to begin with. 😉


Add breadcrumb UI component

Current Behavior
Add breadcrumb UI component
Desired Behavior
A breadcrumbs UI component is a navigational element commonly used in user interfaces to display the hierarchical path or trail of the user's location within a website or application. It helps users understand their current location within a website's structure and provides a quick way to navigate back to higher-level pages
Screenshots / Mockups

Please assign me this issue @thekavikumar
thanks

Assign too @thekavikumar


MINOR: Enable deep-iteration to print data in DumpLogSegments

Enable deep-iteration option when print-data-log is enabled in DumpLogSegments. Otherwise data is not printed. System test was wrongly reporting that data was lost since no payloads were printed.
Committer Checklist (excluded from commit message)

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

@hachikuji Thanks for the review, will rebase and merge to trunk and 1.1.


etcd failed to start up automatically after system reboot

I've installed a kubernetes cluser on Ubuntu Trusty VMs with a single etcd node installed in the master VM. All components works well after deployment but the only issue I've experienced is etcd don't start automatically after system reboot. So the apiserver didn't start and all the cluster is down.
At a first sight, I've checked the initscript /etc/init.d/etcd file and it seems ok. When I run:
$ service etcd start

the service runs and I get this message in stdout:
* Starting etcd k/v store etcd
Failed to remove container (etcd1): Error response from daemon: No such container: etcd1

and finally it ends by creating a new etcd container:
3d49dc542863        quay.io/coreos/etcd:v3.0.6                 "/usr/local/bin/etcd"    4 minutes ago       Up 4 minutes                            etcd1

The cluster is again up and all things work correctly.

I've been having this issue too in my trials starting this weekend. Sometimes rebooting the node will get it so that the docker etcd starts running.
Once etcd  is running on all the node specified in inventory, I can bring up the cluster...  and they keep running, until I reset the cluster-- then I have typically have been seeing it again (i.e., etcd containers not running stopping ansible TASK [etcd : Ensure etcd is running]).

The issue seems to be in the initscript. Changing the line 53:
{{ docker_bin_dir | default("/usr/bin") }}/docker rm -f {{ etcd_member_name | default("etcd-proxy") }} &>/dev/null || true

to
{{ docker_bin_dir | default("/usr/bin") }}/docker rm -f {{ etcd_member_name | default("etcd-proxy") }} > /dev/null 2>&1 || true

did the trick.
In fact, it seems that the command is forked in a sub-shell and the stderr/stdout are not correctly redirected as expected because of the &> operator.
Otherwise, I just realized that only systemd unit files that manages etcd are keept. Here is the commit.

Here is a quick fix which may be useful for a v2.0.2, who knows.
https://github.com/abessifi/kargo/commit/7342954905a8c03d352b2a38e556a1e22100cb1e
I close the issue.

@abessifi why not create a pull request?

PR https://github.com/kubernetes-incubator/kargo/pull/912 just created.


eka2l1 error

hey yall, so anyways i was trying to install ngagesdk, but when i type make into the terminal it gives me a error the error says: Error copying file "home/ngage-toolchain/sdk/../cmake/stub-eka2l1.cmake" to "home/ngage-toolchain/sdk/eka2l1/CMakeLists.txt".
make[2]: *** [CMakeFiles/EKA2L1.dir/build.make:103: EKA2L1-prefix/src/EKA2L1-stamp/EKA2L1-patch] Error 1
make[1]: *** [CMakeFiles/Makefile2:78: CMakeFiles/EKA2L1.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
IDK what this means so can you help me please!

Unfortunately I can't reproduce your issue.
However, it seems that you are trying to install the SDK on Linux. Unfortunately, this is not currently supported.
  [1/7] Performing download step (download, verify and extract) for 'EKA2L1'
  -- verifying file...
         file='C:/ngage-toolchain/sdk/cache/eka2l1.zip'
  -- File already exists and hash match (skip download):
    file='C:/ngage-toolchain/sdk/cache/eka2l1.zip'
    SHA1='0f172f0ae5f12dffcd191065922bf66754d44504'
  -- extracting...
       src='C:/ngage-toolchain/sdk/cache/eka2l1.zip'
       dst='C:/ngage-toolchain/sdk/eka2l1'
  -- extracting... [tar xfz]
  -- extracting... [analysis]
  -- extracting... [rename]
  -- extracting... [clean up]
  -- extracting... done
  [2/7] No update step for 'EKA2L1'
  [3/7] Performing patch step for 'EKA2L1'
  [4/7] Performing configure step for 'EKA2L1'
  -- The C compiler identification is MSVC 19.31.31105.0
  -- The CXX compiler identification is MSVC 19.31.31105.0
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.31.31103/bin/Hostx64/x64/cl.exe - skipped
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.31.31103/bin/Hostx64/x64/cl.exe - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Configuring done
  -- Generating done
  -- Build files have been written to: C:/ngage-toolchain/setup/out/build/Release/EKA2L1-prefix/src/EKA2L1-build
  [5/7] Performing build step for 'EKA2L1'
  Skipping build step.
  [6/7] Performing install step for 'EKA2L1'
  Skipping install step.
  [7/7] Completed 'EKA2L1'

Build All succeeded.


Allow users define controller workers

Signed-off-by: mingzhou.swx<EMAIL_ADDRESS>
Ⅰ. Describe what this PR does
Allow users define controller workers

/lgtm

Codecov Report

Merging #67 (f67d000) into master (65b75a6) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #67      +/-   ##
==========================================
+ Coverage   16.18%   16.20%   +0.02%
==========================================
  Files          30       30
  Lines        3460     3461       +1
==========================================
+ Hits          560      561       +1
  Misses       2800     2800
  Partials      100      100

Flag
Coverage Δ

unittests
16.20% <100.00%> (+0.02%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...controller/batchrelease/batchrelease_controller.go
22.11% <100.00%> (ø)

pkg/controller/rollout/rollout_controller.go
12.50% <100.00%> (+1.59%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

/approve


Callback not triggering on "long" message?

I'm trying to publish a JSON message to a topic. I'm using ArduinoJson, which parses it fine in this form:
const char *testConfig = "{\"log-topic\" : \"device/test/log\", \"state-topic\" : \"device/test/state\", \"power-topic\": \"device/test/power\", \"all-power-topic\": \"device/all/power\", \"reset-topic\": \"device/test/config-timestamp\", \"monitor-topic\": \"device/test/monitor\", \"extra-topic\": \"extra\"}";
I publish this to my MQTT broker, and other clients see it as this:
{"log-topic" : "device/test/log", "state-topic" : "device/test/state", "power-topic": "device/test/power", "all-power-topic": "device/all/power", "reset-topic": "device/test/config-timestamp", "monitor-topic":"device/test/monitor", "extra-topic": "extra"}
Now... if I just publish a short message like "foo" to the topic, the callback triggers no problem. If I publish a shorter JSON message like...
{"log-topic": "device/test/log"}
That also works fine.
Any ideas? The message is something like 212 characters. It's well be low the limit of what an MQTT broker can handle, and other clients receive the message, just not this one using PubSubClient.

Hi @alc6379
The default maximum packet length supported by this client is 128 bytes.
You need to edit MQTT_MAX_PACKET_SIZE in PubSubClient.h to something big enough to accommodate the message size you want to handle - remembering that this comes straight out of your available memory on whatever device you're running on.
Also note this is packet size, not payload length. So it needs to be big enough to handle the combined length of the payload and topic as both are present in the MQTT publish packet.

Awesome, thanks for the information.
I'm fine with increasing the packet size for my particular application, because the application itself is relatively simple, and I've got the memory to spare.


No such command "js" in OS X 10.6

I don't think OS X includes the "js" command anymore. Regardless, running: "sudo port install spidermonkey" resolves this issue.

Recent versions of the plugin check for the executable that @mat813 mentions.  That executable seems to be present on pretty much every OS X installation.
Thanks for the bug report!


Appcode looks for injection app only in /Applications

I put injection in /Applications/Developer and appcode plugin didn't work

Appcode plugin has to know where to find an executable so it assumes Injection is installed in /Applications.


SRS/4.0.34(Leo)_rtc.conf启动_ffmpeg推rtmp_内存泄漏

描述(Description)

描述你遇到了什么问题(Please description your issue here)

SRS版本(Version): SRS/4.0.34(Leo)
SRS的日志如下(Log):

部分关键日志如下：

==45713== 6,192 bytes in 1 blocks are still reachable in loss record 441 of 464
==45713==    at 0x4C2A10A: operator new(unsigned long) (vg_replace_malloc.c:334)
==45713==    by 0x41F5E2: SrsFormat::on_audio(long, char*, int) (srs_kernel_codec.cpp:645)
==45713==    by 0x4C9F4C: SrsRtmpFormat::on_audio(SrsSharedPtrMessage*) (srs_protocol_format.cpp:53)
==45713==    by 0x60631F: SrsRtcFromRtmpBridger::on_audio(SrsSharedPtrMessage*) (srs_app_rtc_source.cpp:506)
==45713==    by 0x4FFE86: SrsSource::on_audio_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2767)
==45713==    by 0x4FFA63: SrsSource::on_audio(SrsCommonMessage*) (srs_app_source.cpp:2722)
==45713==    by 0x4F30D3: SrsRtmpConn::process_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:1020)
==45713==    by 0x4F2F7F: SrsRtmpConn::handle_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:999)
==45713==    by 0x5A64B0: SrsPublishRecvThread::consume(SrsCommonMessage*) (srs_app_recv_thread.cpp:393)
==45713==    by 0x5A4E60: SrsRecvThread::do_cycle() (srs_app_recv_thread.cpp:147)
==45713==    by 0x5A4CC9: SrsRecvThread::cycle() (srs_app_recv_thread.cpp:116)
==45713==    by 0x5230CA: SrsSTCoroutine::cycle() (srs_app_st.cpp:198)
==45713==
==45713== 6,192 bytes in 1 blocks are still reachable in loss record 442 of 464
==45713==    at 0x4C2A10A: operator new(unsigned long) (vg_replace_malloc.c:334)
==45713==    by 0x41F5E2: SrsFormat::on_audio(long, char*, int) (srs_kernel_codec.cpp:645)
==45713==    by 0x4C9F4C: SrsRtmpFormat::on_audio(SrsSharedPtrMessage*) (srs_protocol_format.cpp:53)
==45713==    by 0x4FD111: SrsMetaCache::update_ash(SrsSharedPtrMessage*) (srs_app_source.cpp:2195)
==45713==    by 0x500017: SrsSource::on_audio_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2791)
==45713==    by 0x4FFA63: SrsSource::on_audio(SrsCommonMessage*) (srs_app_source.cpp:2722)
==45713==    by 0x4F30D3: SrsRtmpConn::process_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:1020)
==45713==    by 0x4F2F7F: SrsRtmpConn::handle_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:999)
==45713==    by 0x5A64B0: SrsPublishRecvThread::consume(SrsCommonMessage*) (srs_app_recv_thread.cpp:393)
==45713==    by 0x5A4E60: SrsRecvThread::do_cycle() (srs_app_recv_thread.cpp:147)
==45713==    by 0x5A4CC9: SrsRecvThread::cycle() (srs_app_recv_thread.cpp:116)
==45713==    by 0x5230CA: SrsSTCoroutine::cycle() (srs_app_st.cpp:198)
==45713==
==45713== 6,200 bytes in 1 blocks are still reachable in loss record 443 of 464
==45713==    at 0x4C2A10A: operator new(unsigned long) (vg_replace_malloc.c:334)
==45713==    by 0x41F894: SrsFormat::on_video(long, char*, int) (srs_kernel_codec.cpp:690)
==45713==    by 0x4C9FC8: SrsRtmpFormat::on_video(SrsSharedPtrMessage*) (srs_protocol_format.cpp:67)
==45713==    by 0x4FD1C9: SrsMetaCache::update_vsh(SrsSharedPtrMessage*) (srs_app_source.cpp:2203)
==45713==    by 0x50087C: SrsSource::on_video_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2893)
==45713==    by 0x50049E: SrsSource::on_video(SrsCommonMessage*) (srs_app_source.cpp:2853)
==45713==    by 0x4F314E: SrsRtmpConn::process_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:1027)
==45713==    by 0x4F2F7F: SrsRtmpConn::handle_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:999)
==45713==    by 0x5A64B0: SrsPublishRecvThread::consume(SrsCommonMessage*) (srs_app_recv_thread.cpp:393)
==45713==    by 0x5A4E60: SrsRecvThread::do_cycle() (srs_app_recv_thread.cpp:147)
==45713==    by 0x5A4CC9: SrsRecvThread::cycle() (srs_app_recv_thread.cpp:116)
==45713==    by 0x5230CA: SrsSTCoroutine::cycle() (srs_app_st.cpp:198)
==45713==
==45713== 6,200 bytes in 1 blocks are still reachable in loss record 444 of 464
==45713==    at 0x4C2A10A: operator new(unsigned long) (vg_replace_malloc.c:334)
==45713==    by 0x41F894: SrsFormat::on_video(long, char*, int) (srs_kernel_codec.cpp:690)
==45713==    by 0x4C9FC8: SrsRtmpFormat::on_video(SrsSharedPtrMessage*) (srs_protocol_format.cpp:67)
==45713==    by 0x4F9A8A: SrsOriginHub::on_video(SrsSharedPtrMessage*, bool) (srs_app_source.cpp:1558)
==45713==    by 0x5008FA: SrsSource::on_video_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2898)
==45713==    by 0x50049E: SrsSource::on_video(SrsCommonMessage*) (srs_app_source.cpp:2853)
==45713==    by 0x4F314E: SrsRtmpConn::process_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:1027)
==45713==    by 0x4F2F7F: SrsRtmpConn::handle_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:999)
==45713==    by 0x5A64B0: SrsPublishRecvThread::consume(SrsCommonMessage*) (srs_app_recv_thread.cpp:393)
==45713==    by 0x5A4E60: SrsRecvThread::do_cycle() (srs_app_recv_thread.cpp:147)
==45713==    by 0x5A4CC9: SrsRecvThread::cycle() (srs_app_recv_thread.cpp:116)
==45713==    by 0x5230CA: SrsSTCoroutine::cycle() (srs_app_st.cpp:198)
==45713==
==45713== 6,200 bytes in 1 blocks are still reachable in loss record 445 of 464
==45713==    at 0x4C2A10A: operator new(unsigned long) (vg_replace_malloc.c:334)
==45713==    by 0x41F894: SrsFormat::on_video(long, char*, int) (srs_kernel_codec.cpp:690)
==45713==    by 0x4C9FC8: SrsRtmpFormat::on_video(SrsSharedPtrMessage*) (srs_protocol_format.cpp:67)
==45713==    by 0x4FD1C9: SrsMetaCache::update_vsh(SrsSharedPtrMessage*) (srs_app_source.cpp:2203)
==45713==    by 0x606994: SrsRtcFromRtmpBridger::on_video(SrsSharedPtrMessage*) (srs_app_rtc_source.cpp:636)
==45713==    by 0x50097D: SrsSource::on_video_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2903)
==45713==    by 0x50049E: SrsSource::on_video(SrsCommonMessage*) (srs_app_source.cpp:2853)
==45713==    by 0x4F314E: SrsRtmpConn::process_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:1027)
==45713==    by 0x4F2F7F: SrsRtmpConn::handle_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:999)
==45713==    by 0x5A64B0: SrsPublishRecvThread::consume(SrsCommonMessage*) (srs_app_recv_thread.cpp:393)
==45713==    by 0x5A4E60: SrsRecvThread::do_cycle() (srs_app_recv_thread.cpp:147)
==45713==    by 0x5A4CC9: SrsRecvThread::cycle() (srs_app_recv_thread.cpp:116)
==45713==
==45713== 6,200 bytes in 1 blocks are still reachable in loss record 446 of 464
==45713==    at 0x4C2A10A: operator new(unsigned long) (vg_replace_malloc.c:334)
==45713==    by 0x41F894: SrsFormat::on_video(long, char*, int) (srs_kernel_codec.cpp:690)
==45713==    by 0x4C9FC8: SrsRtmpFormat::on_video(SrsSharedPtrMessage*) (srs_protocol_format.cpp:67)
==45713==    by 0x606A0E: SrsRtcFromRtmpBridger::on_video(SrsSharedPtrMessage*) (srs_app_rtc_source.cpp:640)
==45713==    by 0x50097D: SrsSource::on_video_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2903)
==45713==    by 0x50049E: SrsSource::on_video(SrsCommonMessage*) (srs_app_source.cpp:2853)
==45713==    by 0x4F314E: SrsRtmpConn::process_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:1027)
==45713==    by 0x4F2F7F: SrsRtmpConn::handle_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:999)
==45713==    by 0x5A64B0: SrsPublishRecvThread::consume(SrsCommonMessage*) (srs_app_recv_thread.cpp:393)
==45713==    by 0x5A4E60: SrsRecvThread::do_cycle() (srs_app_recv_thread.cpp:147)
==45713==    by 0x5A4CC9: SrsRecvThread::cycle() (srs_app_recv_thread.cpp:116)
==45713==    by 0x5230CA: SrsSTCoroutine::cycle() (srs_app_st.cpp:198)
==45713==
==45713== 7,776 bytes in 1 blocks are still reachable in loss record 447 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x80464F: av_malloc (mem.c:87)
==45713==    by 0x80464F: av_mallocz (mem.c:238)
==45713==    by 0x76328D: init_context_defaults (options.c:127)
==45713==    by 0x76328D: avcodec_alloc_context3 (options.c:163)
==45713==    by 0x6129B6: SrsAudioDecoder::initialize() (srs_app_rtc_codec.cpp:72)
==45713==    by 0x613A35: SrsAudioRecode::initialize() (srs_app_rtc_codec.cpp:374)
==45713==    by 0x605FC7: SrsRtcFromRtmpBridger::initialize(SrsRequest*) (srs_app_rtc_source.cpp:460)
==45713==    by 0x6055B6: SrsRtcSource::initialize(SrsRequest*) (srs_app_rtc_source.cpp:278)
==45713==    by 0x604FD7: SrsRtcSourceManager::fetch_or_create(SrsRequest*, SrsRtcSource**) (srs_app_rtc_source.cpp:206)
==45713==    by 0x4FD4E7: SrsSourceManager::fetch_or_create(SrsRequest*, ISrsSourceHandler*, SrsSource**) (srs_app_source.cpp:2251)
==45713==    by 0x4EEC80: SrsRtmpConn::stream_service_cycle() (srs_app_rtmp_conn.cpp:506)
==45713==    by 0x4EDFFF: SrsRtmpConn::service_cycle() (srs_app_rtmp_conn.cpp:396)
==45713==
==45713== 8,192 bytes in 1 blocks are still reachable in loss record 448 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x8041D9: av_malloc (mem.c:87)
==45713==    by 0x8113FF: av_samples_alloc (samplefmt.c:182)
==45713==    by 0x8113FF: av_samples_alloc_array_and_samples (samplefmt.c:206)
==45713==    by 0x61342C: SrsAudioResample::initialize() (srs_app_rtc_codec.cpp:275)
==45713==    by 0x613CC0: SrsAudioRecode::transcode(SrsSample*, char**, int*, int&) (srs_app_rtc_codec.cpp:411)
==45713==    by 0x606563: SrsRtcFromRtmpBridger::transcode(char*, int) (srs_app_rtc_source.cpp:570)
==45713==    by 0x606462: SrsRtcFromRtmpBridger::on_audio(SrsSharedPtrMessage*) (srs_app_rtc_source.cpp:538)
==45713==    by 0x4FFE86: SrsSource::on_audio_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2767)
==45713==    by 0x4FFA63: SrsSource::on_audio(SrsCommonMessage*) (srs_app_source.cpp:2722)
==45713==    by 0x4F30D3: SrsRtmpConn::process_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:1020)
==45713==    by 0x4F2F7F: SrsRtmpConn::handle_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:999)
==45713==
==45713== 15,360 bytes in 1 blocks are still reachable in loss record 449 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x804397: av_malloc (mem.c:87)
==45713==    by 0x804397: av_malloc_array (mem.c:188)
==45713==    by 0x40C4F1: ff_mdct15_init (mdct15.c:278)
==45713==    by 0x40A185: aac_decode_init (aacdec_template.c:1234)
==45713==    by 0x76B89E: avcodec_open2 (utils.c:935)
==45713==    by 0x612A13: SrsAudioDecoder::initialize() (srs_app_rtc_codec.cpp:77)
==45713==    by 0x613A35: SrsAudioRecode::initialize() (srs_app_rtc_codec.cpp:374)
==45713==    by 0x605FC7: SrsRtcFromRtmpBridger::initialize(SrsRequest*) (srs_app_rtc_source.cpp:460)
==45713==    by 0x6055B6: SrsRtcSource::initialize(SrsRequest*) (srs_app_rtc_source.cpp:278)
==45713==    by 0x604FD7: SrsRtcSourceManager::fetch_or_create(SrsRequest*, SrsRtcSource**) (srs_app_rtc_source.cpp:206)
==45713==    by 0x4FD4E7: SrsSourceManager::fetch_or_create(SrsRequest*, ISrsSourceHandler*, SrsSource**) (srs_app_source.cpp:2251)
==45713==
==45713== 16,384 bytes in 1 blocks are still reachable in loss record 450 of 464
==45713==    at 0x4C2A7F7: operator new[](unsigned long) (vg_replace_malloc.c:423)
==45713==    by 0x61381C: SrsAudioRecode::SrsAudioRecode(int, int) (srs_app_rtc_codec.cpp:345)
==45713==    by 0x605D04: SrsRtcFromRtmpBridger::SrsRtcFromRtmpBridger(SrsRtcSource*) (srs_app_rtc_source.cpp:433)
==45713==    by 0x605343: SrsRtcSource::SrsRtcSource() (srs_app_rtc_source.cpp:254)
==45713==    by 0x604FB2: SrsRtcSourceManager::fetch_or_create(SrsRequest*, SrsRtcSource**) (srs_app_rtc_source.cpp:205)
==45713==    by 0x4FD4E7: SrsSourceManager::fetch_or_create(SrsRequest*, ISrsSourceHandler*, SrsSource**) (srs_app_source.cpp:2251)
==45713==    by 0x4EEC80: SrsRtmpConn::stream_service_cycle() (srs_app_rtmp_conn.cpp:506)
==45713==    by 0x4EDFFF: SrsRtmpConn::service_cycle() (srs_app_rtmp_conn.cpp:396)
==45713==    by 0x4ECA43: SrsRtmpConn::do_cycle() (srs_app_rtmp_conn.cpp:209)
==45713==    by 0x4EAC3F: SrsConnection::cycle() (srs_app_conn.cpp:172)
==45713==    by 0x5230CA: SrsSTCoroutine::cycle() (srs_app_st.cpp:198)
==45713==    by 0x523176: SrsSTCoroutine::pfn(void*) (srs_app_st.cpp:213)
==45713==
==45713== 16,384 bytes in 1 blocks are still reachable in loss record 451 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x80445F: av_malloc (mem.c:87)
==45713==    by 0x80445F: av_mallocz (mem.c:238)
==45713==    by 0x80445F: av_mallocz_array (mem.c:195)
==45713==    by 0x7EDBC0: swri_realloc_audio (swresample.c:418)
==45713==    by 0x7EDBC0: swr_convert_internal.part.3 (swresample.c:597)
==45713==    by 0x7EE97C: swr_convert_internal (swresample.c:416)
==45713==    by 0x7EE97C: swr_convert (swresample.c:766)
==45713==    by 0x6136FC: SrsAudioResample::resample(SrsSample*, char*, int&) (srs_app_rtc_codec.cpp:319)
==45713==    by 0x613D4B: SrsAudioRecode::transcode(SrsSample*, char**, int*, int&) (srs_app_rtc_codec.cpp:421)
==45713==    by 0x606563: SrsRtcFromRtmpBridger::transcode(char*, int) (srs_app_rtc_source.cpp:570)
==45713==    by 0x606462: SrsRtcFromRtmpBridger::on_audio(SrsSharedPtrMessage*) (srs_app_rtc_source.cpp:538)
==45713==    by 0x4FFE86: SrsSource::on_audio_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2767)
==45713==    by 0x4FFA63: SrsSource::on_audio(SrsCommonMessage*) (srs_app_source.cpp:2722)
==45713==    by 0x4F30D3: SrsRtmpConn::process_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:1020)
==45713==
==45713== 16,384 bytes in 2 blocks are still reachable in loss record 452 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x8041D9: av_malloc (mem.c:87)
==45713==    by 0x7F8E08: av_buffer_alloc (buffer.c:72)
==45713==    by 0x7F986C: pool_alloc_buffer (buffer.c:312)
==45713==    by 0x7F986C: av_buffer_pool_get (buffer.c:349)
==45713==    by 0x7610B6: audio_get_buffer (decode.c:1634)
==45713==    by 0x7610B6: avcodec_default_get_buffer2 (decode.c:1720)
==45713==    by 0x761CA6: get_buffer_internal (decode.c:1941)
==45713==    by 0x761CA6: ff_get_buffer (decode.c:1966)
==45713==    by 0x779653: frame_configure_elements (aacdec_template.c:180)
==45713==    by 0x779653: aac_decode_frame_int.isra.26 (aacdec_template.c:3143)
==45713==    by 0x77A663: aac_decode_frame (aacdec_template.c:3372)
==45713==    by 0x75F04F: decode_simple_internal (decode.c:433)
==45713==    by 0x75F04F: decode_simple_receive_frame (decode.c:629)
==45713==    by 0x75F04F: decode_receive_frame_internal (decode.c:647)
==45713==    by 0x75FCC7: avcodec_send_packet (decode.c:705)
==45713==    by 0x612B2F: SrsAudioDecoder::decode(SrsSample*, char*, int&) (srs_app_rtc_codec.cpp:101)
==45713==
==45713== 16,896 bytes in 1 blocks are still reachable in loss record 453 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x80445F: av_malloc (mem.c:87)
==45713==    by 0x80445F: av_mallocz (mem.c:238)
==45713==    by 0x80445F: av_mallocz_array (mem.c:195)
==45713==    by 0x7ECF2B: swri_realloc_audio (swresample.c:418)
==45713==    by 0x7ED291: resample (swresample.c:553)
==45713==    by 0x7EDDD8: swr_convert_internal.part.3 (swresample.c:646)
==45713==    by 0x7EE97C: swr_convert_internal (swresample.c:416)
==45713==    by 0x7EE97C: swr_convert (swresample.c:766)
==45713==    by 0x6136FC: SrsAudioResample::resample(SrsSample*, char*, int&) (srs_app_rtc_codec.cpp:319)
==45713==    by 0x613D4B: SrsAudioRecode::transcode(SrsSample*, char**, int*, int&) (srs_app_rtc_codec.cpp:421)
==45713==    by 0x606563: SrsRtcFromRtmpBridger::transcode(char*, int) (srs_app_rtc_source.cpp:570)
==45713==    by 0x606462: SrsRtcFromRtmpBridger::on_audio(SrsSharedPtrMessage*) (srs_app_rtc_source.cpp:538)
==45713==    by 0x4FFE86: SrsSource::on_audio_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2767)
==45713==
==45713== 17,856 bytes in 1 blocks are still reachable in loss record 454 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x80445F: av_malloc (mem.c:87)
==45713==    by 0x80445F: av_mallocz (mem.c:238)
==45713==    by 0x80445F: av_mallocz_array (mem.c:195)
==45713==    by 0x7ECF2B: swri_realloc_audio (swresample.c:418)
==45713==    by 0x7EDCDA: swr_convert_internal.part.3 (swresample.c:601)
==45713==    by 0x7EE97C: swr_convert_internal (swresample.c:416)
==45713==    by 0x7EE97C: swr_convert (swresample.c:766)
==45713==    by 0x6136FC: SrsAudioResample::resample(SrsSample*, char*, int&) (srs_app_rtc_codec.cpp:319)
==45713==    by 0x613D4B: SrsAudioRecode::transcode(SrsSample*, char**, int*, int&) (srs_app_rtc_codec.cpp:421)
==45713==    by 0x606563: SrsRtcFromRtmpBridger::transcode(char*, int) (srs_app_rtc_source.cpp:570)
==45713==    by 0x606462: SrsRtcFromRtmpBridger::on_audio(SrsSharedPtrMessage*) (srs_app_rtc_source.cpp:538)
==45713==    by 0x4FFE86: SrsSource::on_audio_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2767)
==45713==    by 0x4FFA63: SrsSource::on_audio(SrsCommonMessage*) (srs_app_source.cpp:2722)
==45713==
==45713== 17,856 bytes in 1 blocks are still reachable in loss record 455 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x80445F: av_malloc (mem.c:87)
==45713==    by 0x80445F: av_mallocz (mem.c:238)
==45713==    by 0x80445F: av_mallocz_array (mem.c:195)
==45713==    by 0x7ECF2B: swri_realloc_audio (swresample.c:418)
==45713==    by 0x7EDCFC: swr_convert_internal.part.3 (swresample.c:608)
==45713==    by 0x7EE97C: swr_convert_internal (swresample.c:416)
==45713==    by 0x7EE97C: swr_convert (swresample.c:766)
==45713==    by 0x6136FC: SrsAudioResample::resample(SrsSample*, char*, int&) (srs_app_rtc_codec.cpp:319)
==45713==    by 0x613D4B: SrsAudioRecode::transcode(SrsSample*, char**, int*, int&) (srs_app_rtc_codec.cpp:421)
==45713==    by 0x606563: SrsRtcFromRtmpBridger::transcode(char*, int) (srs_app_rtc_source.cpp:570)
==45713==    by 0x606462: SrsRtcFromRtmpBridger::on_audio(SrsSharedPtrMessage*) (srs_app_rtc_source.cpp:538)
==45713==    by 0x4FFE86: SrsSource::on_audio_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2767)
==45713==    by 0x4FFA63: SrsSource::on_audio(SrsCommonMessage*) (srs_app_source.cpp:2722)
==45713==
==45713== 20,608 bytes in 1 blocks are still reachable in loss record 456 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x80471F: av_malloc (mem.c:87)
==45713==    by 0x80471F: av_mallocz (mem.c:238)
==45713==    by 0x80471F: av_calloc (mem.c:248)
==45713==    by 0x7F5C60: resample_init (resample.c:348)
==45713==    by 0x410600: swr_init (swresample.c:275)
==45713==    by 0x6133A5: SrsAudioResample::initialize() (srs_app_rtc_codec.cpp:270)
==45713==    by 0x613CC0: SrsAudioRecode::transcode(SrsSample*, char**, int*, int&) (srs_app_rtc_codec.cpp:411)
==45713==    by 0x606563: SrsRtcFromRtmpBridger::transcode(char*, int) (srs_app_rtc_source.cpp:570)
==45713==    by 0x606462: SrsRtcFromRtmpBridger::on_audio(SrsSharedPtrMessage*) (srs_app_rtc_source.cpp:538)
==45713==    by 0x4FFE86: SrsSource::on_audio_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2767)
==45713==    by 0x4FFA63: SrsSource::on_audio(SrsCommonMessage*) (srs_app_source.cpp:2722)
==45713==    by 0x4F30D3: SrsRtmpConn::process_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:1020)
==45713==
==45713== 30,720 bytes in 1 blocks are still reachable in loss record 457 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x804397: av_malloc (mem.c:87)
==45713==    by 0x804397: av_malloc_array (mem.c:188)
==45713==    by 0x40C4F1: ff_mdct15_init (mdct15.c:278)
==45713==    by 0x40A1A7: aac_decode_init (aacdec_template.c:1237)
==45713==    by 0x76B89E: avcodec_open2 (utils.c:935)
==45713==    by 0x612A13: SrsAudioDecoder::initialize() (srs_app_rtc_codec.cpp:77)
==45713==    by 0x613A35: SrsAudioRecode::initialize() (srs_app_rtc_codec.cpp:374)
==45713==    by 0x605FC7: SrsRtcFromRtmpBridger::initialize(SrsRequest*) (srs_app_rtc_source.cpp:460)
==45713==    by 0x6055B6: SrsRtcSource::initialize(SrsRequest*) (srs_app_rtc_source.cpp:278)
==45713==    by 0x604FD7: SrsRtcSourceManager::fetch_or_create(SrsRequest*, SrsRtcSource**) (srs_app_rtc_source.cpp:206)
==45713==    by 0x4FD4E7: SrsSourceManager::fetch_or_create(SrsRequest*, ISrsSourceHandler*, SrsSource**) (srs_app_source.cpp:2251)
==45713==
==45713== 48,484 bytes in 1 blocks are still reachable in loss record 458 of 464
==45713==    at 0x4C29AAB: malloc (vg_replace_malloc.c:299)
==45713==    by 0x81DC1C: opus_alloc (os_support.h:49)
==45713==    by 0x81DC1C: opus_encoder_create (opus_encoder.c:528)
==45713==    by 0x612E1D: SrsAudioEncoder::initialize() (srs_app_rtc_codec.cpp:160)
==45713==    by 0x613AB0: SrsAudioRecode::initialize() (srs_app_rtc_codec.cpp:380)
==45713==    by 0x605FC7: SrsRtcFromRtmpBridger::initialize(SrsRequest*) (srs_app_rtc_source.cpp:460)
==45713==    by 0x6055B6: SrsRtcSource::initialize(SrsRequest*) (srs_app_rtc_source.cpp:278)
==45713==    by 0x604FD7: SrsRtcSourceManager::fetch_or_create(SrsRequest*, SrsRtcSource**) (srs_app_rtc_source.cpp:206)
==45713==    by 0x4FD4E7: SrsSourceManager::fetch_or_create(SrsRequest*, ISrsSourceHandler*, SrsSource**) (srs_app_source.cpp:2251)
==45713==    by 0x4EEC80: SrsRtmpConn::stream_service_cycle() (srs_app_rtmp_conn.cpp:506)
==45713==    by 0x4EDFFF: SrsRtmpConn::service_cycle() (srs_app_rtmp_conn.cpp:396)
==45713==    by 0x4ECA43: SrsRtmpConn::do_cycle() (srs_app_rtmp_conn.cpp:209)
==45713==    by 0x4EAC3F: SrsConnection::cycle() (srs_app_conn.cpp:172)
==45713==
==45713== 49,152 bytes in 1 blocks are still reachable in loss record 459 of 464
==45713==    at 0x4C29AAB: malloc (vg_replace_malloc.c:299)
==45713==    by 0x61B32B: _st_epoll_init (event.c:1047)
==45713==    by 0x6166BC: st_init (sched.c:163)
==45713==    by 0x4CC7D9: srs_st_init() (srs_service_st.cpp:80)
==45713==    by 0x5DBBBC: SrsHybridServer::initialize() (srs_app_hybrid.cpp:134)
==45713==    by 0x61603E: run_hybrid_server() (srs_main_server.cpp:480)
==45713==    by 0x615C08: run_directly_or_daemon() (srs_main_server.cpp:420)
==45713==    by 0x6146BC: do_main(int, char**) (srs_main_server.cpp:207)
==45713==    by 0x61485A: main (srs_main_server.cpp:218)
==45713==
==45713== 65,535 bytes in 1 blocks are still reachable in loss record 460 of 464
==45713==    at 0x4C2A7F7: operator new[](unsigned long) (vg_replace_malloc.c:423)
==45713==    by 0x5C0520: SrsUdpMuxListener::SrsUdpMuxListener(ISrsUdpMuxHandler*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int) (srs_app_listener.cpp:416)
==45713==    by 0x5FEF49: SrsRtcServer::listen_udp() (srs_app_rtc_server.cpp:205)
==45713==    by 0x6012EB: RtcServerAdapter::run() (srs_app_rtc_server.cpp:550)
==45713==    by 0x5DBD89: SrsHybridServer::run() (srs_app_hybrid.cpp:168)
==45713==    by 0x616096: run_hybrid_server() (srs_main_server.cpp:485)
==45713==    by 0x615C08: run_directly_or_daemon() (srs_main_server.cpp:420)
==45713==    by 0x6146BC: do_main(int, char**) (srs_main_server.cpp:207)
==45713==    by 0x61485A: main (srs_main_server.cpp:218)
==45713==
==45713== 65,535 bytes in 1 blocks are definitely lost in loss record 461 of 464
==45713==    at 0x4C2A7F7: operator new[](unsigned long) (vg_replace_malloc.c:423)
==45713==    by 0x5BFD54: SrsUdpMuxSocket::SrsUdpMuxSocket(void*) (srs_app_listener.cpp:286)
==45713==    by 0x5C0F7F: SrsUdpMuxListener::cycle() (srs_app_listener.cpp:521)
==45713==    by 0x5230CA: SrsSTCoroutine::cycle() (srs_app_st.cpp:198)
==45713==    by 0x523176: SrsSTCoroutine::pfn(void*) (srs_app_st.cpp:213)
==45713==    by 0x616C8B: _st_thread_main (sched.c:337)
==45713==    by 0x617403: st_thread_create (sched.c:616)
==45713==
==45713== 65,536 bytes in 1 blocks are still reachable in loss record 462 of 464
==45713==    at 0x4C2B95E: calloc (vg_replace_malloc.c:711)
==45713==    by 0x61B2C9: _st_epoll_init (event.c:1038)
==45713==    by 0x6166BC: st_init (sched.c:163)
==45713==    by 0x4CC7D9: srs_st_init() (srs_service_st.cpp:80)
==45713==    by 0x5DBBBC: SrsHybridServer::initialize() (srs_app_hybrid.cpp:134)
==45713==    by 0x61603E: run_hybrid_server() (srs_main_server.cpp:480)
==45713==    by 0x615C08: run_directly_or_daemon() (srs_main_server.cpp:420)
==45713==    by 0x6146BC: do_main(int, char**) (srs_main_server.cpp:207)
==45713==    by 0x61485A: main (srs_main_server.cpp:218)
==45713==
==45713== 85,904 bytes in 1 blocks are still reachable in loss record 463 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x80464F: av_malloc (mem.c:87)
==45713==    by 0x80464F: av_mallocz (mem.c:238)
==45713==    by 0x410048: swr_alloc (options.c:150)
==45713==    by 0x613282: SrsAudioResample::initialize() (srs_app_rtc_codec.cpp:256)
==45713==    by 0x613CC0: SrsAudioRecode::transcode(SrsSample*, char**, int*, int&) (srs_app_rtc_codec.cpp:411)
==45713==    by 0x606563: SrsRtcFromRtmpBridger::transcode(char*, int) (srs_app_rtc_source.cpp:570)
==45713==    by 0x606462: SrsRtcFromRtmpBridger::on_audio(SrsSharedPtrMessage*) (srs_app_rtc_source.cpp:538)
==45713==    by 0x4FFE86: SrsSource::on_audio_imp(SrsSharedPtrMessage*) (srs_app_source.cpp:2767)
==45713==    by 0x4FFA63: SrsSource::on_audio(SrsCommonMessage*) (srs_app_source.cpp:2722)
==45713==    by 0x4F30D3: SrsRtmpConn::process_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:1020)
==45713==    by 0x4F2F7F: SrsRtmpConn::handle_publish_message(SrsSource*, SrsCommonMessage*) (srs_app_rtmp_conn.cpp:999)
==45713==
==45713== 547,744 bytes in 1 blocks are still reachable in loss record 464 of 464
==45713==    at 0x4C2BC87: memalign (vg_replace_malloc.c:857)
==45713==    by 0x4C2BD85: posix_memalign (vg_replace_malloc.c:1020)
==45713==    by 0x80464F: av_malloc (mem.c:87)
==45713==    by 0x80464F: av_mallocz (mem.c:238)
==45713==    by 0x776C30: che_configure (aacdec_template.c:135)
==45713==    by 0x776C30: output_configure (aacdec_template.c:474)
==45713==    by 0x77A1EA: parse_adts_frame_header (aacdec_template.c:3007)
==45713==    by 0x77A1EA: aac_decode_frame_int.isra.26 (aacdec_template.c:3132)
==45713==    by 0x77A663: aac_decode_frame (aacdec_template.c:3372)
==45713==    by 0x75F04F: decode_simple_internal (decode.c:433)
==45713==    by 0x75F04F: decode_simple_receive_frame (decode.c:629)
==45713==    by 0x75F04F: decode_receive_frame_internal (decode.c:647)
==45713==    by 0x75FCC7: avcodec_send_packet (decode.c:705)
==45713==    by 0x612B2F: SrsAudioDecoder::decode(SrsSample*, char*, int&) (srs_app_rtc_codec.cpp:101)
==45713==    by 0x613B9E: SrsAudioRecode::transcode(SrsSample*, char**, int*, int&) (srs_app_rtc_codec.cpp:397)
==45713==    by 0x606563: SrsRtcFromRtmpBridger::transcode(char*, int) (srs_app_rtc_source.cpp:570)
==45713==    by 0x606462: SrsRtcFromRtmpBridger::on_audio(SrsSharedPtrMessage*) (srs_app_rtc_source.cpp:538)
==45713==
==45713== LEAK SUMMARY:
==45713==    definitely lost: 68,279 bytes in 47 blocks
==45713==    indirectly lost: 1,083 bytes in 20 blocks
==45713==      possibly lost: 0 bytes in 0 blocks
==45713==    still reachable: 1,168,705 bytes in 494 blocks
==45713==                       of which reachable via heuristic:
==45713==                         multipleinheritance: 40 bytes in 1 blocks
==45713==         suppressed: 0 bytes in 0 blocks
==45713==
==45713== For counts of detected and suppressed errors, rerun with: -v
==45713== Use --track-origins=yes to see where uninitialised values come from
==45713== ERROR SUMMARY: 19389574 errors from 1929 contexts (suppressed: 0 from 0)

SRS的配置如下(Config):

listen              1935;
max_connections     1000;
srs_log_tank        console;
srs_log_file        ./objs/srs.log;
daemon              off;

http_server {
    enabled         on;
    listen          8080;
    dir             ./objs/nginx/html;
}

http_api {
    enabled         on;
    listen          1985;
}
stats {
    network         0;
}
rtc_server {
    enabled         on;
    # Listen at udp://8000
    listen          8000;
    #
    # The $CANDIDATE means fetch from env, if not configed, use * as default.
    #
    # The * means retrieving server IP automatically, from all network interfaces,
    # @see https://github.com/ossrs/srs/issues/307#issuecomment-599028124
    candidate       $CANDIDATE;
    merge_nalus  off;
}

vhost __defaultVhost__ {
    rtc {
        enabled     on;
        bframe      discard;
    }
}

[内存泄漏.log](https://github.com/ossrs/srs/files/4910352/default.log)

重现(Replay)

重现Bug的步骤(How to replay bug?)

通过vld启动程序：valgrind --leak-check=full --error-limit=no --show-reachable=yes ./objs/srs -c conf/rtc.conf
启动ffmpeg 推流 ： ffmpeg -rtsp_transport tcp -i "rtsp://<IP_ADDRESS>:554/Streaming/Channels/101" -vcodec copy -acodec copy -f flv "rtmp://<IP_ADDRESS>:1935/live/livestream"
推流端30s之后手动停止
srs 在停止推流3min之后手动停止

期望行为(Expect)

描述你期望发生的事情(Please describe your expectation)

自己已修复


add new literal value to generic resource

As a Pod owner I want to add new properties with literal values to an existing resource,
so that I can add information even if I do not have a specific app for this type of resource
and also no knowledge about editing raw turtle.
Acceptance criteria

[ ] when viewing a generic resource I can add a new property and literal value
[ ] when typing a propery name I get proposals from common vocabularies, I can choose from
[ ] I can also insert a URI that is not in the proposal list
[ ] if the property is relative, it will create a URI relative to the current document
[ ] the new property and its value shows up in the list of literals
[ ] the type of the value is a simple string
[ ] show an error message, when the resources could not be edited
[ ] do not provide this feature when the document cannot be edited by the current user / visitor

Out of scope

other data types than string
adding links / relations to other resources
languages of literals

Technical notes:

WAC-Allow headers contain info about the access rights, but there should be a higher-level method to check it via rdflib
there is an npm package rdf-namespaces that could be used for the autocomplete list

Open Tasks

[ ] integration tests for data input
[ ] styling
[ ] resource is not considered editable directly after login
[ ] add event for changes in pos-select-term
[ ] use selected term when saving
[ ] consider using type Term in addPropertyValue method instead of string
[ ] update literals list after adding a term
[ ] e2e test
[ ] storybook / docs


ensureIndexes() throws unhandleable "Index with name: xyz_1" already exists with different options"

When opening a datastore, we call the ensureIndexes() on it so be sure all indexes defined by morphia annotations are created.
If annotations get updated in the software over time, e.g. a sparse=true attribute is set, this call will fail on each existing datastore. We would have to delete the old indexes by hand.
It would be great to have an additional parameter in the ensureIndexes() method to define if existing indexes should be overwritten, like already existing in other methods like
ensureIndex(Class clazz, String name, String fields, boolean unique, boolean dropDupsOnCreate);
for single collections.

The tricky part about that feature is you'd either be recreating indexes every time (terribly expensive) or you'd have to deploy one version passing in true for that boolean and then immediately change it back to not pass in true.

Would it be possible to check whether an index exists and compare the properties to the annotated index options?

if an index with same parameters exists, do nothing (adds a roundtrip for reading indexes, but cheaper than reindexing every time)
if an index with different parameters exists, drop it and create with annotated options (expensive only unce, and imho better than an exception)
if no index exists, create index (same as current behaviour)


replace update_package_lock action

Applied mkpr on .github/workflows/update_package_lock.yml
/tmp/x

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

npm package (@latest dist-tag)
v6.1.16
GitHub release

Your semantic-release bot :package::rocket:


Set idField only when it exists to avoid throwing an exception when performing a dummy insert or upsert.

SEARCH-173084
PL | fix review mode for create and upsert commands
I faced an issue where the dummy upsert or insert did not work.
To fix it, we decided to set the primary field only when it exists.
java.lang.RuntimeException: java.lang.IllegalArgumentException: Field ID of entity "sov keyword" is not fetched

The story https://kenshoo.atlassian.net/browse/SEARCH-173096

thanks! I found the article.


Searching in docz-theme-default menu duplicates menu items in the UI

Bug Report
When adding menu field to md/mdx frontmatter, it creates bugs in the search interface of docz-theme-default.  The bug causes more menu items to be created when users backspace and retype the values again.  A console warning is fired as well which warns about duplicate keys.
I think the bug is because the search typeahead is looking at both the menu text and nested menu text to decide whether it should display on the search bar.  When backspace is pressed, it doesn't clear the state (probably due to non-unique React keys), which causes the old elements to still persist, leading to duplication of UI submenu items in the menu.
This makes the nested menu somewhat unusable.
I also tested that if the menu name doesn't clash with any of the existing component names, then things work fine.  For example, searching for m, a, menu, aaa are all fine below without errors.
// md1.mdx
---
menu: aaa
---

// md2.mdx
---
menu: aaa
---

The issues happens when the markdown file names have matching characters as the menu frontmatter value e.g.
// md1.mdx
---
menu: mymenu
---

// md2.mdx
---
menu: mymenu
---

Typing m and backspacing will create the bug because m exists in both the menu frontmatter value, as well as the markdown file names.
To Reproduce

Clone and install test repo

git clone git@github.com:chrisrzhou/docz-test-menu.git
cd docz-test-menu
yarn
yarn docz dev

Or create two markdown files like this:
// md1.mdx
---
menu: mymenu
---

// md2.mdx
---
menu: mymenu
---

Search in menu by typing m, then m1
Backspace and repeat 2 over and over again.

Expected behavior
Expect that it should show m1 and m2 and then m1, but what we get is m1, m2 being duplicated in the menu.  The following error trace is also shown in the console:
Warning: Encountered two children with the same key, `01CZ5B2RC11CXABZ3AC94BWSNY`. Keys should be unique so that components maintain their identity across updates. Non-unique keys may cause children to be duplicated and/or omitted — the behavior is unsupported and could change in a future version.
    in nav (created by Context.Consumer)
    in Styled(nav) (created by Context.Consumer)
    in div (created by Context.Consumer)
    in Styled(div) (created by Context.Consumer)
    in div (created by Context.Consumer)
    in Styled(div) (created by Context.Consumer)
    in Menu (created by SidebarBase)
    in SidebarBase (created by withSizes(SidebarBase))
    in withSizes(SidebarBase) (created by Context.Consumer)
    in div (created by Context.Consumer)
    in Styled(div) (created by Main)
    in Main (created by Context.Consumer)
    in ThemeConfig (created by Page)
    in Page (created by AsyncRoute)
    in AsyncRoute (created by Route)
    in Route (created by Context.Consumer)
    in Switch (created by Context.Consumer)
    in MDXProvider (created by DocPreview)
    in DocPreview (created by Context.Consumer)
    in ThemeProvider (created by Context.Consumer)
    in ThemeConfig (created by Theme)
    in Theme (created by Theme)
    in ScrollToTopBase (created by Route)
    in Route (created by withRouter(ScrollToTopBase))
    in withRouter(ScrollToTopBase) (created by Theme)
    in Router (created by BrowserRouter)
    in BrowserRouter (created by Router)
    in Router (created by Theme)
    in DataServer (created by Theme)
    in StateProvider (created by Theme)
    in ErrorBoundary (created by Theme)
    in Theme (at root.jsx:5)
    in Root (created by HotExportedRoot)
    in AppContainer (created by HotExportedRoot)
    in HotExportedRoot (at app/index.jsx:14)

Environment

OS: macOS 10.14.1
Node/npm version: 0.13.5 (but I've ran into issues in 0.12.* as well)

Additional context/Screenshots
Add any other context about the problem here. If applicable, add screenshots to help explain.

Same problem here 😢

Looks like this issue can be closed now @pedronauck :muscle:

This isn't fixed.


tex-fmt: init at 0.4.3

Description of changes
tex-fmt is a formatter for LaTeX source files.
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 341818 run on x86_64-darwin 1

1 package built:

tex-fmt


Fixes to Layouts

This patch fixes an issue that Wide Long and Focus Long have had apparently.

haven't tested this myself but I'm trusting you that this is the correct fix


Waypoint: Make Images Mobile Responsive - where to add img

Challenge http://beta.freecodecamp.com/challenges/waypoint-make-images-mobile-responsive
I think it would be nice if the instructions told you where to add the image,i.e. directly below the existing img.

Adding a clarification now :)


Change delimiter in OwnerOperator

Definition of Ready

[ ] Does this meet the INVEST criteria?
[ ] Does this have a clearly defined user?
[ ] Does this have an estimate?
[ ] Does this have acceptance criteria?
[ ] Does this have sufficient context for the specific functionality being developed (design, business rules, etc.)
[ ] Does this have a dev link been provided in the design?
[ ] Is this traceable to a feature, epic, or PI?

User Story
As a
I want
So that
Acceptance Criteria
Given
When
Then
Development Notes
Does this Story require 508 Testing?

[ ] Implementing a new authoring tool that will produce code / content for the application
[ ] Implementing a 3rd party widget that will be part of the application
[ ] Adding new / updating custom functionality
[ ] Adding new / updating a page template
[ ] Adding new / replacing existing functionality (unless the replacement has already passed 508 testing)
[ ] Full Site Review prior to a scheduled EPA 508 review
[ ] Planning a video that will appear on the application
[ ] Producing a video that will appear on the application
[ ] Producing Training materials
[ ] Producing documents

Context
3/7/2023 (tlageman) - Current delimiter is a comma (,). This makes it impossible to parse out different Owner Operators from the outputted data. Previously, the old system had a "< br >" as the delimiter. Recommend using a "|" as we have for other parts of the new EASEY system.
This affects Facility/Unit Attributes, and all allowance and compliance data sub types and their streaming services counterparts.
Testing
Test Case:
Tester:
Definition of Done

[ ] Have all Acceptance Criteria been agreed to and validated by the scrum team?
[ ] Has the code been unit tested and peer reviewed?
[ ] Have the functional tests been executed?
[ ] Have all defects been reviewed and dispositioned, resolved, or deferred?
[ ] Is the user story ready to be deployed to the test/staging environments?

fixed the test cases and also update the node version along with delimiter changes
https://github.com/US-EPA-CAMD/easey-streaming-services/pull/94

@shahbazkhan1999  Build is failed. Need to fix build error (update node version in github->workflow-> .yml files)

@shahbazkhan1999
Can you please add some local env testing screenshot.

Bottom of our app's main page first click on the button "Start your data query"
(https://campd-stg.app.cloud.gov/)
Then move to the next page where we have data type select the data type "compliance" and also select the sub-data type "Allowance based"
After the selection of both click on the apply button and next apply each filter one by one in all filter '|' delimiter is applied check-in data table owner/operator column this delimiter is applied
Also download the CSV and check the owner/operator column.
I added some attachments for both CSV and Data Table views. Check these Attachments links below.

Private Zenhub Image
Private Zenhub Image
Private Zenhub Image
Private Zenhub Image

A few corrections @shahbazkhan1999 :

account info - data preview is missing | and shows , still. The download looks good though.
allowance holdings - data preview has the | but the download is still using the ,
allowance transactions - data preview and download are still using the , Keep in mind that transactions has Owner (Transferor) and Owner (Transferee) fields that both need the | instead of the ,
compliance emissions - data preview and download are still using the ,

@shahbazkhan1999
Allowance-> Account Information Download Not same as display
Account Information Download

@shahbazkhan1999 examples of improper "|" in the csv remain. Private Zenhub Image

Allowance - Transactions preview AND CSV display a "," between names in the "Owner (Transferee)" and "Owner (Transferor)" fields instead of "|"
For example,
AEP Generation Resources, Inc.,Buckeye Power, Inc.
should display as
AEP Generation Resources, Inc. | Buckeye Power, Inc.

Compliance - Allowance based preview display a "|" in "Owner/Operator" when it should display a ",".
For example, search on program = CSSO2G1 and preview. Ctrl-F "Springfield"
Preview screen

ownerOperator is found in the following APIs/endpoints and should have the | delimiter applied between each owner/operator value in a record e.g., "Georgia Power Company (Owner)|Southern Company (Owner)|Alabama Power Company (Operator)" which should be returned in the API call, CAMPD UI, and CAMPD file (json or csv) download.

account-mgmt

allowance-holdings
allowance-holdings/attributes/applicable
accounts/attributes
allowance-compliance
emissions-compliance

facilities-mgmt

facilities/attributes

streaming-services

facilities/attributes
accounts/attributes
allowance-holdings
allowance-compliance
emissions-compliance

buyOwner & sellOwner is found in the following APIs/endpoints and should have the | delimiter applied between each owner/operator value in a record e.g., "Georgia Power Company (Owner)|Southern Company (Owner)|Alabama Power Company (Operator)" which should be returned in the API call, CAMPD UI, and CAMPD file (json or csv) download.

account-mgmt

allowance-transactions

streaming-services

allowance-transactions

Note in the account-mgmt API there are endpoints for each data type that end in /applicable or /owner-operators but I am not sure if these are effected by this work. I think not, but wanted to make sure they were known.

Retagging this ticket to v1.4 to address remaining items which are to address the concatenation that occurs on the "Owner/Operator" columns in:
Compliance, Emissions Based (Owner/ Operator displays "," instead of "|" between owner and operator. "|" displays as expected between multiple owners and multiple operators.)
Facility, Facility/Unit Attributes (Owner/ Operator displays "," instead of "|" between owner and operator. "|" displays as expected between multiple owners and multiple operators.)

@shahbazkhan1999 On the Compliance, Emissions Based and Facility, Facility/Unit Attributes Custom Data Downloads, Owner' Operator still displays a "," instead of "|" between owner and operator in the data preview and CSV files.
Compliance, Emissions Based:

Compliance, Emissions Based CSV Download:

Facility, Facility/ Unit Attributes:

Facility CSV Download:

Blocked by #6101

@lgiannini1
#6101 I revert to previous (disable CSP). I think you can test from now onwards.

@shahbazkhan1999 I am still seeing the issues noted above where a "," is displayed instead of "|" between owners and operators in the Compliance, Emissions Based and Facility, Facility/Unit Attributes Custom Data data previews and CSV downloads.
Data Preview:

CSV Download:

@lgiannini1 changes were merged but not deployed I do not have the access for that but now they are deployed you can test.

Delimiters look correct in Facility/Unit Attributes, and all Allowance and Compliance data sub types

Checked Owner/Operator Column in Facility, Allowance (Account Info, Holdings, and Transactions), and Compliance (Emissions and Allowance based) on Data Queries in staging: https://campd-stg.app.cloud.gov/data/custom-data-download. No comments on the facility, allowance, or allowance based compliance data.
For compliance data, emissions based: The Owner/Operator Column doesn't have a delimiter and seems to only have operator data in that column. Is that how to data is suppose to display? It is also that way in the production environment.
@lgiannini1

Issue
Data Type: Compliance
Data Subtype: Allowance Based
programCode : ARP
facilityId: 2828

Made changes in

easey-account-api: Removed extra pipe in ownerOperator and The ownerOperator examples on the Swagger page
easey-facilities-api: The ownerOperator examples on the Swagger page
easey-streaming-services : The ownerOperator examples on the Swagger page

Developer test

easey-account-api

2. easey-facilities-api

3. easey-streaming-services

In the Facility, Facility/Unit Attributes CSV download, a "," is displayed instead of "|" between owner and operator.

On the streaming services swagger page, a "," displayed instead of "|" between owners and operators

Fixed the above issue in the streaming-services
Developer test.

Delimiters look correct on Facility/Unit Attributes, and all Allowance and Compliance data sub types in UI, CSV Downloads, and Swagger pages.

Took a look at this and agree with @lgiannini1 on each part except swagger pages. The data return is fine, but the example schemas need some tweaking to accurately reflect the delimiter patter of "value|value". Right now, some of them have "value , value" and "value | value". Here the corrections needed.
Account Mgmt
- Holdings - swagger page example schema - extra space around |
- Transactions - swagger page example schema - has , instead of |
- Attributes - swagger page example schema - extra space around |
- Account-based compliance - swagger page example schema - extra space around |
- Emissions-based compliance - swagger page example schema - extra space around |
Facilities Mgmt
- Attributes - swagger page example schema - extra space around |
Streaming Services
- Facility attributes - swagger page example schema - extra space around |
- Account attributes - swagger page example schema - extra space around |
- Holdings - swagger page example schema - extra space around |
- Transactions - swagger page example schema - has , instead of |
- Account-based compliance - swagger page example schema - extra space around |
Emissions-based compliance - swagger page example schema - extra space around |
FYI @szintgraff

@tlageman-epa
For the clarification : Transactions - swagger page example schema - has , instead of |  Is it in the  sellOwner ?

@ergjustin yes, buyOwner is fine

Developer Test
Fixed

swagger page example schema - extra space around |

2.  swagger page example schema - has , instead of |

Example schemas on account-mgmt, facilities-mgmt, and streaming-services swagger pages have the correct delimiters for ownerOperator with no additional spaces.

There is a pipe where I think a coma should be for "Louisiana 1".

Till now owner/operator was split with “),” then it joins with “)|”.
When the above situation “),” splits an extra pipe joins. The reason for that is owner/operator has (West),LLC which joins the pipe.
Solution:
owner/operator split with “r),” and pipe joins to it
OR
owner/operator split with “Owner),” and pipe joins to it. OR owner/operator split with “Operator),” and pipe joins to it

@mark-hayward-erg @ergjustin @alangmaid
This explanation doesn't align with what I understand about the approach for this ticket. Let's talk about it during the CAMPD weekly meeting later today. My questions are:

Which database is this data coming from?
What does it look like in the original database?
Are there multiple operators in one column?
If not, why are are splitting by ")," and then rejoining?

I tested the locations below and am moving to ready for deployment.
Testing description:
I spot checked unique occurrences of owner/operator columns in the following data pulls and specifically looked for "space|", "|space", "| INC", "| LLC", "| LP", "| LTD".

Downloaded facility data from 2015-2021
Compliance data allowance based for 2021 and 2022
Compliance emission based data from 2015-2021
Allowance, Account Info for all states
Allowance, holding from 2015-2021
Allowance transaction data from 2020-2021


FIP 1: Comments support

Abstract
Comment functionality is a core feature of all social networks. Comment support make social networks fun to use and increases user engagement.
FEEDweave currently supports only top-level posts, with no way to thread a discussion related to a post.
Commenting has been one of the most requested features since launch.
Instead of implementing commenting as a proprietary feature of FEEDweave, it can be implemented as a generic and reusable component on Arweave so it can be used by other applications in the ecosystem.
Making comments a component will also enable easy nesting of comments. Nesting depth can be enforced by the UI.
Specification
Arweave data apps are essentially transactions that follow a specific schema and are tagged with a unique App-Name tag. You can see examples of Arweave apps on the App Explorer.
To implement commenting in the most generic way, we'll design the component so a comment can be posted about any Arweave transaction. App-Name: transaction-comment feels like an appropriate name.
Let's imagine someone wants to comment on the FEEDweave tutorial post, which is represented by transaction 47zeUWFxruVhf9l-IZpxw-I7No7up2wSGekw7gQFwhE.
Here is what the data for a comment transaction would look like:
{
  "data": "FEEDweave is very interesting. I'd **love** to help build it! 😍",
  "tags": {
    "App-Name": "transaction-comment",
    "Parent-Transaction": "47zeUWFxruVhf9l-IZpxw-I7No7up2wSGekw7gQFwhE"
  }
}

The data field can be arbitrary markdown.
In order to render comments in the FEEDweave UI, the application would query a gateway for all transactions with "App-Name": "transaction-comment" and "Parent-Transaction": "47zeUWFxruVhf9l-IZpxw-I7No7up2wSGekw7gQFwhE", decorate them with user profile data, and  render them chronologically.
In order to post a comment in response to a comment, the Parent-Transaction would just be that of another comment.
Gateways can to implement custom processing to enable querying trees of comments efficiently.

Comment support is live!
Here is an example:
https://feedweave.co/post/UpPLAexuiTnfZcpxNUKfrT0qvvX4NimzOoxzKtm6Rj8
You can explore the raw comments data here:
https://explorer.arweave.co/app/transaction-comment


Need to ignore .DS_Store from macOS filesystem

Reasons for making this change:

In macOS, there is a hidden system-generated file .DS_Store which is not important for git, but always gets added to commits making them dirtier.
Links to documentation supporting these rule changes:
WikiPedia:

.DS_Store files may impose additional burdens on a revision control process, since they are frequently changed and can therefore appear in commits, unless specifically excluded.

Microsoft:

Corrupted .DS_Store files can prevent OneDrive from syncing correctly. Deleting the corrupted files can help restore normal sync operation.
No data is lost by deleting the corrupted files as Mac Finder only creates .DS_Store files to store viewing options, such as the positions of icons, size of the Finder window, and window backgrounds.

Adobe:

These files contain information about system configuration. If you upload them along with other files, the files can be misused to obtain information about your computer.

Apple:

By enticing a user to open a directory containing a maliciously crafted .DS_Store file, an attacker may cause arbitrary code execution. This update addresses the issue through improved bounds checking.

If this is a new template:

Link to application or project’s homepage: TODO

@shiftkey @bdougie

The global ignore should be used for OS-specific files: https://github.com/github/gitignore/tree/main/Global#globally-useful-gitignores
A comment like the one for PyCharm may be added instead, if maintainers find this to be a common request.
As https://github.com/github/gitignore/blob/main/Global/macOS.gitignore has many rules, I'd rather not include the whole thing.


[BUG] update_many with aggregate set fields to a nested document not the exact expression value

Describe the bug
When use find & update_many to replace array fields frist N elements with new elements, the command update the fields value to nest document not the expresssion calculated value
To Reproduce
origin_children_ancestors = [ObjectId("65acdb2f025de11c4b6f4fa8"),ObjectId("65ad037edbe9cca114dcaf38")]
new_children_ancestors = [ObjectId("65acdb2f025de11c4b6f4fa8"),ObjectId("65ad037edbe9cca114dcaf38"), ObjectId(""65ae10c1652cea51d101c0c1"")]

await Categories.find({
    f"ancestors.{i}": val for i, val in enumerate(origin_children_ancestors)
}).update_many({
    "$set": {
        "ancestors": {
            "$concatArrays": [
                new_children_ancestors,
                {"$slice": ["$ancestors", len(origin_children_ancestors), {"$size": "$ancestors"}]}
            ]
        }
    }
})

Expected behavior
"ancestors" field should be updated starts with "new_children_ancestors" array.
Additional context
"ancestors" is wrong updated to a dict {
"$concatArrays": [
new_children_ancestors,
{"$slice": ["$ancestors", len(origin_children_ancestors), {"$size": "$ancestors"}]}
]}

I think we should change the *args: Mapping[str, Any] signture of the update_many method to *args: Mapping[str, Any] | Sequence[Mapping[str, Any]] and used as:

await Categories.find({
    f"ancestors.{i}": val for i, val in enumerate(origin_children_ancestors)
}).update_many([{
    "$set": {
        "ancestors": {
            "$concatArrays": [
                new_children_ancestors,
                {"$slice": ["$ancestors", len(origin_children_ancestors), {"$size": "$ancestors"}]}
            ]
        }
    }
}])

Currently, this script can be executed as expect but with issue hints in IDE.

Thank you for the catch. I'll pick this up on the next bug fixing session


Registration: submit button is inactive when MiddleName is empty (though it is not required)

Environment: develop

OoS-Backend\OutOfSchool\OutOfSchool.IdentityServer\Views\Auth\Register.cshtml

If it is not mandatory - there is no need to disable the button. I shall be enabled even if there is no information in the field.


Move ui-shared back to app services-ui

See: https://github.com/redhat-developer/app-services-ui-shared#readme
I think all shared components might need to go to some shared folder.

@riccardo-forina assigning to you but feel free to drop if needed.

Closing. We do not need that right now


allows for overriding basic auth

I made a simple change allowing for the basic auth settings to be overridden. The use case is passing in credentials for a sub account.

I'm studying the API more and it looks like Account may do the trick for me!

Account doesn't provide the use case I need. I'd like to be able to create messages under a sub account. I'm going to play around with exposing the underlying http options. I just started playing with Elixir this week. Do you have a better idea of how we could support CRUD actions scoped to subaccounts?


Wordsmithing Improvements to "What is Gradle?"

Suggests some tweaks for the What is Gradle section.  I really like the overall direction of the change.

New favorite line:

while effortlessly benefiting

Effortlessly might be me slightly overselling it. 😛

Removing "effortelessly" would be better. It will feels less like an advert.

@bot-gradle test and merge

WARN: The milestone of this PR is 8.2 RC1, but the base branch version is 8.3

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