[Confused] the Mesh Rope only supports horizontal rope , is it a bug ?

If I set the points of Rope in vertical ， the Display Object will be rotated 90 degree.
Is it a bug ? or feature ?

Need an example. Also, there's no support in Meshes for rotated textures yet (texture.rotate = 4 and so)

the official  example ：  http://pixijs.github.io/examples/#/basics/textured-mesh.js
re defined the points in vertical  direction  ( x =0 , y=i*ropeLength) ,
and in update , swap the x and y of point ， you will see the bug。

@ivanpopelyshev  , there is a example :
var renderer = PIXI.autoDetectRenderer(800, 600);
document.body.appendChild(renderer.view);

// create the root of the scene graph
var stage = new PIXI.Container();

var count = 0;

// build a rope!
var ropeLength = 256 / 10;

var points = [];

for (var i = 0; i < 10; i++)
{
    points.push(new PIXI.Point(0, i * ropeLength));
}

var strip = new PIXI.mesh.Rope(PIXI.Texture.fromImage('http://fattyboy.cn/pt/HTML5_Badge_256.png'), points);

strip.position.x = 200;
strip.position.y = 100;

stage.addChild(strip);

var g = new PIXI.Graphics();

g.x = strip.x;
g.y = strip.y;
stage.addChild(g);

// start animating
animate();

function animate() {

    count += 0.1;

    // make the snake
    for (var i = 0; i < points.length; i++) {

        points[i].x = Math.sin((i * 0.5) + count) * 20;

        points[i].y = i * ropeLength + Math.cos((i * 0.3) + count) * 10;

    }

    // render the stage
    renderer.render(stage);

    renderPoints();

    requestAnimationFrame(animate);
}

function renderPoints () {

    g.clear();

    g.lineStyle(2,0xffc2c2);
    g.moveTo(points[0].x,points[0].y);

    for (var i = 1; i < points.length; i++) {
        g.lineTo(points[i].x,points[i].y);
    };

    for (var i = 1; i < points.length; i++) {
        g.beginFill(0xff0022);
        g.drawCircle(points[i].x,points[i].y,10);
        g.endFill();
    };
}

Yes, its supposed to be only horizontal. If you want to change something, look into "uvs".

@ivanpopelyshev , How to let it support vertical ?
Could you give me some suggestions?
I try to swap these two lines
https://github.com/pixijs/pixi.js/blob/master/src/mesh/Rope.js#L191-L192
But It doesn't work (take a new mistake).

Here: https://github.com/pixijs/pixi.js/blob/master/src/mesh/Rope.js#L117

I can't understand these code  :'(  tears .
I want to do something like this :
// add getter setter :

    /**
     * Get the array of {@link PIXI.Point} objects to construct this rope.
     *
     * @member {PIXI.Point[]}
     */
    get points()
    {
        return this._points;
    }

    /**
     * Set the array of {@link PIXI.Point} objects to construct this rope.
     *
     * @param {PIXI.Point[]} value - The value to set to.
     */
    set points(value)
    {
        this._points = value;
        if (!value || value.length < 2)
        {
            this._vertical = false;
        }

        const first = value[0];
        const last = value[value.length - 1];
        const dx = last.x - first.x;
        const dy = last.y - first.y;

        this._vertical = dx === 0 || Math.abs(dy / dx) > 1;
        return this._points;
    }

in  setter , check the slope of rope，and set this._vertical =false/true.
Than we could try to let Rope support horizontal & vertical automatically.
Could you give me some advices and help ?

I've changed to this :
            uvs[index + 0] = 0 + offset.x;
            uvs[index + 1] = amount * factor.y + offset.y;

            uvs[index + 2] = factor.x + offset.x;
            uvs[index + 3] = amount * factor.y + offset.y;

But I don't know the next step


NOT NULL to NULL Field AutoMigrate

Your Question
Should gorm be able to change a field in the DB from NOT NULL to NULL? Based on the Auto-Migration docs, it seems like it should. However from inspection of the source, alterColumn is only set to true if the field is not primary key and column in the database is currently nullable
https://github.com/go-gorm/gorm/blob/33601dc72f4abf86ce68cbb663f7f5c898bee0a3/migrator/migrator.go#L398-L404
The document you expected this should be explained
https://gorm.io/docs/migration.html#Auto-Migration
Expected answer
I would actually expect NULL to NOT NULL to be the case gorm cannot automatically handle (due to the need to update existing rows which have NULL values), but I assumed NOT NULL to NULL would be ok

I've been spending hours trying to figure this one out, I read the note on the documentation page that you linked such that it should handle both ways (see below). However, in my testing it appears to not handle either way, I've made an update where I changed one field from Nullable to Not Null as well as a field that is Not Null but that I'm trying to make a Not Null field but neither changes. If I clear the database and re-run the automigrate it creates the tables correctly but it won't migrate existing tables.
NOTE: AutoMigrate will create tables, missing foreign keys, constraints, columns and indexes. It will change existing column’s type if its size, precision, nullable changed. It WON’T delete unused columns to protect your data.

I enabled full debugging in postgres to see what was actually communicated to the database and saw that it is actually running ALTER TABLE commands specifically for the changed columns, however, it is only setting the TYPE, not the nullability of the fields.  I might very well have missed something here but this seems wrong.

I just ran into the same problem. The issue still seems to exist.

I am also facing the same problem.


System doesn't start in Buster

When upgraded to Buster, the system will not start, because of this:
root@raspberrypi:/# sudo su -c 'raspimjpeg > /dev/null &' www-data
This account is currently not available.
root@raspberrypi:/# sudo su -c "php /var/www/$rpicamdir/schedule.php > /dev/null &" www-data
This account is currently not available.
root@raspberrypi:/#
That's for the same reason as #500
But I don't think I should change /etc/passwd to remove "sbin/nologin" and put "bash" for "www-data", as that will cause security issues. (we don't want to have security issues on a system with a camera, right? ;) )
Using PHP 7.3.4.

The camera install script does give www-data user a bash login. This is needed for both start up and to allow macro scripts to run.
The www-data user has very limited privileges and I don't think there is a particular security concern there. If you try to access a .sh script from the browser then it just returns the test; it doesn't execute it.
A clean install of buster followed by the camera software install does result in the system operational. A dist upgrade to buster does seem to revert the www-data bash set up and causes this issue, but a re-run of the install.sh should fix that.

Thank you very much for explaining. I trust what you say is correct. :)
Running "install.sh" (and a few other commands that I had to run to correct some of the errors with the upgrade!!) fixed the problem. Everything working great.
In the install, I had to write "7.3" as the PHP version, as otherwise with just "7" it will try to find "php7", which doesn't exist. But, "php" and "php7.3" exist in the system.
All good. Thank you very much.

Good to hear that all is OK.
The old install.sh does just use the version number of php directly. The latest version of install.sh should convert a plain 7 into 7.3, although if a more explicit version is put in (like if it ever changes to 7.4) then it will try to install that.


Querying continuous query with time condition

I'm trying to querying some data from a continuous query with time condition. When I run the following query it gives "Field time doesn't exist in series test". Is this the expected behaviour?
select value from test where time>"2015-03-26 18:03:247.010"

The continuous query is
select mean(value) as value,time from "M00010000167A0C58.channelA" group by time(1h) into test

You must wrap the time string in single-quotes, as explained here:
http://influxdb.com/docs/v0.9/query_language/querying_data.html#date-time-strings
Philip
On Mon, Mar 30, 2015 at 11:29 AM, Erdinc Bereketoglu <
<EMAIL_ADDRESS>wrote:

I'm trying to querying some data from a continuous query with time
condition. When I run the following query it gives "Field time doesn't
exist in series test". Is this the expected behaviour?
select value from test where time>"2015-03-26 18:03:247.010"
—
Reply to this email directly or view it on GitHub
https://github.com/influxdb/influxdb/issues/2119.


Issue with LineChart showing label points on android with data set greater than 80

Description
issue with the library on android when data set is  greater than 80 the label components are not showing up and horizontal scroll line are disappearing
<LineChart
               focusEnabled={true}
               adjustToWidth

               data={
             [{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100},{value:100} ...................,{value:100}] //array is greaterthan 100
               }
               spacing={80}
               showTextOnFocus
               initialSpacing={80}
               focusedDataPointColor={globalColors.purple}
               color={globalColors.purple}
               dataPointsColor={globalColors.bluegem}
               yAxisColor={globalColors.zumthor}
               xAxisColor={globalColors.zumthor}
               rulesType="solid"
               showVerticalLines
               showStripOnFocus
               leftShiftForLastIndexTooltip={55}
               height={heightPercentageToDP(35)}
               rulesColor={globalColors.brightGray}
               verticalLinesColor={globalColors.transparent}
               xAxisLabelTexts={xAxisLabelTexts?.reverse()}
               xAxisLabelTextStyle={{ alignSelf: "flex-start" }}
               maxValue={
                 this.state.highestMetric === 0
                   ? 3
                   : this.state.highestMetric < 1
                   ? 1
                   : Math.round(
                       (this.state.highestMetric * 1.5) /
                         Math.pow(
                           5,
                           Math.round(
                             this.state.highestMetric * 1.5
                           ).toString().length - 1
                         )
                     ) *
                     Math.pow(
                       5,
                       Math.round(this.state.highestMetric * 1.5).toString()
                         .length - 1
                     )
               }
               roundToDigits={
                 !Number.isInteger(this.state.highestMetric) ? 2 : 0.1
               }
               yAxisLabelWidth={55}
               minValue={0}
               yAxisOffset={0}
               noOfSections={3}
               showFractionalValues={true}

             />

https://github.com/user-attachments/assets/299fe290-ebee-422e-a9f0-62d4e42e9676
Steps to reproduce
Android
data grater than 100
Snack or a link to a repository
No response
version of react-native-gifted-charts
1.4.43
React Native version
0.71.6
Platforms
Android, iOS
Workflow
React Native

