[core] fix n^2 code path in marking text

This caused some unnecessary slowdowns and GCs when adding many (thousands) of text markers. I looked around and couldn't find anything relying on new versions of the markedSpans array needing to be referentially different, but I could have missed something.

I think the history code that handles undoing marks does rely on immutable span arrays.
I suspect a lot of efficiency could be gained by adding a mass-mark-adding interface. Would that help in your case?

Yes, we'd definitely use that! We already wrap things in an operation, but a batch method would be even better.

On closer look, the interface doesn't really allow for a very elegant way to define a mass-add method, so attached patch just optimizes adding spans within a transaction. Let me know whether it fixes your slowdown.


Add Request Header Authorization

Implements a middleware handler to check the request header for a "auth_code" value to match the configured "authentication_code" in config.json (optional).

https://github.com/maddox/harmony-api/pull/73/commits/4016e9675a23cdd394a8b1fc1004379221016b5d
https://github.com/maddox/harmony-api/pull/73/commits/4344e5f740a2599e050d11b337c9c3e2e8b27f7
https://github.com/maddox/harmony-api/pull/73/commits/c30c37a176fb70bcb7bcdd94ccbd101ffebd9511a


Do you have a chinese pre-training model about layoutlm

you know, for students, we cann't train the model because of the cost

@wolfshow

@hyybuaa Language expansion is one of our future work, but no eta for now. Will let you know once we have the models for other languages

thank you!!


Updated old app logo to Image Hub logo

fixes #7
Signed-off-by: ashiscs<EMAIL_ADDRESS>

Thanks, @ashiscs. Can you post a screenshot to confirm that the image fits well?

Thanks, @ashiscs. Can you post a screenshot to confirm that the image fits well?

Yes sir, image fits well !

@shivaylamba did we verify that this fits as expected in the app?

@shivaylamba, any word here? https://github.com/layer5io/image-hub/pull/27#issuecomment-653569633

@ashiscs @shivaylamba will either of you confirm that when this app is built that the new logo is of the right size?


Microsoft AutoUpdate json invalid

https://github.com/Jamf-Custom-Profile-Schemas/ProfileManifestsMirror/blob/main/manifests/ManagedPreferencesApplications/com.microsoft.autoupdate2.json
Jamf says JSON is invalid. JSON Validator says, it's not.

I dug into this, and it seems the part Jamf doesn't like is the date type, which appears in several dictionaries like this:
"ForcedUpdateDate": {
    "type": "date",
    "title": "Forced Update Date",
    "description": "The date and time to force the update."
},

In the resulting plist, this key type should be date, so this might be a bug in Jamf's validation.

I dug into this, and it seems the part Jamf doesn't like is the date type, which appears in several dictionaries like this:
"ForcedUpdateDate": {
    "type": "date",
    "title": "Forced Update Date",
    "description": "The date and time to force the update."
},

In the resulting plist, this key type should be date, so this might be a bug in Jamf's validation (PI110413).

I removed all entries of that quoted text and it worked! Thank you so much.

Hello, please correct me if I'm wrong but from my understanding JSON Schema does not accept "type": "data"and only accepts date as a format of string, "type": "string", "format": "date".
Not all JSON validators seem to check for the correct "type". An example, https://jsonlint.com/ says the JSON is valid but just below the input box they have a note "Dates, and similar object types, aren't adequately supported and should be converted to strings". I personally prefer https://www.jsonschemavalidator.net/ which does match Jamf's validator in the "type": "data" being invalid.
All this being said, there is a feature request to have Jamf handle the date formatted string and convert it to the plist date so please upvote that here: https://ideas.jamf.com/ideas/JN-I-15984 . This will require the JSON being updated to the "type": "string", "format": "date". I'd be more than happy to submit a pull request as needed.
I have not done any testing to confirm if Microsoft can handle the date formatted as a string or not.


Better server params and fields

This is a lot, but the net is that:

Unsupported fields were removed
Supported (but missing) fields were added
A ton of information in parameters were added (via Field annotations)

Reasoning should be in commit messages for individual decisions, with some more details here: https://github.com/Stonelinks/llama-cpp-python/issues/3
The result of all this should be better documentation from the swagger / openapi docs available from the server, as well as improved clients generated from openapi.json (up next)

Upvote. Muchas gracias! :+1:

@Stonelinks great work!
I want to merge this in but I'd like to keep the unsupported fields in the API as they were before. Otherwise I'm very happy with the addition of the Fields object because it works really well with how I've implemented CLI options for the server.


Test the system by different users

Comment what is good and what is not
Describe features that you want to add in project (if any)

I tested the project on my PC and found that project works well. It seems that the only one flaw of our API is that it does not send single files without archiving. I suppose this feature should be added.

Conducted manual tests of API and frontend interface showed that the program works fine, and the speed of conversion is acceptable. There are no artifacts after conversion on the files that I used for testing.
Required features: I agree with @zaqbez39me that the single file should not be archived after conversion.
Disadvantages: Frontend is not adaptive.
Note: frontend is not adaptive since the converter is designed to be used only as an API from another backend, and it is not planned to be used on mobile devices. Also, I emphasize that the interface is only used as a demo for a presentation, and it is not planned to be used in future.

Everything works as it should. Nothing to add to my teammates comments

Tested by 3 team members, can be closed.

Aproximately 14 files were converted by the programm and in 2-3 of them several minor issues were detected. Seems that there are no ways to somehow improve the quality of convertion without writing writing the whole convertion algorithm from nothing. It will require much longer time resources, but the in the result we will get pretty the same product(in terms of quality), but with some "bonus" features.

For this moment, 4 team members tested our system. This issue can be closed.


ViaVersion doesn't seem to be detected

Vision：
Geyser-Fabric-1.4.3-SNAPSHOT
ViaVersion-4.2.2-SNAPSHOT
fabric-server-mc.1.17.1-loader.0.13.3-launcher.0.10.2
Bedrock1.18.30
details
ViaVersion successfully loaded on the server
Geyser also seems to be loaded successfully
1.18.2 java version players can also enter the server
But Bedrock Edition show
Outdated Geyser proxy server! This server supports the following Bedrock Edition versions: 1.17.10/1.17.11, 1.17.30, 1.17.40

Your running an old version of geyser-fabric, please update it to join on newer bedrock versions.
https://ci.opencollab.dev/job/GeyserMC/job/Geyser-Fabric/job/java-1.18/

Your running an old version of geyser-fabric, please update it to join on newer bedrock versions. https://ci.opencollab.dev/job/GeyserMC/job/Geyser-Fabric/job/java-1.18/

My server is 1.17.1,https://ci.opencollab.dev/job/GeyserMC/job/Geyser-Fabric/job/java-1.18 isn't work.
and I want to let Bedrock Edition to join it.
I use Viafabric to allow the high version to join,and it work will.Java 1.18.2 can join it.but Bedrock Edition can't join


Fix for pagination for grouped vulnerabilities. Backend was returning the wrong number of entities, thereby breaking pagination.

🗣 Description
This fix will allow the most common vulnerabilities to be shown with pagination. This will allow the user to see more than just one page of results when looking at the /vulnerabilities/inventory/grouped by clicking on the most common vulnerabilities on the home page of crossfeed
💭 Motivation and context
This will close issue 1783 (/inventory/vulnerabilities/grouped only returns first 15 results with no pagination at bottom)
It is a small change on the backend
🧪 Testing
Manual testing and ran npm test and no changes
✅ Pre-approval checklist

[X] This PR has an informative and human-readable title.
[X] Changes are limited to a single goal - eschew scope creep!
[X] All future TODOs are captured in issues, which are referenced
in code comments.
[X] All relevant type-of-change labels have been added.
[X] I have read the CONTRIBUTING document.
[X] These code changes follow cisagov code standards.
[X] All relevant repo and/or project documentation has been updated
to reflect the changes in this PR.
[ ] Tests have been added and/or modified to cover the changes in this PR.
[X] All new and existing tests pass.

✅ Pre-merge checklist

[ ] Finalize version.

✅ Post-merge checklist

[ ] Create a release.

Tested and works as advertised.

Marked OBE - Due to planned redesign in Q2.

Marked OBE - Due to planned redesign in Q2.


chore: release 1.0.0

:robot: I have created a release *beep* *boop*
1.0.0 (2019-05-13)
Bug Fixes

