dxwrapper : unhandled exception filter, what does this mean?

I tried running dxwrapper with a game called "birthright : gorgon's alliance", using the ddraw.dll file.
At one point, the game gave me exception errors (this happens without dxwrapper as well). With dxwrapper however, the game didnt just crash, i was able to keep playing for a bit more time, but the graphics of all the characters became corrupted :

After playing for a while more, the game kept giving me exception errors, after the 3rd time, the game started freezing up every few seconds and it became impossible to play.
My question is, does the dxwrapper log file include any useful information on the exception error? Will any other config settings help?
dxwrapper-winbr.log
I have attached the log file. The interesting part is this :
12584 23:33:37.163 UnhandledExceptionFilter: exception code=3221225477 flags=0 addr=0044DA53 12584 23:33:37.196 UnhandledExceptionFilter: NOP opcode=・len=2 12584 23:33:37.790 UnhandledExceptionFilter: exception code=3221225477 flags=0 addr=0044DA59 12584 23:33:37.790 UnhandledExceptionFilter: NOP opcode=f len=4 12584 23:38:45.560 UnhandledExceptionFilter: exception code=3221225477 flags=0 addr=0044DCA6 12584 23:38:45.560 UnhandledExceptionFilter: NOP opcode=f len=4 12584 23:38:46.057 UnhandledExceptionFilter: exception code=3221225477 flags=0 addr=0044DC88 12584 23:38:46.057 UnhandledExceptionFilter: NOP opcode=・len=2 12584 23:38:46.483 UnhandledExceptionFilter: exception code=3221225477 flags=0 addr=0044DC8F 12584 23:38:46.483 UnhandledExceptionFilter: NOP opcode=・len=2 12584 23:38:50.477 UnhandledExceptionFilter: exception code=3221225477 flags=0 addr=0044DA28 12584 23:38:50.477 UnhandledExceptionFilter: NOP opcode=・len=3
Any suggestions for the .ini file settings?
`;; Config file for DirectX DLL Wrapper
;;
;; For details, see: https://github.com/elishacloud/dxwrapper/wiki/Configuration
;;
[General]
RealDllPath                = AUTO
WrapperMode                = AUTO
LoadCustomDllPath          =
ExcludeProcess             =
IncludeProcess             =
RunProcess                 =
WaitForProcess             = 0
DisableLogging             = 0
[Plugins]
LoadPlugins                = 0
LoadFromScriptsOnly        = 0
[Compatibility]
Dd7to9                     = 1
D3d8to9                    = 0
DDrawCompat                = 1
Dinputto8                  = 0
DisableGameUX              = 0
DxWnd                      = 0
EnableDdrawWrapper         = 1
EnableD3d9Wrapper          = 1
EnableDinput8Wrapper       = 0
EnableDsoundWrapper        = 0
HandleExceptions           = 1
SingleProcAffinity         = 4
[DDrawCompat]
DDrawCompat20              = 0
DDrawCompat21              = 0
DDrawCompat31              = 1
DDrawCompatDisableGDIHook  = 0
DDrawCompatNoProcAffinity  = 0
[ddraw]
ConvertToDirectDraw7       = 1
ConvertToDirect3D7         = 1
DdrawFixByteAlignment      = 0
DdrawOverrideBitMode       = 0
[Dd7to9]
AutoFrameSkip              = 0
DdrawEmulateSurface        = 0
DdrawRemoveScanlines       = 0
DdrawReadFromGDI           = 0
DdrawWriteToGDI            = 0
DdrawLimitDisplayModeCount = 0
DdrawUseNativeResolution   = 0
DdrawClippedWidth          = 0
DdrawClippedHeight         = 0
DdrawOverrideWidth         = 0
DdrawOverrideHeight        = 0
DdrawOverrideRefreshRate   = 0
DdrawIntegerScalingClamp   = 0
DdrawMaintainAspectRatio   = 0
[d3d9]
AnisotropicFiltering       = 0
AntiAliasing               = 0
EnableVSync                = 0
EnableWindowMode           = 0
ForceMixedVertexProcessing = 0
ForceSystemMemVertexCache  = 0
ForceVsyncMode             = 0
FullscreenWindowMode       = 0
WindowModeBorder           = 0
[FullScreen]
FullScreen                 = 0
ForceWindowResize          = 0
WaitForWindowChanges       = 0
[dinput8]
FilterNonActiveInput       = 0
[dsound]
Num2DBuffers               = 0
Num3DBuffers               = 0
ForceCertification         = 0
ForceExclusiveMode         = 0
ForceSoftwareMixing        = 0
ForceHardwareMixing        = 0
ForceHQ3DSoftMixing        = 0
ForceNonStaticBuffers      = 0
ForceVoiceManagement       = 0
ForcePrimaryBufferFormat   = 0
PrimaryBufferBits          = 16
PrimaryBufferSamples       = 44100
PrimaryBufferChannels      = 2
AudioClipDetection         = 0
`
Im not even sure if i should be using the ddraw.dll file. The documentation doesnt explain how to figure out which file to use.

At one point, the game gave me exception errors (this happens without dxwrapper as well). With dxwrapper however, the game didnt just crash, i was able to keep playing for a bit more time, but the graphics of all the characters became corrupted

It appears that there is some kind of bug in the game.  dxwrapper can help with certain types of crashes, but it appears like this one it cannot help with.

My question is, does the dxwrapper log file include any useful information on the exception error?

Probably not.  This would need to be debugged.

Will any other config settings help?  Any suggestions for the .ini file settings?