I've also had crashes happening on android when the data set is longer than 100 on my phone (Huawei P20 Pro). The crash error was java.lang.RuntimeException: Canvas: trying to draw too large(114117768bytes) bitmap.
The focusedCustomDataPoint prop also doesn't work for me on data points when pressing on any point after 68 points on my phone.

Hi @saadiyakazi @SamyOptimize
Android does not allow rendering very large svgs. See https://github.com/software-mansion/react-native-svg/issues/440
For large datasets, you must use pagination instead of rendering the entire data at once. See pagination related props
Here's a related issue


Bug in 401_CNN.ipynb

Besides bugs mentioned in https://github.com/MorvanZhou/PyTorch-Tutorial/pull/55,
print('Epoch: ', epoch, '| train loss: %.4f' % loss.data[0], '| test accuracy: %.2f' % accuracy)
should be replaced with
print('Epoch: ', epoch, '| train loss: %.4f' % loss.item(), '| test accuracy: %.2f' % accuracy)
to suppress the following warning:

/opt/conda/lib/python3.6/site-packages/ipykernel_launcher.py:41: UserWarning: invalid index of a 0-dim tensor. This will be an error in PyTorch 0.5. Use tensor.item() to convert a 0-dim tensor to a Python number

Thanks for the update


A11y improvements.

This PR makes a number of changes to the html to improve accessibility. Primarily by replacing structural divs with more semantic elements and splitting up the page structurally. Orca (the default Linux screen reader) is currently refusing to work for me on any web browser, so I am making these changes deaf (as it were) and relying on automated testing tools.
I'm still not happy with the mobile menu, but not sure what could be done there; someone with more experience of these matters and perhaps a better understanding of semantic ui would need to take a look at that. These commit should all keep visual changes to an absolute minimum, only altering site appearance when absolutely necessary.
If there are any queries / suggestions please ping me and I can go over things in more depth.

@17cupsofcoffee If you do ever decide to change framework and need some help, let me know. I'm happy to lend a hand if and when time allows.

I did notice one issue I missed in the previous PR's review, though sweat_smile Commenting out @import 'semantic/grid'; broke the layout of the footer slightly (it used to be three columns but now it's all displaying in one) - could we fix that while we're here?

Woops! I also didn't spot that, clearly wasn't paying enough attention to the footer :sweat_smile:
I've pushed up a commit reinstating that now.

Thanks again for the PR!


add 1.13 survey

@therealmitchconnors: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio_release-1.13
71cb5a0b9054a5ef3095d77a7a3f98d89c0499ca
link
true
/test release-notes_istio_release-1.13

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@therealmitchconnors: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio_release-1.13
71cb5a0b9054a5ef3095d77a7a3f98d89c0499ca
link
true
/test release-notes_istio_release-1.13

gencheck_istio_release-1.13
71cb5a0b9054a5ef3095d77a7a3f98d89c0499ca
link
true
/test gencheck_istio_release-1.13

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@therealmitchconnors: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio_release-1.13
71cb5a0b9054a5ef3095d77a7a3f98d89c0499ca
link
true
/test release-notes_istio_release-1.13

gencheck_istio_release-1.13
71cb5a0b9054a5ef3095d77a7a3f98d89c0499ca
link
true
/test gencheck_istio_release-1.13

lint_istio_release-1.13
71cb5a0b9054a5ef3095d77a7a3f98d89c0499ca
link
true
/test lint_istio_release-1.13

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


add unit tests II

This PR adds more unit tests to test for errors
OSD-16571

Codecov Report

Merging #18 (1717bb0) into main (0e18fbd) will increase coverage by 1.92%.
The diff coverage is 75.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #18      +/-   ##
==========================================
+ Coverage   14.69%   16.62%   +1.92%
==========================================
  Files          10       10
  Lines         415      415
==========================================
+ Hits           61       69       +8
+ Misses        341      337       -4
+ Partials       13        9       -4

Impacted Files
Coverage Δ

pkg/goalert/service.go
74.11% <75.00%> (+9.41%)
:arrow_up:

/lgtm

/approve


Impr mbe: remove unecessary temporary vec

It's a micro optimization. I don't know if it's really necessary (less alloc is always better).

bors r+


Added fibonacci_pattern.py

Why:
Closes #85
What's being changed:

Added fibonacci_pattern.py, a python script that prints the Fibonacci sequence up to a certain value entered by the user.

Check off the following:

[ ] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[ ] For content changes, I have completed the self-review checklist.

Hey @rossilor95
This PR is included in #661
Closing this one 👍🏻


[High] Cannot create columns or rows

Cannot create new rows or columns where the default/first value in the dropdowns is used

If I select another option (either built in type or other custom type) it works

The problem is on SelectInput component. It doesn't have an empty value option. So it will show the first option on the list but the value is an empty string.
Fixed

related supabase/infrastructure/issues/1231


Mention the feed url:
{
    url: https://cybercultural.com/feed.xml
}

fixed in https://github.com/murtuzaalisurti/rssed/commit/65b68423b6ec88d678d78fa94ca11b62ed4bcb6b


ConvertTo-Json

Steps to reproduce
@('a')|convertto-json

Expected behavior
[
"a"
]

Actual behavior
"a"

Environment data

The pipeline by nature unwraps arrays into individual items. To a receiving cmdlet, there is so distinguishable difference between these two scenarios:
'a' | ConvertTo-Json

@('a') | ConvertTo-Json

If you need single-item arrays you will need to pass them directly to the -InputObject parameter rather than using the pipeline.

Not sure if I should open up a new ticket or glue my similar issue to this one, so I'll go with the former and may the mods hit me over the head with a clue-stick if necessary :)
This is one thing I think ConvertTo-Json should handle:
PS /> ps
PID TTY          TIME CMD
24618 pts/0    00:00:00 sudo
24622 pts/0    00:00:00 su
24623 pts/0    00:00:00 bash
25724 pts/0    00:00:01 pwsh
25757 pts/0    00:00:00 ps
PS ACTUAL> ps | ConvertTo-Json
[
"  PID TTY          TIME CMD",
"24618 pts/0    00:00:00 sudo",
"24622 pts/0    00:00:00 su",
"24623 pts/0    00:00:00 bash",
"25724 pts/0    00:00:01 pwsh",
"26184 pts/0    00:00:00 ps"
]
PS EXPECTED> ps | ConvertTo-Json
[
{
"PID": 24618,
"TTY": "pts/0",
"TIME": "00:00:00",
"CMD": "sudo"
},
{
"PID": 24622,
"TTY": "pts/0",
"TIME": "00:00:00",
"CMD": "su"
},
{
"PID": 24623,
"TTY": "pts/0",
"TIME": "00:00:00",
"CMD": "bash"
},
{
"PID": 25724,
"TTY": "pts/0",
"TIME": "00:00:00",
"CMD": "pwsh"
},
{
"PID": 26184,
"TTY": "pts/0",
"TIME": "00:00:00",
"CMD": "ps"
}
]
Because if it doesn't, then by default it could be replaced with something like this simple awk script :)
awk 'BEGIN{printf("["); c="\n";}{printf("%s\t"%s"",c,$0); c=",\n"; }END{print "\n]";}'
user@wslhost:/mnt/c/Users/user$ ps | awk 'BEGIN{printf("["); c="\n";}{printf("%s\t"%s"",c,$0); c=",\n"; }END{print "\n]";}'
[
"  PID TTY          TIME CMD",
"  218 pts/4    00:00:00 bash",
"  269 pts/4    00:00:00 ps",
"  270 pts/4    00:00:00 awk"
]
But then I may be overreaching?

@thorsig bit of a different issue there. The alias ps that points to Start-Process in Windows editions of PowerShell (including recent versions of PowerShell 7 GA) is not actually present in linux, due to there being a native ps executable that many folks use.
That executable only ever emits string data, so ConvertTo-Json can only treat it as such.
What you seem to be wanting is still achievable with Get-Process | ConvertTo-Json. 🙂
If you instead want the text output from ps to be interpreted as some kind of object, you need to provide that conversion yourself; cmdlets in PowerShell can't afford to make any assumptions about the expected format of string data without breaking other users' assumptions in the process. It's for a similar reason that many very useful aliases were removed for Unix editions of PowerShell; many Unix users got very upset that PowerShell was "taking over" these native executables with its aliases.


quickcheck zebra reading

This adds a test that just savages some random Icicle facts to Zebra, reads them into an input struct, and peeks the result.
depends on https://github.com/ambiata/zebra/pull/64
! @jystic @amosr

It might be easier to convert the icicle type to a Schema then convert the icicle value to a zebra Value, then you can use:
fromRow :: Schema -> Value -> Either (TableError Schema) (Table Schema)

might be a safer test because otherwise you're testing your encoding of tables vs the icicle generated code.

true, that is less savage actually -- I'll convert to a Schema

using zebra Schema now

💯 for the test
👍 after we resolve the mapping from icicle types to zebra, happy to discuss IRL, maybe it's not so important, but I can see that testing stuff becoming the basis for our production mapping

:1st_place_medal: wow

I'm going to rebase and merge this, ignoring the unmelted value failure (see #500)


Map service registry error codes once backend introduces them

error.go file currently has number of errors but backend still doesn't return any valid ones.
Issue logged in srs:
https://github.com/bf2fc6cc711aee1a0c2a/srs-fleet-manager/issues/81

Unblocked by @jsenko and published to QA env

Blocked by preeliminary work on the SDK's

Same issue as https://github.com/redhat-developer/app-services-cli/issues/1057 - requires some work in SDK


Use service lister instead of kubeclient

I don't quite like that the tests seem to cover barely anything here, but I'd like to approach that separately seeing as the tests are like that currently too.
We really shouldn't use a kubeclient here though. We're even adding services to the tracker but are never setting up an informer, so this fixes that.

/lgtm


"Tătărani", "Căprioru" are listed in the drop-down menu

Description:
When user writes ” Tătărani” and "Căprioru" the locations appear in the drop-down menu next to the comune and the county which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Tătărani"

Expected results
The location appears in the drop-down menu as "Sat Tătărani, DÂMBOVIȚA (Tătărani)".

Step 3
Write in the search bar "Căprioru"