DEADLINE_EXCEEDED is idempotent (#5) (dfe31b9)

Features

initial commit of library for review (7a08281)
initial generation of library (#1) (adfb92f)
write quickstart sample and generate READMEs (#2) (c2ef972)

Release is at https://github.com/googleapis/nodejs-web-risk/releases/tag/v1.0.0

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


No storage provided

What version of fuels-ts are you using?
0.89.1
Steps to Reproduce
Used default connectors in the next app., getting the error while building the application during deploying.
Expected Behavior
the error should not be there
Actual Behavior
No storage provided

error:-

Error: No storage provided
    at e.getStorage (/home/chappie/fuelart_app/.next/server/chunks/987.js:23:241993)
    at new e (/home/chappie/fuelart_app/.next/server/chunks/987.js:23:241401)
    at D (/home/chappie/fuelart_app/.next/server/chunks/987.js:23:248250)
    at 8141 (/home/chappie/fuelart_app/.next/server/chunks/672.js:1:2371)
    at t (/home/chappie/fuelart_app/.next/server/webpack-runtime.js:1:142)
    at F (/home/chappie/fuelart_app/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:91984)
    at $ (/home/chappie/fuelart_app/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:90535)
    at rE (/home/chappie/fuelart_app/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:34657)
    at nO (/home/chappie/fuelart_app/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:60678)
    at nI (/home/chappie/fuelart_app/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:65445)
(node:751587) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.

Thanks for raising this issue, it seems to be that you are trying to access the window before it's initialized. Could you provide a link to the next app and steps to reproduce this on the repo?

hey @maschad https://github.com/chappie1998/my-fuel-project/tree/storage-bug I made a dummy repo for bug. you just need to build the repo.

this one looks like it's in connector side, instead of sdk @chappie1998 , by any change are you using the defaultConnectors and building it in nodejs env?

@LuizAsFight yes

@chappie1998 I haven't been able to reproduce this error on my side. I've built the project and I have it running at localhost (see the screenshot attached).

Below is my fuelup show output for my toolchain

Could you please provide clear step-by-step instructions on how to reproduce this exact error?
As @LuizAsFight asked are you using defaultConnectors to deploy to a node environment? As the window would not be available there.

we are aware of this problem, should be fixed soon https://github.com/FuelLabs/fuel-connectors/issues/107

I'll close this issue as it's not directly related to this repo. We can continue tracking it at https://github.com/FuelLabs/fuel-connectors/issues/107


[Feature]  Add a new MediaLibrary Component

Feature Request
Add a new <MediaLibrary> component that will show the Cloudinary Media Library Widget
Found the Media Library Widget documentation here https://cloudinary.com/documentation/media_library_widget
Check this React examples as reference https://github.com/cloudinary-community/cloudinary-examples/tree/main/examples/react-ts-media-library

Hey @matiasfha I would love to work on it.

Great!! All yours!
If you have any question please ping me

Hi @aggmoulik, how are things going? Were you able to work on this feature?
Thanks


[Xamarin.iOS] DryIocTypeResolver.Resolve (System.Type type) SIGABRT: Operation is not supported on this platform.

DryIoc.dll vesions: 5.2.2, 5.2.1, 5.2.0, 5.1.0, 5.0.2, 5.0.1, 4.8.8
iOS version: 15.7
Xamarin.iOS: <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>
The container is created like this:
var container = CurrentPlatform == Device.iOS
				? new Container(Rules.Default.WithUseInterpretation())
				: new Container();

Maybe this line - https://github.com/dadhi/DryIoc/blob/master/src/DryIoc/FastExpressionCompiler.cs#L459
This only happens in the release configuration (TestFlight) when navigating to the page again (Xamarin.Forms project)
StackTrace:
Xamarin Exception Stack:
System.PlatformNotSupportedException: Operation is not supported on this platform.
at System.Reflection.Emit.DynamicMethod..ctor (System.String name, System.Type returnType, System.Type[] parameterTypes, System.Type owner, System.Boolean skipVisibility) <0x103346df0 + 0x00010> in <ae4d2b2e1a52451bbb0fbe726a40b592#80ffc4493c7251d006b14594f2d9afb9>:0
at DryIoc.FastExpressionCompiler.LightExpression.ExpressionCompiler.CompileNoArgsNew (System.Reflection.ConstructorInfo ctor, System.Type delegateType, System.Type[] closurePlusParamTypes, System.Type returnType) <0x1048b18e4 + 0x0006f> in <78cda8c2f8b0438899aa3a8eeea13482#80ffc4493c7251d006b14594f2d9afb9>:0
at DryIoc.FastExpressionCompiler.LightExpression.ExpressionCompiler.TryCompileBoundToFirstClosureParam (System.Type delegateType, DryIoc.FastExpressionCompiler.LightExpression.Expression bodyExpr, DryIoc.FastExpressionCompiler.LightExpression.IParameterProvider paramExprs, System.Type[] closurePlusParamTypes, System.Type returnType, DryIoc.FastExpressionCompiler.LightExpression.CompilerFlags flags) <0x1048b19f8 + 0x00173> in <78cda8c2f8b0438899aa3a8eeea13482#80ffc4493c7251d006b14594f2d9afb9>:0
at DryIoc.FactoryDelegateCompiler.CompileToFactoryDelegate (DryIoc.FastExpressionCompiler.LightExpression.Expression expression, System.Boolean preferInterpretation) <0x10480bff8 + 0x0011b> in <78cda8c2f8b0438899aa3a8eeea13482#80ffc4493c7251d006b14594f2d9afb9>:0
at DryIoc.Container.DryIoc.IResolver.Resolve (System.Type serviceType, DryIoc.IfUnresolved ifUnresolved) <0x1047ee1bc + 0x0031b> in <78cda8c2f8b0438899aa3a8eeea13482#80ffc4493c7251d006b14594f2d9afb9>:0
at DryIoc.Resolver.Resolve (DryIoc.IResolver resolver, System.Type serviceType) <0x10482a170 + 0x00047> in <78cda8c2f8b0438899aa3a8eeea13482#80ffc4493c7251d006b14594f2d9afb9>:0

@JustickDM Hi, thanks for reporting. I need to process what's happening here.

@JustickDM Hi, thanks for reporting. I need to process what's happening here.

4.8.8 - same, even with the use of WithUseInterpretation + WithoutFastExpressionCompiler

I migrated to Microsoft Extensions DependencyInjection and everything is fine, so you have a bug somewhere

@JustickDM Ok. Regarding the issue I am trying and not able to reproduce, is it possible that CurrentPlatform == Device.iOS was false?

No, of course it's true

@JustickDM Ok. Regarding the issue I am trying and not able to reproduce, is it possible that CurrentPlatform == Device.iOS was false?

No, of course it's true

Linking the #552


env variable changes

@CodiumAI-Agent /review

Preparing review...

PR Analysis

🎯 Main theme: Environment variable changes
📌 Type of PR: Refactoring
🧪 Relevant tests added: No
✨ Focused PR: No, because the PR lacks a clear and coherent description. The title 'env variable changes' is also too generic and does not provide enough context about the changes made.
🔒 Security concerns: No, because the changes made in this PR do not introduce any new security vulnerabilities. However, it's important to ensure that the environment variable 'kruize' is properly sanitized and validated before use.

PR Feedback

💡 General PR suggestions: The PR lacks a clear description of the changes made. It would be beneficial to provide a detailed explanation of the changes, why they were necessary, and how they improve the codebase. Additionally, it would be helpful to include tests that verify the new behavior works as expected.

How to use

Tag me in a comment '@CodiumAI-Agent' and add one of the following commands:
/review [-i]: Request a review of your Pull Request. For an incremental review, which only considers changes since the last review, include the '-i' option.
/describe: Modify the PR title and description based on the contents of the PR.
/improve: Suggest improvements to the code in the PR. These will be provided as pull request comments, ready to commit.
/ask <QUESTION>: Pose a question about the PR.


How does this fit in the strategy of using Yammer for enterprise-wide (broad) communication?

At Ignite the strategy for communication & collaboration was described where Teams was meant for focused team-based collaboration, whereas Yammer is in the picture for broader enterprise-wide communication.
Since we can now create org-wide teams in Microsoft Teams, how does this feature fit in this strategy? There seems to be an overlap? Does it change the recommended approach of when to use Teams & when to use Yammer?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 76309c0b-2a9c-36a8-d7c7-f7d6f311d39b
Version Independent ID: bc69c0e3-0fa7-c86e-5e8c-067c8811e9bf
Content: Create an org-wide team in Microsoft Teams
Content Source: Teams/create-an-org-wide-team.md
Service: msteams
GitHub Login: @LanaChin
Microsoft Alias: v-lanac

@bartbilliet Thank you for this inquiry
I am not sure how this new feature fits in with this stratagy. Let me get this over to the Teams/Skype for Business team for investigation.
The team will get this prioritized into a sprint plan. Thank you for reporting and making the docs better. Much appreciated.
I made a note to request the team to update this when the work is complete.

The relationship between Yammer and Teams is also causing me some head-aches. Currently, the maximum number of members for a team is 2500 (while the maximum number of members for an org-wide team is 1000???, see: https://docs.microsoft.com/en-us/microsoftteams/limits-specifications-teams). So, it seems to me that the main reason to start using Yammer today is that your organization is too big for org-wide teams. And this, honestly, makes no sense to me. Why such a low limit? I'd be curious to know a) whether there are any concrete plans for significantly increasing the maximum membership limit in the near future, and b) whether there is any on-premise workaround for that limitation that would allow a large organization to create larger teams?

@tophee - see your link, Microsoft has increased the maximum org-wide team size from 1000 to 2500 members!

@PhilFancy Thanks for pointing that out. Unfortunately, it's still far from what we would need. So my question remains: why such a low limit?

Re-opening: The question on how org-wide teams relates to the strategy with Yammer for enterprise-wide communications (=topic starter) was not answered. We are still waiting feedback on this.

I agree with @bartbilliet, the question at the top of this thread "How does this fit in the strategy of using Yammer for enterprise-wide communication" has not been answered.
There is now, very clearly, an overlap between org-wide teams and Yammer (this seems to be endemic in Office 365, see SharePoint & OneDrive for another example). The "inner-loop" versus "outer-loop" rubbish is just marketing spin for the fact that (for legitimate historical reasons) there are two products that have considerable overlap.
Surely the time has come to simply turn Yammer off?

inner-loop vs outer-loop : https://techcommunity.microsoft.com/t5/Community-Management/We-took-the-Inner-Loop-and-Outer-Loop-visual-a-little-further/td-p/123178

@bartbilliet   Thank you very much for your kind feedback. Considering your valuable feedback, we have logged this issue as a User Voice. Concerning team will evaluate and take the appropriate action, as per their schedule.  You can create your own user voice also. Thanks again for taking out some time and sharing your feedback.
User Voice Link: https://microsoftteams.uservoice.com/forums/555103-public/suggestions/33863491-need-to-be-able-to-add-a-disclaimer-for-the-use-of
https://microsoftteams.uservoice.com/forums/555103-public/suggestions/19515259-merge-outlook-groups-skype-for-business-and-yamme

We've turned off Yammer as it serves no value in our organization with everyone using Teams. MS needs to help organizations reduce collections points users have to poll for information rather than maintaining an ever growing number of services.


Add test for CAPA cluster in Cilium ENI mode

What this PR does
Towards https://github.com/giantswarm/roadmap/issues/2563
To ensure we're testing the right thing, I've added a basic "is this really ENI mode" check (pod IPs).
Checklist

[x] Update changelog in CHANGELOG.md.

Trigger e2e tests

/run cluster-test-suites

Trying again – at least the CAPA tests should succeed but several tests and cluster deletion timeout are flaky
/run cluster-test-suites

/run cluster-test-suites

/run cluster-test-suites

/run cluster-test-suites

/run cluster-test-suites

Trying again after rebase, just to be sure
/run cluster-test-suites

The Crossplane providers are missing on grizzly – there's no CRD SecurityGroup* which we use to create necessary cloud resources for Cilium ENI mode.

Crossplane AWS providers were installed/upgraded via https://github.com/giantswarm/giantswarm-management-clusters/pull/617 and https://github.com/giantswarm/giantswarm-management-clusters/pull/618.
/run cluster-test-suites

/run cluster-test-suites

Looks fine. I'll merge main and force-merge this, since no CAPA tests are failing.


nzScrollToBottom continue emiting multiple time

Reproduction link
https://iudgyz.run.stackblitz.io
Steps to reproduce
just scroll down.  You can see yhis bug in your examples, that represented here: https://ng.ant.design/components/select/en
What is expected?
emit one time
What is actually happening?
emiting multiple time

Environment
Info

ng-zorro-antd
8.5.2

Browser
chrome 79.0.3945.88

I was looking on github, and in there its like fixed, but no

慢速滑动会有此问题


fix: verify generation in record status

Please answer these questions before submitting a pull request

Why submit this pull request?

[x] Bugfix

[ ] New feature provided

[ ] Improve performance

[ ] Backport patches

Related issues
#671 #682

Codecov Report

Merging #706 (b065ed0) into master (a01888b) will decrease coverage by 0.07%.
The diff coverage is 0.00%.

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

Can we add tests?

@gxthrj Could you add more descriptions on this PR so that we can know the context of it, frankly, I don't know the exact purpose of Generation.


[CRA] Non-relative imports doesn't work

It seems non-relative imports dont't work when using create-react-app-preset, althought it works with built-in preset (which will be removed at 6.*)

Hi @val-o, can you provide an example that I can test against? I can then work on a fix :)

I have same issue. Unfortunately I cannot provide any examples, but I guess the easiest way to reproduce it is to run npx create-react-app demo --typescript and then configure tsconfig.json to have baseUrl: "src". Any component that has a non-relative path ends up with this issue
TypeError: Cannot read property 'secondary' of undefined     at http://localhost:9009/main.1b5867a66c58acd044d5.bundle.js:451:73     at flatten (http://localhost:9009/vendors~main.1b5867a66c58acd044d5.bundle.js:183884:21)     at ComponentStyle.generateAndInjectStyles (http://localhost:9009/vendors~main.1b5867a66c58acd044d5.bundle.js:184127:27)     at useInjectedStyle (http://localhost:9009/vendors~main.1b5867a66c58acd044d5.bundle.js:184341:120)     at useStyledComponentImpl (http://localhost:9009/vendors~main.1b5867a66c58acd044d5.bundle.js:184368:28)     at Input__Label (http://localhost:9009/vendors~main.1b5867a66c58acd044d5.bundle.js:184421:12)     at renderWithHooks (http://localhost:9009/vendors~main.1b5867a66c58acd044d5.bundle.js:138075:18)     at updateForwardRef (http://localhost:9009/vendors~main.1b5867a66c58acd044d5.bundle.js:140090:20)     at beginWork (http://localhost:9009/vendors~main.1b5867a66c58acd044d5.bundle.js:141928:16)     at HTMLUnknownElement.callCallback (http://localhost:9009/vendors~main.1b5867a66c58acd044d5.bundle.js:123438:14)

@mkinfrared, I just tried that in one of our example projects and it worked as expected.


Config File has a small mix up

Set window mode. 1 = Fullscreen, 2 = Borderless, 3 = Windowed.
Setting type: Int32
Default value: 1
Acceptable value range: From 1 to 3
WindowMode = #
1 is actually Borderless and 2 is Fullscreen

Hmm, they are actually correctly labelled. Though in my testing it looks like both 1 and 2 produce a borderless-like result and 3 is windowed correctly. Perhaps this is a quirk of Unity?
iWindowMode = Config.Bind("Set Custom Resolution",
                                "WindowMode",
                                 1,
                                new ConfigDescription("Set window mode. 1 = Fullscreen, 2 = Borderless, 3 = Windowed.",
                                new AcceptableValueRange<int>(1, 3)));

BootOption.WindowMode fullscreenMode;
                switch (iWindowMode.Value)
                {
                    case 1:
                        fullscreenMode = BootOption.WindowMode.FullScreen;
                        break;
                    case 2:
                        fullscreenMode = BootOption.WindowMode.Borderless;
                        break;
                    case 3:
                        fullscreenMode = BootOption.WindowMode.Window;
                        break;
                    default:
                        fullscreenMode = BootOption.WindowMode.FullScreen;
                        break;
                }

ahh unity... explains a lot of the issues with this game a little better realizing that.


Data type validation on RPC calls

Jitar needs to have an option to validate incoming data through its apis. As with the rest of the product, we want to have a configuration only option to define the validation schemas.
What needs to be done for this story;

update the segment file configuration with a validation model
add the configuration to generated cache files
validate the incoming data on the server with the provided configuration
translate validation errors to http 400

After we have investigated the issue and setup a first version, we found out that there is a large amount of work to be done for this story.
There are more urgent issues to pick up, as the validation can also be done by an application using excellent libraries available.

@petermasking are we planning to use a zod ovject for this?

We close this issue because we have changed our strategy regarding the validation of incoming requests. The data should be validated in the applicaiton code to make it easier to move away from jitar without the need for rebuilding the validation elsewhere.


sys: util: Add sizeof_field() macro

This macro allows to know the size of a struct member at compile time. Its implementation is taken from the Linux kernel linux/stddef.h.

Want to point out that the Linux file is under GPL-2 and Zephyr is under Apache-2.0. There is probably a licensing issue here.

Want to point out that the Linux file is under GPL-2 and Zephyr is under Apache-2.0. There is probably a licensing issue here.

I can remove the Linux comment from the commit message. There should be no issue about the implementation itself because it is present in a lot of projects other than Linux.
Would this be enough ?

we have this in local headers, would be nice to to replace those custom usages with the new macro:
drivers/gpio/gpio_gecko.c:#define member_size(type, member) sizeof(((type *)0)->member)

OK, I will change the commit message.
It seems that there are some other parts where this macro could be used, are you OK if I do a second commit that uses this macro where needed ?
Below are the candidates :
~/zephyrproject/zephyr$ grep -rn ")[[:space:]]*0)->"
subsys/bluetooth/audio/mcc_internal.h:98:       char write_buf[sizeof(((struct mpl_cmd *)0)->opcode) +
subsys/bluetooth/audio/mcc_internal.h:99:                      sizeof(((struct mpl_cmd *)0)->param)];
subsys/bluetooth/mesh/blob.h:52:                                        MAX(sizeof(((struct bt_mesh_blob_block *)0)->missing), \
subsys/bluetooth/mesh/blob.h:55:                                      MAX(sizeof(((struct bt_mesh_blob_block *)0)->missing), \
subsys/bluetooth/mesh/blob.h:58:#define BLOB_BLOCK_REPORT_STATUS_MSG_MAXLEN sizeof(((struct bt_mesh_blob_srv *)0)->block.missing)
subsys/bluetooth/mesh/blob.h:59:#define BLOB_BLOCK_STATUS_MSG_MAXLEN (5 + sizeof(((struct bt_mesh_blob_srv *)0)->block.missing))
subsys/bluetooth/mesh/blob.h:62:#define BLOB_XFER_STATUS_MSG_MAXLEN (17 + sizeof(((struct bt_mesh_blob_srv *)0)->state.blocks))
subsys/net/lib/sockets/sockets_select.c:14:#define STRUCT_MEMBER_ARRAY_SIZE(type, field) ARRAY_SIZE(((type *)0)->field)
subsys/lorawan/nvm/lorawan_nvm_settings.c:32:           .size = sizeof(((LoRaMacNvmData_t *)0)->_member),               \
include/zephyr/net/socket_select.h:51:#define ZSOCK_FD_SETSIZE (sizeof(((zsock_fd_set *)0)->bitset) * 8)
include/zephyr/net/http/server.h:81:         sizeof(((struct http_resource_detail *)0)->bitmask_of_supported_http_methods))
include/zephyr/sys/util.h:240:  BUILD_ASSERT(SAME_TYPE(*(ptr), ((type *)0)->field) || \
include/zephyr/sys/util.h:282:#define SIZEOF_FIELD(type, member) sizeof((((type *)0)->member))
drivers/gpio/gpio_gecko.c:66:#define member_size(type, member) sizeof(((type *)0)->member)
tests/posix/headers/src/stropts_h.c:28: zassert_true(sizeof(((struct strbuf *)0)->maxlen) > 0, "maxlen size is 0");
tests/posix/headers/src/stropts_h.c:29: zassert_true(sizeof(((struct strbuf *)0)->len) > 0, "len size is 0");
tests/posix/headers/src/stropts_h.c:30: zassert_true(sizeof(((struct strbuf *)0)->buf) > 0, "buf size is 0");

Please add a test case.

Good idea ! It's done, test is passing when using the command west twister -v -p unit_testing --test tests/unit/util/utilities.dec.

Hi !
Is there something else I need to modify in this PR ?

@yperess Please revisit.

Hi ! Would it be possible to merge this PR now that there are 4 approvals ?


Gerrit integration: Implement scaffolder publish action

Feature Suggestion
A missing piece of the Gerrit Integration is support for publishing to new Gerrit projects with the "Scaffolder". This is issue is created to track our contribution of this feature.
Possible Implementation

A new RepoUrlPicker for Gerrit will be added.
A new action in "scaffolder-backend" that will create and push to a new Gerrit project ("gerrit-publish").

Sounds good!

Yes, you can assign me.


Failed to get route: typeError: Cannot read properties of undefined (reading 'split') at UssdMenu.resolveRoute

I am getting this error whenever I try to my app. if you have bypassed this kindly assist.
Failed to get route: TypeError: Cannot read properties of undefined (reading 'split')
at UssdMenu.resolveRoute (/var/task/node_modules/ussd-menu-builder/lib/ussd-menu.js:76:46)
at /var/task/node_modules/ussd-menu-builder/lib/ussd-menu.js:357:22
/var/task/node_modules/ussd-menu-builder/lib/ussd-menu.js:365
return this.emit('error', new Error(err));
^
Error: TypeError: Cannot read properties of undefined (reading 'split')
at /var/task/node_modules/ussd-menu-builder/lib/ussd-menu.js:365:43
Emitted 'error' event on UssdMenu instance at:
at /var/task/node_modules/ussd-menu-builder/lib/ussd-menu.js:365:29
Node.js v18.18.2

Could you share some sample code to reproduce the issue. It appears like it was trying to split a string but the string was undefined. How did you defined your routes?

Did you get this resolved? I am getting the same error while running my codes.

Did you get this resolved? I am getting the same error while running my codes.

unfortunately no.

Could you share some sample code to reproduce the issue. It appears like it was trying to split a string but the string was undefined. How did you defined your routes?

You can check the full snippet here. https://github.com/Robertishimwe/Simple-USSD/blob/master/app.js

I got it sorted,thanks.
On Thu, Nov 7, 2024, 6:43 PM Robertishimwe @.***> wrote:

Did you get this resolved? I am getting the same error while running my
codes.
unfortunately no.
—
Reply to this email directly, view it on GitHub
https://github.com/habbes/ussd-menu-builder/issues/39#issuecomment-2462565368,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARK7H6FHZHNKEVU6IAPA7RTZ7ODCFAVCNFSM6AAAAABPLFRJP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRSGU3DKMZWHA
.
You are receiving this because you commented.Message ID:
@.***>

I got it sorted,thanks.
…
On Thu, Nov 7, 2024, 6:43 PM Robertishimwe @.> wrote: Did you get this resolved? I am getting the same error while running my codes. unfortunately no. — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARK7H6FHZHNKEVU6IAPA7RTZ7ODCFAVCNFSM6AAAAABPLFRJP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRSGU3DKMZWHA . You are receiving this because you commented.Message ID: @.>

Do you mind sharing the solution?

I will share with you tomorrow bro.
On Thu, Nov 7, 2024, 6:45 PM Robertishimwe @.***> wrote:

Could you share some sample code to reproduce the issue. It appears like
it was trying to split a string but the string was undefined. How did you
defined your routes?
You can check the full snippet here.
https://github.com/Robertishimwe/Simple-USSD/blob/master/app.js
—
Reply to this email directly, view it on GitHub
https://github.com/habbes/ussd-menu-builder/issues/39#issuecomment-2462569181,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARK7H6DHI5I7X2M3JHWR6PTZ7ODIHAVCNFSM6AAAAABPLFRJP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRSGU3DSMJYGE
.
You are receiving this because you commented.Message ID:
@.***>


cilium node chain refactor

The intent of this PR is to remove the CiliumNodeChain.
Review commit by commit.
bgp/speaker: use Resource[T] instead of NodeChains
As part of a refactoring effort to remove the CiliumNodeChain, remove
the dependency of the MetalLBSpeaker on it, by directly using the
LocalCiliumNodeResource.

Note that the speaker always discarded events not pertaining to the
local Node, hence no functional change results from the fact that the
CiliumNodeChain proagated events from all cluster CiliumNodes.

As an added benefit, the CiliumNode events now don't stop coming once we
connect to KVStore, since the resource doesn't stop.

ipam: multipool: use resource for node events
As part of a refactoring effort to remove the CiliumNodeChain, remove
the multipool IPAM dependency on it.

Since IPAM isn't yet part of the hive, we need to pass the resource down
to IPAM through the daemon, in `startIPAM`. Once IPAM code is
modularised, this is no longer necessary.

In order to keep the tests largely unchanged, we reimplement the
fakeNodeK8sAPI testing infrastructure in terms of the resource API. This
leads to code duplication, but a commit later in this series removes the
duplication again, by also converting the other usages to the resource style.

watchers: remove ciliumnodechain
Previous commits in the series have removed all subscribers to the
CiliumNodeChain by moving them over to use the LocalCiliumNodeResource.
This commit reaps the benefits by deleting all of the now unused code.

Finally got around to updating this. Significant changes since last review:

clusterpool has been dropped upstream, hence dropping changes to it in this PR.
improved context handling in the speaker, and added an explanation which in IPAM there isn't a signal available to stop.

PTAL.

/test

want to address Jussi's nits before merging

/test

/ci-external-workloads

/ci-ipsec-upgrade

@bimmlerd the ipsec upgrade job is failing due to this error:
Unable to contact Hubble Relay, disabling Hubble telescope and flow validation: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp: lookup localhost on <IP_ADDRESS>:53: no such host"

I don't understand why Cilium Agent is using a DNS server to resolve localhost. It appears to be related to this flake.

@bimmlerd the ipsec upgrade job is failing due to this error:
Unable to contact Hubble Relay, disabling Hubble telescope and flow validation: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp: lookup localhost on <IP_ADDRESS>:53: no such host"

I don't understand why Cilium Agent is using a DNS server to resolve localhost. It appears to be related to this flake.

I don't think so. AFAICT it's failing because of   🟥 Pod test-conn-disrupt-client-54df7db847-nqmzw flow was interrupted (restart count does not match 2 != 3)
In any case, this isn't a required test, which is typically a strong signal that the test is either still in development or was deemed too flaky. The new failure is different than the two before that, so I'm not considering it as a signal of breakage.


Create envd-on-remote-serve.md

Please add this to https://github.com/tensorchord/envd-docs/blob/main/docs/.vitepress/config/sidebar/blog.ts

some nits

Thx and fixed

https://app.netlify.com/sites/envd/deploys/636cf7ca017cdd00085f5a80#L98
There is a build error.

https://app.netlify.com/sites/envd/deploys/636cf7ca017cdd00085f5a80#L98
There is a build error.

fixed

LGTM


Mod fails to load correctly in MC Forge version 1.14.4-forge-28.0.45

Minecraft Forge version 1.14.4-forge-28.0.45 breaks some things causing this mod to load incorrectly.
Log:
https://pastebin.com/hTumad6Q

Are you actually on the latest version (The 1.14.4 one) ?


Support regex based path rewrites

What would you like to be added:
Tracks support for regex based path substitution mentioned in the GEP
https://gateway-api.sigs.k8s.io/geps/gep-726/#future-extension
Why this is needed:
Automate path rewrites that have a common pattern
e.g.
/auth/v1/{pattern} -> /self-service/{pattern}/browser
/auth/v1/login -> /self-service/login/browser
/auth/v1/recovery -> /self-service/recovery/browser
/auth/v1/settings -> /self-service/settings/browser

Related

Thoughts from users and maintainers regarding supporting this - https://github.com/kubernetes-sigs/gateway-api/issues/726#issuecomment-984430631
Supported in Istio - https://github.com/istio/istio/issues/22290 / https://github.com/istio/istio/pull/45398

Sounds like a good one to have:
/triage accepted
However, we don't expect this to be something we need for v1 so we're not necessarily ready for anyone to jump in on this one (unless this is the ONLY thing you want to work on).

Something that would also be useful in this same sort of rewrite would be matching parts of the hostname to put in the path.  An example of this is mapping a sub-domain to a sub path of a backend application.
Some example nginx configuration:
server_name ~(?<sub>.+)\.example.com
if ( $sub != "" ) {
  rewrite ^/(v1|v2)/(.*) /app/$sub/$1/$2 break;
}

The biggest reason why this is not done yet is about regular expression compatibility. An GEP that addresses this will need also to address:

what flavors of regexes are supported across most if not all Gateway API implementations
what flavor of regex is chosen as the Gateway API flavor. Ideally we should only be choosing one.
why that particular flavor has been chosen. Note that any flavor that's not supported by all implementations will need some pretty significant justification here.

Other concerns I'd like to see addressed in this GEP that aren't regex compatibility:

How do regexes get sorted in a list of matches? What happens when a regex also matches a Prefix or Exact match? ( I suspect the answer should be "Exact beats Prefix beats Regex beats /", but we will need to specify this precisely). Also note that the discussion about cascading matches is very relevant here too (what happens if cascading matches are enabled? Will that be hard to reason about or produce surprising results?)
Using regex path matching basically precludes also doing any sort of path-based route delegation (which we haven't discussed for a long time, but we have discussed previously). What should we do here?
As raised by @plnordquist, what's the support for using other data inside a regex match, like hostname, port, etc? Should we also allow the use of regex capture groups inside rewrite filters? (That is, can you match on /api/{path} and then use $1 or something to represent the matched path in a rewrite filter?).

For the last two items, we don't need to answer those in the GEP, but if we aren't going to, we need to explicitly put them in as "reserved for future work", so the discussion doesn't get derailed. The regex flavor discussions has all the hallmarks of one that could be contentious to me, which is concerning.

Envoy Gateway just added support for this using a filter in v1.2, here's an example


[OMD Scheduler/production] Pundit::NotDefinedError: unable to find policy NilClassPolicy for nil

Backtrace
line 7 of [PROJECT_ROOT]/app/controllers/shifts_controller.rb: index
line 34 of [PROJECT_ROOT]/app/controllers/application_controller.rb: set_time_zone

View full backtrace and more info at honeybadger.io

I believe we should prevent a user from deleting the last shift of a need. Display an alert that says something to the effect of:

Cannot remove the last shift from this need. Perhaps you mean to delete the need itself?

Feel free to reword, but that's the gist.

This is fixed and in production :+1:


[Automated] Update eventing-kafka-broker-eventing nightly

/assign @knative-extensions/eventing-wg-leads
/cc @knative-extensions/eventing-wg-leads
Produced via:
for x in eventing-crds.yaml eventing-core.yaml eventing-tls-networking.yaml; do
  curl https://storage.googleapis.com/knative-nightly/eventing/latest/$x > ${GITHUB_WORKSPACE}/./third_party/eventing-latest/$x
done

Details:
bumping knative.dev/eventing 9de5275...5168dc3:
  > 5168dc3 Update dependencies (# 7378)
  > f9314d8 [main] Upgrade to latest dependencies (# 7372)
  > 4a07fdc Move OIDC e2e tests to test/auth (# 7363)
  > 0933c11 Expose audience of an InMemoryChannel in its status (# 7371)
  > 169542f OIDC - Support auto generation of ApiServerSource identity service account and expose in AuthStatus (# 7330)
  > 62ec33b Support auto generation of Subscriptions identity service account and… (# 7338)
  > 0af3ef6 [main] Upgrade to latest dependencies (# 7370)
  > cf6b140 [main] Update community files (# 7369)
  > de6915a Pass sink namespace to PingSource (# 7368)
  > 6dca8c4 [main] Upgrade to latest dependencies (# 7366)
  > 082d90a Remove unneeded configmapinformer in sinkbinding controller (# 7357)
  > f321ba5 Update dependencies (# 7347)
  > 4c9ad03 Mark new trigger filter tests as beta (# 7349)
  > 494ebb2 bumped x/net to v0.17 to fix cve-2023-44487 (# 7348)
  > da0fba3 Workaround for cert-manager update spec issue (# 7345)
  > a0e4c18 Update `kncloudevents.Dispatcher` to add a JWT (# 7328)
  > c46bdd3 support auto generation of SinkBindings identity service account (# 7327)
  > 029b340 Remove unnecessary filter accumulation logic (# 7325)
  > fb494d1 [main] Update community files (# 7342)
  > ba02f4a [main] Upgrade to latest dependencies (# 7340)

/retest

/retest

/retest

/retest

/retest

/retest

/retest-required

/retest-required

/retest

/retest-required

/retest

/retest

/retest


pseudographics broken after upgrade

After upgrading ports/pkgs from Jan 2023 to 12-EOL (same 12.4 underhood) synth outputs somewhat unreadable in both xterm and vt(4) console:

This is the only complain I've seen on this (in over 10 months).  Can I assume this resolved itself?

No, it didn't. I did not update system from that time due to unworking synth, though :) I can provide some debug, just don't know what.

you can try this to restore the system:
https://github.com/Ravenports/Ravenports/wiki/Synth_Install
another thing you can do is load the /usr/local/etc/synth/synth.ini and change
Display_with_ncurses= true

to
Display_with_ncurses= false

on the profile that's active.
you won't get the ncurses interface but you should be able to build.  There's a web interface though.

to be clear, this is some kind of termcap/terminfo + ncurses issue.

In fact it does build, just interface is unusable, so I use it for synth install some_small|port blindly, but don't feel it comfortable to be blind for large upgrades - when there is often need to press keys for shutdown.
The false setting works, though I did not understand on short port
00:00:06 => [01] Builder launched
00:00:06 => [01]          Kickoff sysutils/wait_on
00:00:06 => [02]          Shutting down
00:00:16 => [01] 00:00:10 Success sysutils/wait_on
00:00:16 => [01]          Shutting down

if that will have time/line updates on each build phase?

to be clear, this is some kind of termcap/terminfo + ncurses issue.

It doesn't seem to be linked with ncurses:
$ ldd `which synth`
/usr/local/bin/synth:
        libthr.so.3 => /lib/libthr.so.3 (0x800628000)
        libc.so.7 => /lib/libc.so.7 (0x800656000)
$ ll `which synth`
-r-xr-xr-x  1 root  wheel  1980264  8 Jan   2024 /usr/local/bin/synth*
$ file `which synth`
/usr/local/bin/synth: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.4, FreeBSD-style, stripped
$ pkg info synth | head -19
synth-2.13_1
Name           : synth
Version        : 2.13_1
Installed on   : Sun Jan 14 05:32:23 2024 MSK
Origin         : ports-mgmt/synth
Architecture   : FreeBSD:12:amd64
Prefix         : /usr/local
Categories     : ports-mgmt
Licenses       : ISCL
Maintainer<EMAIL_ADDRESS>WWW            : https://github.com/jrmarino/synth
Comment        : Custom package repository builder for FreeBSD and DragonFly
Options        :
        WATCHDOG       : off
Annotations    :
        FreeBSD_version: 1204000
        repo_type      : binary
        repository     : Synth
Flat size      : 1.96MiB

strings /usr/local/bin/synth gives, amongst terminal_interface-curses*adb*,
ncurses 6.4.20221231

for this version, and
ncurses 6.3.20211021

from -rw-r--r--  1 root  wheel  732132  5 Dec 2022 /var/cache/pkg/synth-2.12~99b0d6aa51.pkg

the freebsd ports version of synth should link to the base ncurses (so it won't be listed on the manifest).
The ravenports version of synth links to the ravenports-provided terminfo.
Again - I recommended pointing a browser at the web-based reported if you desire details during the build.
also, if you can't fix the base terminfo problem, I do recommend you install the ravenports version of synth (which is currently newer than the freebsd ports version).  I believe there's something wrong with your base but you can work around it with either using web-based reports or the ravenports-built synth.

I see that synth 3 is released and there were curses discussion/patches in PRs referenced from freshports commit logs (as far as I understoo, that was ports ncurses statically linked, not base in my case), so chances are high that problem no longer exists. I probably just need to install fresh synth first somehow, before upgrading all other ports with it, when I'll receive new videocard in a week and start base/pkg builds & upgrades.


Fix cert copying bug [URGENT]

cc @ehazlett
This fixes an issue that was breaking creation of Ubuntu instances in master.
I accidentally introduced the issue in my cert PR from yesterday, this fixes it!
Closes https://github.com/docker/machine/issues/1169.
Thanks @Herkemer.
There's some additional SSH debug information that I added, if you really want me to put it in another PR I will, but I figured it was probably OK here and not too irrelevant.
Signed-off-by: Nathan LeClaire<EMAIL_ADDRESS>

LGTM


Output

Hi,
I have changed the function outputs from list to TreeSE object for all simulations. However, the problem is there were different types of features in the list object which I didn't know where to insert when converting to TreeSE format. I probably would need @gaoyu19920914 help on what exactly the outputs features were in the list object and @antagomir help to figure out where to insert these features in TreeSE. Also, the GitHub actions doesn't really even run through the file, it throws an error immediately. Maybe @TuomasBorman help me to look into that.
I am planning to change the documentation and examples after the TreeSE object correctly implemented in the functions.

Hello,
The output features in each simulations contains basically 3 parts:

a matrix of species dynamics along the time (with columns as species and last column as time), and
(for CRM only) a matrix of resources dynamics (with columns as resources and last column as time) and a matrix of volume dynamics (with first column as volume and last column as time), and
other useful data for each simulation, generally some important inputs. This is designed to keep the data provenance and simplify the chaining of different simulations. Their meanings and types can be found in the documentation of each simulateXXX function. You can also refer to this link for more details.

goes to assay data; the time column is different type and it should go to colData where it actually belongs since it is sample / colData, not assay data; functions to be updated accordingly
goes to colData; note that these columns would be better called by their name in functions rather than location in order to reduce possibility for errors and allow extensibility
goes to metadata (metadata(tse) <- list(...) so just add all the extra stuff there as a list); this slot is inherited from the SingleCellExperiment class.

OK?

Re: build error in GHA.
You changed from master to main branch? Then the github actions (GHA) workflow file should be updated accordingly for automated tests (master -> main): .github/workflows/*.yml. Perhaps this solves the issue or at least some of it.

There was no master branch previously, it was initially set to main, actually. I also thought changing it in the .github/workflows/*.yml would work, but it doesn't recognize the main branch as well.

Examples, tests and vignette are corrected, convertToSE function is removed. Only there are some functions in utils file that could be useful such as generateSimulations since it generates multiple simulations out of one simulation function and stores them in a list. Same can be done with TreeSE object (multiple TreeSE objects in a list) but it can also be removed.

Me / Tuomas can check those final list and other things once this is otherwise completed. Kindly confirm when this seems ready from your side? We may then still suggest some updates (or possibly not).

mia had same problem with GHA, I fixed it in this PR https://github.com/microbiome/mia/pull/323

It is ready from my side. Feel free to check and give your feedback/suggest changes.

Do @danielriosgarza or @gaoyu19920914 have anything coming up before we check the next round with @TuomasBorman ?

Do @danielriosgarza or @gaoyu19920914 have anything coming up before we check the next round with @TuomasBorman ?

Not from my side

Do @danielriosgarza or @gaoyu19920914 have anything coming up before we check the next round with @TuomasBorman ?

Nothing from me. Good to go

Great!
@TuomasBorman could you review the package for us. I will then have a final look if something more is needed.

The website actually shows what is on main branch. After the changes in this PR merged, the website should change as well. For now, whatever is in the vignette of the main branch is also on the website.
Also, the checks are failing because of the generateSimulations function in utils. This can be handled by either removing the function or just changing its structure to TreeSE and the output of the function still can remain list object.

Clear, great.
Do I understand correctly that generateSimulations is generating a list of TreeSE objects, each corresponding to a different set of parameters? I am not sure how necessary the other arguments are after the first two - model and params_list. It seems those other arguments that are listed after these can be incorporated through params_list as well, and that would be more direct and clear way.
If so, then a more straightforward way to run the same is something like:
.. for varying parameters (given as a list):
simlist <- lapply(params_list, function (pars) { do.call(model, pars) })
.. and for n_instances plus fixed parameters (pars):
simlist <- lapply(seq_len(n_instances), function (i) { do.call(model, pars) })
This is simple and clear, and it could be shown in examples and vignettes.
That would save us from maintenance burden for this function that is relatively complicated, and seems to have parameter options that tend to override each other in somewhat complicated ways.
Hence I suggest to remove this function and replace it with examples showing how to do the same with lapply.
This will imply changes in other parts of utils.R and perhaps in unit tests and vignettes (to be checked).
@YagmurSimsekk could you implement the change? Then the error should be solved.

There is only one more function left to clear: estimateAFromSimulations in utils.R. Is it necessary to keep this function and implement with TreeSE object? Or could it be also written with some built-in functions and shown in vignette?

This function uses parameter simulations  which is a list object that would be created by generateSimulations function that is just removed. So the parameters and the most of the function has to be changed accordingly if the function is staying. Before changing anything, I would like to hear from @gaoyu19920914 and @danielriosgarza if this function is essential and can be shown with some examples using TreeSE.

This function uses parameter simulations which is a list object that would be created by generateSimulations function that is just removed. So the parameters and the most of the function has to be changed accordingly if the function is staying. Before changing anything, I would like to hear from @gaoyu19920914 and @danielriosgarza if this function is essential and can be shown with some examples using TreeSE.

Hello and sorry for the late reply.
This estimateAFromSimulationsfunction is written to show how different models could be connected. This is one of main reasons why we bring various models together and keep them in the same data structure.
It is useful to estimate the matrix A (as in the gLV model) from different kinds of simulations, and one example is given in utils.R in the devel branch: estimate matrix A from CRM-based simulations, and then simulate another time-series using gLV model with this estimated A.
With this function and the example, people can see how these models could interact, and understand why the unified data format (either the previous matrix or current TreeSE) is used.

Great, then it is good to keep.
It would be good to merge the current branches as soon as possible, then we could check this one based on the final main branch and make sure that the examples run well.

This is almost passing the checks: Error: package or namespace load failed for ‘miaSim’ in namespaceExport(ns, exports):
undefined exports: generateSimulations, getCommunity -> @YagmurSimsekk could you have a look?
I open a separate issue about estimateAFromSimulations

Thanks! @antagomir


Add 'files' to package.json to reduce the install size

I found that installed vis-network contains a lot of files needed only during development.
Why not add files to package.json?
{
  "name": "vis-network",
  ...
  "files": [
    "dist",
    "LICENSE-APACHE-2.0",
    "LICENSE-MIT",
  ],
  ...
}

cf. https://docs.npmjs.com/files/package.json#files

We can't do this because the building process is broken (see #85). We need the source files to build vis-charts where all the packages can properly work together.


Make net7.0 upgrade cause i has problem and you are only who know about the app and his packages

I Need This

will be part of the https://github.com/fullstackhero/dotnet-webapi-boilerplate/tree/dotnet-7 branch.


Create a GUI

https://github.com/wailsapp/wails

Running in Docker container was better. Ignoring this feature,


Checkbox is not unchecking programmatically

https://jsfiddle.net/rorc/pwbfc990/
Expected behaviour:
When counter == 3, after one second counter will equal 0 and checkbox must be unchecked.

This is a limitation of inputs while focused: they cannot update. You can however get around it by running the blur() method: https://jsfiddle.net/posva/ka9rLjwu/

@posva Ok, thanks.

@posva And this way is right?
https://jsfiddle.net/rorc/pwbfc990/2/

Yes, it also works. In v-model we don't change an input if it's focused because it may end up in weird ux


[Bug] [Zeta] Local tasks are not allowed to run concurrently; only one can be running at a time.

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
I would like to run the seatunnel locally multiple times （-e local）where only the first run is successful, and all subsequent runs fail.
SeaTunnel Version
2.3.2
SeaTunnel Config
env {
  execution.parallelism = 2
  job.mode = "STREAMING"
  checkpoint.interval = 2000
  #execution.checkpoint.interval = 10000
  #execution.checkpoint.data-uri = "hdfs://localhost:9000/checkpoint"
}
source {
  FakeSource {
    parallelism = 2
    result_table_name = "fake"
    row.num = 16
    schema = {
      fields {
        name = "string"
        age = "int"
      }
    }
  }
}

sink {
  Console {
  }
}

Running Command
sh bin/seatunnel.sh -c config/v2.streaming.conf.template -e local

Error Exception
2023-06-28 12:53:09,962 INFO  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] HazelcastClient 5.1 (20220228 - 21f20e7) is STARTING
2023-06-28 12:53:09,963 WARN  com.hazelcast.logging.impl.LoggingServiceImpl$DefaultLogger.log(LoggingServiceImpl.java:263) - [localhost]:5802 [seatunnel-551475] [5.1] Received an invalid join request from [localhost]:5801, cause: members part of different cluster
2023-06-28 12:53:09,965 INFO  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] HazelcastClient 5.1 (20220228 - 21f20e7) is STARTED
2023-06-28 12:53:09,970 INFO  com.hazelcast.logging.impl.LoggingServiceImpl$DefaultLogger.log(LoggingServiceImpl.java:263) - [localhost]:5802 [seatunnel-551475] [5.1] Connection[id=5, /<IP_ADDRESS>:5802->/<IP_ADDRESS>:46982, qualifier=null, endpoint=[localhost]:5801, remoteUuid=e02c61f2-6c78-45f1-abd1-07b0b03b6e3b, alive=false, connectionType=MEMBER, planeIndex=0] closed. Reason: Connection closed by the other side
2023-06-28 12:53:09,991 INFO  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] Trying to connect to cluster: seatunnel-551475
2023-06-28 12:53:09,993 INFO  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] Trying to connect to [localhost]:5801
2023-06-28 12:53:10,013 WARN  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] ClientConnection{alive=false, connectionId=1, channel=NioChannel{/<IP_ADDRESS>:43672->localhost/<IP_ADDRESS>:5801}, remoteAddress=null, lastReadTime=2023-06-28 12:53:10.008, lastWriteTime=2023-06-28 12:53:10.007, closedTime=2023-06-28 12:53:10.010, connected server version=null} closed. Reason: Failed to authenticate connection
com.hazelcast.client.AuthenticationException: Authentication failed. The configured cluster name on the client (see ClientConfig.setClusterName()) does not match the one configured in the cluster or the credentials set in the Client security config could not be authenticated
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.checkAuthenticationResponse(TcpClientConnectionManager.java:995) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.onAuthenticated(TcpClientConnectionManager.java:898) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.getOrConnectToAddress(TcpClientConnectionManager.java:615) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.lambda$doConnectToCandidateCluster$3(TcpClientConnectionManager.java:505) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.connect(TcpClientConnectionManager.java:459) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.doConnectToCandidateCluster(TcpClientConnectionManager.java:505) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.doConnectToCluster(TcpClientConnectionManager.java:411) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.connectToCluster(TcpClientConnectionManager.java:372) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.clientside.HazelcastClientInstanceImpl.start(HazelcastClientInstanceImpl.java:381) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.HazelcastClient.constructHazelcastClient(HazelcastClient.java:460) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.HazelcastClient.newHazelcastClientInternal(HazelcastClient.java:416) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.HazelcastClient.newHazelcastClient(HazelcastClient.java:136) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.engine.client.SeaTunnelHazelcastClient.<init>(SeaTunnelHazelcastClient.java:53) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.engine.client.SeaTunnelClient.<init>(SeaTunnelClient.java:46) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.core.starter.seatunnel.command.ClientExecuteCommand.execute(ClientExecuteCommand.java:111) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.core.starter.SeaTunnel.run(SeaTunnel.java:40) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.core.starter.seatunnel.SeaTunnelClient.main(SeaTunnelClient.java:34) [seatunnel-starter.jar:2.3.2]
2023-06-28 12:53:10,020 WARN  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] Exception during initial connection to [localhost]:5801: com.hazelcast.client.AuthenticationException: Authentication failed. The configured cluster name on the client (see ClientConfig.setClusterName()) does not match the one configured in the cluster or the credentials set in the Client security config could not be authenticated
2023-06-28 12:53:10,021 WARN  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] Unable to get live cluster connection, retry in 1000 ms, attempt: 1, cluster connect timeout: 3000 ms, max backoff: 30000 ms
2023-06-28 12:53:10,426 INFO  com.hazelcast.logging.impl.LoggingServiceImpl$DefaultLogger.log(LoggingServiceImpl.java:263) - [localhost]:5802 [seatunnel-551475] [5.1] This node become a new active master node, begin init coordinator service
2023-06-28 12:53:10,658 INFO  com.hazelcast.logging.impl.LoggingServiceImpl$DefaultLogger.log(LoggingServiceImpl.java:263) - [localhost]:5802 [seatunnel-551475] [5.1] Initializing cluster partition table arrangement...
2023-06-28 12:53:11,021 INFO  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] Trying to connect to [localhost]:5801
2023-06-28 12:53:11,032 WARN  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] ClientConnection{alive=false, connectionId=2, channel=NioChannel{/<IP_ADDRESS>:54643->localhost/<IP_ADDRESS>:5801}, remoteAddress=null, lastReadTime=2023-06-28 12:53:11.028, lastWriteTime=2023-06-28 12:53:11.025, closedTime=2023-06-28 12:53:11.029, connected server version=null} closed. Reason: Failed to authenticate connection
com.hazelcast.client.AuthenticationException: Authentication failed. The configured cluster name on the client (see ClientConfig.setClusterName()) does not match the one configured in the cluster or the credentials set in the Client security config could not be authenticated
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.checkAuthenticationResponse(TcpClientConnectionManager.java:995) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.onAuthenticated(TcpClientConnectionManager.java:898) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.getOrConnectToAddress(TcpClientConnectionManager.java:615) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.lambda$doConnectToCandidateCluster$3(TcpClientConnectionManager.java:505) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.connect(TcpClientConnectionManager.java:459) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.doConnectToCandidateCluster(TcpClientConnectionManager.java:505) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.doConnectToCluster(TcpClientConnectionManager.java:411) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.connectToCluster(TcpClientConnectionManager.java:372) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.clientside.HazelcastClientInstanceImpl.start(HazelcastClientInstanceImpl.java:381) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.HazelcastClient.constructHazelcastClient(HazelcastClient.java:460) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.HazelcastClient.newHazelcastClientInternal(HazelcastClient.java:416) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.HazelcastClient.newHazelcastClient(HazelcastClient.java:136) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.engine.client.SeaTunnelHazelcastClient.<init>(SeaTunnelHazelcastClient.java:53) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.engine.client.SeaTunnelClient.<init>(SeaTunnelClient.java:46) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.core.starter.seatunnel.command.ClientExecuteCommand.execute(ClientExecuteCommand.java:111) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.core.starter.SeaTunnel.run(SeaTunnel.java:40) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.core.starter.seatunnel.SeaTunnelClient.main(SeaTunnelClient.java:34) [seatunnel-starter.jar:2.3.2]
2023-06-28 12:53:11,035 WARN  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] Exception during initial connection to [localhost]:5801: com.hazelcast.client.AuthenticationException: Authentication failed. The configured cluster name on the client (see ClientConfig.setClusterName()) does not match the one configured in the cluster or the credentials set in the Client security config could not be authenticated
2023-06-28 12:53:11,036 WARN  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] Unable to get live cluster connection, retry in 1050 ms, attempt: 2, cluster connect timeout: 3000 ms, max backoff: 30000 ms
2023-06-28 12:53:12,087 INFO  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] Trying to connect to [localhost]:5801
2023-06-28 12:53:12,096 WARN  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] ClientConnection{alive=false, connectionId=3, channel=NioChannel{/<IP_ADDRESS>:35959->localhost/<IP_ADDRESS>:5801}, remoteAddress=null, lastReadTime=2023-06-28 12:53:12.094, lastWriteTime=2023-06-28 12:53:12.091, closedTime=2023-06-28 12:53:12.095, connected server version=null} closed. Reason: Failed to authenticate connection
com.hazelcast.client.AuthenticationException: Authentication failed. The configured cluster name on the client (see ClientConfig.setClusterName()) does not match the one configured in the cluster or the credentials set in the Client security config could not be authenticated
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.checkAuthenticationResponse(TcpClientConnectionManager.java:995) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.onAuthenticated(TcpClientConnectionManager.java:898) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.getOrConnectToAddress(TcpClientConnectionManager.java:615) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.lambda$doConnectToCandidateCluster$3(TcpClientConnectionManager.java:505) ~[seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.connect(TcpClientConnectionManager.java:459) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.doConnectToCandidateCluster(TcpClientConnectionManager.java:505) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.doConnectToCluster(TcpClientConnectionManager.java:411) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.connection.tcp.TcpClientConnectionManager.connectToCluster(TcpClientConnectionManager.java:372) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.impl.clientside.HazelcastClientInstanceImpl.start(HazelcastClientInstanceImpl.java:381) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.HazelcastClient.constructHazelcastClient(HazelcastClient.java:460) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.HazelcastClient.newHazelcastClientInternal(HazelcastClient.java:416) [seatunnel-starter.jar:2.3.2]
	at com.hazelcast.client.HazelcastClient.newHazelcastClient(HazelcastClient.java:136) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.engine.client.SeaTunnelHazelcastClient.<init>(SeaTunnelHazelcastClient.java:53) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.engine.client.SeaTunnelClient.<init>(SeaTunnelClient.java:46) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.core.starter.seatunnel.command.ClientExecuteCommand.execute(ClientExecuteCommand.java:111) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.core.starter.SeaTunnel.run(SeaTunnel.java:40) [seatunnel-starter.jar:2.3.2]
	at org.apache.seatunnel.core.starter.seatunnel.SeaTunnelClient.main(SeaTunnelClient.java:34) [seatunnel-starter.jar:2.3.2]
2023-06-28 12:53:12,099 WARN  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] Exception during initial connection to [localhost]:5801: com.hazelcast.client.AuthenticationException: Authentication failed. The configured cluster name on the client (see ClientConfig.setClusterName()) does not match the one configured in the cluster or the credentials set in the Client security config could not be authenticated
2023-06-28 12:53:12,100 WARN  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] Unable to get live cluster connection, retry in 892 ms, attempt: 3, cluster connect timeout: 3000 ms, max backoff: 30000 ms
2023-06-28 12:53:12,994 INFO  com.hazelcast.client.impl.clientside.ClientLoggingService$DefaultLogger.log(ClientLoggingService.java:104) - hz.client_1 [seatunnel-551475] [5.1] Trying to connect to [localhost]:5801

Flink or Spark Version
No response
Java or Scala Version
1.8
Screenshots
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Currently, we can run multiple tasks in local mode using separate JVM instances. The issue likely stems from the hazelcast-client.yaml where cluster-members doesn't include multiple ports. I suggest configuring it like the image shown below:

With this, we can run up to 9 jobs simultaneously

Currently, we can run multiple tasks in local mode using separate JVM instances. The issue likely stems from the hazelcast-client.yaml where cluster-members doesn't include multiple ports. I suggest configuring it like the image shown below:  With this, we can run up to 9 jobs simultaneously

I also encountered this problem, but after I configured it according to the picture, it still didn’t work and I reported this error:
2024-01-02 10:04:01,964 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-503037] [5.1] Exception during initial connection to [localhost]:5809: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5809
2024-01-02 10:04:01,964 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-503037] [5.1] Exception during initial connection to [localhost]:5804: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5804
2024-01-02 10:04:01,965 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-503037] [5.1] Exception during initial connection to [localhost]:5803: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5803
2024-01-02 10:04:01,965 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-503037] [5.1] Exception during initial connection to [localhost]:5815: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5815
2024-01-02 10:04:01,965 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-503037] [5.1] Exception during initial connection to [localhost]:5818: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5818
2024-01-02 10:04:01,966 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-503037] [5.1] Exception during initial connection to [localhost]:5802: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5802
2024-01-02 10:04:01,966 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-503037] [5.1] Exception during initial connection to [localhost]:5810: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5810
2024-01-02 10:04:01,966 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-503037] [5.1] Exception during initial connection to [localhost]:5814: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5814
2024-01-02 10:04:01,966 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-503037] [5.1] Exception during initial connection to [localhost]:5806: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5806
2024-01-02 10:04:01,967 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-503037] [5.1] Exception during initial connection to [localhost]:5817: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5817
2024-01-02 10:04:01,967 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-503037] [5.1] Exception during initial connection to [localhost]:5813: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5813

And i change hazelcast-client.yaml like this:
hazelcast-client:
cluster-name: seatunnel
properties:
hazelcast.logging.type: log4j2
network:
cluster-members:

localhost:5801
localhost:5805
localhost:5812

It reported this error:
2024-01-02 10:51:01,422 WARN  org.apache.seatunnel.engine.server.TaskExecutionService - [localhost]:5802 [seatunnel-995578] [5.1] The Node is not ready yet, Node state STARTING,looking forward to the next scheduling
2024-01-02 10:51:01,436 WARN  org.apache.seatunnel.engine.server.service.slot.DefaultSlotService - failed send heartbeat to resource manager, will retry later. this address: [localhost]:5802
2024-01-02 10:51:01,716 WARN  com.hazelcast.cluster - [localhost]:5802 [seatunnel-995578] [5.1] Node could not join cluster at node: [localhost]:5801 Cause: the target cluster has a different cluster-name
2024-01-02 10:51:02,609 WARN  com.hazelcast.instance.impl.Node - [localhost]:5802 [seatunnel-995578] [5.1] Config seed port is 5801 and cluster size is 1. Some of the ports seem occupied!
Jan 02, 2024 10:51:02 AM com.hazelcast.internal.config.AbstractConfigLocator
INFO: Loading configuration '/opt/seatunnel/seatunnel-2.3.3/config/hazelcast-client.yaml' from System property 'hazelcast.client.config'
Jan 02, 2024 10:51:02 AM com.hazelcast.internal.config.AbstractConfigLocator
INFO: Using configuration file at /opt/seatunnel/seatunnel-2.3.3/config/hazelcast-client.yaml
2024-01-02 10:51:02,700 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-995578] [5.1] Exception during initial connection to [localhost]:5812: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5812
2024-01-02 10:51:02,700 WARN  com.hazelcast.client.impl.connection.ClientConnectionManager - hz.client_1 [seatunnel-995578] [5.1] Exception during initial connection to [localhost]:5805: com.hazelcast.core.HazelcastException: java.io.IOException: Connection refused to address localhost/<IP_ADDRESS>:5805


Proof of Concept: detect stack overflows (x86_64-linux-gnu target only)

I noticed that memory accesses that segfaults are near the bottom of stack, that is within the stack guard allocated by the kernel —I initially expected the guard to be after the stack, but it's actually within it. Checking if addr in the segfault handler (the faulting memory address) is within the stack of the current fiber stack is enough to detect a stack overflow.
Since the main fiber doesn't have a @stack, I use getrlimit(2) to get the default stack size and determine the main stack limit. I only added bindings for x86_64-linux-gnu, but they should be the same for all Linux libc.
I don't know how other POSIX systems (Darwin, OpenBSD, FreeBSD) handle their stack guard.
NOTE: there could a Crystal::System.within_current_stack?(addr) or stack_overflow? method.
refs #271

Or why not checking if the signal is 11? When I do this:
def method
  method
end
method

then I always get signal 11.

@r00ster91 because you also get it if you do Pointer(String).new(0).value https://carc.in/#/r/4i4r

@r00ster91 SIGSEGV (signal 11) can have a number of reasons, one of them can be a stack overflow. More details at https://en.wikipedia.org/wiki/Segmentation_fault

@ysbaddaden ping, this seems like a couple characters fix then ready to merge

@ysbaddaden are you interested in continuing this PR? It'd solve a long-standing problem in crystal and the code looks good

If someone is willing to add the missing sys/resource bindings, please do :-)

@RX14 , @ysbaddaden: On macOS it turns out that the SEGV always happens at an address lower than the top of the stack, but near the top of the stack.  The actual amount depends on the size of the stack frames being allocated in recursion.  So the check being done here never detects stack overflow.
Even on x86_64-linux-gnu, the SEGV isn't always within the body of the stack.  E.g., in some calls of a recursive function that allocates 4kb on the stack, sometimes I see something like
top 0x7fff4a664000 addr 0x7fff4a665c98 bottom 0x7fff4ae64000
where addr is the location of the SEGV. This triggers the check. But other times it's something like
threshold 0x7ffc2cfd6000 addr 0x7ffc2cfd57e8 bottom 0x7ffc2d7d6000
which does not.
I think the thing to do is

Expand the size of the check region to include a few reasonable sized stack frames (4K or so?) beyond the top of the stack.

If the check passes, report an error message like:

Invalid memory access (signal 11) at address 0x7fff4a665c98
Potential stack overflow (e.g., infinite or very deep recursion)

I.e. keep the original message (after all, although unlikely, it might have just been a vanilla bad pointer dereference).  But add on a clause that it looked like a stack overrun to help the diagnosis.  The aim isn't to be perfect, just helpful much of the time.

About those bindings, I'd offer to help but I'm a little intimidated.  Presumably the linux versions will all be the same, and the darwin and BSD versions should be the same.  But that's a lot of hardware to test and verify on (esp. arm-linux-gnueabihf).  What have you guys done in the past?
Oh, and Windows. Windows doesn't have the POSIX getrlimit but has GetCurrentThreadStackLimits which might work instead.

I'd say the last page in the stack and then the page after the stack.

We use mprotect to protect the last 4KB. This can be bypassed, but it's weird that macOS is always below the stack, it should usually trigger a SIGSEGV within the last 4KB as on Linux.

@damaxwell mentioned functions which allocate 4k on the stack, which could bypass a whole page.

I took a look and I don't think there is a call to mprotect for the main fiber; that happens in allocate_stack, which isn't called. My initials tests only involved overrunning the stack on the main fiber, and even the trivial recursive program on macOS seg faults at an address below the top of the stack.
I just checked, and for spawned fibers on macOS, the seg faults are indeed within the stack for small recursive functions, just like Linux.
So the difference seems to be that the two OS's protect the end of the main stack differently, one within and one outside.
I think the easiest thing to do is just expand the check zone a page or two regardless.  This will address the macOS main thread, and the extra buffer will capture some other cases where stack allocation leads to a SIGSEGV beyond the end of the stack.

Oh. We can't call mprotect on the main stack obviously. Good catch!
Since the program segfaulted, and if that happened within the stack or the next 4KB below it, but we safely say "Potential stack overflow (e.g., infinite or very deep recursion)", yes.

@damaxwell you can try https://github.com/multiarch/alpine

With #6928 merged, this can be closed.


1360-NPE-at-FeignLogbookLogger

1360-NPE-at-FeignLogbookLogger: if response body is empty then don't throw NPE, tests are fixed.
Description
#1360
Motivation and Context
So if a response from a server comes without body then FeignLogbookLogger throws an NPE, instead of logging the correct response, like in my example 401 Unauthorized. With my fix we avoid NPE in such cases. The empty body related test was wrong I fixed it as well to test this new bugfix.
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] I have added tests to cover my changes.

@whiskeysierra or @lukasniemeier-zalando or @AlexanderYastrebov  could you please approve it? It's just a small modification, but would be very useful to fix this issue.

Hi, could you please review this PR? We would need this essential fix as soon as possible. Thank you.

Hi @hgabor83, sorry for the silence. Could you please merge main branch again to have a green build?

:+1:


Incorporate new logical type parameters into schema language

The new logical types API introduces new type parameters for time logical type (isAdjustedToUTC, unit), int type (bitWidth, isSigned) and timestamp type (isAdjustedToUTC, unit).
The schema language doesn't support these type parameters yet.
Reporter: Nándor Kollár / @nandorKollar
Related issues:

Support for new logical type representation (duplicates)
Support for new logical type representation (depends upon)

Note: This issue was originally created as PARQUET-1284. Please see the migration documentation for further details.

Nándor Kollár / @nandorKollar:
This was implemented as part of PARQUET-1253


Add submariner data to gather

Add submariner-addon CRs and logs to gather.
Signed-off-by: Vishal Thapar<EMAIL_ADDRESS>Related Issue:  stolostron/backlog#22897
Description of Changes:

Gather submariner-addon CRs
Gather pod log from submariner-operator namespace

What resource is being added: submarinerconfigs.submarineraddon.open-cluster-management.io, brokers.submariner.io
Is this a Hub or Managed cluster change?:
Hub Cluster, Managed Cluster
Notes:
Users will still need to run subctl gather to capture connectivity data, so this PR is only focussing on addon data which is not covered by subctl currently.

Users will still need to run subctl gather to capture connectivity data, so this PR is only focussing on addon data which is not covered by subctl currently.

Fixes: https://github.com/stolostron/backlog/issues/22897

@vthapar can you please link to the issue by using "Fixes"?

@vthapar can you please link to the issue by using "Fixes"?

Done. I thought the Related Issue field may serve same purpose.


lazy collections and bytecode enhancer

So I've run into what I consider to be some pretty unexpected behavior of Hibernate ORM when the bytecode enhancer is enabled with enableLazyInitialization = true.
There's two aspects of the behavior that, naïvely, look suboptimal to me, at least in the context of HR:

By default, lazy collection are marked for field-level lazy fetching. I gotta say I just don't see much advantage to this, how is it better than the collection proxy? Indeed, it's arguably worse, since direct field access doesn't get intercepted. That's tolerable for fields that the user has explicitly marked for lazy fetching, but not for this implicit behavior.
When you do fetch the collection, AbstractEntityPersister.initializeLazyProperty() doesn't set the field of the entity like what it does for other lazy fields. That's either a bug, or it's due to how we're calling this method in Hibernate reactive. Whatever, it means that AbstractEntityPersister.initializeLazyProperty() has a pretty fragile contract.

@Sanne I know you're an expert on this stuff, can you help me understand all this please?

@Sanne the workaround in #375 solves problem (2) at least for HR. But shouldn't this be done in core?

Hi Gavin, I'm not sure on terminology which might be important; and no I'm not the expert in this area, I've just started recently to fix some issues with it in the context of making the existing stuff work in Quarkus. What do you mean by field-level lazy fetching exactly?
And by "bytecode enhancer is enabled", I assume you're referring to build time enhancement?
It might help to keep in mind that we can't do proxies in Quarkus, as you can't have a proxy compiled to native image; so we're focusing on bytecode manipulation of the class - which wasn't indeed as stable as I'd like it, but it has other advantages as well over proxies: the type identity is consistent at runtime, which helps with various subtle bugs people had, e.g. integrating with other tools and frameworks.
Regarding field access: we actually intercept field accessors too and re-map them; in particular Panache likes this.
So conceptually I don't feel it's a bad choice, but in practice this is possibly not very mature yet; we certainly had a list of issues manifesting since Quarkus made this model more popular. So please give me some more context on what didn't work - did you have a problem in Quarkus, or a different test?

There's one more novelty to keep in mind; we now support "enhanced proxies": this allows some loading patterns to perform much better.
See Steve's blog for a description:

https://in.relation.to/2019/07/30/bytecode-proxy/

What do you mean by field-level lazy fetching exactly?

I mean enableLazyInitialization = true.

And by "bytecode enhancer is enabled", I assume you're referring to build time enhancement?

Right. In Gradle.

It might help to keep in mind that we can't do proxies in Quarkus

Yeah but that's doesn't affect collection proxies. They're just regular classes.

Regarding field access: we actually intercept field accessors too and re-map them

Perhaps that works in Quarkus, but it's not working for me, outside Quarkus.

Regarding field access: we actually intercept field accessors too and re-map them

Perhaps that works in Quarkus, but it's not working for me, outside Quarkus.

Field access requires enhancing the caller (the application) so it's not easy to setup generally; Stephane did some extra magic in Quarkus. So I agree it's not the best choice as general purpose strategy, but it's not a bad choice in Quarkus. Just to clarify the context.
So yes I am confused like you by what you say in #2 , that seems odd; we should ask the real experts ( @sebersole @dreab8 ) , but it might be easier to figure out what you mean if you have a failing test they could toy with?
It seems plausible that it's more likely a fragile contract than a bug, as I'd be very surprised if we had no tests covering this area (and no complaints).

@Sanne @sebersole I think perhaps I've tracked it down to this commit:
https://github.com/hibernate/hibernate-orm/commit/cc01f2561dbca95bd58048f85e283ba1719ee588

Specifically, this change:
https://github.com/hibernate/hibernate-orm/commit/cc01f2561dbca95bd58048f85e283ba1719ee588#diff-7c0b4e29c08a30311a237f9811d44861L1057-R1088

Thanks for digging! Interesting, so by reading the https://hibernate.atlassian.net/browse/HHH-11147 description it seems intentional to support getReference, which indeed does make good use for a non-initialized entity.

it seems intentional to support getReference, which indeed does make good use for a non-initialized entity.

This is a collection proxy, not an entity proxy.

Specifically, this change:

Well, no, actually I now realize there's two parts to this:
initializeLazyProperty() doesn't fetch the collection
First, initializeLazyProperty() doesn't fetch the collection. In fact, that's probably sorta OK in Hibernate ORM, where collection fetching happens transparently when you access the collection.
But it's a huge pain in HR, where fetch() is an explicit operation, because first I have to explicitly fetch the field, and then I have to explicitly fetch the collection. But OTOH perhaps there's a way for my to hide that from the user. I will see if I can.
Even so, it seems like a useless behavior: why make collection fields lazy in the first place? There doesn't seem to be any useful purpose to that, at least not that I can think of!
initializeLazyProperty() doesn't set the collection wrapper to the field
Now, this seems to be simply wrong. For other lazy properties, initializeLazyProperty() sets the field value into the entity, but this doesn't happen for a collection wrapper.

But OTOH perhaps there's a way for me to hide that from the user. I will see if I can.

Oops, no, there's not. I can't.

The thing is, I guess I also question EnhancementHelper.includeInBaseFetchGroup(), which returns false for lazy collections. I don't think it should.

Now, this seems to be simply wrong. For other lazy properties, initializeLazyProperty() sets the field value into the entity, but this doesn't happen for a collection wrapper.

Oh, right, so I guess the assumption is that you're only going to access the collection via getter method. So it's inconsistent with what happens for other fields, but it's not actually broken.


Appstudio update test-component-pac-yvjd

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI/test-component-pac-yvjd-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
5 seconds
init

✅ Succeeded
19 seconds
clone-repository

✅ Succeeded
57 seconds
build-container

✅ Succeeded
12 seconds
sast-snyk-check

✅ Succeeded
27 seconds
inspect-image

✅ Succeeded
43 seconds
clamav-scan

✅ Succeeded
7 seconds
sbom-json-check

✅ Succeeded
7 seconds
deprecated-base-image-check

✅ Succeeded
3 minutes
clair-scan

✅ Succeeded
6 seconds
show-sbom

✅ Succeeded
7 seconds
show-summary

Pipelines as Code CI/test-component-pac-yvjd-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
9 seconds
init

✅ Succeeded
16 seconds
clone-repository

✅ Succeeded
49 seconds
build-container

✅ Succeeded
29 seconds
sast-snyk-check

✅ Succeeded
11 seconds
sbom-json-check

✅ Succeeded
16 seconds
clair-scan

✅ Succeeded
42 seconds
clamav-scan

✅ Succeeded
21 seconds
inspect-image

✅ Succeeded
11 seconds
deprecated-base-image-check

✅ Succeeded
7 seconds
show-sbom

✅ Succeeded
7 seconds
show-summary

Pipelines as Code CI/test-component-pac-yvjd-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
9 seconds
init

✅ Succeeded
16 seconds
clone-repository

✅ Succeeded
49 seconds
build-container

✅ Succeeded
29 seconds
sast-snyk-check

✅ Succeeded
11 seconds
deprecated-base-image-check

✅ Succeeded
16 seconds
clair-scan

✅ Succeeded
11 seconds
sbom-json-check

✅ Succeeded
21 seconds
inspect-image

✅ Succeeded
42 seconds
clamav-scan

✅ Succeeded
7 seconds
show-summary

✅ Succeeded
7 seconds
show-sbom


Refactor ingress class templating

Which problem is this PR solving?

Closes #173

Short description of the changes
Moves templating to be equal across the ingresses and updates the example default values file with an example.

Sorry completely forgot I even opened this PR

@masonjlegere are you able to make further changes to this one? We can't merge it as-is.

Yes! Corrected and added a basic unit test for it but can remove the test if it's not wanted. I imagine they can get ran whenever ct is being used against minikube in CircleCI. This could also just be made into a proper integration test if the kubecontext gets set.

I am not seeing the CircleCI test job as a status check 🤔

@masonjlegere it looks like maybe you had a bad merge/rebase.  The files changed tab is showing a bunch of changes that are already in main.


python312Packages.aiocache: 0.12.2 -> 0.12.3

Diff: https://github.com/aio-libs/aiocache/compare/refs/tags/v0.12.2...v0.12.3
Changelog: https://github.com/aio-libs/aiocache/releases/tag/v0.12.3
Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 344605 run on x86_64-linux 1

11 packages built:

home-assistant-component-tests.permobil
python311Packages.aiocache
python311Packages.aiocache.dist
python311Packages.mypermobil
python311Packages.mypermobil.dist
python312Packages.aiocache
python312Packages.aiocache.dist
python312Packages.mypermobil
python312Packages.mypermobil.dist
wapiti
wapiti.dist

Looks like that some tests are performance- or timing dependent. I can make another test fails locally.
[...]
collected 804 items / 1 deselected / 803 selected

tests/acceptance/test_base.py .......................................... [  5%]
................................................                         [ 11%]
tests/acceptance/test_decorators.py .................................... [ 15%]
.........                                                                [ 16%]
tests/acceptance/test_factory.py .......                                 [ 17%]
tests/acceptance/test_lock.py .......................................... [ 22%]
......F......                                                            [ 24%]
tests/acceptance/test_plugins.py .............                           [ 26%]

All tests are passing on Hydra.