It looks like you have some conflicting settings enabled.  Both Dd7to9 and DDrawCompat can't work at the same time.  Also, there is probably no need to enable DDrawCompat31.  I would also recommend disabling ConvertToDirectDraw7 and 'ConvertToDirect3D7`.
A few things to try:

Try with just EnableDdrawWrapper, EnableD3d9Wrapper and HandleExceptions enabled.
Try with just DDrawCompat and HandleExceptions enabled.
Try with just Dd7to9 and HandleExceptions enabled.
Try with Dd7to9, DdrawEmulateSurface and HandleExceptions enabled.

Closing issue.  You can reopen it if there are still questions here.


Merge 7 ➡ 8

➡ Forward port
Port gz-sensors7 to gz-sensors8
Branch comparison: https://github.com/gazebosim/gz-sensors/compare/gz-sensors8...gz-sensors7
Note to maintainers: Remember to Merge with commit (not squash-merge or rebase)

fixed UNIT_Sensor_TEST by removing the test for ignition_frame_id as it's no longer supported in Harmonic (replaced by gz_frame_id)


Feature-gate Context for Option?

Would you consider a PR to put the Context implementation for Option behind a feature?
At present, it is easy to wind up with a mix of ok_or_else and with_context applied to Option instances.
While I can see arguments for either, providing an enabled-by-default feature that one could turn off would help those who prefer ok_or_else.

I would prefer not to change this, but one doesn't have to use this crate's Context trait. You can define an alternative Context trait in your own codebase with only the impls you want.

Understood. Thanks.


Change to data warehouse structure so that it can be applied to folders, not just buckets ✨

Describe the feature request.
Currently the AP Control Panel allows users to create their own data warehouse (S3 bucket) and then allows them to have admin permissions to this bucket and grant others access to the entire bucket, or selected paths. However, this approach seems to be leading to a bucket-per-project approach being used, where users make a new bucket per project. Given AWS S3's limit of 1,000 buckets, another solution may be required.
If users share a bucket across multiple projects, one person still needs to be admin of the bucket, meaning they have admin control over all folders in that bucket. This may present DPIA and governance issues, as the admin will have access to everything and will need to be in the DPIA for everything. Then if that person leaves the organisation, a new admin will be required and they may have to be retrospectively added to multiple DPIAs and governance documents.
This request would be to explore whether we could:

Allow AP Users to Create Team of users in the AP Control Panel
Allow AP Users to Create Buckets with no admin (except super-admins of the AP)
Allow Team Members to create folders within the Bucket (but not see all contents of the buckets other folders by default)
Allow the Folder Creator to add Individual level permissions to the folder.

This should, in theory, allow Users to more easily follow a bucket-per-domain/team approach and folder-per-project, reducing the number of buckets.
Describe the context.
No response
Value / Purpose
No response
User Types
AP Users

I'm wondering if this would be better achieved using Lake Formation and/or Data Zone as opposed to building something. And use database-access instead as a work-around. @mshodge how big of a priority is this?

@mshodge I'll be discussing access with @julialawrence this week and get back to you next with some more info

Aren't the AP/DE team defacto owners of all datasources? That is, they have access to all of them anyway It would just be a shift toward requesting folder level permissions and paths instead of bucket level?
I guess the use case is just to reduce the number of buckets.
This is what currently happens, a bucket per project

approach.
Inn some cases proactive people create folders under a bucket (Person A here for example who is on three of those projects - but if they leave the org then the bucket has no owner anyway)

But ideally the folder owner approach would allow folders across an entire domain to be under one bucket. And even if a person (or people) in those teams who had folder permissions left, it wouldn't impact on the ability of others to add/remove folder level permissions

Another approach I guess is for each domain to have a data controller/owner who owns all data in that domain and can be the bucket level admin; rather than the analysts creating the buckets.


ng new my-project --skip-tests shouldn't generate karma/protractor files

The --skip-tests flag for ng new didn't quite match my expectations as a developer.
Versions
Angular CLI: 1.6.0-beta.0
Node: 8.4.0
OS: linux x64
Angular:
...

Angular CLI 6.0.7 still the same

Tested with @angular/cli 6.0.8:

--skip-tests still generated e2e files;
--skip-e2e not work.

Still an issue in 6.2.2

Just a 'what if' -- for library development, I generally generate a new app and a single library - the app acting as the 'demo' for the library.
Generating without tests (including e2e) makes sense on the top level, but I do unit tests on the library.
A lot of the libraries innards (karma, lint, etc..) extend the upper level, which would then be missing if these do go away.
Figured I'd share - maybe I should just start testing my demos :)

In CLI v7.0.4 the --minimal flag is already working as expected. No generated test files. 👌

In CLI v7.0.4 the --minimal flag is already working as expected. No generated test files.

It removes the test files, but also removes linting so it isn't really the right solution.  The issue still remains that --skip-tests should remove ALL testing frameworks, not just unit tests

--minimal also forces the templates and styles to be inline

Also, --minimal with --inlineTemplate and --inlineStyle set to false is not working.

ng new my-project-no-test --minimal=true --routing=true --skip-tests=true

ng new my-project-no-test --minimal=true --routing=true --skip-tests=true
see https://angular.io/cli/new

See my comment above.  The issue is the --minimal flag removes linting in addition to removing the testing frameworks.  I think this would be fine, as that seems pretty minimal, however the flag's description only says it removes test frameworks and doesn't mention linting:

When true, creates a project without any testing frameworks.

To make things more flexible, there should probably be a --linting flag

ng new my-project-no-test --minimal=true --routing=true --skip-tests=true
see https://angular.io/cli/new

See my comment above. The issue is the --minimal flag removes linting in addition to removing the testing frameworks. I think this would be fine, as that seems pretty minimal, however the flag's description only says it removes test frameworks and doesn't mention linting:

When true, creates a project without any testing frameworks.

To make things more flexible, there should probably be a --linting flag

Roger!

You have to Use --skipTests

Still a problem in 10.2

This is expected as per description --skipTest doesn't generate .spec.ts files, but it still still adds the testing framework and it's config. If you want to create an application without any testing framework use --minimal.
More info: https://angular.io/cli/new

This is expected as per description --skipTest doesn't generate .spec.ts files, but it still still adds the testing framework and it's config. If you want to create an application without any testing framework use --minimal.
More info: https://angular.io/cli/new

The problem with using --minimal is that it enforces inline style and templating, and we don't want that. We just want an Angular project without testing.

For anyone wanting to create an Angular project without test packages, files and configurations, I'll leave my conclusions:
Using<EMAIL_ADDRESS>Create a project using --skip-tests.
Remove the following:

e2e folder
karma.conf.js
inside angular.json: the test and e2e configuration sections.
src/test.ts
Run npm uninstall @types/jasmine, @types/jasminewd2, jasmine-core, jasmine-spec-reporter, karma, karma-chrome-launcher, karma-coverage-istanbul-reporter, karma-jasmine, karma-jasmine-html-reporter, protractor

why in angular.io is written --skip-tests and they didnt fix to --skipTests. they dont care?

@Dewberrycat, the reason why is that camel cased arguments such as --skipTests are now deprecated and will be removed in the a future version.

@Dewberrycat, the reason why is that camel cased arguments such as --skipTests are now deprecated and will be removed in the a future version.

ok, --skip-tests also still doesnt work, what is wrong with angular team? do they remember where angular.io is? why they dont care about people, should we all be Nostradamuses to guess what to do?

@Dewberrycat, the reason why is that camel cased arguments such as --skipTests are now deprecated and will be removed in the a future version.

The reason is not the issue. Out of date documentation is the issue.

@Dewberrycat,
Can you elaborate on what’s the not correct in the docs about the skip test option?
In https://angular.io/cli/new the description of -skip-tests states the clearly what it does;

Do not generate "spec.ts" test files for the new project.

May I also remind you to keep the conversation constructive per the code of conduct. Thanks
@ErroneousFatality / @Dewberrycat this is an OSS project, feel free to create a PR to improve the docs if you find some parts are out of dated or incorrect. Such contributions would be greatly appreciated.

Update 2021
Angular V12
If you want to have the minimal mode and not have the inlineTemplate, I have done the following:
ng new test4 --minimal --inline-style = false
(--inline-style = false didn't work)
But in the angular.json file I have looked for the inlineTemplate file and I have set it to false (it can be removed since it is false by default).
"@schematics/angular:component": {
          "inlineTemplate": false,
          "style": "scss",
          "skipTests": true
        },

However I think it is a mistake to set --inline-style = false and that it does not work the first time.

How can this still be an issue 6 version later ?

It still here

And still here!

Had some discussion about this today and we all agreed that ng new --skipTests should drop the test configuration.
With the work going on with Web Test Runner and Jest, we're planning to add something like ng new --test-runner jest|web-test-runner. We'll likely want to eventually replace --skipTests with --test-runner none to align with that flag.
One challenge with not generating tests is that it isn't clear how to add tests later if a user changes their mind for a project. We should look into some kind of ng generate karma-setup (eventually web-test-runner-setup and jest-setup as well) to add tests after project creation. That's not a strict blocker for fixing --skipTests behavior, since this is an existing problem today for users who manually delete tests after ng new or use ng new --minimal.
There was a recent PR for this in https://github.com/angular/angular-cli/pull/25901. We're likely a little too late to get this into version 17, but it's definitely something we can consider for v18.


[sw, rom_exts] Determine ROM_EXT manifest Peripheral Lockdown Info field encoding

Introduction
The ROM_EXT manifest format is described in the following document:
https://docs.opentitan.org/sw/device/rom_exts/docs/manifest/
"Peripheral Lockdown Info This is a 128-bit value which describes how some peripherals should be configured, before the write-enable bits for their configuration registers are cleared. This is used by the Mask ROM to configure specific peripherals (including, for example, pinmux and padctrl), in such a way that their configuration cannot be updated by the ROM_EXT or any other later firmware."
The primary goal for this mechanism is for ROM_EXT to communicate peripheral configuration information to Mask ROM, which is a way to convey application needs up the Secure Boot chain. Please see the next section for potential use-cases.
Potential use-cases

Configure SPI in "TPM busy mode"
TPM has timing constraints for responding to queries over SPI. On power-up and wake-up from sleep, the OpenTitan chip will go through the entire Secure Boot process. The payload authentication takes significant time, which may violate TPM timing restrictions. TPM provisions a "please wait" reply, which we intend to leverage in the Mask ROM through configuring SPI in "TPM busy mode".

Extra level of protection by locking critical resources early

Problem description
At this point it is not clear to what extent we would want to utilise this mechanism. I have mentioned some potential use-cases, but it is not enough to decide on reasonable encoding for this field.
For example, a peripherals like Pinmux and GPIO have 32 pins, which makes configuring all of them challenging via 128-bit field. Pinmux and GPIO are only two peripherals, and if we need to configure more - it puts even more strain on the limited 128-bit field.
Potential encoding schemes

RIGID: In this 128-b field we allocate fixed size fields that represent a configuration profile for a peripheral. The configuration profile will be just an ID (0, 1, 2, 3, ...). This ID would be only meaningful for the peripheral it describes, so we could have different width for these configuration fields per peripheral. This method implies that all peripheral variants are hardcoded in the Mask ROM and ROM_EXT simply can mix and match the profiles provisioned in the Mask ROM.

SEMI-RIGID:  We could expand the 128-bit field to be wider, and then there are more options on how and what information to encode.

FLEXIBLE: We could have similar strategy as we do for ROM_EXT extensions where we have a checksum and the offset to the extension inside the image. We could then have very thorough configuration information, but this is more sophisticated and probably also needs additional consideration from the security perspective.

@gkelly @asb @mcy @mundaym @jon-flatley @alphan @moidx @luismarques @tjaychen
Please feel free to add other people as well.

@gkelly mentioned that the SPI TPM busy mode may be configured via OTP.  We can investigate if having support to configure this via peripheral lockdown is still needed.
To understand better potential use cases, under what conditions do we recommend locking down peripherals before jumping to the next boot stage?
Is the next boot stage ok with unconditionally applying the peripheral lockdown commands?
I could see peripheral lockdown associated with the implementation of logical-SKU (or soft-SKU) capabilities, which could be implemented as MMIO configuration settings. However, from a logical-SKU perspective, we may as well have the ROM_EXT apply its own restrictions.
What are other potential use cases? I think narrowing this down would help us decide on next steps.

To understand better potential use cases, under what conditions do we recommend locking down peripherals before jumping to the next boot stage?

The only concrete use-case that I managed to come up with is the "busy TPM mode",  thus opening this issue to get more thoughts in.

I could see peripheral lockdown associated with the implementation of logical-SKU (or soft-SKU) capabilities, which could be implemented as MMIO configuration settings. However, from a logical-SKU perspective, we may as well have the ROM_EXT apply its own restrictions.

The SKU seems like a potential candidate for going into the Peripheral Lockdown Info field, however as you have pointed out - it might be reasonable to perform this configuration in the ROM_EXT.
Potential use cases:

Security (early lockdown of critical resources): I can't find any concrete use-cases
Application specific early configuration (very niche - must be required to be configured as soon as possible, otherwise can be just done in ROM_EXT): I can't find any concrete use-cases apart from "TPM busy", however as you have pointed out, it may be configured in OTP.
SKU (again, only applicable for configuration that must be done as early as possible, otherwise there is no point): I can't find any concrete use-cases.

It would be very useful if more people could look into this.
If we can't find any use-cases - it might be a good idea to mark the field as reserved for now, or settle for the simplest approach (described as RIGID in the issue description). There are several variations of how we can do it, it doesn't have to be completely static. For example, we could have something like: periph_id(N bits), variant_id(N bits), periph_id(N bits) ... - this makes it slightly more flexible, but eats up bits for the peripheral IDs.

@felixmiller

@cfrantz


Bump nuclio version and fix issues from the outdated version

Motivation and context

Issue https://github.com/opencv/cvat/issues/6183 still exists in CVAT v2.5.2. Following up the addressed issue https://github.com/nuclio/nuclio/issues/2938 in the nuclio community, they suggested to use new nuclio version (1.11.x). It seems that the templates fetching mechanism on the old nuclio versions is not supported anymore, causing the mentioned issue.
How has this been tested?

Following the Semi-automatic and Automatic Annotation guideline on the CVAT v2.5.2 release branch (for the sake of stability) in a RHEL 8 machine, but changed the nuclio version to 1.11.24 and disabling the /tmp mounting to the nuclio container. Additionally, removed the unused static IP address value in the no_proxy environment. Tested using SAM model with GPU following that guideline on some random images from a remote client.
Checklist

[x] I submit my changes into the develop branch
[x] I have added a description of my changes into the CHANGELOG file
[x] I have updated the documentation accordingly
~- [ ] I have added tests to cover my changes~
[x] I have linked related issues (see GitHub docs)
~- [ ] I have increased versions of npm packages if it is necessary
(cvat-canvas,
cvat-core,
cvat-data and
cvat-ui)~

License

[x] I submit my code changes under the same MIT License that covers the project.

@MuhammadSYahyaS , thanks for the contribution!


ResultOperationType not included with iOS extension target

Any reason for this?
I'm also not even sure how the extension target builds without this because it's referenced in the code.

Hi Jamie -- sorry about this. I think the extension project might just be out of sync. Are you using master or development branch?

yeah I'm running off of development.
I've been thinking about these different projects. Would it make more sense to split all the none extension stuff into a separate framework within the same repo? So have like Operations.framework (core stuff) then Operations_App.framework

Yes, when I did it at the time, I knew that it would be a huge PITA to keep them in sync. I spect a fair bit of time looking though how to use a custom modulemap so that stuff that was iOS only, or "non-extension" would be in a different module, i.e.
import Operations // This would be API extension compatible
import Operations.Application // This would be non-API extension compatible
import Operations.Application.iOS // ?? Maybe for example?

But... at the time, I thought Carthage was going to resolve the issues, and hopefully SwiftPM will bring about even greater changes to how it's structured.
However, these are taking time, so it's possibly time to look at our options again. Unfortunately I've let the API extensions compatible stuff get out of sync - and I don't even have specific tests in CI for building that project. So, this is what I propose (to happen on Sunday at the earliest unless I can get it done tonight, or if you can submit a PR)
In one ticket:

Update .ci/scripts, .ci/buildkite and .fastlane/Fastfile to add tests for iOS extensions project.
Update the project to include all the correct files.

Then....

Update to latest Carthage - does it help us?
Ask in Swift Mailing lists about suggested or possible approaches.
Refactor to see if we can make a workspace with nested projects? (as per your suggestion?)

Thoughts?


saturate() on vectors is broken

This might be an upstream bug.
    // FIXME: MojoShader workaround
    if (0) {
        value = saturate(value);
    } else {
        value = float3(saturate(value.r), saturate(value.g), saturate(value.b));
    }

I think MOD_SATURATE is the name you want to look up in the source. It’s some weird miscellaneous value modifier and it’s most likely only covering certain types of values.

The MOD_SATURATE implementation is correct, it seems like clamp() isn't being generated by the shader at all so I'm going to try and figure out why.

Problem with generated code became evident once I hand-inlined constants:
    ps_r1 = texture2D(ps_s0, ps_r1.xy);
    ps_r2 = ps_r1 + vec4(0);
    ps_r1.x = ((ps_r2.x >= 0.0) ? ps_r1.x : 0);
    ps_r1.y = ((ps_r2.y >= 0.0) ? ps_r1.y : 0);
    ps_r1.z = ((ps_r2.z >= 0.0) ? ps_r1.z : 0);
    ps_r1.w = ((ps_r2.w >= 0.0) ? ps_r1.w : 0);
    ps_r2 = ps_r1 + vec4(-1.0);
    ps_r1.x = ((ps_r2.z >= 0.0) ? 1.0 : ps_r1.z);
    ps_r1.y = ((ps_r2.x >= 0.0) ? 1.0 : ps_r1.x);
    ps_r1.z = ((ps_r2.y >= 0.0) ? 1.0 : ps_r1.y);
    ps_r1.w = ((ps_r2.w >= 0.0) ? 1.0 : ps_r1.w);

This problem could be hidden in the d3d9 bytecode in a way that doesn't show up through the D3D shader compiler, I'll have to see.

That weird zxyw is in the D3D9 bytecode, so maybe this is a fxc bug? I don't know how it works through the D3D api though.
    texld r1, r1, s0
    add r2, r1, -0.0
    cmp r1, r2, r1, 0.0
    add r2, r1, -1.0
    cmp r1, r2.zxyw, 1.0, r1.zxyw
    mov r1.xyz, r1
    mov r0.w, c4.x
    mov r2.x, c3.x
    mov r1.xyz, r1
    add r2.y, r2.x, -1.0
    mov r1.x, r1.x
    mul r2.z, r2.y, r1.x
    frc r2.w, r2.z
    mov r2.w, -r2.w
    add r3.x, r2.z, r2.w
    mov r3.y, -r2.z
    mov r3.z, -r3.y
    add r3.z, r2.z, r3.z
    cmp r3.z, r3.z, 0.0, 1.0
    add r2.w, r2.w, r2.w
    cmp r2.w, r2.w, 0.0, 1.0
    mul r2.w, r2.w, r3.z
    add r2.w, r2.w, r3.x

Basic test case seems fine with FXC 9.29.952.3111.
Source:
void PixelPoot(inout float4 color : COLOR0)
{
        color = saturate(color);
}

technique T
{
        pass P
        {
                PixelShader = compile ps_3_0 PixelPoot();
        }
}

ASM:
technique T
{
    pass P
    {
        //No embedded vertex shader
        pixelshader =
            asm {
            //
            // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
                ps_3_0
                dcl_color v0
                mov_sat oC0, v0

            // approximately 1 instruction slot used
            };
    }
}

glsl120:
EFFECT: poot.fxb
    PROFILE: glsl120

    TECHNIQUE #0 ('T'):
        PASS #0 ('P'):
            STATE 147:
                VALUE: (null) -> (null)
                    CLASS: OBJECT
                    TYPE: PIXELSHADER
                    ROWS/COLUMNS/ELEMENTS: 0, 0, 0
                    TOTAL VALUES: 1
                    PIXELSHADER VALUES:

    OBJECT #1: SHADER, technique 0, pass 0
        PROFILE: glsl
        SHADER TYPE: pixel
        VERSION: 3.0
        INSTRUCTION COUNT: 1
        MAIN FUNCTION: ShaderFunction1
        INPUTS: (none.)
        OUTPUTS:
            * (null) ("ps_oC0")
        CONSTANTS: (none.)
        UNIFORMS: (none.)
        SAMPLERS: (none.)
        SYMBOLS: (none.)
        OUTPUT:
            #version 120
            #define ps_v0 gl_Color
            #define ps_oC0 gl_FragColor

            void main()
            {
            	ps_oC0 = clamp(ps_v0, vec4(0.0), vec4(1.0));
            }

Yeah it only happens at some point in complexity for the shaders. It does show up in the fxc output at that point, which is nice - mojoshader isn't constructing it from thin air. It might be something specific to that swizzle, because it looks like it was added in a later pixel shader profile than the rest of the swizzles. I haven't figured out what causes it to get generated yet.

Forgot to mention, this is very sensitive to optimization level like most of the other bugs I'm finding. When I messed around with fxc, the codegen for this stuff was dramatically different between /Od and /O0 before you even got to the stuff the later levels of optimization do. This problem only occurs in /Od.

Same test with Od:
ASM:
technique T
{
    pass P
    {
        //No embedded vertex shader
        pixelshader =
            asm {
            //
            // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
                ps_3_0
                def c0, -0, 0, -1, 1
                dcl_color v0
                add r0, c0.x, v0
                cmp r0, r0, v0, c0.y
                add r1, r0, c0.z
                cmp oC0, r1, c0.w, r0

            // approximately 4 instruction slots used
            };
    }
}

glsl120:
EFFECT: poot.fxb
    PROFILE: glsl120

    TECHNIQUE #0 ('T'):
        PASS #0 ('P'):
            STATE 147:
                VALUE: (null) -> (null)
                    CLASS: OBJECT
                    TYPE: PIXELSHADER
                    ROWS/COLUMNS/ELEMENTS: 0, 0, 0
                    TOTAL VALUES: 1
                    PIXELSHADER VALUES:

    OBJECT #1: SHADER, technique 0, pass 0
        PROFILE: glsl
        SHADER TYPE: pixel
        VERSION: 3.0
        INSTRUCTION COUNT: 4
        MAIN FUNCTION: ShaderFunction1
        INPUTS: (none.)
        OUTPUTS:
            * (null) ("ps_oC0")
        CONSTANTS:
            * 0: float (-0.000000 0.000000 -1.000000 1.000000)
        UNIFORMS: (none.)
        SAMPLERS: (none.)
        SYMBOLS: (none.)
        OUTPUT:
            #version 120
            const vec4 ps_c0 = vec4(0.0, 0.0, -1.0, 1.0);
            vec4 ps_r0;
            vec4 ps_r1;
            #define ps_v0 gl_Color
            #define ps_oC0 gl_FragColor

            void main()
            {
            	ps_r0 = ps_c0.xxxx + ps_v0;
            	ps_r0.x = ((ps_r0.x >= 0.0) ? ps_v0.x : ps_c0.y);
            	ps_r0.y = ((ps_r0.y >= 0.0) ? ps_v0.y : ps_c0.y);
            	ps_r0.z = ((ps_r0.z >= 0.0) ? ps_v0.z : ps_c0.y);
            	ps_r0.w = ((ps_r0.w >= 0.0) ? ps_v0.w : ps_c0.y);
            	ps_r1 = ps_r0 + ps_c0.zzzz;
            	ps_oC0.x = ((ps_r1.x >= 0.0) ? ps_c0.w : ps_r0.x);
            	ps_oC0.y = ((ps_r1.y >= 0.0) ? ps_c0.w : ps_r0.y);
            	ps_oC0.z = ((ps_r1.z >= 0.0) ? ps_c0.w : ps_r0.z);
            	ps_oC0.w = ((ps_r1.w >= 0.0) ? ps_c0.w : ps_r0.w);
            }

As... awful as this is, it does appear to be accurate.

Does this help?
\Documents\Projects\Fracture\ext\fxc\fxc.exe /T ps_3_0 \Documents\Projects\FNA\clamptest.fx.txt
 /Od /Fo clamptest.fx.bin && testparse.exe glsl120 clamptest.fx.bin > output.glsl.txt

clamptest.fx.txt
output.glsl.txt

Minor corrections (bad at reducing test cases here):
    // bad
    value.rgb = saturate(value.rgb);

And then the suspect output from /Od:
        	ps_r3.x = ((ps_r3.x >= 0.0) ? ps_r1.x : ps_c3.z);
        	ps_r3.y = ((ps_r3.y >= 0.0) ? ps_r1.y : ps_c3.z);
        	ps_r3.z = ((ps_r3.z >= 0.0) ? ps_r1.z : ps_c3.z);
        	ps_r4.xyz = ps_r3.xyz + ps_c3.xxx;
        	ps_r3.x = ((ps_r4.z >= 0.0) ? ps_c3.w : ps_r3.z);
        	ps_r3.y = ((ps_r4.x >= 0.0) ? ps_c3.w : ps_r3.x);
        	ps_r3.z = ((ps_r4.y >= 0.0) ? ps_c3.w : ps_r3.y);

And then for reference, here's that zxyw I noticed before, which was added in a later version of PS (ps_2_0, I think), generated in /Od:
    cmp r3.xyz, r4.zxyw, c3.w, r3.zxyw

Here's the /O3 output in comparison:
    mov_sat r5.xyz, r5

        	ps_r5.xyz = clamp(ps_r5.xyz, vec3(0.0), vec3(1.0));

Still looks accurate to me, the only odd thing I'm seeing is this from fxc:

cmp r1.xy, r1.zwzw, v3.zwzw, r1

Weird that it would even bother with zwzw but I guess it's because they didn't want to do r1.xy.


Cleaning up generated LV code and restricting scope as warranted

Description
Cleaning up generated LV code for readability and restricting access scope where appropriate. I also modified the generated code for the server such that the concrete service instances are created by default and will handle multiple service APIs without requiring manual coding from the user.
Implementation

Changes to template VIs (client, server, and oneof) were just standard cleanup of block diagrams and front panel. Access scope for some of the templates were changed to private/protected as warranted.
Inserted BD/FP cleanup calls to the scripted code any time new nodes were scripted or typedef constants/controls were updated.
Added scripting calls to change access scope of generated VIs / typedefs as warranted. In general, all of the "flat" typdef and serialization VIs are marked as private implementation details.
Updated server template so that the generator automatically scripts creation of each concrete service class. The template then handles spinning up the service classes in parallel and synchronizes shutdown across all instances. This was mostly stolen from what is done in the measurement-plugin-labview repo with measurement services.

Testing
Manually tested generation of both the client and the server using proto APIs that included nested messages, enums, and oneof fields.

One general concern about cleaning up the front panel and block diagram. Sometimes it can change the diagram quite a bit, e.g. from the way we arranged it in the client or server template. If we spend effort making the template VIs nice (which doesn't match what cleanup diagram would do), we may be wasting effort there.
So, are you running cleanup on every template VI we instantiate? Or only ones that you modify significantly. Have you compared the cleaned up VIs with the template VIs?
I don't think this is a major concern, just wanted to bring it up for discussion.

One general concern about cleaning up the front panel and block diagram. Sometimes it can change the diagram quite a bit, e.g. from the way we arranged it in the client or server template. If we spend effort making the template VIs nice (which doesn't match what cleanup diagram would do), we may be wasting effort there.
So, are you running cleanup on every template VI we instantiate? Or only ones that you modify significantly. Have you compared the cleaned up VIs with the template VIs?
I don't think this is a major concern, just wanted to bring it up for discussion.

My thoughts on this:

You can never really go wrong with applying FP cleanup.
Even if we run BD cleanup on the template VI, starting with a clean layout of the template is still helpful from a readability/maintainability standpoint.
We don't do BD cleanup on all template VIs, only the ones where we script new nodes on the diagram or replace place holder constants/controls with the generated typedef reference. Most of these templates are simple enough that BD cleanup gives you something close or good enough to what you might layout by hand. It is certainly better than what you get with scripting nodes on top of each other. Calculating positions so nodes don't overlap without using BD cleanup is otherwise difficult/tedious. If you run into a situation where you have a significant portion of a diagram that is "static" and you want to manually lay it out in addition to a significant amount of scripted code you want to "auto layout", then I think the recommended practice is to extract all of the scripted code into a sub VI and use the VI boundary to isolate the cleanup actions.
There are probably more opportunities for further cleanup. For instance, there are cases where we update constants like string constants and don't re-layout because of that. This can lead to overlap/crowding on the block diagram. Similarly, there are cases where cluster constants on the block diagram only serve as a type specifier. In those cases, we could save space and the BD cleanup would be more effective by using the icon view for cluster. However, I think this setting gets lost when doing replacements, and I haven't taken the time to try and enforce it with scripting yet. Maybe in a future PR.

Anyway, I've audited generated code for both the client and the server, and I think these changes are an improvement in almost all cases. If you look at before and after comparisons of the generated code with this change, you can see for yourself. I couldn't think of a great way to easily show that with pictures, but I can attach some after pictures if there is something in particular you wanted to see.

One general concern about cleaning up the front panel and block diagram. Sometimes it can change the diagram quite a bit, e.g. from the way we arranged it in the client or server template. If we spend effort making the template VIs nice (which doesn't match what cleanup diagram would do), we may be wasting effort there.
So, are you running cleanup on every template VI we instantiate? Or only ones that you modify significantly. Have you compared the cleaned up VIs with the template VIs?
I don't think this is a major concern, just wanted to bring it up for discussion.

My thoughts on this:

You can never really go wrong with applying FP cleanup.
Even if we run BD cleanup on the template VI, starting with a clean layout of the template is still helpful from a readability/maintainability standpoint.
We don't do BD cleanup on all template VIs, only the ones where we script new nodes on the diagram or replace place holder constants/controls with the generated typedef reference. Most of these templates are simple enough that BD cleanup gives you something close or good enough to what you might layout by hand. It is certainly better than what you get with scripting nodes on top of each other. Calculating positions so nodes don't overlap without using BD cleanup is otherwise difficult/tedious. If you run into a situation where you have a significant portion of a diagram that is "static" and you want to manually lay it out in addition to a significant amount of scripted code you want to "auto layout", then I think the recommended practice is to extract all of the scripted code into a sub VI and use the VI boundary to isolate the cleanup actions.
There are probably more opportunities for further cleanup. For instance, there are cases where we update constants like string constants and don't re-layout because of that. This can lead to overlap/crowding on the block diagram. Similarly, there are cases where cluster constants on the block diagram only serve as a type specifier. In those cases, we could save space and the BD cleanup would be more effective by using the icon view for cluster. However, I think this setting gets lost when doing replacements, and I haven't taken the time to try and enforce it with scripting yet. Maybe in a future PR.

Anyway, I've audited generated code for both the client and the server, and I think these changes are an improvement in almost all cases. If you look at before and after comparisons of the generated code with this change, you can see for yourself. I couldn't think of a great way to easily show that with pictures, but I can attach some after pictures if there is something in particular you wanted to see.

I'm fine with it then since you've inspected the generated code.


Override storageLayout extra output while building

It seems like foundry (or ethers-rs) is not defaulting anymore to including the storageLayout key in the artifacts or the build.
This has the effect to cause a crash when solc_to_k builds an identifier of the contract, by hasing the name and a json structure of the storage layout from the artifacts.
ifrostizz@kevm-dev-personal-01:~/tmp/my_kevm_project$ poetry run -C ~/rv/evm-semantics/kevm-pyk kevm foundry-kompile

WARNING 2023-05-30 07:41:00,700 __main__ - Ignoring command-line option: -O0
WARNING 2023-05-30 07:41:00,700 __main__ - Ignoring command-line option: -O1
WARNING 2023-05-30 07:41:00,700 __main__ - Ignoring command-line option: -O2
WARNING 2023-05-30 07:41:00,700 __main__ - Ignoring command-line option: -O3
Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/ifrostizz/rv/evm-semantics/kevm-pyk/src/kevm_pyk/__main__.py", line 905, in <modu
le>
    main()
  File "/home/ifrostizz/rv/evm-semantics/kevm-pyk/src/kevm_pyk/__main__.py", line 72, in main
    execute(**vars(args))
  File "/home/ifrostizz/rv/evm-semantics/kevm-pyk/src/kevm_pyk/__main__.py", line 178, in exec_
foundry_kompile
    foundry_kompile(
  File "/home/ifrostizz/rv/evm-semantics/kevm-pyk/src/kevm_pyk/foundry.py", line 287, in foundr
y_kompile
    _imports: dict[str, list[str]] = {contract.name: [] for contract in foundry.contracts.value
s()}
  File "/usr/lib/python3.10/functools.py", line 981, in __get__
    val = self.func(instance)
  File "/home/ifrostizz/rv/evm-semantics/kevm-pyk/src/kevm_pyk/foundry.py", line 102, in contra
cts
    _contracts[contract_name] = Contract(contract_name, contract_json, foundry=True)
  File "/home/ifrostizz/rv/evm-semantics/kevm-pyk/src/kevm_pyk/solc_to_k.py", line 231, in __in
it__
    msig, mid, method, method_ast, self.name, self.digest, self.storage_digest, self.sort_metho
d
  File "/usr/lib/python3.10/functools.py", line 981, in __get__
    val = self.func(instance)
  File "/home/ifrostizz/rv/evm-semantics/kevm-pyk/src/kevm_pyk/solc_to_k.py", line 254, in stor
age_digest
    return hash_str(f'{self.name} - {json.dumps(self.contract_json["storageLayout"], sort_keys=
True)}')
KeyError: 'storageLayout'

The solution is to explicitely choose the storageLayout variable when building the project with forge.

If we specify --extra-output ... manually like this in the call to forge ..., does that override the foundry.toml that the user supplies? For example: https://github.com/runtimeverification/evm-semantics/blob/a68c97a2280b7ac9f1fc81f142464d0a23793b8d/tests/foundry/foundry.toml#LL4C32-L4C32.
If you check that forge build ... is adding those extra arguments instead of overriding them, and indeed foundry is adding to those arguments, then you can add automerge here.

@ehildenb , the arguments are indeed overridden by the command.
For instance, two --extra-output arguments that are apparently not mandatory for the Foundry internal to work and thus are optional are storageLAyout and evm.gasEstimates.
#foundry.toml
[profile.default]
src = "src"
out = "out"
libs = ["lib"]
extra_output = ['storageLayout', 'abi', 'evm.methodIdentifiers', 'evm.deployedBytecode.object', 'evm.gasEstimates']

Running forge b, the storageLayout and evm.gasEstimates are present in the build artifacts.
Running forge b --extra-output storageLayout will suppress the evm.gasEstimates in the new artifacts.

As mentioned by @anvacaru this was fixed by making it optional, but then contract whose name is the same would produce the same digest. We may want to use something like the absolute path, as two contract of the same name cannot be declared in the same file.

Let's ask the Foundry maintainers about this in their Telegram (or maybe @gakonst can chime in directly here). The problem is that we need to sometimes pass arguments both via foundry.toml and forge build ..., but it seems that if we pass --extra-output via forge build, it doesn't append to the values in foundry.toml, it overwrites them. Is it possible to get appending behavior?

cc @evalir who was looking at this (and @mattsse for viz)

If we specify --extra-output ... manually like this in the call to forge ..., does that override the foundry.toml that the user supplies

this is the expected behaviour imo
@evalir This could be solved with the figment::Provider impl
but I'm actually not sure if this would be the right fix because if we merge them then you can no longer override them via cli

It seems like foundry (or ethers-rs) is not defaulting anymore to including the storageLayout key in the artifacts or the build.

I'm not aware of any change regarding this

I'm not aware of any change regarding this

Msg from @Evalir on tg:

For following the convo:
https://t.me/foundry_rs/29110
But this may have always been default, and not introduced at all
If that is a no-fix for Foundry config, and only affecting the --extra-output, then we could purposely parse the arguments from the foundry.toml and append them ?

Ah right, that comment is on the issue—it's not a change, and I suspect this behavior has always been the default as we haven't introduced any changes regarding solc output.
On the config side, this might be a no-fix indeed :( I think what you propose could be your way to go!


asar-unpack: mention multiple directory support in documentation

Here is a new pull request.

... ok, sorry


Version History: The workspace didn't match with the chosen version history

Describe the bug
Version History: The workspace didn't match with the chosen version history
Steps to reproduce the behavior
1.Navigate to https://arcade.makecode.com/beta.
2.Create a project.
3.Add some blocks or code in workspace.
4.More->Version History, click the time and observe the workspace
Actual behavior:
The workspace shows didn't match with chosen version.
Expected behavior:
The workspace matches with the chosen version.
Screen Recording:

Additional context:
1.OS: Windows 11
2.arcade version: 1.13.55
3.Microsoft MakeCode version: 9.3.10

@abchatra Please have a look this bug about version history. The version didn't save in time that the workspace didn't match with chosen version.

@riknoll ?

looks like a bug!

@abchatra  @riknoll I noticed that version history interval should be every 5 minutes from https://github.com/microsoft/pxt/pull/9693, but in reproduced recording, it is not recording the version every 5 minutes.


Status bar icon sizes

Some status bar icons (e.g. Self-destructing Cookies) appear bigger than most (e.g. NoScript) and the height of the status bar is increased to accommodate them. I haven't looked into how the status bar is styled, but is this something can be fixed? Or is the issue that some add-ons do not provide icons with low enough resolution?

I second this, this is pretty annoying. I just emailed SDC's author asking about this. I will update this issue when I get a reply.

For whatever reason, this issue seems to be fixed in Firefox 40.


Search sort should support grouping by repository

The problem I'm trying to solve:

Currently the sort dropdown only has 3 values:

How I imagine hub could expose this functionality:

I would like an extra option to sort by repository, thus grouping all the matches from repos together. I am using the Search to find packages and would like to grasp an idea of which of my projects use that package so i can do some refactoring etc.
Eg java package x.y.z currently gives a lot of matches but stuff isnt grouped so i would have to visit all N matches to record the repos (projects) they belong too, basically manually doing the group by thing. I need this across many of my projects and since theres lots (somewhere around possibly 50) this seemed like something useful for me and others with the same idea.

Hi, I believe this is a question about GitHub.com, the website. This issue tracker is for a command-line utility called hub, not the website itself. For reporting bugs and requesting features for GitHub the website, please go to https://github.com/contact or visit https://github.community. Thank you!


Character %2F is automatically converted to / in URL param

When passing a parquet URL that contains the character %2F, it seems that the character is considered as /, which convert the original URL to a different one.
See, for example, the file: https://huggingface.co/datasets/squad/resolve/refs%2Fconvert%2Fparquet/plain_text/squad-train.parquet.
The app gives the following error:
Error

Traceback (most recent call last):
  File "/lib/python311.zip/_pyodide/_base.py", line 540, in eval_code_async
    await CodeRunner(
  File "/lib/python311.zip/_pyodide/_base.py", line 365, in run_async
    await coroutine
  File "<exec>", line 110, in <module>
  File "/lib/python311.zip/pyodide/http.py", line 201, in bytes
    self._raise_if_failed()
  File "/lib/python311.zip/pyodide/http.py", line 125, in _raise_if_failed
    raise OSError(
OSError: Request for https://huggingface.co/datasets/squad/resolve/refs/convert/parquet/plain_text/squad-train.parquet failed with status 404: Not Found

in these two cases:

original: https://lite.datasette.io/?parquet=https://huggingface.co/datasets/squad/resolve/refs%2Fconvert%2Fparquet/plain_text/squad-train.parquet
replacing %2F with '/' (does not exist): https://lite.datasette.io/?parquet=https://huggingface.co/datasets/squad/resolve/refs/convert/parquet/plain_text/squad-train.parquet

cc @julien-c

Note, in case somebody looks at this issue to load a HuggingFace dataset with lite.datasette.io, we now provide a simpler API to access the parquet files:
https://lite.datasette.io/?parquet=https://huggingface.co/api/datasets/glue/parquet/ax/test/0.parquet
It does not contain %2F this time 😄


error ts compiling

src/utils.ts:56:113 - error TS2339: Property 'markPrice' does not exist on type 'MarkPrice | MarkPrice[]'.
Property 'markPrice' does not exist on type 'MarkPrice[]'.
56         return this.floorPrecised( ((await this.usdmClient.getMarkPrice({isIsolated: "FALSE", symbol: symbol})).markPrice), pricePrecision );
~~~~~~~~~
Found 1 error in src/utils.ts:56

I don't know. I just cloned the repo, tried to compile and everything works.
As written in file "./futures-binance-bot/node_modules/binance/lib/usdm-client.d.ts" the method getMarkPrice returns Promise. So I don't know how you got the type 'MarkPrice | MarkPrice[]'. Try to reinstall this repository or check the declaration of function "getMarkPrice".

Promise

Is it normal for the node index.js to get stuck here for some time: [
'Websocket connected',
{ category: 'binance-ws', wsKey: 'usdm_forceOrder@arr__' }
]
[
'Websocket reconnected',
{
category: 'binance-ws',
wsKey: 'usdmTestnet_userData_S2dZhi0S0MaOiUbINYBNnz97YrRcfveLMLCy4auPmVI6QV94eAMpQNkNNTwd10ED'
}
]

or maybe it is because I'm testing on windows wsl and it's giving me these problems


Added prerelease input

Current dependencies on/for this PR:

main

PR #11

PR #9

PR #10

PR #14

PR #16

PR #18

PR #19   👈

This comment was auto-generated by Graphite.

Current dependencies on/for this PR:

main

PR #11

PR #9

PR #10

PR #14

PR #16

PR #18

PR #19   👈

This comment was auto-generated by Graphite.


fix: class prototype is read only

Trying webpack 3 with the 2.x.beta version of Framework7 (I know that's not stable released yet :D). It seems we cannot override a Class prototype. instead, we can extend its prototype using Object.assign. This PR does the same.
Also related StackOverflow question: https://stackoverflow.com/questions/45955494/cannot-assign-to-read-only-property-prototype-of-function-class-template7

Thanks, that was a quick port to ES-next module. But if you use it with some es-transpilier (Buble or Babel) it shouldn't throw any errors. Anyway, i'll rework it to something more clear :)

@nolimits4web Thanks for merge :) It seems working now. For transpilation of files inside node_modules we have a potential problem, babel-loader docs recommend ignoring requests inside node_modules so libraries should be already transpiled or library users explicitly include template7 for babel loader.
BTW Looking forward to your rework :)

Well, actually there is a serious reason why i keep module builds in ES-next syntax in all my projects. ES-modules are great way to bundle packages and we often use bundlers like Rollup and Webpack, and the very great feature in these bundlers is so called tree-shaking when it removes unused code from final package.
For example, let's say we have animals.js:
class Animal {
  //...
}
class Dog extends Animal {
  // ...
}
class Cat extends Animal {
  // ...
}
export { Dog, Cat };

And in our project we do import Dog from './animals.js'. It is pretty obvious that in final bundle we shouldn't see Cat class as it is not used in our project. And bundlers do this job pretty well, but their tree-shaking algorithm is pretty careful, and if there is something that bundler can't recognise it just leaves it in final bundle. And this what happens with transpiling with Buble for example:
var Animal = function Animal(){
  // ...
}

var Dog = (function (Animal$$1) {
  function Dog() {
    Animal$$1.call(this)
    // ...
  }
  if ( Animal$$1 ) Dog.__proto__ = Animal$$1;
  Dog.prototype = Object.create( Animal$$1 && Animal$$1.prototype );
  Dog.prototype.constructor = Dog;

  return Dog;
}(Animal));

var Cat = (function (Animal$$1) {
  function Cat() {
    Animal$$1.call(this)
    // ...
  }
  if ( Animal$$1 ) Cat.__proto__ = Animal$$1;
  Cat.prototype = Object.create( Animal$$1 && Animal$$1.prototype );
  Cat.prototype.constructor = Cat;

  return Cat;
}(Animal));

And with a 99% probability all such transpiled classes will be included in final bundle as the current tree-shaking algorithm  because these are pretty complex operation for bundlers to decide to remove it.
I've been tested a lot such things these days to make huge F7 library fully modular (https://github.com/nolimits4web/Framework7/blob/v2/dist/js/framework7.modular.js#L21302), and the only way to have it is to keep it in ES-next syntax. And now, if we do import { Framework7, Modal, Dialog } from 'framework7.modular.js we won't get anything not needed in final bundle.
P.S.
@pi0 already reworked :) https://github.com/nolimits4web/Template7/commit/3fdbc95156621e3e9380479b6383c359a59a198e


fix(modal): add type button to SfModal stories

Related issue
https://github.com/DivanteLtd/storefront-ui/issues/1423
Closes #
Scope of work
I added type="button" to template in Molecules|Modal
Screenshots of visual changes

Checklist

[x] No commented blocks of code left
[x] Run tests and docs
[x] Self code-reviewed
[ ] Changes documented

If applicable:

[ ] I followed composition rules for my component
[ ] I tested the component in most common device sizes (can be tested in Storybook from viewport addon in top menu)

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


Refactor the 'rotate' command

Refactor the 'rotate' command #4

I will take a crack at this.

ok thanks for the update @RenCloud


Overall UX design improvement

Common theme through all the tools, better UI design, feedback from users

what do you mean by "feadback from users"?

Hi, this is a generic issues as a reminder for an overall UX design improvement. We should conclude to a design and receive feedback on it from users


Positional encoding.

Dear authors,
I thoroughly enjoyed reading through your paper 'Spatio-Temporal Graph Transformer Networks for Pedestrian Trajectory Prediction'.  Thanks for the effort.
I do have a question however. In the transformer model, a positional encoding is added to the embedded input, as you guys also mention in section 2.1. However, I fail to detect how this positional encoding is implemented in your spatial & temporal Transformers.
Any help would be highly appreciated. Thanks!
BTW; I also sent an email, but got an error back. Therefore, i am also putting up my question here. If you have received this question twice, sorry for that.

Thank you for raising the question. TLDR: We did not use the positional encoding.
For Spatial Transformer: In the spatial dimension, the feature of each node in the graph is the coordinate(position). Thus, we do not have to use positional encoding since the feature itself contains the positional information.
For Temporal Transformer: In the temporal dimension, we tried to use positional encoding at the beginning. Yet, we observed little improvement but more computational cost. Therefore, we decided not to use it in the final version. I believe there is still something we can explore.
Since I have left SenseTime, the email address in the paper is now deactivated. Please email me at<EMAIL_ADDRESS>if you prefer to use email. Sorry for the inconvenience caused.
Thank you & Have a nice day.

Thank you for raising the question. TLDR: We did not use the positional encoding.
For Spatial Transformer: In the spatial dimension, the feature of each node in the graph is the coordinate(position). Thus, we do not have to use positional encoding since the feature itself contains the positional information.
For Temporal Transformer: In the temporal dimension, we tried to use positional encoding at the beginning. Yet, we observed little improvement but more computational cost. Therefore, we decided not to use it in the final version. I believe there is still something we can explore.
Since I have left SenseTime, the email address in the paper is now deactivated. Please email me at<EMAIL_ADDRESS>if you prefer to use email. Sorry for the inconvenience caused.
Thank you & Have a nice day.


no module named 'matplotlib' when using openpose pose node

I'm trying these custom nodes for the first time with my first runs of comfyui, and I am getting the modulenotfounderror: no module named 'matplotlib' whenever I try to start a image generation with the openpose pose node in the workflow. I don't know if anything else would work as I haven't tried them, mostly because I'm not sure how much I'd ever end up using them compared to openpose.
here's a paste of my traceback in my command terminal.
!!! Exception during processing!!! No module named 'matplotlib'
Traceback (most recent call last):
File "B:_StableDiff\ComfyUI_windows_portable\ComfyUI\execution.py", line 151, in recursive_execute
output_data, output_ui = get_output_data(obj, input_data_all)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "B:_StableDiff\ComfyUI_windows_portable\ComfyUI\execution.py", line 81, in get_output_data
return_values = map_node_over_list(obj, input_data_all, obj.FUNCTION, allow_interrupt=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "B:_StableDiff\ComfyUI_windows_portable\ComfyUI\execution.py", line 74, in map_node_over_list
results.append(getattr(obj, func)(**slice_dict(input_data_all, i)))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "B:_StableDiff\ComfyUI_windows_portable\ComfyUI\custom_nodes\comfyui_controlnet_aux\node_wrappers\openpose.py", line 20, in estimate_pose
from controlnet_aux.open_pose import OpenposeDetector
File "B:_StableDiff\ComfyUI_windows_portable\ComfyUI\custom_nodes\comfyui_controlnet_aux\src\controlnet_aux\open_pose_init_.py", line 25, in
from . import util
File "B:_StableDiff\ComfyUI_windows_portable\ComfyUI\custom_nodes\comfyui_controlnet_aux\src\controlnet_aux\open_pose\util.py", line 3, in
import matplotlib
ModuleNotFoundError: No module named 'matplotlib'
hope someone can help. thanks in advance.

Use pip install matplotlib to install the missing dependency.

Thanks

Use pip install matplotlib to install the missing dependency.

how? Install in system python, not in the COMFYUI embeded phyton folder .

Use pip install matplotlib to install the missing dependency.

If I use that command, it tells me: "Requirement already satisfied" too all of the things


Experimenting with wrapping tasks in classes - Calling runtime->destroy_X from destructor doesn't release memory

I'm experimenting with wrapping tasks in classes that follows the following format:
MyTask::MyTask(/*any input required for the task*/) {
  // Create the necessary components for running the task (e.g., index space, field spaces, logical regions).
}

MyTask::execute() {
  // Launch the static task_body
}

static  MyTask::task_body(/*regular task parameters*/) {
    // Task body
}

RETURN_TYPE MyTask::get_result() {
  // Return the result of the task future
}

MyTask::~MyTask() {
    // Destroy any necessary logical regions, field spaces, and index spaces that were created in the constructor
}

This seems to work as expected until the destructor is called, in which case the runtime doesn't seem to actually destroy the regions that had been in use by the object. I've provided a concrete example below of a DotTask class that basically computes the dot product of 2 vectors (2 fields in a region). I've included the implementation below, as well as a screenshot of the results of running the profiler on this program (only having a single CPU available to the Legion runtime) (I can also upload the actual output files fromthe profiling run if that would be helpful).
You can see in the main function that we loop 3 times, with each loop creating a new DotTask object, executing it, getting the results, and then destroying it. I expected the space allocated for the regions to be removed once a loop iteration completes (i.e., the DotTask object's destructor is called, destroying it's associated logical regions, field spaces, and index spaces. But you can see in the profiling results that it is not the case.
In fact, when I run this program with larger values (n_repeat=100, vector_size=pow(2, 20)), I actually get the following error:
[0 - 7fde0d471800]   37.770054 {5}{default_mapper}: Default mapper failed allocation of size 16777216 bytes for region  requirement 0 of task init_task (UID 451) in memory 1e00000000000000 (SYSTEM_MEM) for processor 1d00000000000001 (LOC_PROC). This means the working set of your application is too big for the allotted capacity of the given memory under the default mapper's mapping scheme. You have three choices: ask Realm to allocate more memory, write a custom mapper to better manage working sets, or find a bigger machine.
dot_product_class_task_wrapper: /home/ben/legion/legion_repo/runtime/mappers/default_mapper.cc:2450: void Legion::Mapping::DefaultMapper::default_report_failed_instance_creation(const Legion::Task&, unsigned int, Legion::Processor, Legion::Memory, size_t) const: Assertion `false' failed.
Aborted (core dumped)