Expected results
The location appears in the drop-down menu as "Sat Căprioru, DÂMBOVIȚA (Tătărani)".


test client grpc test case

[Task] shenyu-client-grpc test case #4545

Make sure that:

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

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (c6c7fdb) 61.16% compared to head (c076301) 60.72%.
Report is 2 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #5395      +/-   ##
============================================
- Coverage     61.16%   60.72%   -0.44%
  Complexity     8597     8597
============================================
  Files          1248     1254       +6
  Lines         38017    38280     +263
  Branches       3647     3662      +15
============================================
- Hits          23253    23247       -6
- Misses        12666    12931     +265
- Partials       2098     2102       +4

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

pls add my wechat: yijia1949


backend/admin_ops: don't verify certs on send request

Fixes: aquarist-labs/s3gw#737
Signed-off-by: Joao Eduardo Luis<EMAIL_ADDRESS>

Adding a test case would be complicated, right?

Adding a test case would be complicated, right?

I don't think it's feasible. It would require something else to connect to, and ensuring we're connecting to it. I also think we wouldn't get much value out of it.


release 0.7

The new pre-release is out since more than two weeks, I've been using it flawlessly since its release on archlinux. I'd like to know what is missing to make it an true new release. Thanks!

I've just promoted 0.7 to stable release!


Support: How to set portrait only Scene , Thanks

Version
Tell us which versions you are using:

react-native-router-flux v3.?.?
react-native v0.?.?

Expected behaviour
Actual behaviour
Steps to reproduce

Is not the purpose of this library, you have to use a custom bridge or another library to do this.

Well, thanks for the support.


Task graph [1/10]: resource synchronization state tracking

This is the first patch on the road to a task graph, the replacement for the current synchronization. It includes the resource state tracker and the definition of a task. Some form of resource state tracker is at the heart of all task graph implementations I've seen (except Bevy's, as wgpu does synchronization internally) and what everything else should be built upon. Similarly, a task graph can't function without inversion of control: a task must have a callback that records commands into a command buffer and/or do host accesses. This is what the Task trait defines.
Documentation and testing is sparse at the moment because it's possible that things will change drastically over the coming days.
Design goals
Going forward I would like to establish some design goals for following work on the task graph. In order of importance:

Having something that works very well in as many use cases as possible.
Being as performant as possible.
Being safe.

The problems of the current synchronization
First of all it should be noted that vulkano's synchronization dates back to when Vulkan was in its infancy and no one knew how to best abstract the enormous amount of details that comes with an API as low level as this, so it's only natural that the current system has its problems. It's also, I believe, the last remaining piece of tech debt, at least in a public API, and why a rewrite is in order.
The current synchronization falls short on all of the above design goals. In my opinion, the single biggest factor in all its problems is that the synchronization is immediate-mode and just-in-time. To quote Hans-Kristian Arntzen in his "Render graphs and Vulkan — a deep dive" article:

Essentially, if what we want is just-in-time automatic sync, we basically want OpenGL/D3D11 again. Drivers have already been optimized to death for this, so why do we want to reimplement it in a half-assed way?

That sums it up very nicely. The current system is very hard to use correctly, and many common use cases are not possible to express at all, because GpuFutures must be chained in just the right way (because everything is JIT) and your usage of the API is validated rather than incorrect usage being ruled out by design. The error messages are a constant source of frustration and very hard to debug. When there are no errors, there are many instances of the synchronization working incorrectly and cauing validation errors instead, or plain data races, because GpuFuture was never safe either. And while it would be possible to fix some of these issues, it would still be a subpar system as summed up in the above quote. There are also many glaring issues in terms of performance both on the host and device, for instance because of the resource tracking that each command buffer and descriptor set do on each recording, all the clones and allocations going along with that, all the locking of resources, etc.
Enter the task graph
As mentioned, one of the fundamental building blocks of any task graph is a global state tracker and that the task has a callback to record commands. This means that:

The task graph compiler can order tasks such that none of them can cause conflicting resource accesses to begin with. This system is declarative and ahead-of-time, which makes it much easier to use correctly.
It's also much easier to make performant:

The individual command buffers and descriptor sets don't need to keep any references or any other internal state, because there is one central resource state tracker that persists between submissions and the task graph compiler can insert pipeline barriers and semaphore wait/signal operations between the task executions.
Since there is a global resource state tracker, there is no longer a need for the overly conservative global memory barriers at the start of a command buffer and other vulkano-isms that limit the performance on the device.

Adding the features that GpuFuture and AutoCommandBufferBuilder are missing is much easier as well:

You can easily mix automatic and manual sync, because a task has an input/output interface that is defined ahead of time, and so doing manual pipeline barriers or executing other raw command buffers (cc #2222) inside a task is fine as long as the task has defined access to the affected resources (or no sync is needed, as with immutable shared resources).
Cross-queue synchronization is easier to implement correctly, again because a task has defined its inputs/outputs, and the task graph compiler can insert queue family ownership transfers ahead of time.

Having a global resource state tracker, I believe it is imperative that we allow the user to manipulate it directly. This is mostly based on @john01dav's (very valid) criticisms that not enough of vulkano's internals can be manipulated. This allows the user to access a resource externally and update vulkano's resource tracker to then use the resource with the automatic sync.

Prior art

Render graphs and Vulkan — a deep dive
Organizing GPU Work with Directed Acyclic Graphs
REAC 2023 DAY 1 Task Graph Renderer at Activision
kajiya-rg
bevy_render::render_graph

Changelog:
### Additions
- Added `memory::allocator::{align_down, align_up}`.

\o/


Return IServiceCollection from builder methods so that additional calls can be chained

Previously the AddCaching method did this. It is also common in other builder methods like this. It doesn't do any harm for those that don't want to chain and allows cleaner code with fewer variable declarations for those that do.

Hi @ajcvickers, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

@Eilon @javiercn This support was intentionally removed, correct?

https://github.com/aspnet/Caching/pull/156#discussion_r54686083

@Tratcher indeed this was a deliberate change, but we're changing our minds on this and going back to allow chaining.

:shipit:


Added whisper-diff command

This command is useful for performing sanity checks before whisper-merge

Is there some reason this isn't included in the master branch now/anymore?  Sounds like a super helpful tool, and I could use it for a project I'm on right now.
Is this still working and possibly tested?

Looks like I failed at squashing the commits. See the commit that merged this all that I did. Not sure how I pulled that off.
I'll try to get that back into whisper master in the next few days when I'm able. @bheilman or @gpatmore feel free to open another PR adding it back if you so choose.


Fix zsh completion

This addresses completion issues mentioned here: https://github.com/majjoha/voxctl/pull/1#issuecomment-670546682
Additionally, I moved the actual file from share/zsh/site-functions to contrib/completion which seems a bit more standard-ish in comparison to other brew distributed stuff.

I've just tested the script and it works perfectly. It is quite nice to have completion now so thank you once again.


Publish: add selectors to publish and unpublish dialogs

Description
It's required to add the ability to select items when creating a request to publish or unpublish a folder
Use case/motivation
No response
Related issues
No response
Confidential information

[X] I confirm that do not share any confidential information

related issues
#1801
#1805

Open questions:

Chats with files can be published without files or it should be not allowed?
Can chat with files be unpublished without files ( unpublish only chat, files still remain published)?

Closing the ticket as there is still no design session was organized.


can i replace default css

i have problem with default css min-width 300px, can i rewrite css rule?

Open another


Update explainer.md

Cover the rationale for name prefix matching and name matching

Does this explain the rationale adequately, @pwnall  ?

Everything here is useful!


valgrind: multiple memory leaks

Describe the bug
On multiple of our machines running Sysmon for Linux, we have noticed Sysmon for Linux occupying an ever-increasing amount of memory until the OOM killer steps in and terminates the process.
To verify that these are indeed unintended leaks, we had Sysmon for Linux run under valgrind over the weekend. This produced the output seen under Logs.
To Reproduce
We used a build of valgrind at commit ef95220ddae1af65c85d8d59a8f0dcbb9d7af90f (https://sourceware.org/git/?p=valgrind.git;a=commit;h=ef95220ddae1af65c85d8d59a8f0dcbb9d7af90f), since the version shipped with Debian 11 crashes when encountering unsupported eBPF commands.
Sysmon version
Sysmon for Linux 1.3.2, but built from source (at tag <IP_ADDRESS>) with -DCMAKE_CXX_FLAGS="-ggdb3" to enhance valgrind output.
sysmon.service was modified to run under valgrind as follows (this must occur at compile time, since the service definition is linked into the Sysmon binary):
#
#    Copyright (c) Microsoft Corporation
#
#    All rights reserved.
#
#    MIT License
#
#    Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the ""Software""), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
#
#    The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#

[Unit]
Description=Sysmon event logger
After=syslog.service

[Service]
Type=forking
User=root
WorkingDirectory=/opt/sysmon
ExecStart=/root/valgrind-ef95220ddae1af65c85d8d59a8f0dcbb9d7af90f/vg-in-place --trace-children=yes --smc-check=all --tool=memcheck --leak-check=yes --log-file=/var/log/valgrind/sysmon_%%p.log /opt/sysmon/sysmon -i /opt/sysmon/config.xml -service

[Install]
WantedBy=multi-user.target

This causes sysmon -i to hang after enabling the service, but Ctrl-Cing after that works and keeps the service running.
Distro/kernel version
Debian 11 "Bullseye", Kernel 6.1.0-18-amd64
Sysmon configuration
<Sysmon schemaversion="4.90">
    <HashAlgorithms>md5,sha1,sha256</HashAlgorithms>
    <EventFiltering>
        <RuleGroup name="ngs-pulsar ProcessTerminate include none" groupRelation="or">
            <ProcessTerminate onmatch="include"></ProcessTerminate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1021.004" groupRelation="and">
            <ProcessCreate onmatch="include">
                <Image condition="end with">ssh</Image>
                <CommandLine condition="contains">ConnectTimeout=</CommandLine>
                <CommandLine condition="contains">BatchMode=yes</CommandLine>
                <CommandLine condition="contains">StrictHostKeyChecking=no</CommandLine>
                <CommandLine condition="contains any">wget;curl</CommandLine>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1027.001" groupRelation="and">
            <ProcessCreate onmatch="include">
                <Image condition="is">/bin/dd</Image>
                <CommandLine condition="contains all">dd;if=</CommandLine>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1033" groupRelation="or">
            <ProcessCreate onmatch="include">
                <CommandLine condition="contains">/var/run/utmp</CommandLine>
                <CommandLine condition="contains">/var/log/btmp</CommandLine>
                <CommandLine condition="contains">/var/log/wtmp</CommandLine>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1053.003" groupRelation="or">
            <ProcessCreate onmatch="include">
                <Image condition="end with">crontab</Image>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1059.004" groupRelation="or">
            <ProcessCreate onmatch="include">
                <Image condition="end with">/bin/bash</Image>
                <Image condition="end with">/bin/dash</Image>
                <Image condition="end with">/bin/sh</Image>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1070.006" groupRelation="and">
            <ProcessCreate onmatch="include">
                <Image condition="is">/bin/touch</Image>
                <CommandLine condition="contains any">-r;--reference;-t;--time</CommandLine>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1087.001" groupRelation="or">
            <ProcessCreate onmatch="include">
                <CommandLine condition="contains">/etc/passwd</CommandLine>
                <CommandLine condition="contains">/etc/sudoers</CommandLine>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1105" groupRelation="or">
            <ProcessCreate onmatch="include">
                <Image condition="end with">wget</Image>
                <Image condition="end with">curl</Image>
                <Image condition="end with">ftpget</Image>
                <Image condition="end with">tftp</Image>
                <Image condition="end with">lwp-download</Image>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1123" groupRelation="and">
            <ProcessCreate onmatch="include">
                <Image condition="contains">/bin/aplay</Image>
                <CommandLine condition="contains">arecord</CommandLine>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1136.001" groupRelation="or">
            <ProcessCreate onmatch="include">
                <Image condition="end with">useradd</Image>
                <Image condition="end with">adduser</Image>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1485" groupRelation="and">
            <ProcessCreate onmatch="include">
                <Image condition="is">/bin/dd</Image>
                <CommandLine condition="contains all">dd;of=;if=</CommandLine>
                <CommandLine condition="contains any">if=/dev/zero;if=/dev/null</CommandLine>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1505.003" groupRelation="and">
            <ProcessCreate onmatch="include">
                <Image condition="contains any">whoami;ifconfig;/usr/bin/ip;/bin/uname</Image>
                <ParentImage condition="contains any">httpd;lighttpd;nginx;apache2;node;dash</ParentImage>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1543.002" groupRelation="or">
            <ProcessCreate onmatch="include">
                <Image condition="end with">systemd</Image>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1548.001" groupRelation="or">
            <ProcessCreate onmatch="include">
                <Image condition="end with">chmod</Image>
                <Image condition="end with">chown</Image>
                <Image condition="end with">fchmod</Image>
                <Image condition="end with">fchmodat</Image>
                <Image condition="end with">fchown</Image>
                <Image condition="end with">fchownat</Image>
                <Image condition="end with">fremovexattr</Image>
                <Image condition="end with">fsetxattr</Image>
                <Image condition="end with">lchown</Image>
                <Image condition="end with">lremovexattr</Image>
                <Image condition="end with">lsetxattr</Image>
                <Image condition="end with">removexattr</Image>
                <Image condition="end with">setuid</Image>
                <Image condition="end with">setgid</Image>
                <Image condition="end with">setreuid</Image>
                <Image condition="end with">setregid</Image>
            </ProcessCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1037" groupRelation="or">
            <FileCreate onmatch="include">
                <TargetFilename condition="begin with">/etc/init/</TargetFilename>
                <TargetFilename condition="begin with">/etc/init.d/</TargetFilename>
                <TargetFilename condition="begin with">/etc/rc.d/</TargetFilename>
            </FileCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1053.003" groupRelation="or">
            <FileCreate onmatch="include">
                <TargetFilename condition="is">/etc/cron.allow</TargetFilename>
                <TargetFilename condition="is">/etc/cron.deny</TargetFilename>
                <TargetFilename condition="is">/etc/crontab</TargetFilename>
                <TargetFilename condition="begin with">/etc/cron.d/</TargetFilename>
                <TargetFilename condition="begin with">/etc/cron.daily/</TargetFilename>
                <TargetFilename condition="begin with">/etc/cron.hourly/</TargetFilename>
                <TargetFilename condition="begin with">/etc/cron.monthly/</TargetFilename>
                <TargetFilename condition="begin with">/etc/cron.weekly/</TargetFilename>
                <TargetFilename condition="begin with">/var/spool/cron/crontabs/</TargetFilename>
            </FileCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1105" groupRelation="or">
            <FileCreate onmatch="include">
                <Image condition="end with">wget</Image>
                <Image condition="end with">curl</Image>
                <Image condition="end with">ftpget</Image>
                <Image condition="end with">tftp</Image>
                <Image condition="end with">lwp-download</Image>
            </FileCreate>
        </RuleGroup>
        <RuleGroup name="MitreId=T1543.002" groupRelation="or">
            <FileCreate onmatch="include">
                <TargetFilename condition="begin with">/etc/systemd/system</TargetFilename>
                <TargetFilename condition="begin with">/usr/lib/systemd/system</TargetFilename>
                <TargetFilename condition="begin with">/run/systemd/system/</TargetFilename>
                <TargetFilename condition="contains">/systemd/user/</TargetFilename>
            </FileCreate>
        </RuleGroup>
    </EventFiltering>
</Sysmon>

Logs
==3891603== Memcheck, a memory error detector
==3891603== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3891603== Using Valgrind-3.18.0.GIT and LibVEX; rerun with -h for copyright info
==3891603== Command: /opt/sysmon/sysmon -i /opt/sysmon/config.xml -service
==3891603== Parent PID: 3890757
==3891603==
==3891603== Syscall param bpf(attr->expected_attach_type) points to uninitialised byte(s)
==3891603==    at 0x4E8C719: syscall (syscall.S:38)
==3891603==    by 0x48713E6: sys_bpf (bpf.c:75)
==3891603==    by 0x48713E6: sys_bpf_fd (bpf.c:83)
==3891603==    by 0x48713E6: sys_bpf_prog_load (bpf.c:92)
==3891603==    by 0x48764A0: probe_kern_prog_name (libbpf.c:4527)
==3891603==    by 0x4879B7E: kernel_supports (libbpf.c:4910)
==3891603==    by 0x4879B7E: kernel_supports (libbpf.c:4898)
==3891603==    by 0x487BE1C: bpf_object__create_map (libbpf.c:5034)
==3891603==    by 0x4886F25: bpf_object__create_maps (libbpf.c:5296)
==3891603==    by 0x4888202: bpf_object_load (libbpf.c:7738)
==3891603==    by 0x4888202: bpf_object__load (libbpf.c:7787)
==3891603==    by 0x486AB15: ebpfStart (telemetryLoader.c:1319)
==3891603==    by 0x486AB15: ebpfStart (telemetryLoader.c:1256)
==3891603==    by 0x486B2AC: telemetryStart (telemetryLoader.c:1510)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==  Address 0x1ffeffe9c4 is on thread 1's stack
==3891603==  in frame #2, created by probe_kern_prog_name (libbpf.c:4510)
==3891603==
==3891603== Syscall param bpf(attr->prog_ifindex) points to uninitialised byte(s)
==3891603==    at 0x4E8C719: syscall (syscall.S:38)
==3891603==    by 0x48713E6: sys_bpf (bpf.c:75)
==3891603==    by 0x48713E6: sys_bpf_fd (bpf.c:83)
==3891603==    by 0x48713E6: sys_bpf_prog_load (bpf.c:92)
==3891603==    by 0x48764A0: probe_kern_prog_name (libbpf.c:4527)
==3891603==    by 0x4879B7E: kernel_supports (libbpf.c:4910)
==3891603==    by 0x4879B7E: kernel_supports (libbpf.c:4898)
==3891603==    by 0x487BE1C: bpf_object__create_map (libbpf.c:5034)
==3891603==    by 0x4886F25: bpf_object__create_maps (libbpf.c:5296)
==3891603==    by 0x4888202: bpf_object_load (libbpf.c:7738)
==3891603==    by 0x4888202: bpf_object__load (libbpf.c:7787)
==3891603==    by 0x486AB15: ebpfStart (telemetryLoader.c:1319)
==3891603==    by 0x486AB15: ebpfStart (telemetryLoader.c:1256)
==3891603==    by 0x486B2AC: telemetryStart (telemetryLoader.c:1510)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==  Address 0x1ffeffe9c0 is on thread 1's stack
==3891603==  in frame #2, created by probe_kern_prog_name (libbpf.c:4510)
==3891603==
==3891603== Syscall param bpf(attr->value) points to uninitialised byte(s)
==3891603==    at 0x4E8C719: syscall (syscall.S:38)
==3891603==    by 0x4872241: sys_bpf (bpf.c:75)
==3891603==    by 0x4872241: bpf_map_update_elem (bpf.c:394)
==3891603==    by 0x486ABE6: ebpfStart (telemetryLoader.c:1358)
==3891603==    by 0x486ABE6: ebpfStart (telemetryLoader.c:1256)
==3891603==    by 0x486B2AC: telemetryStart (telemetryLoader.c:1510)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==  Address 0x1ffeffee94 is on thread 1's stack
==3891603==  in frame #2, created by ebpfStart (telemetryLoader.c:1267)
==3891603==
==3891603== Syscall param bpf(attr->value) points to uninitialised byte(s)
==3891603==    at 0x4E8C719: syscall (syscall.S:38)
==3891603==    by 0x4872241: sys_bpf (bpf.c:75)
==3891603==    by 0x4872241: bpf_map_update_elem (bpf.c:394)
==3891603==    by 0x486AC15: ebpfStart (telemetryLoader.c:1365)
==3891603==    by 0x486AC15: ebpfStart (telemetryLoader.c:1256)
==3891603==    by 0x486B2AC: telemetryStart (telemetryLoader.c:1510)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==  Address 0x1ffeffee94 is on thread 1's stack
==3891603==  in frame #2, created by ebpfStart (telemetryLoader.c:1267)
==3891603==
--3891603-- WARNING: unhandled eBPF command 28
--3891603-- WARNING: unhandled eBPF command 28
--3891603-- WARNING: unhandled eBPF command 28
==3891603==
==3891603== HEAP SUMMARY:
==3891603==     in use at exit: 700,472,339 bytes in 17,382,631 blocks
==3891603==   total heap usage: 545,916,492 allocs, 528,533,861 frees, 121,240,204,927 bytes allocated
==3891603==
==3891603== 4 bytes in 1 blocks are definitely lost in loss record 4 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x18139D: HashingValidation (parsecommandline.c:324)
==3891603==    by 0x181D57: ParseCommandLine (parsecommandline.c:952)
==3891603==    by 0x172B46: main (sysmonforlinux.c:1226)
==3891603==
==3891603== 16 bytes in 1 blocks are definitely lost in loss record 101 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x4E298E9: strdup (strdup.c:42)
==3891603==    by 0x1844B7: ApplyConfigurationFile (xml.cpp:1485)
==3891603==    by 0x181BC6: ParseCommandLine (parsecommandline.c:868)
==3891603==    by 0x172B46: main (sysmonforlinux.c:1226)
==3891603==
==3891603== 16 bytes in 1 blocks are definitely lost in loss record 102 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x4E298E9: strdup (strdup.c:42)
==3891603==    by 0x1844B7: ApplyConfigurationFile (xml.cpp:1485)
==3891603==    by 0x181BC6: ParseCommandLine (parsecommandline.c:868)
==3891603==    by 0x17565E: setConfigFromStoredArgv (sysmonforlinux.c:1009)
==3891603==    by 0x172E3E: main (sysmonforlinux.c:1429)
==3891603==
==3891603== 4,160 bytes in 121 blocks are possibly lost in loss record 270 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x4E298E9: strdup (strdup.c:42)
==3891603==    by 0x18B9AC: EventResolveField (eventsCommon.cpp:2137)
==3891603==    by 0x18C469: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2441)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 4,536 bytes in 63 blocks are possibly lost in loss record 271 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x1AB34D: CRYPTO_zalloc (in /opt/sysmon/sysmon)
==3891603==    by 0x178095: LinuxGetFileHash (linuxHelpers.cpp:902)
==3891603==    by 0x18BAB1: EventResolveField (eventsCommon.cpp:1739)
==3891603==    by 0x18C469: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2441)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 4,896 bytes in 68 blocks are possibly lost in loss record 272 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x1AB34D: CRYPTO_zalloc (in /opt/sysmon/sysmon)
==3891603==    by 0x178085: LinuxGetFileHash (linuxHelpers.cpp:900)
==3891603==    by 0x18BAB1: EventResolveField (eventsCommon.cpp:1739)
==3891603==    by 0x18C469: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2441)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 5,184 bytes in 72 blocks are possibly lost in loss record 273 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x1AB34D: CRYPTO_zalloc (in /opt/sysmon/sysmon)
==3891603==    by 0x17808D: LinuxGetFileHash (linuxHelpers.cpp:901)
==3891603==    by 0x18BAB1: EventResolveField (eventsCommon.cpp:1739)
==3891603==    by 0x18C469: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2441)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 20,726 bytes in 68 blocks are possibly lost in loss record 278 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x18A3E4: ProcessCache::ProcessAdd(GUID, SYSMON_EVENT_HEADER*) (eventsCommon.cpp:366)
==3891603==    by 0x18AA71: GenerateUniquePGUID(GUID*, SYSMON_EVENT_HEADER*, bool) (eventsCommon.cpp:499)
==3891603==    by 0x18C1DC: EventResolveField (eventsCommon.cpp:1888)
==3891603==    by 0x18CA23: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2363)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 36,816 bytes in 944 blocks are possibly lost in loss record 279 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x4E298E9: strdup (strdup.c:42)
==3891603==    by 0x18B9AC: EventResolveField (eventsCommon.cpp:2137)
==3891603==    by 0x18CA44: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2371)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 37,011 bytes in 949 blocks are possibly lost in loss record 280 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x4E298E9: strdup (strdup.c:42)
==3891603==    by 0x18B9AC: EventResolveField (eventsCommon.cpp:2137)
==3891603==    by 0x18CA65: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2379)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 38,688 bytes in 992 blocks are possibly lost in loss record 281 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x4E298E9: strdup (strdup.c:42)
==3891603==    by 0x18B9AC: EventResolveField (eventsCommon.cpp:2137)
==3891603==    by 0x18CA23: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2363)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 844,498 bytes in 3,453 blocks are definitely lost in loss record 283 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x18A3E4: ProcessCache::ProcessAdd(GUID, SYSMON_EVENT_HEADER*) (eventsCommon.cpp:366)
==3891603==    by 0x18AA71: GenerateUniquePGUID(GUID*, SYSMON_EVENT_HEADER*, bool) (eventsCommon.cpp:499)
==3891603==    by 0x18C1DC: EventResolveField (eventsCommon.cpp:1888)
==3891603==    by 0x18C469: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2441)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 12,934,204 (12,933,720 direct, 484 indirect) bytes in 179,635 blocks are definitely lost in loss record 284 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x1AB34D: CRYPTO_zalloc (in /opt/sysmon/sysmon)
==3891603==    by 0x17808D: LinuxGetFileHash (linuxHelpers.cpp:901)
==3891603==    by 0x18BAB1: EventResolveField (eventsCommon.cpp:1739)
==3891603==    by 0x18C469: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2441)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 12,935,041 (12,934,512 direct, 529 indirect) bytes in 179,646 blocks are definitely lost in loss record 285 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x1AB34D: CRYPTO_zalloc (in /opt/sysmon/sysmon)
==3891603==    by 0x178095: LinuxGetFileHash (linuxHelpers.cpp:902)
==3891603==    by 0x18BAB1: EventResolveField (eventsCommon.cpp:1739)
==3891603==    by 0x18C469: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2441)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 12,935,161 (12,934,152 direct, 1,009 indirect) bytes in 179,641 blocks are definitely lost in loss record 286 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x1AB34D: CRYPTO_zalloc (in /opt/sysmon/sysmon)
==3891603==    by 0x178085: LinuxGetFileHash (linuxHelpers.cpp:900)
==3891603==    by 0x18BAB1: EventResolveField (eventsCommon.cpp:1739)
==3891603==    by 0x18C469: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2441)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 26,166,422 bytes in 1,257,826 blocks are definitely lost in loss record 287 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x4E298E9: strdup (strdup.c:42)
==3891603==    by 0x18B9AC: EventResolveField (eventsCommon.cpp:2137)
==3891603==    by 0x18C469: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2441)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 31,422,094 bytes in 117,275 blocks are definitely lost in loss record 288 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x18A3E4: ProcessCache::ProcessAdd(GUID, SYSMON_EVENT_HEADER*) (eventsCommon.cpp:366)
==3891603==    by 0x18AA71: GenerateUniquePGUID(GUID*, SYSMON_EVENT_HEADER*, bool) (eventsCommon.cpp:499)
==3891603==    by 0x18C1DC: EventResolveField (eventsCommon.cpp:1888)
==3891603==    by 0x18CA23: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2363)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 200,989,035 bytes in 5,153,565 blocks are definitely lost in loss record 289 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x4E298E9: strdup (strdup.c:42)
==3891603==    by 0x18B9AC: EventResolveField (eventsCommon.cpp:2137)
==3891603==    by 0x18CA23: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2363)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 200,991,063 bytes in 5,153,617 blocks are definitely lost in loss record 290 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x4E298E9: strdup (strdup.c:42)
==3891603==    by 0x18B9AC: EventResolveField (eventsCommon.cpp:2137)
==3891603==    by 0x18CA44: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2371)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== 200,991,063 bytes in 5,153,617 blocks are definitely lost in loss record 291 of 291
==3891603==    at 0x484079B: malloc (vg_replace_malloc.c:381)
==3891603==    by 0x4E298E9: strdup (strdup.c:42)
==3891603==    by 0x18B9AC: EventResolveField (eventsCommon.cpp:2137)
==3891603==    by 0x18CA65: EventProcess(SYSMON_EVENT_TYPE_FMT*, SYSMON_DATA_DESCRIPTOR*, SYSMON_EVENT_HEADER*, unsigned long*) (eventsCommon.cpp:2379)
==3891603==    by 0x18D5C3: DispatchEvent (eventsCommon.cpp:2900)
==3891603==    by 0x174D3F: processProcessCreate (sysmonforlinux.c:616)
==3891603==    by 0x48786B0: perf_buffer__process_record (libbpf.c:11925)
==3891603==    by 0x4878803: perf_event_read_simple.constprop.0 (libbpf.c:11553)
==3891603==    by 0x4886631: perf_buffer__process_records (libbpf.c:11947)
==3891603==    by 0x4886631: perf_buffer__poll (libbpf.c:11972)
==3891603==    by 0x486B359: telemetryStart (telemetryLoader.c:1526)
==3891603==    by 0x173768: main (sysmonforlinux.c:1668)
==3891603==
==3891603== LEAK SUMMARY:
==3891603==    definitely lost: 700,206,595 bytes in 17,378,278 blocks
==3891603==    indirectly lost: 2,022 bytes in 24 blocks
==3891603==      possibly lost: 152,017 bytes in 3,277 blocks
==3891603==    still reachable: 109,689 bytes in 1,031 blocks
==3891603==         suppressed: 0 bytes in 0 blocks
==3891603== Reachable blocks (those to which a pointer was found) are not shown.
==3891603== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3891603==
==3891603== Use --track-origins=yes to see where uninitialised values come from
==3891603== For lists of detected and suppressed errors, rerun with: -s
==3891603== ERROR SUMMARY: 26 errors from 25 contexts (suppressed: 0 from 0)

Expected behavior
The main issues seem to be lack of freeing the intermediary duplicates of tmpStringBuffer e.g. in https://github.com/Sysinternals/SysmonCommon/blob/c1a02f4c73c81b591272ce927d8cf83f6edadf1b/eventsCommon.cpp#L2137, where the duplicate created by _tcsdup is not freed after being duplicated again in EventDataDescCreate (https://github.com/Sysinternals/SysmonForLinux/blob/<IP_ADDRESS>/linuxHelpers.cpp#L719). Additionally, the hash contexts created in LinuxGetFileHash are never destroyed.

Hi @elmeyer - Sorry for the delayed response and thanks for the detailed issue report. I've tagged this is a bug and we'll work on fixed for these.

Thanks for the +1. We're working on some other issues at the moment, but we will make sure to circle back to this backlog item soon.

Hi, I would also like to add us to this problem..
We are running Sysmon version 1.3.3 on Red Hat Enterprise Linux 8.10 (Ootpa)
We experience that the memory in the system is slowly being eaten up to a point that the monitoring is alerting about high swap utilization.
Sysmon consumes 7 of 8Gb swap and 1 of 3Gb RAM.
A restart of the sysmon service solves the problem in the short term, after the restart sysmon is slowly consuming more and more RAM.

Hi - Thanks for following up on this! We are working on some other priority issues at the moment, but we haven't forgotten about this. Once we’ve made progress on our current priorities, we’ll revisit this issue and provide an update. In the meantime, feel free to share any additional details or context. Your input is much appreciated.