I'm not understanding why calling the destroy_whatever function in the class destructor doesn't release their storage back to the runtime. Am I doing something obviously wrong here? Any insight would be appreciated.
// dot_product_class_task_wrapper.h
#include <fstream>
#include <iostream>
#include <string>
#include <stdio.h>
#include <cmath>

// Legion
#include "legion.h"

using namespace std;
using namespace Legion;

enum TaskIDs {
    TOP_LEVEL_TASK_ID,
    DOT_TASK_ID,
    INIT_TASK_ID
};

template <typename TASK>
void preregister_task(TaskID task_id, const char *name);
template <typename RETURN_VALUE, typename TASK>
void preregister_task(TaskID task_id, const char *name);

class TopLevelTask {
public:
    static void task_body(const Task *task, const std::vector<PhysicalRegion> &regions, Context ctx, Runtime *runtime);
};

struct DotArgs {
    FieldID lhs_fid;
    FieldID rhs_fid;
};

class DotTask {
public:
    DotTask(long long int n_partitions = 4);
    DotTask* execute();
    double get_result();
    static double task_body(const Task *task, const std::vector<PhysicalRegion> &regions, Context ctx, Runtime *runtime);
    ~DotTask();
private:
    long long int n_partitions_;
    FieldID lhs_fid_;
    FieldID rhs_fid_;
    FieldSpace field_space_;
    IndexSpace index_space_;
    LogicalRegion logical_region_;
    FutureMap fm_;
    double result_;
};