Hi @MarioHewardt , just a warm follow up on this. May I have your update on the fix of this bug? any ETA on that ? Thanks!


numpy.std function not returning the correct results

In my process to create a function that calculates the correlation between two time-series I come across this error. The following code demonstrates the result that I have.
I am using windows 10 with python 3.8.8 and numba 0.56.4
import numpy as np
from numba import jit

@jit
def error_test(a,b):

    sdb = np.std(b)
    sda = np.std(a)

    return sda,sdb

error_test(np.array([0.2,0.1]),np.array([0.3,0.2]))

The sda and sdb are supposed to be equal to 0.05 but the output I get is
(0.05, 0.0)
I was originally using @jit(no_python = True) but the result was the same. Also, if I remove '@jit`, the result is correct:
(0.05, 0.04999999999999999)
EDIT: Upgrading to python 3.11.4 using anaconda installer has resolved the issue for now.

Hi @GeorgePapanik, I cannot reproduce this error locally.
$ cat repro.py
import numpy as np
from numba import njit

@njit
def error_test(a,b):
    sdb = np.std(b)
    sda = np.std(a)
    return sda, sdb

a = np.array([0.2, 0.1])
b = np.array([0.3, 0.2])
print(error_test(a, b))
print(error_test.py_func(a, b))

$ python d.py
(0.05, 0.04999999999999999)
(0.05, 0.04999999999999999)

EDIT: Upgrading to python 3.11.4 using anaconda installer has resolved the issue for now.

Glad to hear that. I'll close this issue for now. Feel free to post an update if this issue happens again.


Add rules_ios 3.0.0

@fmeum thanks for the help here! Im going to go the route of creating a new tag, but first fixing up the presubmit.yml let me know if this works: https://github.com/bazel-ios/rules_ios/pull/787
We dont ship the tests, only the rule sources in our release archive.


add validate export sink in tcld

What was changed

Why?

Checklist

Closes

How was this tested:

Any docs updates needed?

This looks good to me. Just curious, is there a way to enforce the customer to apply the policy document or cloudformation stack run when using tcld?

I haven't looked at in tcld about the cloudformation stack. In the user's doc, we ask user to set up role manually beforehand.


Fix/coin link

Currently, some links couldn't be open correctly on one (or both) Coingecko, Coinmarketcap websites:

Doge, Buff Doge Coin: the problem is about converting name to ID, also related to the old issue because the name of Doge (name: Dogecoin) is similar to the symbol of the Buff Doge Coin (symbol: DOGECOIN).
Travala.com: coingecko supports travala/travala.com slug but the CoinLink method is using a regex to replace non Alpha numeric chars to dash. So the original name is "Travala.com" and the converted name is "travala-com" -> unable to use.
https://github.com/cointop-sh/cointop/blob/8b8db3bd13c366a9657434af71b61400e6b01ad9/pkg/api/util/util.go#L12-L15
shouldn't change the regex because it will impact to yearn.finance coin (it only works with "yearn-finance" slug on Coingecko).

Seems both Coingecko and Coinmarketcap supported slug, please see the below. This PR is about switching to use slug instead of name.
Coingecko supports id
{
    "id": "concierge-io",
    "symbol": "ava",
    "name": "Travala.com",
    "image": "https://assets.coingecko.com/coins/images/3014/large/Travala.png?1558020611",
    "current_price": 2.77,
    "market_cap": 147501823,
    "market_cap_rank": 411,
    "fully_diluted_valuation": null,
    "total_volume": 7569293,
    "high_24h": 2.8,
    "low_24h": 2.71,
    "price_change_24h": 0.01135146,
    "price_change_percentage_24h": 0.41202,
    "market_cap_change_24h": 9243.35,
    "market_cap_change_percentage_24h": 0.00627,
    "circulating_supply": 53373082,
    "total_supply": 61383832,
    "max_supply": null,
    "ath": 6.45,
    "ath_change_percentage": -57.11379,
    "ath_date": "2021-04-14T07:24:28.788Z",
    "atl": 0.01218947,
    "atl_change_percentage": 22576.29765,
    "atl_date": "2019-02-27T00:00:00.000Z",
    "roi": {
        "times": 6.9040071307770114,
        "currency": "usd",
        "percentage":<PHONE_NUMBER>777012
    },
    "last_updated": "2021-11-13T12:54:15.485Z"
}

it is equivalent to API id on the UI

Coinmarketcap supports slug
{
    "id": 1,
    "name": "Bitcoin",
    "symbol": "BTC",
    "slug": "bitcoin",
    "cmc_rank": 5,
    "num_market_pairs": 500,
    "circulating_supply": 16950100,
    "total_supply": 16950100,
    "max_supply": 21000000,
    "last_updated": "2018-06-02T22:51:28.209Z",
    "date_added": "2013-04-28T00:00:00.000Z",
    "tags": [
        "mineable"
    ],
    "platform": null,
    "quote": {
        "USD": {
            "price": 9283.92,
            "volume_24h":<PHONE_NUMBER>,
            "volume_change_24h": -0.152774,
            "percent_change_1h": -0.152774,
            "percent_change_24h": 0.518894,
            "percent_change_7d": 0.986573,
            "market_cap":<PHONE_NUMBER>50.2758,
            "market_cap_dominance": 51,
            "fully_diluted_market_cap":<PHONE_NUMBER>31.14,
            "last_updated": "2018-08-09T22:53:32.000Z"
        },
        "BTC": {
            "price": 1,
            "volume_24h": 772012,
            "volume_change_24h": 0,
            "percent_change_1h": 0,
            "percent_change_24h": 0,
            "percent_change_7d": 0,
            "market_cap": 17024600,
            "market_cap_dominance": 12,
            "fully_diluted_market_cap":<PHONE_NUMBER>31.14,
            "last_updated": "2018-08-09T22:53:32.000Z"
        }
    }
}

I didn't even know about this openlink functionality! (though miguel referred to it, when we were talking about right-mouse buttons once).
Rather than adding slug to Coin, couldn't we pass the whole Coin to the api method, and let it use whatever it wants?

I think keep it as string is good enough, can consider to pass the pointer when we need more than current. Actually, my first thought is passing the pointer of Coin to try with ID/name by some ways, before I have the slug.

Rather than adding slug to Coin, couldn't we pass the whole Coin to the api method, and let it use whatever it wants?

Sorry, which api method?

I was suggesting that the interface method could be
CoinLink(coin Coin) string
Then the implementations could use whichever attribute of Coin they felt like.  Plus this would support (future) situations where it might need more than one attribute.