class InitTask {
  public:
    static void task_body(const Task *task, const std::vector<PhysicalRegion> &regions, Context ctx, Runtime *runtime);
};

// dot_product_class_task_wrapper.cc
#include "dot_product_class_task_wrapper.h"

int main(int argc, char **argv) {
    Runtime::set_top_level_task_id(TOP_LEVEL_TASK_ID);
    preregister_task<TopLevelTask>(TOP_LEVEL_TASK_ID, "top_level_task");
    preregister_task<InitTask>(INIT_TASK_ID, "init_task");
    preregister_task<double, DotTask>(DOT_TASK_ID, "dot_task");
    return Runtime::start(argc, argv);
}

template <typename TASK>
void preregister_task(TaskID task_id, const char *name) {
    TaskVariantRegistrar registrar(task_id, name);
    registrar.add_constraint(ProcessorConstraint(Processor::LOC_PROC));
    Runtime::preregister_task_variant<TASK::task_body>(registrar, name);
}

template <typename RETURN_VALUE, typename TASK>
void preregister_task(TaskID task_id, const char *name) {
    TaskVariantRegistrar registrar(task_id, name);
    registrar.add_constraint(ProcessorConstraint(Processor::LOC_PROC));
    Runtime::preregister_task_variant<RETURN_VALUE, TASK::task_body>(registrar, name);
}

void TopLevelTask::task_body(const Task *task, const std::vector<PhysicalRegion> &regions, Context ctx, Runtime *runtime) {
    const InputArgs &command_args = Runtime::get_input_args();
    double result;
    int n_repeat = 3;
    for (int i=0; i < n_repeat; i++) {
        double n_partitions = pow(2, 2);
        DotTask* dt = (new DotTask(n_partitions))->execute();
        result = dt->get_result();
        cout << "result=" << result << endl;
        delete dt;
    }
}

DotTask::DotTask(long long int n_partitions): n_partitions_(n_partitions) {
    lhs_fid_ = 101;
    rhs_fid_ = 102;
    Runtime *runtime = Runtime::get_runtime();
    Context ctx = runtime->get_context();

    // Create region and fields for lhs and rhs
    long long int vector_size = pow(2, 10);
    const Rect<1> elem_rect(0, vector_size - 1);
    index_space_ = runtime->create_index_space(ctx, elem_rect);
    runtime->attach_name(index_space_, "index_space");
    field_space_ = runtime->create_field_space(ctx);
    runtime->attach_name(field_space_, "field_space");
    {
        FieldAllocator field_allocator = runtime->create_field_allocator(ctx, field_space_);
        field_allocator.allocate_field(sizeof(double), lhs_fid_);
        runtime->attach_name(field_space_, lhs_fid_, "lhs");
        field_allocator.allocate_field(sizeof(double), rhs_fid_);
        runtime->attach_name(field_space_, rhs_fid_, "rhs");
    }
    logical_region_ = runtime->create_logical_region(ctx, index_space_, field_space_);
    runtime->attach_name(logical_region_, "logical_region");

    TaskLauncher lhs_launcher(INIT_TASK_ID, TaskArgument(NULL, 0));
    lhs_launcher.add_region_requirement(RegionRequirement(logical_region_, WRITE_DISCARD, EXCLUSIVE, logical_region_));
    lhs_launcher.add_field(0/*idx*/, lhs_fid_);
    runtime->execute_task(ctx, lhs_launcher);

    TaskLauncher rhs_launcher(INIT_TASK_ID, TaskArgument(NULL, 0));
    rhs_launcher.add_region_requirement(RegionRequirement(logical_region_, WRITE_DISCARD, EXCLUSIVE, logical_region_));
    rhs_launcher.add_field(0/*idx*/, rhs_fid_);
    runtime->execute_task(ctx, rhs_launcher);

}