I was suggesting that the interface method could be
CoinLink(coin Coin) string
Then the implementations could use whichever attribute(s) of Coin they felt like, and not have to pre-emptively squash it into a string called Slug.
coingecko.go: func (s *Service) CoinLink(coin Coin) string { return fmt.Sprintf("https://www.coingecko.com/en/coins/%s", coin.ID) }
coinmarketcap.go: func (s *Service) CoinLink(coin Coin) string { return fmt.Sprintf("https://www.coingecko.com/en/coins/%s", coin.ID) // ID? slug? }
(cmc currently uses v.Name for coin.ID which seems possibly wrong?)

Understood your point now. Actually, I came with it previously, but I have changed to the string for a simple & enough type as current. If we need more than 1 parameter for CoinLink, can switch to use the whole Coin pointer later, for now I think that's fine to keep as string. In anyway, we still have to store Slug value for at least Coinmarketcap, so I think a separated field is better than reuse ID field of Coin struct.

(cmc currently uses v.Name for coin.ID which seems possibly wrong?)
I don't have a conclusion because Coingecko and Coinmarketcap has different type for id field, so may be Coin struct can be free to define its own ID, as long as it still works well. I mean it could be change if we found the limitation.

(cmc currently uses v.Name for coin.ID which seems possibly wrong?)

I don't have a conclusion because Coingecko and Coinmarketcap has different type for id field, so may be Coin struct can be free to define its own ID, as long as it still works well. I mean it could be change if we found the limitation.

This just looks wrong to me:
		ret = append(ret, apitypes.Coin{
			ID:               util.FormatID(v.Name),
			Name:             util.FormatName(v.Name),
...

Especially when v.Name is not guaranteed to be unique?

I agree. I think this PR is tiny PR for just open link problem. The ID, I worry it relates to so many flows to be fixing. I created another issue for it https://github.com/cointop-sh/cointop/issues/279

needs a cache clear in order to work (structure of Coin changed). Can you think of a way we can detect that situation?  (I think value is blank)
on CMC the URL is https://coinmarketcap.com/currencies/xxx which immediately redirects to https://coinmarketcap.com/currencies/xxx/ (trailing slash).  Let's include the trailing slash in the url, to save the redirect, which will make it a little faster

FWIW on Coingecko it opens https://www.coingecko.com/en/coins/concierge-io which redirects to https://www.coingecko.com/en/coins/travala but I don't think we can do any better there


Readme.md update required.

This URL shortener is written in django. So to execute it on local server a few steps are needed. How to clone, install dependencies, virtual environment install, commands in terminal (preferably Ubuntu or Fedora). Commands in other distros are welcome too!

How about containerized it via Docker? That way, you can run it on most of the machines.

If you are able to do that then you are welcome to do so.
See the thing is i don't have much idea about the docker and now since you have mentioned about it i will look into the details about it. This was just a free time web app i had made so i didn't go into much details about production.
I would first of all recommend you to run the app and find a few bugs and if possible correct them and let me know. Then you can proceed to containerize it.
Will that be okay?
And i will be glad if you are able to do what you have asked. I will also get to learn a few things. :)


feat: Added price feeds for Star Atlas tokens POLIS and ATLAS

Redo for https://github.com/FlipsideCrypto/sql_models/pull/637
So I saw the July 20 cutoff for legacy data, which I suppose means that we won't have data for these tokens beyond that date?

@dahifi - We should still have data for those tokens beyond that date, just uses a different data source location.  We will take a look at this and get back to you if any questions or issues.  Otherwise look for this to be merged next week, thanks!

Looks like these tokens were added as part of an update Jessica did earlier today. Awaiting update in production data ... later?


adding clower deployment spec

PR Template:
Describe your changes
Deploy insights-rebac as clowder app.
Add documentation to jira

...

Ticket reference (if applicable)
Fixes #
Checklist

[ ] Are the agreed upon acceptance criteria fulfilled?

[ ] Was the 4-eye-principle applied? (async PR review, pairing, ensembling)

[ ] Do your changes have passing automated tests and sufficient observability?

[ ] Are the work steps you introduced repeatable by others, either through automation or documentation?

[ ] If automation is possible but not done due to other constraints, a ticket to the tech debt sprint is added
[ ] An SOP (Standard Operating Procedure) was created

[ ] The Changes were automatically built, tested, and  - if needed, behind a feature flag - deployed to our production environment. (Please check this when the new deployment is done and you could verify it.)

[ ] Are the agreed upon coding/architectural practices applied?

[ ] Are security needs fullfilled? (e.g. no internal URL)

[ ] Is the corresponding Ticket in the right state? (should be on "review" now, put to done when this change made it to production)

[ ] For changes to the public API / code dependencies: Was the whole team (or a sufficient amount of ppl) able to review?

Verified that the deployment spec works in the target env. LGTM


Usage with davezuko's starter kit

I'm trying to create a universal React Redux project based on some of the fundamentals of davezuko's starter kit. Found your stuff but it seems to be very unclear how to achieve it so I'm turning to you here for some instructions with the configuration.
I also opened a question here
Thanks in advance!

it seems to be very unclear how to achieve it

Everything becomes clear after you learn things

Thanks, I'm trying. But can't do everything at once.

In the documentation there is the following - which I want to avoid having some generated stuff like build/server/server.js - It'd be nice to have it on the fly like the Webpack-dev-server does

Then use another library

But can't do everything at once.

You're not supposed to

Then use another library
Your library look decent to me so that I've chosen it. Are you saying it is not possible to achieve what I want with it? - thats also a solution.

This library requires compiling server-side code into a file on disk.
If you are looking for a way to avoid that then that would be another library.

I see, thanks.

You may have a look at webpack-isomorphic-tools
https://github.com/halt-hammerzeit/webpack-isomorphic-tools
It doesn't compile it to a file on disk, but it does create a webpack-assets.json file on disk.


Two 4.1.0 Releases?

Looking through the releases I noticed there are two 4.1.0 releases on different commits

https://github.com/UW-Madison-DoIT/uw-frame/releases/tag/v4.1.0
https://github.com/UW-Madison-DoIT/uw-frame/releases/tag/uw-frame-maven-4.1.0

Is that intended?

Looks like the former was promoted from mere tag to release in error. Deleted that release, demoting it to just a tag.

Follow up question looking through tags, there appears to be a consistent pattern of tagging both:
uw-frame-maven-{semver-version-number}
and
v{semver-version-number}
Is that also intended?

Two release tags is result of releasing each release twice, once to npm and once to Maven OSS Central. Someday we'll mature to uw-frame not being a Java artifact and no longer adopting it in frame-based apps via Maven Overlay.

Thanks @apetro!


macOS: global hotkey stopped working

macOS global hotkeys access (my global binding) broke in Version: a36bdd97 Build: 7613 and I can't get it back (restarted a few time, it's not asking for permissions) - tried to add it by hand too and that's not helping - this is on 14.7 (23H124) and it worked before the update or at least ~2 days ago
my config:
theme=Dark+
window-save-state = always
shell-integration = bash
shell-integration-features= no-cursor,sudo
keybind = global:ctrl+escape=toggle_quick_terminal
# keybind = global:function+escape=toggle_quick_terminal

I have the same issue:
GhosTTY version: 1.0.0
MacOS version: 15.2 (M1 Pro)
I've enabled GhosTTY to monitor keyboard input even when other applications are on top.
It currently only works when I have a GhosTTY window in focus.


The output of state export is not consistent in "previous_state_hash" and "previous_height"

The generated fork state contains for the following field:
    "fork": {
      "previous_state_hash": "3NLiejEBoNuXjgC59Jt8PUvvqNbPxgNFZBU4a9ZgrpNzzdXPYPbb",
      "previous_length": 368,
      "previous_global_slot": 2326
    }

The length and global_slot of "previous_state_hash" is different from what we have here.
It turns out that the "previous_length" and "previous_global_slot" corresponds to next block's length and global_slot.

@ghost-not-in-the-shell I think this is due to incorrect state being forked off of. Is the new one as expected:
   "fork": {
      "previous_state_hash": "3NLKED8SDWLEa6aEZXvJ52EuZoUrhB3Hj9jTUpmjHuP6yes2PcWY",
      "previous_length": 366,
      "previous_global_slot": 2319

No, the previous_state_hash is still from the previous block

So state hash is from previous block but rest is from block at slot 2319. @Sventimir was this the expectation?

Remove previous from all the fields and have the following -
  "fork": {
      "state_hash": "3NLiejEBoNuXjgC59Jt8PUvvqNbPxgNFZBU4a9ZgrpNzzdXPYPbb",
      "blockchain_length": 368,
      "global_slot_since_genesis": 2326
    }

@deepthiskumar so the new semantics is that state_hash is the state hash to evolve from, but blockchain_lengthand global_slot_since_genesis specify the exact parameters for the fork, not to be incremented?

Remove previous from all the fields and have the following -

This is at odds with the change you asked for here. The global slot really is the previous_global_slot_since_genesis, and making this change is actively harmful.

Fixed by https://github.com/MinaProtocol/mina/issues/15070 and https://github.com/MinaProtocol/mina/pull/15109.


Fix simulator, android debug builds.

@jmgao Thanks so much for the contribution! I've been able to replicate the segfault locally using non NVIDIA hardware and confirmed that your fix has resolved the issue.
I haven't been able to test the Android fix but this seems like a fairly straightforward change.

This has been superseded by #183 due to a minor clippy fix.


arcticdb 1.4.1 release

Checklist

[ / ] Used a personal fork of the feedstock to propose changes
[ / ] Reset the build number to 0 (if the version changed)

@conda-forge-admin please rerender

Declining this in favour of the auto-generated one https://github.com/conda-forge/arcticdb-feedstock/pull/15


Rotate a single credential

As a user I want to be able to rotate a single credential by name without specifying an expires_within time

I believe this could be closed.. the solution has always been --name=/name/of/cert
./carousel rotate --name="/deployment-prod-bosh/deployment-prod-cf/some_cert_ca"


Genotype pca

Alright attempt at densifying + genotype PCs using Hail Query for TOB + BioHEART here

Closing this PR as this was resolved by running the large cohort pipeline
Slack message: https://centrepopgen.slack.com/archives/C018KFBCR1C/p1708467427589119?thread_ts=1708039709.702859&cid=C018KFBCR1C


Test Issue created at Thu, 03 Jun 2021 10:17:31 GMT

Test issue body  Thu, 03 Jun 2021 10:17:31 GMT

Comment on issue at Thu, 03 Jun 2021 10:17:32 GMT


universal-lock: use resolution of a fork as input preferences to its child forks

@konstin brought this up as both a potential performance optimization and a more solid guarantee that resolutions between forks settle on consistent versions.
At present, the forks in the universal resolver are completely independent. When a fork happens, one of them is run to completion and then the other is solved only after the first is finished. When all forks have finished, the resolutions output from each are merged into one.
But we could make it so that once a fork finishes, its resolution is used as an input to all forks it created. This should help with ensuring we pick the same version of packages across forks whenever possible.
I don't have a good sense of how common an issue this is in practice. I also don't have a test case yet.

Makes sense.

As an example, i'm looking at transformers (https://github.com/konstin/transformers, 133e706e57e57776e4338eeab3c52c4400b3d947, pyproject.toml: https://gist.github.com/konstin/9a12dd0f8280e30746d22f3cc7949331). We have two forks (on opencv-python over numpy), but their resolution is the same since opencv-python has different minimal lower versions of numpy, but we're picking a more recent version anyway. Timinig wise, we spend:

Pre-fork 33ms
Split 1 57ms
Split 2 39ms
We could skip most or all of the split 2 work by reusing the solution in the first fork.

Now transformers is an even more special case: We could infer that the solution we have fulfills all branches of opencv-python equally, so we can short-cut exit (the solution is compatible with the sibling too). So:

In the general case, we should use the first sibling as preference for all others (and make sure the sibling order is arbitrary, but stable)
In the specific case of non-disjoint requirements with conflicting markers, we may even infer that the solution we have fulfills all branches of the fork and skip the sibling fork since the current solution fulfills the sibling too (like the numpy version that fulfills opencv-python in both cases)

Is it possible that once we do the first thing (preferences), the timing required to solve the second split goes to ~zero? Since it's all in-memory?

Possibly! We'll have to implement it and benchmark, i agree we should start with preferences

@konstin - do you want to try https://github.com/astral-sh/uv/pull/4662 on your example?

Nice work!
Benchmark 1: ~/projects/uv/uv-main lock
  Time (mean ± σ):     202.3 ms ±   3.5 ms    [User: 178.9 ms, System: 112.7 ms]
  Range (min … max):   198.3 ms … 210.4 ms    15 runs

Benchmark 2: ~/projects/uv/uv-branch lock
  Time (mean ± σ):     111.0 ms ±   3.3 ms    [User: 126.0 ms, System: 105.4 ms]
  Range (min … max):   106.9 ms … 123.0 ms    26 runs

Summary
  ~/projects/uv/uv-branch lock ran
    1.82 ± 0.06 times faster than ~/projects/uv/uv-main lock

main:
DEBUG Pre-fork split universal took 0.028s
DEBUG Split python_version >= '3.12' and platform_machine == 'aarch64' and platform_system == 'Darwin' and platform_system == 'Linux' took 0.044s
DEBUG Split python_version == '3.9' and platform_machine == 'arm64' and platform_system == 'Darwin' took 0.034s

branch:
DEBUG Pre-fork split universal took 0.029s
DEBUG Split python_version >= '3.12' and platform_machine == 'aarch64' and platform_system == 'Darwin' and platform_system == 'Linux' took 0.044s
DEBUG Split python_version == '3.9' and platform_machine == 'arm64' and platform_system == 'Darwin' took 0.004s

Sweet, thanks


Add mops package manager

Wow, this is surprising. I'll take care of that, but I'm working on a general overhaul anyways. Stay tuned.


Add vaccination status to data

subject.vaccinated_covid19_dates (list)
subject.vaccinated_covid19 (boolean)

Do not include data from followup as it is noisy

Is the requirement to add information on the number of vaccine shots - quantity? or boolean yes/no if someone had/had not received vaccine(s) at the time of data collection?

add to schemas and guide ..
only at admission

Added in #197


One domain backed by multiple hidden service

IMHO, TXT record can provide multiple addresses of hidden services. Entry proxy selects an address with round-robin. Adding new instances to a site would not require changes on existing instances.
(I know about https://github.com/DonnchaC/onionbalance but in case of oniongateway it is more reliable and convinient just to have multiple hidden services for balancing.)

I am implementing entry proxy (still a draft!). I see that my proposal about multiple hidden service addresses is not ideal, because an entry proxy would have to memorize which addresses are alive.

Great! Thanks for getting started on this.
I think providing multiple onion addresses in the TXT record is a nice idea for load balancing at an early stage. However as you pointed out the onion service will need to update DNS TXT records as addresses become unavailable.
I think another provider will normally be managing the DNS. The onion service should probably not need to regularly interact with that layer.


💄 Label "Beta API key" as "API key"

The current API key should now be labeled as "legacy".

https://github.com/laminlabs/lamindb/pull/2054
https://github.com/laminlabs/lamin-cli/pull/92
https://github.com/laminlabs/lamindb-setup/pull/886


Issue367 samples templates

[ ] closes #xxxx
[ ] tests added / passed
[ ] passes nox -s blacken lint

Redundant with https://github.com/googleapis/python-bigquery-pandas/pull/380


Generic hybrid covariance

Description
Companion PR of https://github.com/JCSDA-internal/oops/pull/996, updating the yaml files for hybrid background error covariance.
Issue(s) addressed
None.
Dependencies
Should be merged together with:

https://github.com/JCSDA-internal/oops/pull/996
https://github.com/JCSDA-internal/saber/pull/44

Impact
None.

OOPS & SABER PR merged, you can merge this one!

OOPS & SABER PR merged, you can merge this one!


Fix docker-push.sh execution

Why this commit exists:
"build and push master" buildkite steps are failing, due to both:

their images not having unzip available
protoc failing to run on alpine after adding unzip, e.g. /bin/sh: .build/bin/protoc: not found

This fixes that by 1) adding unzip, and 2) not executing thrift/proto codegen during those release builds (and in other locations).

Lots more details:
Protoc is apparently incompatible with alpine images, it has something to do with musl and (g?)libc incompatibilities.
In the alpine images, sh complains .build/bin/protoc: not found, but after some more digging you can see ldd has more info:
ldd .build/bin/protoc
	/lib64/ld-linux-x86-64.so.2 (0x7f9b1f366000)
	libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f9b1f366000)
	libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f9b1f366000)
	libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f9b1f366000)
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by .build/bin/protoc)
Error relocating .build/bin/protoc: __strftime_l: symbol not found