DotTask* DotTask::execute() {
    Runtime *runtime = Runtime::get_runtime();
    Context ctx = runtime->get_context();

    Rect<1> color_bounds(0, n_partitions_ - 1);
    IndexSpace color_index_space = runtime->create_index_space(ctx, color_bounds);
    IndexPartition index_partition = runtime->create_equal_partition(ctx, index_space_, color_index_space);
    runtime->attach_name(index_partition, "index_partition");
    LogicalPartition logical_partition = runtime->get_logical_partition(ctx, logical_region_, index_partition);
    runtime->attach_name(logical_partition, "logical_partition");

    ArgumentMap arg_map;
    DotArgs dotArgs = {lhs_fid_, rhs_fid_};
    IndexLauncher dot_launcher(DOT_TASK_ID, color_index_space, TaskArgument(&dotArgs, sizeof(dotArgs)), arg_map);
    dot_launcher.add_region_requirement(RegionRequirement(logical_partition, 0/*projection ID*/, READ_ONLY, EXCLUSIVE, logical_region_));
    dot_launcher.region_requirements[0].add_field(lhs_fid_);
    dot_launcher.region_requirements[0].add_field(rhs_fid_);
    fm_ = runtime->execute_index_space(ctx, dot_launcher);
    return this;
}

double DotTask::get_result() {
    double result = 0.0;
    for (int i = 0; i < n_partitions_; i++) {
        result += fm_.get_result<double>(i);
    }
    return result;
}

double DotTask::task_body(const Task *task, const std::vector<PhysicalRegion> &regions, Context ctx, Runtime *runtime) {
    assert(regions.size() == 1);
    assert(task->regions.size() == 1);
    assert(task->arglen == sizeof(DotArgs));
    DotArgs dotArgs = *(const DotArgs *)task->args;
    FieldID lhs_fid = dotArgs.lhs_fid;
    FieldID rhs_fid = dotArgs.rhs_fid;

    const FieldAccessor<READ_ONLY, double, 1> acc_lhs(regions[0], lhs_fid);
    const FieldAccessor<READ_ONLY, double, 1> acc_rhs(regions[0], rhs_fid);

    Rect<1> rect = runtime->get_index_space_domain(ctx, task->regions[0].region.get_index_space());
    double result = 0.0;
    for (PointInRectIterator<1> pir(rect); pir(); pir++) {
        result += acc_lhs[*pir] * acc_rhs[*pir];
    }
    return result;
}

DotTask::~DotTask() {
    // Remove legion runtime stuff
    Runtime *runtime = Runtime::get_runtime();
    Context ctx = runtime->get_context();
    runtime->destroy_logical_region(ctx, logical_region_);
    runtime->destroy_field_space(ctx, field_space_);
    runtime->destroy_index_space(ctx, index_space_);
    cout << "destructor" << endl;
}

void InitTask::task_body(const Task *task, const std::vector<PhysicalRegion> &regions, Context ctx, Runtime *runtime) {
    assert(regions.size() == 1);
    assert(task->regions.size() == 1);
    assert(task->regions[0].privilege_fields.size() == 1);

    FieldID fid = *(task->regions[0].privilege_fields.begin());
    const FieldAccessor<WRITE_DISCARD,double,1> acc(regions[0], fid);
    Rect<1> rect = runtime->get_index_space_domain(ctx, task->regions[0].region.get_index_space());
    for (PointInRectIterator<1> pir(rect); pir(); pir++) {
        acc[*pir] = drand48();
    }
}

Notice how a DotTask is created 3 times, and the storage required for each tasks persists even after the objects destructor has been called.

Which branch are you running this on?
Most likely the problem right now is the default mapper is setting the garbage collection priority for the physical instances of those regions to "never collect" which prevents those instances from ever being collected, even though the logical regions for those instances have been destroyed. This is a heuristic in the default mapper to optimize for the common case of applications reusing logical regions for long periods of time, but it does mean that instances stick around for the duration of a run.
Legion destroys logical regions and their meta-data independently from the physical instances made to store the data contained in those regions. It's debatable whether it's more surprising for an application to delete a logical region and not have the instances for that region collected, or whether it is more surprising for an instance to be deleted when the mapper did say never to collect the instance. Right now we come down on the later side since instances are really the purview of the mapper, but we you could make the case that it should be the other way.

I'm working from the master branch (pulled and rebuilt just to confirm everything was up-to-date, still have the same issue).
I also tried overriding the the DefaultMapper to always return LEGION_GC_FIRST_PRIORITY from default_policy_select_garbage_collection_priority (as well as disable caching just because I saw it), the code for which is below, but I'm still seeing the same behavior of the regions persisting,
class GarbageCollectPriorityMapper : public DefaultMapper {
  public:
    GarbageCollectPriorityMapper(Machine machine, Runtime *rt, Processor p): DefaultMapper(rt->get_mapper_runtime(), machine, p) { }
  public:
    virtual int default_policy_select_garbage_collection_priority(
        MapperContext ctx,
        MappingKind kind,
        Memory memory,
        const PhysicalInstance &inst,
        bool meets_fill_constraints,
        bool reduction
    ) {
        return LEGION_GC_FIRST_PRIORITY;
    }

    virtual DefaultMapper::CachedMappingPolicy default_policy_select_task_cache_policy(MapperContext ctx, const Task &task) {
      return DEFAULT_CACHE_POLICY_DISABLE;
    }
};

// Code to replace Default Mapper
void mapper_registration(Machine machine, Runtime *rt, const std::set<Processor> &local_procs) {
    for (std::set<Processor>::const_iterator it = local_procs.begin(); it != local_procs.end(); it++) {
        rt->replace_default_mapper(new GarbageCollectPriorityMapper(machine, rt, *it), *it);
    }
}

// ...

int main(int argc, char **argv) {
    // ...same stuff as before
    Runtime::add_registration_callback(mapper_registration);
    return Runtime::start(argc, argv);
}


2 issues : image file type change to ’.jpeg‘, and big image file upload error.

flagrow/upload extension version: 0.4.8 and some previous
flarum version: beta6
Upload adapter causing issues:

issues 1 : when .jpg upload , it auto change to .jpeg .
issues 2 : when upload a image with more than 2mb , get error and upload fail .PHP configer is ok with 20mb max upload（post_max_size、upload_max_filesize）,and 40s max_execution_time.

What is the exact problem you experience with renaming .jpg to .jpeg?
Did you update the max file size in the extension setting page too, see image:

auto rename is not necessary and it's just wrong
of course, i have set to 20480

auto rename is not necessary and it's just wrong

I disagree. But feel free to offer proper argumentation so at least I have the chance to reconsider, because "not necessary" and "just wrong" doesn't tell me a thing. The reason to do so is to force actual mime types to be used. This prevents abuse of the upload feature. Feel free to read this article and tell me what you think afterward.
Related to the second thing, what error do you get. Uploads still have to be handled by the frontend, I haven't taken into account (nor done any tests with) long running uploads yet (eg movies of several hundreds megabytes).

Mind you, there are 6 different accepted JPEG extensions (.jpg, .jpeg, .jpe, .jif, .jfif, .jfi) and they all should work the same. That's because the MIME type is all JPEG. So, no, it's not wrong and while it might not be necessary it provides some consistency for the extension (which now can look for just one file type instead of 6).

@jordanjay29 @Luceos so great thinking. i have no word to comment.
just 3.5mb jpg and i get error.

but when i use Image Upload 0.3.1, all fine.

by the way, jpg is more popular than jpeg, why not auto change to jpg.

Do you see any errors in your webserver log or storage/logs/flarum.log file that might relate to the upload issue?

@DearTanker  You should check max_post_size in /etc/php.ini. It defaults to 2M.

I've improved error handling of the upload methods. They now verify ini-settings and throw related exceptions. Not going to change logic for jpeg file types.


Historical Data stops with message HMDS query returned no data

Received from Alexander:
I am trying to get continuous ES (or NQ) with this command
python download_bars.py --security-type CONTFUT --start-date 20100101 --end-date 20230401 --exchange CME --size "4 hours" --max-days ES
but only getting about 1 month of data, followed by errors referring to the latest ESM3 contract.
Using the latest TWS  Build 10.22.1h, Apr 5, 2023 3:17:15 PM
I can see  'durationStr': '1 D' in the request, is that right?
22:28:35,83 ibapi.wrapper INFO ANSWER error {'reqId': 22, 'errorCode': 162, 'errorString': 'Historical Market Data Service error message:HMDS query returned no data: ESM3@CME Trades'}
22:28:35,85 ibapi.wrapper ERROR ERROR 22 162 Historical Market Data Service error message:HMDS query returned no data: ESM3@CME Trades
22:28:35,85 root ERROR Error. Id: 22 Code 162 Msg: Historical Market Data Service error message:HMDS query returned no data: ESM3@CME Trades

I'm able to reproduce this issue. It looks like it stops at 2023-03-12, which is a Sunday. Not sure what's going on, but I do recall seeing this error message before.


Host Finite State Binary Scan Plugin

Repository URL
https://github.com/FiniteStateInc/binary-scan-jenkins
New Repository Name
finite-state-binary-scan-plugin
Description
The Finite State binary-scan allows you to easily integrate the Finite State Platform into Jenkins.
GitHub users to have commit permission
@cpfarherFinitestate @phillipcurl
Jenkins project users to have release permission
@cpfarherFinitestate
@phillipcurl
Issue tracker
GitHub issues

Security audit, information and commands
The security team is auditing all the hosting requests, to ensure a better security by default.
This message informs you that a Jenkins Security Scan was triggered on your repository.
It takes ~10 minutes to complete.
Commands
The bot will parse all comments, and it will check if any line start with a command.
Security team only:

/audit-ok => the audit is complete, the hosting can continue :tada:.
/audit-skip => the audit is not necessary, the hosting can continue :tada:.
/audit-findings => the audit reveals some issues that require corrections :pencil2:.

Anyone:

/request-security-scan => the findings from the Jenkins Security Scan were corrected, this command will re-scan your repository :mag:.
/audit-review => the findings from the audit were corrected, this command will ping the security team to review the findings :eyes:.
	It's only applicable when the previous audit required changes.

Only one command can be requested per comment.

(automatically generated message, version: 1.28.4)

The Jenkins Security Scan discovered 21 finding(s) :mag:.
Please follow the instructions below for every identified issues:

Implement the recommended fix to address the issue.
If you think it's a false positive, suppress the warning directly within the code.
Alternative, you write an explanation here about why you think it's irrelevant. That will require a manual review, leading to a slower process.

After addressing the findings through one of the above methods:

If all modifications have been made to the code, please initiate a new security scan by triggering the /request-security-scan command.
If there are any unresolved findings (those not corrected or suppressed), request a review from the Jenkins security team by using the /audit-review command.

Jenkins: Missing permission check on a form fill web method with credentials lookup
You can find detailed information about this finding here.
UploadBinaryScanRecorder.java#377
doFillFiniteStateOrganizationContextItems should perform a permission check before calling #lookupCredentials

UploadBinaryScanRecorder.java#367
doFillFiniteStateSecretItems should perform a permission check before calling #lookupCredentials

UploadBinaryScanRecorder.java#357
doFillFiniteStateClientIdItems should perform a permission check before calling #lookupCredentials

Stapler: Missing POST/RequirePOST annotation
You can find detailed information about this finding here.
UploadBinaryScanRecorder.java#417
Potential CSRF vulnerability: If DescriptorImpl#doCheckFilePath connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#413
Potential CSRF vulnerability: If DescriptorImpl#doCheckVersion connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#409
Potential CSRF vulnerability: If DescriptorImpl#doCheckAssetId connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#404
Potential CSRF vulnerability: If DescriptorImpl#doCheckFiniteStateOrganizationContext connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#399
Potential CSRF vulnerability: If DescriptorImpl#doCheckFiniteStateSecret connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#394
Potential CSRF vulnerability: If DescriptorImpl#doCheckFiniteStateClientId connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#377
Potential CSRF vulnerability: If DescriptorImpl#doFillFiniteStateOrganizationContextItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#367
Potential CSRF vulnerability: If DescriptorImpl#doFillFiniteStateSecretItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#357
Potential CSRF vulnerability: If DescriptorImpl#doFillFiniteStateClientIdItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

Stapler: Missing permission check
You can find detailed information about this finding here.
UploadBinaryScanRecorder.java#417
Potential missing permission check in DescriptorImpl#doCheckFilePath

UploadBinaryScanRecorder.java#413
Potential missing permission check in DescriptorImpl#doCheckVersion

UploadBinaryScanRecorder.java#409
Potential missing permission check in DescriptorImpl#doCheckAssetId

UploadBinaryScanRecorder.java#404
Potential missing permission check in DescriptorImpl#doCheckFiniteStateOrganizationContext

UploadBinaryScanRecorder.java#399
Potential missing permission check in DescriptorImpl#doCheckFiniteStateSecret

UploadBinaryScanRecorder.java#394
Potential missing permission check in DescriptorImpl#doCheckFiniteStateClientId

UploadBinaryScanRecorder.java#377
Potential missing permission check in DescriptorImpl#doFillFiniteStateOrganizationContextItems

UploadBinaryScanRecorder.java#367
Potential missing permission check in DescriptorImpl#doFillFiniteStateSecretItems

UploadBinaryScanRecorder.java#357
Potential missing permission check in DescriptorImpl#doFillFiniteStateClientIdItems

/request-security-scan

The Jenkins Security Scan discovered 9 finding(s) :mag:.
Please follow the instructions below for every identified issues:

Implement the recommended fix to address the issue.
If you think it's a false positive, suppress the warning directly within the code.
Alternative, you write an explanation here about why you think it's irrelevant. That will require a manual review, leading to a slower process.

After addressing the findings through one of the above methods:

If all modifications have been made to the code, please initiate a new security scan by triggering the /request-security-scan command.
If there are any unresolved findings (those not corrected or suppressed), request a review from the Jenkins security team by using the /audit-review command.

Stapler: Missing POST/RequirePOST annotation
You can find detailed information about this finding here.
UploadBinaryScanRecorder.java#406
Potential CSRF vulnerability: If DescriptorImpl#doFillFiniteStateOrganizationContextItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#387
Potential CSRF vulnerability: If DescriptorImpl#doFillFiniteStateSecretItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#360
Potential CSRF vulnerability: If DescriptorImpl#doFillFiniteStateClientIdItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

Stapler: Missing permission check
You can find detailed information about this finding here.
UploadBinaryScanRecorder.java#461
Potential missing permission check in DescriptorImpl#doCheckFilePath

UploadBinaryScanRecorder.java#456
Potential missing permission check in DescriptorImpl#doCheckVersion

UploadBinaryScanRecorder.java#451
Potential missing permission check in DescriptorImpl#doCheckAssetId

UploadBinaryScanRecorder.java#445
Potential missing permission check in DescriptorImpl#doCheckFiniteStateOrganizationContext

UploadBinaryScanRecorder.java#439
Potential missing permission check in DescriptorImpl#doCheckFiniteStateSecret

UploadBinaryScanRecorder.java#433
Potential missing permission check in DescriptorImpl#doCheckFiniteStateClientId

/hosting re-check

/request-security-scan

The Jenkins Security Scan discovered 9 finding(s) :mag:.
Please follow the instructions below for every identified issues:

Implement the recommended fix to address the issue.
If you think it's a false positive, suppress the warning directly within the code.
Alternative, you write an explanation here about why you think it's irrelevant. That will require a manual review, leading to a slower process.

After addressing the findings through one of the above methods:

If all modifications have been made to the code, please initiate a new security scan by triggering the /request-security-scan command.
If there are any unresolved findings (those not corrected or suppressed), request a review from the Jenkins security team by using the /audit-review command.

Stapler: Missing POST/RequirePOST annotation
You can find detailed information about this finding here.
UploadBinaryScanRecorder.java#406
Potential CSRF vulnerability: If DescriptorImpl#doFillFiniteStateOrganizationContextItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#387
Potential CSRF vulnerability: If DescriptorImpl#doFillFiniteStateSecretItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