After a bit of experimenting, it seems that the semi-common tricks of "install libc6-compat or gcompat" do not work for protoc.
I'm not really sure why.
So our options are basically one of:

Abandon alpine for this build section.  It just builds binaries that are copied to the next step, so it won't affect the final image size anyway.  (this builds successfully, but I have not checked the resulting binaries)
Keep alpine, build protoc from source, hope it compiles successfully against musl
Keep alpine, but don't do codegen in this build (this works)

Option 3 seemed worth trying in depth.  After some toying around and (as usual) learning something new about Make, I found this tactic.
It appears to be well-supported and consistent, so I'm OK with using it, though it's rather strange at first glance.
Binaries are still downloaded/built during release builds with this approach, but that seems like a relatively low-risk / low-cost consequence.
This all also means that devs will download and build these tools as part of a normal make bins, but similarly will not run codegen unless needed.
Since that kinda helps "prime" the dev environment, that seems totally fine / possibly even a good thing.  Codegen should still run when necessary though.

Coverage increased (+0.04%) to 61.683% when pulling 1f8468324ba7456e6fd20eb29f12a612679b4732 on fix_release into 710cd618b6ca290204d115a2e94bb6f938f9ff23 on master.

Coverage increased (+0.04%) to 61.683% when pulling 1f8468324ba7456e6fd20eb29f12a612679b4732 on fix_release into 710cd618b6ca290204d115a2e94bb6f938f9ff23 on master.


[CELEBORN-1663] Only register appShuffleDeterminate if stage using celeborn for shuffle

What changes were proposed in this pull request?
Only register appShuffleDeterminate if stage using celeborn for shuffle
Why are the changes needed?
Currently we are passing stage info to lifecyclemanager, eventhough it is not required.
Does this PR introduce any user-facing change?
NA
How was this patch tested?
Existing UTs

Thanks, but also should modify spark-2 @s0nskar

Thanks @zaynt4606 @RexXiong for the review. Raised the followup PR for spark 2 - https://github.com/apache/celeborn/pull/2837


-R | --retention N does not work in my case or...

Hello,
We are using following script for generate pgbadger reports:
#!/bin/bash
date=`date +%F`
hour=`date +%H`
servers="131 132 133 134"

#copy all logs for full day if script was run at 23:59
if [ "$hour" -eq "23" ]
   then
   sleep 3m
fi

#copy postgres logs to our server
for i in $servers
   do
   rsync --inplace --no-whole-file root@192.168.0."$i":/var/log/postgresql/postgresql-"$date".log /mnt/pgbadger/"$i"_logs/
done

for i in $servers
   do
   #if first start in day (at 12am), run pgbadger without -l option
   if [ "$hour" -eq "12" ]
      then
      /mnt/pgbadger/pgbadger/pgbadger --exclude-query="^(COPY|VACUUM)" -H /mnt/pgbadger/"$i"_reports -O /mnt/pgbadger/"$i"_bin -I -j 8  -p '%m %p %u@%d from %h [vxid:%v txid:%x] [%i]' -R 4  /mnt/pgbadger/"$i"_logs/postgresql-"$date".log
   else
      /mnt/pgbadger/pgbadger/pgbadger --exclude-query="^(COPY|VACUUM)" -H /mnt/pgbadger/"$i"_reports -O /mnt/pgbadger/"$i"_bin -I -j 8  -p '%m %p %u@%d from %h [vxid:%v txid:%x] [%i]' -R 4 -l /mnt/pgbadger/"$i"_logs/postgresql-"$date".log  /mnt/pgbadger/"$i"_logs/postgresql-"$date".log
   fi
   #remove unnecessary logs if run last
   if [ "$hour" -eq "23" ]
      then
      rm /mnt/pgbadger/"$i"_logs/postgresql-"$date".log
   fi

And this script runs automatically via cron:
01 12 * * * /mnt/pgbadger/run_pgbadger.sh
02 19 * * * /mnt/pgbadger/run_pgbadger.sh
58 23 * * * /mnt/pgbadger/run_pgbadger.sh

But we have reports since January... Could you please help to understand why old reports (older than 4 weeks) were not remove?
https://imgur.com/a/mnrNh5b

I found another issue:
DEBUG: Starting reading file "/tmp/master/postgresql-Fri.log"...
DEBUG: Start parsing postgresql log at offset 2352987 of file "/tmp/master/postgresql-Fri.log" to 38240609
DEBUG: Saving last parsed line into /tmp/tmp_LAST_PARSED (33965 38241713)queries: 0, events: 0
DEBUG: Received interrupt signaled   2354272 bytes of 147133965 (1.60%), queries: 0, events: 0
DEBUG: Saving last parsed line into /tmp/tmp_LAST_PARSED (	2353168)
DEBUG: Received interrupt signal

I think that pgbadger dead before deleting any files...

Yes, maybe an OOM Killer interruption.

no OOM-killer. We have installed Antivirus on production system (Kaspersky). Our customer should  follow to security rules and install antivirus on all systems. Sometimes Antivirus works very strange and can kill some processes.
We will try to temporary disable AV and rerun pgbadger.

Oh, when the Windows world invites itself into the Linux world :-)

You will be laugh, but it is a Linux system... Yes, some customers must install antivirus on all systems, even on Linux.