UploadBinaryScanRecorder.java#360
Potential CSRF vulnerability: If DescriptorImpl#doFillFiniteStateClientIdItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

Stapler: Missing permission check
You can find detailed information about this finding here.
UploadBinaryScanRecorder.java#461
Potential missing permission check in DescriptorImpl#doCheckFilePath

UploadBinaryScanRecorder.java#456
Potential missing permission check in DescriptorImpl#doCheckVersion

UploadBinaryScanRecorder.java#451
Potential missing permission check in DescriptorImpl#doCheckAssetId

UploadBinaryScanRecorder.java#445
Potential missing permission check in DescriptorImpl#doCheckFiniteStateOrganizationContext

UploadBinaryScanRecorder.java#439
Potential missing permission check in DescriptorImpl#doCheckFiniteStateSecret

UploadBinaryScanRecorder.java#433
Potential missing permission check in DescriptorImpl#doCheckFiniteStateClientId

/request-security-scan

The Jenkins Security Scan did not find anything dangerous with your plugin, congratulations! :tada:

:bulb: The Security team recommends that you are setting up the scan in your repository by following our guide.

/hosting re-check

/request-security-scan

The Jenkins Security Scan did not find anything dangerous with your plugin, congratulations! :tada:

:bulb: The Security team recommends that you are setting up the scan in your repository by following our guide.

/hosting re-check

/hosting re-check

/request-security-scan

Related with this comment https://github.com/jenkins-infra/repository-permissions-updater/issues/3929#issuecomment-2137429941 I already configure the security scan I think. Please, can you confirm that it is ok?
I don't understand why it has the needs-fix label. Please, can you clarify Which is the issue with this PR so I could fix it? Thanks!

Its failing to parse the issue template here: https://github.com/jenkins-infra/repository-permissions-updater/actions/runs/9304869956/job/25610484968
Something will be wrong in the issue description that's breaking it

The Jenkins Security Scan did not find anything dangerous with your plugin, congratulations! :tada:

:bulb: The Security team recommends that you are setting up the scan in your repository by following our guide.

Its failing to parse the issue template here: https://github.com/jenkins-infra/repository-permissions-updater/actions/runs/9304869956/job/25610484968
Something will be wrong in the issue description that's breaking it

Oh, ok thanks. So as I understand is something that a member of the team needs to investigate?. I re check the description but I didn't see any wrong. Please LMK if I could help on some way. Thanks!

You had changed the heading level of the repository url, it should work now

The bom version specified in the pom should match with the jenkins.version. Once aligned, make sure the plugin builds with mvn clean verify package.
https://github.com/FiniteStateInc/binary-scan-jenkins/blob/main/src/main/resources/com/finitestate/uploadbinaryscan/UploadBinaryScanRecorder/config.jelly#L58-L80 inline JS is banned within CSP. Please outsource the code into a js file and load it via stapler adjuncts.
https://github.com/FiniteStateInc/binary-scan-jenkins/tree/main/src/main the path specified should match your GAV in the pom, io.jenkins.plugins
https://github.com/FiniteStateInc/binary-scan-jenkins/blob/b16c3234972806234eeaea1bc1487fdbf68ffc76/pom.xml#L56-L69 instead of shading the dependency yourself, you can depend on the Jenkins plugin equivalent: https://plugins.jenkins.io/docker-java-api/dependencies/
Please remove the other unnecessary dependencies from your pom.

/request-security-scan

/hosting re-check

The bom version specified in the pom should match with the jenkins.version. Once aligned, make sure the plugin builds with mvn clean verify package.
https://github.com/FiniteStateInc/binary-scan-jenkins/blob/main/src/main/resources/com/finitestate/uploadbinaryscan/UploadBinaryScanRecorder/config.jelly#L58-L80 inline JS is banned within CSP. Please outsource the code into a js file and load it via stapler adjuncts.
https://github.com/FiniteStateInc/binary-scan-jenkins/tree/main/src/main the path specified should match your GAV in the pom, io.jenkins.plugins
https://github.com/FiniteStateInc/binary-scan-jenkins/blob/b16c3234972806234eeaea1bc1487fdbf68ffc76/pom.xml#L56-L69 instead of shading the dependency yourself, you can depend on the Jenkins plugin equivalent: https://plugins.jenkins.io/docker-java-api/dependencies/
Please remove the other unnecessary dependencies from your pom.

Thanks for you review. It's done.

/hosting re-check

/hosting host


all overlays broken since 0.5.20

repro: https://github.com/stefanprobst/issue-keystatic-overlays
in current keystatic versions, all overlays (dialogs etc.) are not shown. i only see the dimmed background, but nothing else.
last known version to work is 0.5.19 for me.
to reproduce, clone the repro and in the keystatic ui, add a "Post" and click the "Add" Cards button => see the background being dimmed but nothing else being shown.
when pinning keystatic to 0.5.19 everything works:
"pnpm": {
  "overrides": {
    "@keystatic/core": "0.5.19"
  }
},

I can confirm. I am facing this as well.


No Releases

https://redis.com/lp/hiredis/ links here for releases, which is a page saying There aren’t any releases here
Where can I get a release?

You can use our tags


Fix local redirect policies selecting host networked pods

See commit messages.
Fixes: da35c88eb9f8 ("k8s/watchers: don't silently ignore (*K8sWatcher).updatePodHostData error")
Fixes: 0ab4fa184d3a ("pkg/k8s: ignore certain ipcache errors")
Related: #16920
Release note
Fix a bug with local redirect policies selecting host networked pods as local endpoints not taking effect.

/test

LGTM. One minor nit, the last commit refers to commit 3805bae724e7 but github doesn't recognize it. Is that meant to be 0ab4fa1 ?

Yes, I've already fixed it in both PR and commit descriptions. Was waiting to push the latest commits until the ongoing CI run is complete.

net-next hit https://github.com/cilium/cilium/issues/18520.

 Other reviews are in, and your review comments have been addressed.


Adding DNS TTL AuTests.

Add AuTests that verify the behavior of ATS when DNS goes down. The following configurations are exercised in this test:
        "proxy.config.hostdb.ttl_mode"
        "proxy.config.hostdb.timeout"
        "proxy.config.hostdb.serve_stale_for"

Cherry-picked to v9.1.x branch.


Cannot change any css value after editing color with firepicker

Hi,
I am on Firefox 5.0 / Firebug 1.7.3
In the HTML Tab , after editing a color with firepicker, I cant change any css value until reload the page  ...
the value box appear empty, you can enter a new value, but it doesnt change the original value after validate.
Is there a solution ?
Thanks
Didier

Same issue here. Makes Firebug with Firepicker unusable, unfortunately.

Firepicker 1.3.6
Firebug 1.8.4
Firefox 7.0.1

Hey guys,
this is really frustrating, as I'm unable to repro this on a windows machine :(

Windows 7 32-bit
Firefox 7.0.1
Firebug 1.8.4
Firepicker 1.3.6

Maybe I need to be running the 64-bit version of windows...

you could try...though it's very strange you don't have the same problem...
I have windows ultimate 64bit indeed, and I keep having the same problem also in firefox 8 (with all the addons in their latest versions)
As I wrote earlier, the problem happened after the upgrade of firebug from version 1.6 to version 1.7, maybe you should try to contact the firebug developers...

Tested this on Windows x64 machine FF 8.0.1, FB 1.8.4b1, Firepicker 1.3.6, still no luck :(. Do you get any errors in the Firefox´s Error Console Ctrl+Shift+J?

well, in this very page, as soon as the page finish ti load, I found some of these (and similar others always related to css):
Avviso: Errore durante l'interpretazione di 'display'.  Dichiarazione tralasciata.
File sorgente: https://github.com/thedarkone/firepicker/issues/12#issuecomment-3276597
Riga: 0
and these:
Avviso: L'utilizzo di getAttributeNodeNS() è deprecato. Al suo posto utilizzare getAttributeNS().
File sorgente: https://github.com/thedarkone/firepicker/issues/12#issuecomment-3276597
Riga: 0
Avviso: L'utilizzo di getAttributeNode() è deprecato. Al suo posto utilizzare getAttribute().
File sorgente: https://github.com/thedarkone/firepicker/issues/12#issuecomment-3276597
Riga: 0
Avviso: L'utilizzo di nodeName su attributi è deprecato. Al suo posto utilizzare name.
File sorgente: https://github.com/thedarkone/firepicker/issues/12#issuecomment-3276597
Riga: 0
Avviso: L'utilizzo di nodeValue su attributi è deprecato. Al suo posto utilizzare value.
File sorgente: https://github.com/thedarkone/firepicker/issues/12#issuecomment-3276597
Riga: 0
sorry if they are in italian, I'm sure that google translate will give you the respective english ones ;)

Hi,
Windows 7 x64 - Firefox 9.0.1 Firebug 1.8.4
Perhaps this will help you
After editing a color with firepicker, I cannot change any other css value like height for exemple using the numeric key, but if I use up or down arrow I got this error :
Erreur : uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHTMLInputElement.setSelectionRange]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://firebug_rjs/editor/editor.js :: <TOP_LEVEL> :: line 766"  data: no]
best regards

It means nothing, I was just hoping something might show up ;(.
Alright, since we know the problem shows up somewhere between Firebug 1.6.2 and 1.7.0 I tried to look at the diffs and see if anything pops up. The only main addition to the editor's code seems to be a more evolved handling of text selection added here. Can you see if removing it from Firebug fixes the problem?
Here are the two FB 1.9 test xpi archives: one, two. Please test both of them.

Same thing for me,
No more problem with a new profile,
I reinstall all extensions and it work again ...
Thank you all !!!

Woooot!!!
Would have been nice to get to the bottom of this anyways...


Apply hilbert stc

Fixes #12310.
Updating mne.filter.MixinFilter methods to work with Source Estimated data

working to fix the failed tests

All tests passed.
I think the functions are decent.
For SourceEstimate.resample the function overwrite the MixinFilter.resample so I did not update the latter. However I think that SourceEstimate.resample can be integrated into MixinFilter.resample. Not sure if this would have any implication on speed but I think it would improve the code.

I have addressed all of the suggestions. I also added one function to test to stc.apply_function in test_source_estimate.py . For the object.apply_hilbert function, the test_evoked.py has the test function for raw, epochs and evoked objects, I wonder if the tests should be added in the same function. Also, to test object.apply_function there is pre-existing data in ../io/tests/data . Should we use for example raw data to generate sources? or is there a way to get access for stc_test_data ?


Fixed Manifest link used in 2.13.0 docs

Signed-off-by: Anirudh Sharma<EMAIL_ADDRESS>
What this PR does / why we need it:
Fixes Manifest link used in 2.13.0 docs
Which issue this PR fixes
fixes https://github.com/litmuschaos/litmus/issues/3798
Special notes for your reviewer:
Checklist:

[ ] Fixes #
[ ] Signed the commit for DCO to be passed
[ ] Labelled this PR & related issue with documentation tag

Thanks for the PR @AnirudhBot !

Thanks for the fix @AnirudhBot 🚀

@AnirudhBot, the typo in <VERSION> is there in the previous versions of the doc as well. Can you make the changes in all of them?

@AnirudhBot, the typo in <VERSION> is there in the previous versions of the doc as well. Can you make the changes in all of them?

Yeah sure! If I am not wrong, this typo got introduced from 2.11.0 only