Resolve logging problem

So since a long time, our logs were not getting printed properly :| I tried a lot hacks and work arounds but for some reason I am unable to have the logs written to a particular log file with color and has some encoding issue :-|   Now there are some work arounds mentioned in the issues : 1 and 2, but it doesn't work for me :-| . Now we either use some other library (apparently the one we are using is most popular) or we just cat when we want logs to be written to a particular file.
I also cleaned up the logs -
(i) removed unnecessary logs
(ii) println -> info

Minor nits about imports, but overall I am fine with this change.
Question: when you say you can't output logs in color to a file, do you mean that if you add calls like .green() the logs aren't written at all when sent to a file? Because if you just mean the color is lost, then I'd expect that from the fact that it's a plain test file and not a rich TTY.

Hmmm Its actually that the characters don't get encoded and are shown as blobs :| . It is open issue (https://github.com/env-logger-rs/env_logger/issues/208 and https://github.com/env-logger-rs/env_logger/issues/178) it has something to do with the pipe operation.


Question about initializing lidar motion

Hi again
I know the initalization of the  lidar motion is one of the important thing in ICP
In your code , here
At the beginning pose of current scan, it uses the end pose of previous scan.
I don't catch up how it inits the end pose of current scan?
I don't understand above code
I would appreciate if you can explain that code, if not can you recommend something to refer ?
Best regards.

Hi,
So we have different modes, (constant velocity or no initialization),
With constant velocity, it uses the previous relative pose to initialize the motion
With no initialization, it simply uses the previous begin time.

Thanks a lot !


Add KoP-SIG Chatroom to the Configure File

Add Pulsar - KoP-SIG Chatroom to the Configure File

Hi @tuhaihe , seems that different organization is located in different config file?
See https://github.com/kaiyuanshe/osschat/tree/main/src/config-projects?
So I think we need to create a new config named streamnative?

Hi @tuhaihe , seems that different organization is located in different config file?
See https://github.com/kaiyuanshe/osschat/tree/main/src/config-projects?
So I think we need to create a new config named streamnative?

Sounds great. Let me create one new PR.


allowedHostPaths should set readOnly:true

See https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems

Warning:
There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and abusing the credentials of system services, such as Kubelet.
Writeable hostPath directory volumes allow containers to write to the filesystem in ways that let them traverse the host filesystem outside the pathPrefix. readOnly: true, available in Kubernetes 1.11+, must be used on all allowedHostPaths to effectively limit access to the specified pathPrefix.

Thanks for the comments @liggitt,  I will address that:)

addressed in #12

Thanks for the quick response. If the intent is to generate least privilege PSPs, I think you actually need to check if the volumeMounts are readonly. If so, readonly allowedHostPaths can be generated. If not, you can generate non-readonly allowedHostPaths, but it's probably worth emitting a warning that they will be ineffective at limiting the pods to that prefix

You're right, thanks for pointing it out. Will fix it.

Done.


Add related alerts to Get-DbaAgentOperator

Type of Change

[ ] Bug fix (non-breaking change, fixes #)
[x ] New feature (non-breaking change, adds functionality)
[ ] Breaking change (effects multiple commands or functionality)
[ ] Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
[ ] Adding code coverage to existing functionality
[ ] Pester test is included
[ ] Nunit test is included
[ ] Documentation
[ ] Build system

Purpose
Get-DbaAgentOperator currently pulls agent jobs where the operator is setup for notification. I've added the related alerts, where the operator is setup for alert response.
Approach
Using the alerts smo EnumNotifications and filtering by current operator name
Commands to test
Get-DbaAgentOperator -SqlInstance 'localhost' -Verbose | Select-Object -Property SqlInstance, Name, IsEnabled, RelatedJobs, LastEmail, RelatedAlerts, AlertLastEmail | Format-Table -AutoSize;
Screenshots

ty, looks great! will merge when tests pass

woo! 🎊


Added test cases NMS_FT_165, NMS_FT_167, NMS_FT_168.

Added test cases NMS_FT_165, NMS_FT_167, NMS_FT_168.

ok to test

please merge


DeltaMonitor not cleared on backtracks

Perhaps my understanding of DeltaMonitor is incorrect but I did not expect the following code to throw an error with the latest develop branch.
public static void main(String[] args) {
    Solver s = new Solver();
    final IntVar i = VF.enumerated("i", -2, 2, s);
    final IntVar j = VF.enumerated("j", -2, 2, s);
    // Does nothing, just observes the values removed from variables i and j.
    Propagator p1 = new Propagator(new IntVar[]{i, j}, PropagatorPriority.UNARY, false) {

        private final IIntDeltaMonitor iD = i.monitorDelta(aCause);
        private final IIntDeltaMonitor jD = j.monitorDelta(aCause);

        @Override
        public void propagate(int evtmask) throws ContradictionException {
            iD.freeze();
            iD.forEachRemVal((IntProcedure) x -> {
                System.out.println("Delta monitor for variable says that the value " + x + " is removed from variable i");
                if (i.contains(x)) {
                    throw new Error("Delta monitor lied to me.");
                }
            });
            iD.unfreeze();
            jD.freeze();
            jD.forEachRemVal((IntProcedure) x -> {
                System.out.println("Delta monitor for variable says that the value " + x + " is removed from variable j");
                if (j.contains(x)) {
                    throw new Error("Delta monitor lied to me.");
                }
            });
            jD.unfreeze();
        }

        @Override
        public ESat isEntailed() {
            return ESat.TRUE;
        }
    };
    // if j == 1 then i != 1.
    Propagator p2 = new Propagator(new IntVar[]{i, j}, PropagatorPriority.UNARY, false) {

        @Override
        public void propagate(int evtmask) throws ContradictionException {
            if (j.isInstantiatedTo(1)) {
                i.removeValue(1, aCause);
            }
        }

        @Override
        public ESat isEntailed() {
            return ESat.TRUE;
        }
    };
    Chatterbox.showDecisions(s);
    Chatterbox.showSolutions(s);
    s.post(new Constraint("Constraint", p1, p2));
    s.findAllSolutions();
}

The above code will print:
...[L]j  ==  -2 (0) //i = {-2,-1,0,1,2} j = {-2,-1,0,1,2}
Delta monitor for variable says that the value -1 is removed from variable j
Delta monitor for variable says that the value 0 is removed from variable j
Delta monitor for variable says that the value 1 is removed from variable j
Delta monitor for variable says that the value 2 is removed from variable j
....[L]i  ==  -2 (0) //i = {-2,-1,0,1,2} j = -2
Delta monitor for variable says that the value -1 is removed from variable i
Delta monitor for variable says that the value 0 is removed from variable i
Delta monitor for variable says that the value 1 is removed from variable i
Delta monitor for variable says that the value 2 is removed from variable i
Delta monitor for variable says that the value -1 is removed from variable j
Delta monitor for variable says that the value 0 is removed from variable j
Delta monitor for variable says that the value 1 is removed from variable j
Delta monitor for variable says that the value 2 is removed from variable j
- Solution #1 found. 1 Solutions, Resolution 0.112s, 3 Nodes (26.9 n/s), 0 Backtracks, 0 Fails, 0 Restarts
	i = -2 j = -2 .
....[R]i  ==  -2 (1) //i = {-2,-1,0,1,2} j = -2
Delta monitor for variable says that the value -2 is removed from variable i
.....[L]i  ==  -1 (0) //i = {-1,0,1,2} j = -2
Delta monitor for variable says that the value 0 is removed from variable i
Delta monitor for variable says that the value 1 is removed from variable i
Delta monitor for variable says that the value 2 is removed from variable i
- Solution #2 found. 2 Solutions, Resolution 0.138s, 5 Nodes (36.2 n/s), 1 Backtracks, 0 Fails, 0 Restarts
	i = -1 j = -2 .
.....[R]i  ==  -1 (1) //i = {-1,0,1,2} j = -2
Delta monitor for variable says that the value -1 is removed from variable i
......[L]i  ==  0 (0) //i = {0,1,2} j = -2
Delta monitor for variable says that the value 1 is removed from variable i
Delta monitor for variable says that the value 2 is removed from variable i
- Solution #3 found. 3 Solutions, Resolution 0.142s, 7 Nodes (49.4 n/s), 2 Backtracks, 0 Fails, 0 Restarts
	i = 0 j = -2 .
......[R]i  ==  0 (1) //i = {0,1,2} j = -2
Delta monitor for variable says that the value 0 is removed from variable i
.......[L]i  ==  1 (0) //i = {1,2} j = -2
Delta monitor for variable says that the value 2 is removed from variable i
- Solution #4 found. 4 Solutions, Resolution 0.150s, 9 Nodes (60.1 n/s), 3 Backtracks, 0 Fails, 0 Restarts
	i = 1 j = -2 .
.......[R]i  ==  1 (1) //i = {1,2} j = -2
Delta monitor for variable says that the value 1 is removed from variable i
- Solution #5 found. 5 Solutions, Resolution 0.151s, 10 Nodes (66.3 n/s), 4 Backtracks, 0 Fails, 0 Restarts
	i = 2 j = -2 .
...[R]j  ==  -2 (1) //i = {-2,-1,0,1,2} j = {-2,-1,0,1,2}
Delta monitor for variable says that the value 1 is removed from variable i
Exception in thread "main" java.lang.Error: Delta monitor lied to me.
	at org.clafer.choco.constraint.propagator.PropReifyEqualXY$3.lambda$propagate$7ffb7347$1(PropReifyEqualXY.java:132)
	at org.clafer.choco.constraint.propagator.PropReifyEqualXY$3$$Lambda$4/511754216.execute(Unknown Source)
	at org.chocosolver.solver.variables.delta.monitor.EnumDeltaMonitor.forEachRemVal(EnumDeltaMonitor.java:93)
	at org.clafer.choco.constraint.propagator.PropReifyEqualXY$3.propagate(PropReifyEqualXY.java:129)
	at org.chocosolver.solver.propagation.hardcoded.SevenQueuesPropagatorEngine.propagate(SevenQueuesPropagatorEngine.java:190)
	at org.chocosolver.solver.search.loop.SearchLoop.downBranch(SearchLoop.java:407)
	at org.chocosolver.solver.search.loop.SearchLoop.downRightBranch(SearchLoop.java:397)
	at org.chocosolver.solver.search.loop.SearchLoop.loop(SearchLoop.java:288)
	at org.chocosolver.solver.search.loop.SearchLoop.launch(SearchLoop.java:193)
	at org.chocosolver.solver.Solver.solve(Solver.java:891)
	at org.chocosolver.solver.Solver.findAllSolutions(Solver.java:767)
	at org.clafer.choco.constraint.propagator.PropReifyEqualXY.main(PropReifyEqualXY.java:169)

Your usage of delta monitor is incorrect:
Delta monitors are used for incremental propagation only:

The third argument in the propagator super constructor should be "true"
The method propagate(int e) will be called ONCE (further propagations will be incremental). It should not use the deltamonitors but UNFREEZE them at the end (in order to initialize the datastructure).
You must then override the propagate(int vIdx, int e) method that is called whenever vars[vIdx] has changed. Then you can use the deltamonitor of that variable as you did (freeze, use, unfreeze).

See PropEqualX_Y or PropInverseChannelAC for an example.
Actually, delta monitors are not used that much...

My bad, thanks.

I made the 3 changes you suggested and I still get the exact same error, see updated code snippet below:
public static void main(String[] args) {
    Solver s = new Solver();
    final IntVar i = VF.enumerated("i", -2, 2, s);
    final IntVar j = VF.enumerated("j", -2, 2, s);
    // Does nothing, just observes the values removed from variables i and j.
    Propagator p1 = new Propagator(new IntVar[]{i, j}, PropagatorPriority.UNARY, true) {

        private final IIntDeltaMonitor iD = i.monitorDelta(aCause);
        private final IIntDeltaMonitor jD = j.monitorDelta(aCause);

        @Override
        public void propagate(int evtmask) throws ContradictionException {
            iD.unfreeze();
            jD.unfreeze();
        }

        @Override
        public void propagate(int idxVarInProp, int mask) throws ContradictionException {
            iD.freeze();
            iD.forEachRemVal((IntProcedure) x -> {
                System.out.println("Delta monitor for variable says that the value " + x + " is removed from variable i");
                if (i.contains(x)) {
                    throw new Error("Delta monitor lied to me.");
                }
            });
            iD.unfreeze();
            jD.freeze();
            jD.forEachRemVal((IntProcedure) x -> {
                System.out.println("Delta monitor for variable says that the value " + x + " is removed from variable j");
                if (j.contains(x)) {
                    throw new Error("Delta monitor lied to me.");
                }
            });
            jD.unfreeze();
        }

        @Override
        public ESat isEntailed() {
            return ESat.TRUE;
        }
    };
    // if j == 1 then i != 1.
    Propagator p2 = new Propagator(new IntVar[]{i, j}, PropagatorPriority.UNARY, false) {

        @Override
        public void propagate(int evtmask) throws ContradictionException {
            if (j.isInstantiatedTo(1)) {
                i.removeValue(1, aCause);
            }
        }

        @Override
        public ESat isEntailed() {
            return ESat.TRUE;
        }
    };
    Chatterbox.showDecisions(s);
    Chatterbox.showSolutions(s);
    s.post(new Constraint("Constraint", p1, p2));
    s.findAllSolutions();
}

Actually, delta monitors are not used that much...

There are 20 propagators/views in the choco 3 library that use IIntDeltaMonitor. Quite a few of classes in my own project uses them as well.

Thank you for the bug reporting, I found where this comes from. I'll fix that asap.

Actually, I think your code is not correct either: you should not iterate over removed values of a variable which has not been modified since the last call of the propagator.
In the code of your first propagator, there should be a condition on idxVarInProp.

Finally, I rollback my patch since your code was not correct. I add a error message, though, when delta and deltamonitors are not synchronized (actually, it is an assertion error, but I'm considering moving it to a standard error, even if it may lead to performance issues).


NetInfo.isConnected.addEventListener: diverging behaviors on Android and iOS

https://github.com/facebook/react-native/issues/22954

I did some basic testing and I could not repro this bug (which was filed before the migration to this repo). I realize this contradicts this  snackable example, and I don't really have an explanation for why that is.
I am using<EMAIL_ADDRESS>and I've linked the migrated project on Android and iOS.
Here is the code I tested
NetInfo.addEventListener("connectionChange", (connectionInfo: RNConnectionInfo | RNConnectionType) => console.log(JSON.stringify(connectionInfo)));

Note that I never called NetInfo.isConnected.fetch()
On iPhone 6 - 12.1 Simulator

The connectionChange event listener fired on app launch

On a real Android HTC Desire 530 (Android 6.0.1)

The connectionChange event listener fired on app launch

This leads me to conclude that this is the current behavior (which is unclear from the docs BTW):
connectionChange event listener fired on initial register AND on subsequent network state changes.
es

I think I've managed to reproduce this with an integration test actually. I believe that it's a timing issue. It emits on both platforms if you subscribe close to the app launch, however, if you set up a listen a while after the app launch then the Android one is not called and the iOS one is. You should be able to confirm this by instead setting up the listener on a button press.
I am looking into making it so the listener will always emit when you begin listening to it, and then on any changes, on both platforms.


fix: #20002 optimize head request on serializeDataProvider

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
❌

Fixed issues
#20002

@bizley
I tried my best to add unit test which not covered before, seems sentry still not satisfy and not detect the coverage
Also the test only for previous state, not testing #20002 kind of bug,
to test #20002, I'd need to include Mockery library $arrayDataProviderMocked->shouldReceive('getModels')->never()
But I dont see its usage before, so I think it's not necessary.

I'm not sure if adding it in the same test is not interfering with it. Try to exclude it to a new one. Also, Mockery is not needed, PHPUnit is enough.

I separated the test, codeconv back to be not satisfied
and last time nodejs test<PHONE_NUMBER>7 failed, now it's success, seems some tests are unstable

Cheers


Testcafe - Applicant Profile - My Skills - Fix breaking test.

Notes:

Extent wait time back to previous value.

Is this failing locally? I'm not seeing failures on other PR's

Is this failing locally? I'm not seeing failures on other PR's

No it passed locally for me. I saw it failing on #2499 as well.


Adding some build scripts to the repository

This adds some basic build scripts to the repository.
The current requirements are that a user first:

Install the C++ Toolset
Install Vcpkg
Use Vcpkg to install freetype glad glm lua sdl2 sdl2-image

After that, they need to run:
4) ./generate.sh -DCMAKE_TOOLCHAIN_FILE=$VcpkgDir/scripts/buildsystems/vcpkg.cmake
5) ./build.sh
This should produce the necessary build files, etc.
Users can also optionally run just ./build.sh --ci (or ./scripts/cibuild.sh) which will automatically do steps 2 thru 5 (inclusive).

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

On Ubuntu 16.04, this looks to be the minimal command line to get all required tools that CI won't auto-download.
sudo apt-get update
sudo apt-get install apt-transport-https ca-certificates gnupg software-properties-common wget -y

wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2>/dev/null | sudo apt-key add -
sudo apt-add-repository 'deb https://apt.kitware.com/ubuntu/ xenial main'

wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key 2>/dev/null | sudo apt-key add -
sudo apt-add-repository 'deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial main'

sudo apt-get update
sudo apt-get install clang cmake curl g++ tar unzip -y

Later Ubuntu versions would be similar, but with the respective distro repos (such as bionic, rather than xenial, for 18.04).

Windows requires the C++ Toolchain (generally acquired from Visual Studio) and CMake installed.


Impossible to save a PositionDefinition

Some PositionDefinitions cannot be saved cause of a wrong control.
Test case
Try to save the following PositionDefinition: any book, any Pricing Parameters Set, any currency, a Product Type (ex: IRSwap), no product.
The user should have access to the Product Type (in this example, IRSwap).
Actual results:
The PositionDefinition cannot be saved, error message: "ProductType is not found among the allowed product types. Please contact your administrator."
Expected results:
The PositionDefinition is saved as the user has access to IRSwaps.
Affected version: 1.0.4

The control has been fixed.
The fix will be part of a v1.0.5.


[4.0.0-rc04] Setting repeat mode to RepeatMode.Track causes playback to pause after completing a track

Describe the Bug
When setting repeat mode to RepeatMode.Track on iOS (library version 4.0.0-rc04), playback gets paused after the track is completed. The progress is correctly reset. No PlaybackActiveTrackChanged event is fired.
On android, RepeatMode.Track works as expected. The track restarts after completing, and a PlaybackActiveTrackChanged event is fired.
Steps To Reproduce
On iOS, Set repeat mode to RepeatMode.Track by calling await TrackPlayer.setRepeatMode(RepeatMode.Track). Then finish a track.
Code To Reproduce
export const SetupService = async () => {
     await TrackPlayer.setupPlayer();
     await TrackPlayer.setRepeatMode(RepeatMode.Track)
}

Replicable on Example App?
I created a fork of this project where repeat mode is set to RepeatMode.Track in the example app, in this commit.
Paste the results of npx react-native info:
System:
    OS: macOS 13.2.1
    CPU: (12) arm64 Apple M2 Pro
    Memory: 104.02 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.10.0 - ~/.nvm/versions/node/v16.10.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v16.10.0/bin/yarn
    npm: 7.24.0 - ~/.nvm/versions/node/v16.10.0/bin/npm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.12.0 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4
    Android SDK:
      Android NDK: 25.2.9519653
  IDEs:
    Android Studio: Not Found
    Xcode: 14.3/14E222b - /usr/bin/xcodebuild
  Languages:
    Java: 16.0.2 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.2.0 => 18.2.0
    react-native: 0.71.4 => 0.71.4
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Paste the exact react-native-track-player version you are using
4.0.0-rc04
Real device? Or simulator?
Real device
What OS are you running?
iOS 16.4
How I can Help
I'm pretty sure this is an issue with SwiftAudioEx. I'd love to help, but I don't know Swift and how to integrat work on SwiftAudioEx into this project during development, and my experience with native development is generally very limited. So I'm not sure if I can be of help here unfortunately.

I also can confirm the issue is present in latest 4.0.0-rc04 release.

me too

This is how I temporarily solved the problem：
if (Platform.OS === 'ios') { 			await this.playSoundOnce(url, stop => { 				if (stop) { 					this.playSoundOnce(url); 				} 			}); 		} else { 			await this.playSoundWithMode(url, RepeatMode.Queue); 		}

This is how I temporarily solved the problem
if (Platform.OS === 'ios') { 			let callback = (stop: boolean) => { 				if (stop) { 					this.playSoundOnce(url, callback); 				} 			}; 			await this.playSoundOnce(url, callback); 		} else { 			await this.playSoundWithMode(url, RepeatMode.Queue); 		}

I tried it again in 4.4.0-rc05. Now the playback doesn't pause after completing the track, but no event is fired when the track restarts again. This unfortunately makes it next to impossible to build repeat mode functionality where a track is played n-times :/ Is this maybe just an issue on my end? Or something you experienced as well @jspizziri ?

Since the active track has not changed, why would you expect PlaybackActiveTrackChanged to fire? What happens on android, does it fire the event there?

I agree with you, but unfortunately I experience a few unintended side effects with repeat mode enabled.
PlaybackActiveTrackChanged is called in repeat mode on Android, but not in iOS. In 3.2.0 and before PlaybackTrackChanged was called for both OS every time the track started. PlaybackTrackChanged, though deprecated, is now also not called on iOS but still on Android.
What I just now noticed is that PlaybackQueueEnded is called with the last position of the track if repeat mode is not enabled. If repeat mode is enabled, it is called with position 0.
I currently work around both of these issues by listening to the player progress updates and comparing them with each other, which allows me to detect repeats. This is not ideal, but I didn't see another way. Let me know if I can provide further information!

Thank you for responding & I agree with you @puckey! Unfortunately I experience a few unintended side effects with repeat mode enabled.
PlaybackActiveTrackChanged is called in repeat mode on Android when a track is restarted, but not in iOS. In 3.2.0 and before PlaybackTrackChanged was called for both OS every time the track started. PlaybackTrackChanged, though deprecated, is now also not called on iOS but still on Android.

Could you make an issue for the deprecated PlaybackTrackChanged not being called on ios?
I will check the Android implementation of the PlaybackActiveTrackChanged event, to see if we might change it to not be emitted when the same track repeats. Otherwise I will change the ios implementation to follow the android one.

What I just now noticed is that PlaybackQueueEnded is fired with the last position of the track if repeat mode is not enabled. If repeat mode is enabled, it's fired with position 0.

Could you make a separate issue for this?

I currently work around both of these issues by listening to the player progress updates and comparing them with each other, which allows me to detect repeats. This is not ideal, but I didn't see another way. Let me know if I can provide further information!

What exactly are you doing that you need this workaround for?

(Good chance that the playback queue ended event issue is fixed by https://github.com/doublesymmetry/react-native-track-player/pull/2058)

I created https://github.com/doublesymmetry/react-native-track-player/issues/2059 and https://github.com/doublesymmetry/react-native-track-player/issues/2060
Thanks for your help, @puckey!

@puckey My assumption that this was fixed in 4.0.0-rc5 was wrong unfortunately. This issue still exists in the current version, though it does not appear on an emulator - only on a real device.
Should I close this in favor of https://github.com/doublesymmetry/react-native-track-player/issues/2070, or leave this open because it was about 4.0.0-rc04?


feat!: reject ICA transactions with a message not on hard-coded allowlist

Closes https://github.com/celestiaorg/celestia-app/issues/3836
This PR rejects blocks that include ICA transactions with a message not on the hard-coded allowlist icaAllowedMessages(). This is a temporary solution that we may want until governance votes to modify the allowlist from wildcard to the explicit allowlist.
This targets the v2.x branch and if merged, we would release it as a minor release (e.g. v2.2.x). The original motivation behind this PR is that we could introduce this change as a "soft-fork" and remove it quickly after governance votes to fix the param.
I would rather not merge this. I think there is more risk from merging + releasing this than there is from having the param be a wildcard for a week. This PR is complex and there isn't a lot of time to let this bake on testnets. Note: this PR invalidates the requirement:

Requirement 5 [ProcessProposal, determinism-2]: For any two correct processes p and q, and any arbitrary block u, if p’s (resp. q’s) CometBFT calls RequestProcessProposal on u at height h, then p’s Application accepts u if and only if q’s Application accepts u. Note that this requirement follows from Requirement 4 and the Agreement property of consensus.

From CometBFT docs. In other words for a block with an ICA tx that contains a message not on icaAllowedMessages():

celestia-app nodes < v2.2.x will accept it
celestia-app ndoes > v2.2.x will reject it

Closing b/c this is too complex. We're instead going to modify the param via governance.


update Stable to Next

tentative update

Umm, 96 files 🤯
Can you briefly elaborate what you did for this PR ?

Umm, 96 files exploding_head
Can you briefly elaborate what you did for this PR ?

mainly:
cp -a docs/* versioned_docs/version-stable/
Then, I adapted only one file: versioned_sidebars/version-stable-sidebars.json from sidebars.js

Umm, 96 files exploding_head
Can you briefly elaborate what you did for this PR ?

I think lot of changes comes from screenshots I added to the UI quickstart :smile:

rebased on main, kept following changes as fixups (we'll merge as a squashed commit).
Just done another cp -a docs/* versioned_docs/version-stable/, and added missing part to the versioned sidebar.


Add support for firing a timer at a specific time

This is a sweet workflow! I also am a big fan of timers (I'm actually working on a timer app for iOS). I had this thought of I wish I could set a timer for a specific time, like "at 10:30am" and when I saw it couldn't do it, I thought I would add it real fast!
This PR adds support for firing a timer at a specific time like

"at 4pm"
"at 3p"
"at 11"
"at 11:55"
"at 13:30"

Javascript is not my specialty, so please feel free to clean up and modify as needed 😊

Hi @jangelsb. Thank you for contribution! Looks good, I will review this soon.

@jangelsb I would remove 'at' part from regexp and detect if the input is relative or absolute time based on pattern (they are quite different, so doable).
In general, I'm not so sure about absolute time because of the specifics of this workflow. It transforms time into seconds and fires alarm after Alfred delay. So these timers are not super reliable. Say, if you reload you computer they will be gone. This is where the current limitation of 2 hours comes from and this is the main problem with this workflow.
I now think that it either needs a significant overhaul, or just better use another similar workflow, like Shrieking Chimes (however I wasn't able to make it work) with native Clock app support.


Add support for multiple heads

Kind of a quick and dirty solution--not ideal because it results in multiple API instances hanging on to multiple API keys. But it works.

Thanks Joel.  I will look at this this weekend and get the merge done.   One question, did you just add another instance to you your config, or did you have to run a new instance of homebridge?

Thanks Joel.  I will look at this this weekend and get the merge done.   One question, did you just add another instance to you your config, or did you have to run a new instance of homebridge?

Thanks Joel. I will look at this this weekend and get the merge done. One question, did you just add another copy of the accessory your config, or did you have to run a new instance of homebridge?

Just added a new copy of the accessory.

Thanks Joel. I will look at this this weekend and get the merge done. One question, did you just add another copy of the accessory your config, or did you have to run a new instance of homebridge?

Just added a new copy of the accessory.


Rebase of quic-server feature branch

This is joint work with @sashan that resulted in a rebase of the QUIC server feature branch onto today's master snapshot (2478d3b7f5c4c2da9828e05308b34a4b078035f8).
Merge conflits that need to be resolved were comparatively minor, mostly ordinals, duplicate error numbers and the like.
Guards for ctx.qc->started needed a further tweak to be used only with connected handles and not in listeners, ...

The reverted change was put in place to prevent a call to SSL_handle_events() when the handshake has not yet started, from initiating the handshake. See https://github.com/openssl/openssl/pull/25069#issuecomment-2263458635
Won't reverting it reintroduce the issue?

There probably should be a test for that case...

There probably should be a test for that case...

the change from PR (https://github.com/openssl/openssl/pull/25069/) breaks quic_radix_test which is kept in feature branch. If I understand things right the issue (https://github.com/openssl/openssl/issues/25054) has been discovered by quic interoperability tests. So we should try to get those tests running for feature branch too.
also the change was partly reverted, I believe the relevant part in ossl_quic_conn_poll_events() is still kept.

IMO the revert is wrong. Instead the quic radix test must be fixed to not depend on it.

That may well be so, but with the code as-was, the test was reaching a segfault, because ctx.qc was NULL. Since this was not the case in master, perhaps the basis for the change has changed?  In any case, it made sense for the revert to be made, and for the change to be prominently noted for review.  I expect that someone will soon determine which changes are appropriate, but for now this raises the issue.

IMO the revert is wrong. Instead the quic radix test must be fixed to not depend on it.

That may well be so, but with the code as-was, the test was reaching a segfault, because ctx.qc was NULL. Since this was not the case in master, perhaps the basis for the change has changed? In any case, it made sense for the revert to be made, and for the change to be prominently noted for review. I expect that someone will soon determine which changes are appropriate, but for now this raises the issue.

The key thing to consider are the changes in expect_quic_as (formerly quic_expect), these now also handle QUIC servers, not just clients, and servers don't have a non-nullctx.qc, rather they have a ctx.ql and need their tick setup prior to connection establishment.
So the old logic no longer applies. Perhaps it is still need in just the client case, but then the test should perhaps be:
     if (ctx.qc == NULL || ctx.qc->started)
          ...

Which handles either the non-client case, or a started client??? This version does pass tests... Should I replace the revert with this change?

Yes, that looks good, however all the changes that were added in https://github.com/openssl/openssl/pull/25069/files will probably need the same treatment.

Which handles either the non-client case, or a started client??? This version does pass tests... Should I replace the revert with this change?

Yes, that looks good, however all the changes that were added in https://github.com/openssl/openssl/pull/25069/files will probably need the same treatment.

It turns out that almost all the cases are already handled by using expect_quic_cs before ctx.qc is dereferenced, so the other cases are OK.  But there's one more not from that PR:
So the complete update is I think:
--- a/ssl/quic/quic_impl.c
+++ b/ssl/quic/quic_impl.c
@@ -1301,7 +1301,7 @@ int ossl_quic_handle_events(SSL *s)
         return 0;

     qctx_lock(&ctx);
-    if (ctx.qc->started)
+    if (ctx.qc == NULL || ctx.qc->started)
         ossl_quic_reactor_tick(ossl_quic_obj_get0_reactor(ctx.obj), 0);
     qctx_unlock(&ctx);
     return 1;
@@ -1320,7 +1320,7 @@ int ossl_quic_get_event_timeout(SSL *s, struct timeval *tv, int *is_infinite)
     QCTX ctx;
     OSSL_TIME deadline = ossl_time_infinite();

-    if (!expect_quic_any(s, &ctx))
+    if (!expect_quic_cs(s, &ctx))
         return 0;

     qctx_lock(&ctx);

@vdukhovni could you please retarget this PR against the master branch instead of the feature/quic-server branch? IMO this is unreadable.

@vdukhovni could you please retarget this PR against the master branch instead of the feature/quic-server branch? IMO this is unreadable.

I retargeted it

This pull request is ready to merge

Force pushed to the quic-server branch.


An issue with BufferCleanPayload

Hey
I have an issue with the BufferCleanPayload in that its not called when we get an error from elastic :-)
and then there is a separate issue with the message provided is ToString of a dictionary, and hence just the type name...
A have a fix that I have tested locally for these issues and works fine as far as I can see and will cut a pr for it.
Thanks for a great component :-)
Cheers
Daniel
A few questions before you begin:

Is this an issue related to the Serilog core project or one of the sinks or
community projects.
This issue list is intended for Serilog Elasticsearch Sink issues. If this issue relates to another sink or to the code project,
please log on the related repository.  Please use Gitter chat and Stack Overflow  for discussions and questons.

Does this issue relate to a new feature or an existing bug?

[ X] Bug
[ ] New Feature

What version of Serilog.Sinks.Elasticsearch is affected?  Please list the related NuGet package.
latest at least
What is the target framework and operating system? See target frameworks & net standard matrix.

[x ] netCore 2.0
[ x] netCore 1.0
[ x] 4.7
[ x] 4.6.x
[ x] 4.5.x

Please describe the current behavior?
the BufferCleanPayload action is not called when it should, and if it was the error is the dictionary type name
Please describe the expected behavior?
that the cleanup action is called and and the error message contains the actual error message from elastic
If the current behavior is a bug, please provide the steps to reproduce the issue and if possible a minimal demo of the problem
assign a action BufferCleanPayload and log something that is rejected (for example by having a conflicting type )

Thanks, merged it to dev. Do use the alpha package to test and I will merge it soon to master for a final package.


New request for configurable decimals

In fact, being able to enter the number of actions could be useful, but the possibility of managing the number of decimals would also simplify the output on the cards. Anyway thanks for the great job, this integration was missing in our Home Assistant.

Were you thinking of being able to define places_of_decimal for all numeric attributes or just the entity state?

Were you thinking of being able to define places_of_decimal for all numeric attributes or just the entity state?

Both of them

Both of them

I have addressed this in the latest release. The latest release is a breaking release needing change to component declaration.

I have addressed this in the latest release. The latest release is a breaking release needing change to component declaration.

Great, many thanks.

Great, many thanks.


The benchmark BenchmarkDeepValueSameGoRoutine in package context became 2x slower in go 1.22.
Run the following command:
go test -v -run=BenchmarkDeepValueSameGoRoutine -bench=BenchmarkDeepValueSameGoRoutine

What did you see happen?
With go 1.21.0, I get the following:
goos: linux
goarch: amd64
pkg: context
cpu: AMD Ryzen 9 3950X 16-Core Processor
BenchmarkDeepValueSameGoRoutine
BenchmarkDeepValueSameGoRoutine/depth=10
BenchmarkDeepValueSameGoRoutine/depth=10-16             35302640                33.76 ns/op
BenchmarkDeepValueSameGoRoutine/depth=20
BenchmarkDeepValueSameGoRoutine/depth=20-16             15910783                69.36 ns/op
BenchmarkDeepValueSameGoRoutine/depth=30
BenchmarkDeepValueSameGoRoutine/depth=30-16             11908124                98.36 ns/op
BenchmarkDeepValueSameGoRoutine/depth=50
BenchmarkDeepValueSameGoRoutine/depth=50-16              7204759               164.2 ns/op
BenchmarkDeepValueSameGoRoutine/depth=100
BenchmarkDeepValueSameGoRoutine/depth=100-16             3947766               298.7 ns/op
PASS
ok      context 6.532s

With go 1.22.0 I get this:
goos: linux
goarch: amd64
pkg: context
cpu: AMD Ryzen 9 3950X 16-Core Processor
BenchmarkDeepValueSameGoRoutine
BenchmarkDeepValueSameGoRoutine/depth=10
BenchmarkDeepValueSameGoRoutine/depth=10-16             19228312                62.40 ns/op
BenchmarkDeepValueSameGoRoutine/depth=20
BenchmarkDeepValueSameGoRoutine/depth=20-16             11805692               102.0 ns/op
BenchmarkDeepValueSameGoRoutine/depth=30
BenchmarkDeepValueSameGoRoutine/depth=30-16              8119362               141.5 ns/op
BenchmarkDeepValueSameGoRoutine/depth=50
BenchmarkDeepValueSameGoRoutine/depth=50-16              5516227               216.1 ns/op
BenchmarkDeepValueSameGoRoutine/depth=100
BenchmarkDeepValueSameGoRoutine/depth=100-16             2936217               412.7 ns/op
PASS
ok      context 6.924s

What did you expect to see?
No performance degradation.

Similar Issues

runtime: go 1.10beta2 Benchmarks slower on Mac (possibly related to time) #23419
runtime: performance degradation in high-load long running applications #32398
runtime: CL 501976 performance and jitter regression #65647
Benchmark results vastly different when Tests are skipped with -run=XXX #42696
testing: benchmark cleanup causes inconsistent and slower benchmark time #38314
runtime: time.Tick resolution on Linux dropped to less than 1ms starting with go 1.16?  #63145
testing:  Inconsistent benchmark data when  GOMAXPROCS=1 #31599
crypto/rsa: TLS requests are 2-3x slower in go1.20 with race detection enabled #56980
runtime: huge performance drops in a timer application #35395
runtime: performance degradation on tip on high core count machines #67858

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

I've bisected this degradation to two commits. The first is certainly related to type switches. The second one seems wild, although I have a theory how it can influence things.
The first commit is
commit 28f4ea16a240af6c5a417e20be77745329f817f1
Author: Keith Randall<EMAIL_ADDRESS>Date:   Fri Sep 1 20:32:07 2023 -0700

    cmd/compile: improve interface type switches

    For type switches where the targets are interface types,
    call into the runtime once instead of doing a sequence
    of assert* calls.

    name                                 old time/op  new time/op  delta
    SwitchInterfaceTypePredictable-24    26.6ns ± 1%  25.8ns ± 2%  -2.86%  (p=0.000 n=10+10)
    SwitchInterfaceTypeUnpredictable-24  39.3ns ± 1%  37.5ns ± 2%  -4.57%  (p=0.000 n=10+10)

    Not super helpful by itself, but this code organization allows
    followon CLs that add caching to the lookups.

    Change-Id: I7967f85a99171faa6c2550690e311bea8b54b01c
    Reviewed-on: https://go-review.googlesource.com/c/go/+/526657
    Reviewed-by: Matthew Dempsky<EMAIL_ADDRESS>    LUCI-TryBot-Result: Go LUCI<EMAIL_ADDRESS>    Reviewed-by: Cuong Manh Le<EMAIL_ADDRESS>    Reviewed-by: Keith Randall<EMAIL_ADDRESS>
 src/cmd/compile/internal/ir/node.go                |  23 +-
 src/cmd/compile/internal/ir/node_gen.go            |  46 +++
 src/cmd/compile/internal/ir/op_string.go           |  21 +-
 src/cmd/compile/internal/ir/stmt.go                |  37 ++
 src/cmd/compile/internal/ir/symtab.go              |   1 +
 src/cmd/compile/internal/ssagen/ssa.go             |  10 +
 src/cmd/compile/internal/test/switch_test.go       | 117 ++++++
 .../compile/internal/typecheck/_builtin/runtime.go |   3 +
 src/cmd/compile/internal/typecheck/builtin.go      | 398 +++++++++++----------
 src/cmd/compile/internal/walk/stmt.go              |   1 +
 src/cmd/compile/internal/walk/switch.go            | 390 +++++++++++++-------
 src/internal/abi/switch.go                         |  13 +
 src/runtime/iface.go                               |  16 +
 test/codegen/switch.go                             |  21 ++
 14 files changed, 742 insertions(+), 355 deletions(-)
 create mode 100644 src/internal/abi/switch.go

The benchmark results at commit 28f4ea1:
goos: linux
goarch: amd64
pkg: context
cpu: AMD Ryzen 9 3950X 16-Core Processor
BenchmarkDeepValueSameGoRoutine
BenchmarkDeepValueSameGoRoutine/depth=10
BenchmarkDeepValueSameGoRoutine/depth=10-16             17287828                66.11 ns/op
BenchmarkDeepValueSameGoRoutine/depth=20
BenchmarkDeepValueSameGoRoutine/depth=20-16             10979985               115.8 ns/op
BenchmarkDeepValueSameGoRoutine/depth=30
BenchmarkDeepValueSameGoRoutine/depth=30-16              7719157               178.2 ns/op
BenchmarkDeepValueSameGoRoutine/depth=50
BenchmarkDeepValueSameGoRoutine/depth=50-16              4705028               249.5 ns/op
BenchmarkDeepValueSameGoRoutine/depth=100
BenchmarkDeepValueSameGoRoutine/depth=100-16             2414732               498.4 ns/op
PASS
ok      context 7.277s

The benchmark results at commit 10da3b6 which immediatly precedes 28f4ea1:
goos: linux
goarch: amd64
pkg: context
cpu: AMD Ryzen 9 3950X 16-Core Processor
BenchmarkDeepValueSameGoRoutine
BenchmarkDeepValueSameGoRoutine/depth=10
BenchmarkDeepValueSameGoRoutine/depth=10-16             26770080                40.36 ns/op
BenchmarkDeepValueSameGoRoutine/depth=20
BenchmarkDeepValueSameGoRoutine/depth=20-16             13413070                88.30 ns/op
BenchmarkDeepValueSameGoRoutine/depth=30
BenchmarkDeepValueSameGoRoutine/depth=30-16             10121890               131.7 ns/op
BenchmarkDeepValueSameGoRoutine/depth=50
BenchmarkDeepValueSameGoRoutine/depth=50-16              6123589               216.5 ns/op
BenchmarkDeepValueSameGoRoutine/depth=100
BenchmarkDeepValueSameGoRoutine/depth=100-16             3088478               415.7 ns/op
PASS
ok      context 7.071s

The second commit surprised me, but it also degrades the benchmark noticeably:
commit fa4f951026f697bc042422d95a0806dcbab7ddd0
Author: Jes Cok<EMAIL_ADDRESS>Date:   Fri Sep 29 06:06:40 2023 +0000

    syscall: make origRlimitNofile atomic.Pointer[Rlimit]

    Currently we are bootstrapping with Go 1.20, origRlimitNofile can
    be changed to atomic.Pointer[Rlimit].

    Change-Id: I00ce9d1a9030bd5dbd34e3dc6c4e38683a87be86
    GitHub-Last-Rev: f2ccdb38412019d10661ed6be42086b445e411bf
    GitHub-Pull-Request: golang/go#63274
    Reviewed-on: https://go-review.googlesource.com/c/go/+/531516
    LUCI-TryBot-Result: Go LUCI<EMAIL_ADDRESS>    Reviewed-by: qiulaidongfeng<EMAIL_ADDRESS>    Auto-Submit: Ian Lance Taylor<EMAIL_ADDRESS>    Reviewed-by: Ian Lance Taylor<EMAIL_ADDRESS>    Reviewed-by: Than McIntosh<EMAIL_ADDRESS>
 src/syscall/exec_bsd.go           |  6 +++---
 src/syscall/exec_freebsd.go       |  6 +++---
 src/syscall/exec_libc.go          |  6 +++---
 src/syscall/exec_libc2.go         |  6 +++---
 src/syscall/exec_linux.go         |  6 +++---
 src/syscall/exec_unix.go          |  6 +++---
 src/syscall/export_rlimit_test.go |  4 ++--
 src/syscall/rlimit.go             | 12 +++++-------
 src/syscall/syscall_linux.go      |  2 +-
 9 files changed, 26 insertions(+), 28 deletions(-)

I get the following results when benchmarking fa4f951:
goos: linux
goarch: amd64
pkg: context
cpu: AMD Ryzen 9 3950X 16-Core Processor
BenchmarkDeepValueSameGoRoutine
BenchmarkDeepValueSameGoRoutine/depth=10
BenchmarkDeepValueSameGoRoutine/depth=10-16             29495116                40.77 ns/op
BenchmarkDeepValueSameGoRoutine/depth=20
BenchmarkDeepValueSameGoRoutine/depth=20-16             12556218                92.13 ns/op
BenchmarkDeepValueSameGoRoutine/depth=30
BenchmarkDeepValueSameGoRoutine/depth=30-16              8599995               132.6 ns/op
BenchmarkDeepValueSameGoRoutine/depth=50
BenchmarkDeepValueSameGoRoutine/depth=50-16              6290308               206.4 ns/op
BenchmarkDeepValueSameGoRoutine/depth=100
BenchmarkDeepValueSameGoRoutine/depth=100-16             3201490               387.7 ns/op
PASS
ok      context 6.906s

And these are the results of 9bfaaa1:
goos: linux
goarch: amd64
pkg: context
cpu: AMD Ryzen 9 3950X 16-Core Processor
BenchmarkDeepValueSameGoRoutine
BenchmarkDeepValueSameGoRoutine/depth=10
BenchmarkDeepValueSameGoRoutine/depth=10-16             32503959                34.20 ns/op
BenchmarkDeepValueSameGoRoutine/depth=20
BenchmarkDeepValueSameGoRoutine/depth=20-16             17294968                81.50 ns/op
BenchmarkDeepValueSameGoRoutine/depth=30
BenchmarkDeepValueSameGoRoutine/depth=30-16             12121272               100.1 ns/op
BenchmarkDeepValueSameGoRoutine/depth=50
BenchmarkDeepValueSameGoRoutine/depth=50-16              7719627               158.2 ns/op
BenchmarkDeepValueSameGoRoutine/depth=100
BenchmarkDeepValueSameGoRoutine/depth=100-16             3951139               297.7 ns/op
PASS
ok      context 6.818s

Go 1.23 (commit 44f1870) performs in this benchmark the same way as go 1.22.0.

% go1.22-9bfaaa15fd version
go version devel go1.22-9bfaaa15fd Fri Sep 29 14:58:44 2023 +0000 darwin/arm64
%
% go1.22-fa4f951026 version
go version devel go1.22-fa4f951026 Fri Sep 29 18:51:35 2023 +0000 darwin/arm64
%

% go1.22-9bfaaa15fd test -v -run=BenchmarkDeepValueSameGoRoutine -bench=BenchmarkDeepValueSameGoRoutine -count 10 > 9bfaaa15fd.out
% go1.22-fa4f951026 test -v -run=BenchmarkDeepValueSameGoRoutine -bench=BenchmarkDeepValueSameGoRoutine -count 10 > fa4f951026.out

% ~/go/bin/benchstat 9bfaaa15fd.out fa4f951026.out
goos: darwin
goarch: arm64
pkg: context
                                   │ 9bfaaa15fd.out │           fa4f951026.out           │
                                   │     sec/op     │   sec/op     vs base               │
DeepValueSameGoRoutine/depth=10-8       27.84n ± 1%   27.61n ± 1%       ~ (p=0.171 n=10)
DeepValueSameGoRoutine/depth=20-8       66.41n ± 2%   67.03n ± 1%       ~ (p=0.494 n=10)
DeepValueSameGoRoutine/depth=30-8       94.55n ± 1%   93.91n ± 2%       ~ (p=0.305 n=10)
DeepValueSameGoRoutine/depth=50-8       152.2n ± 0%   150.0n ± 2%  -1.48% (p=0.033 n=10)
DeepValueSameGoRoutine/depth=100-8      293.7n ± 0%   289.0n ± 2%  -1.58% (p=0.000 n=10)
geomean

I tried versions 9bfaaa15fd and fa4f951026 and found that there was no performance degradation, but it got better. I don't know if there is any problem with my operation.

@callthingsoff I do not think there is a problem with your operation. You've tested with a different CPU. It suggests that this benchmark got unlucky with icache aliasing after some code was moved around. I would not bother too much with fa4f951.

I'm pretty sure this is because we're now compiling the type switch in context.value using a jump table instead of a linear search.
Which makes me thing the binary search should have indicated CL 521497, not CL 526657. Maybe the latter happened to allow the binary search in some way it wasn't available before. My guess is it handles the multiple entries in a single case statement better.
In any case, the reason it is slower is the benchmark is basically optimal for linear search, as the case selected is always the first one. Using a jump table requires more overhead but should do better when other cases are the common one.
Just to verify I changed the code of context.value to put the *valueCtx case last instead of first, and tip is now a bit faster than 1.21.
So, not entirely clear what should be done here. Perhaps if value contexts are really the common case, we can promote that case out of the switch into its own if statement.
We could also raise the threshold for using jump tables.
Or we could chalk this up to unfortunate and do nothing.

Well, value contexts are really common. I found this benchmark while figuring it out why open telemetry added so much overhead in a project of mine. It is a very typical pattern to have a chain of contexts like "context with parent span info", "context with my current span", "context with one more stats collector", "context with logger fields", etc. Opentelemetry does that a lot, as well as sentry, azure sdk, golang.org/x/net, etc. Fetching any value from a context that requires going up this chain spends a noticeable amount of time in context.value.

Different coding patterns are going to have different frequencies for context types.  It's not clear to me that valueCtx is the most common type in general, though it certainly is in BenchmarkDeepValueSameGoRoutine.  Different programs are going to have stacks of cancelCtx and/or timerCtx.
That said, @randall77 how did you pick the value 5 for minCases in tryJumpTable?  My intuition, without doing any actual testing, is that that seems low, because direct comparisons against 5 constant values is going to be pretty quick.  But maybe I don't really understand how gc implements type switches.  In this particular example the type switch has 6 cases (and a default case).

It was basically chosen using cmd/compile/internal/test/switch_test.go:BenchmarkSwitchType*. It looked better certainly at 8, both for the predictable and (even more for) unpredictable cases. It was less clear at smaller sizes, but 5 seemed the right threshold because that's the point at which you start having 3 compare/branch to reach some leaves of the binary search (which you need for every case when n=8).
It's certainly possible that a different threshold is warranted. I did not do intensive testing. The only challenge is that it depends on predictability, which we don't know at compile time. So we have to posit some "average" predictability and target that.

and perhaps we put a PGO-informed TODO on the switch code?  If the profile is true, that might be really helpful.

@dr2chase Indeed. We'll need basic block profiles #65466 though.


fix xtask validate error by replacing map with inspect based on clippy

Pull Request Template
Checklist

[ ] Confirmed that run-checks all script has been executed.
[ ] Made sure the book is up to date with changes in this PR.

Related Issues/PRs
Provide links to relevant issues and dependent PRs.
Changes
Summarize the problem being addressed and your solution.
Testing
Describe how these changes have been tested.

テスト用だったので、クローズ


Vhdpmm new release

@JuliaRegistrator register

Comments on pull requests will not trigger Registrator, as it is disabled. Please try commenting on a commit or issue.


Improve inputs

Currently, several input widgets uses a HoverButton as backend. Currently, it only supports one button state at the time, but it should support multiple. For example, when pressing and hovering, it should provide both to the builder callback.

I think we should remove the HoverButton widget, and implement the mouse, gesture detector and focus directly on each input. This would add more boilerplate code, but would give us more control over these things in each widget. This is the approach used on material and cupertino libraries.


chore: update alloy-core, alloy-openapi from 0.2.2 to 0.2.3

About this PR
📦 Updates

com.disneystreaming.alloy:alloy-core
com.disneystreaming.alloy:alloy-openapi

from 0.2.2 to 0.2.3
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.disneystreaming.alloy" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.disneystreaming.alloy" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, commit-count:1

Superseded by #176.


Add support for multiple cluster provisioning

What this PR does / why we need it:

Modify create_packet_cluster.yml and add task for wait till ssh
and provide master and workers config.

Modify vars.yml for store master and workers config

Signed-off-by: Chandan Kumar<EMAIL_ADDRESS>

https://github.com/openebs/litmus/pull/163


🎉 scalafmt !

weehooo

To ease review, it'd be better to separate the auto-formatting into one commit.

Thx!


Use CSV Parser to Insure Proper Parsing

I was getting garbled results for various locations - using a proper csv parser fixed this issue (the original python local-reverse-geocoder uses a csv parser)

Thank you very much! Will review and merge over the weekend.

Thanks again, @solumos, for the Pull Request; the new release just went out as v0.3.0.

Great, glad to help!


Community

Hey!
I see that you are a cool specialist in Jmeter and thank you very much for your contribution to the development of the community and the toolkit around it.
The thoughts of many JMeter users now have a similar trend. The trend is to write tests as code. But there are no good solutions to do this quickly and conveniently. What many are faced with is the paucity of functionality and the dampness of the solution.
What do I want to offer? I want to enlist the support of more like-minded people and focus them on one thing. Now it seems like you need to choose something the most popular. I studied the current solutions for a very long time and I think that I chose the most suitable one, this is https://github.com/abstracta/jmeter-java-dsl
We are going to contribute there and look for more people who are interested in this.
I think that together we will be able to make a really cool and useful DSL tool, which will be officially included in JMeter's delivery. At the moment, I also keep in touch with the JMeter developer, who can be seen in one of the issue https://github.com/abstracta/jmeter-java-dsl/issues/30
I apologize in advance for disturbing you if this is not interesting to you.
If it's interesting, please let me know. 👍
Regards

Hello,
Thanks to be interested to my project. And yes Jmeter should have a programmatic approach as it's more needed.
I think also to have a good DSL/code projects it's should start from Jmeter core as there many limitation and risk related to upgrade solution with future Jmeter release.
In my point of view jmeter-as-code and  jmeter-java-dsl has different approaches :
Jmeter-java-dsl  VS   jmeter-as-code (JMC)

Easy to write as using parameter on constructors <-> more complex as using builder and it's preferred to use classes for each sampler..
I think add new wrapper in JMC is
Limiting Jmeter feature as  only the most important parameters are presents, in JMC all parameters are presents.
Based on Jmeter classes to generate JMX file and to get final Jmeter Objects, in JMC conversion from JMC object to JMX is done without usng Jmeter, a custom Xml converter is used to have the same XML at the end.
JMC can use JMX fragment if for same raison wrapper is not yet present :  https://jmc.anasoid.org/docs/users/include.
JMC can replace using JSR223 by Java it's more easy for debugging: https://jmc.anasoid.org/docs/users/plugins/JSR223toJava .
JMC has an interceptor to change test before generating JMX file. (https://jmc.anasoid.org/docs/users/Interceptor)

cc : @vlsi @rabelenda

Looks really interesting. In java-dsl, to execute any java code, you can pass its source class inside Jmeter. This allows it to be consumed from groovy, which is the most performant solution.
I think I understand your position. Each DSL has pros and cons. My message was to pick the most popular one and develop it. After all, these features can be implemented not only in JMC :)

Hello @anasoid, thank you to bringing this to my attention, and thank you @kirillyu to try help unify efforts in the community.
I really think it would be great to unify efforts, and try to build the best tool for the community.
I have seen that since jmeter-java-dsl (I will refer to it as just "the DSL" in some cases) was released, some related projects have been published as the jmeter-as-code(I will refer to it as jmc in some case) and groovy-jmeter. Maybe they were previously internal and decided to go public, or where inspired by the DSL, or we are in the middle of some inflection point where many people come to same idea or problem.
The jmeter-java-dsl is not the first try to this approach, as is the case for ruby-jmeter listed here, but I do think that it is clearer since jmeter-java-dsl first release that the Java community needed something like this, and it would be great to unify efforts as much as possible.
In general, I think is nice to have alternatives, that explore different ways of tackling a problem. I also think is nice to let alternatives to take form, to review in the process each pros and cons, being each of them potentially targeted or preferred by a "niche" of the users. But if alternatives don't have a clear differentiator, I think is better to join forces, and avoid confusing the community unnecessarily to chose between similar options.
I don't like in general doing comparisons, even though one is done on the DSL in motivation section to clarify things, since they are always subject to how each person assign weights to each item and tools evolve constantly. Additionally, I don't have very objective point of view and would probably need to do more research about jmeter-as-code to provide a more informed opinion.
About the points you mention, from what I initially see, I can say this:

True, but I don't know if creating classes is preferable to creating methods to abstract a common logic in jmc (or in general). Everything depends on the scope of usage of the abstraction you want to use.
I think that you might have missed something in this point, because it currently looks incomplete.
Is true. The Idea of the DSL is to incrementally add coverage for most users needs, keeping out in some cases, and after thorough analysis, some very specific needs that may be usable only by specific domains or use cases, with proper justification. We always try in the DSL to encourage and advise good practices to users, by designing API in certain way or with associated documentation. We also try to provide good abstractions (reducing complexity or having to worry about some JMeter or problem details in some scenarios) and include additional features when necessary. When the DSL does not provide a solution, we strive for it to provide simple ways to create additional either private (internal to a company or team) or public modules that can complement the DSL. Ej: someone might implement RteJmeterDsl to provide methods for RTE protocol in potentially separate project/repository or module, or in the same code as the test plan is used, and can be easily used in conjunction with core module. We also encourage the community to take part of the tool, and try to get as much opinions and hands to support it and make it something useful for most people (not saying that jmc doesn't, but providing everything upfront may hinder this).
This looks like an internal implementation detail, which doesn't directly affect users, but might be of interest to potential contributors. Do you see any particular benefit on it? What drove you to make this decision? The drivers behind such decision sounds like a really interesting matter.
True. The main focus of the DSL is focusing on java programming, and avoid users having to worry about JMX, Jmeter internals, and the like. We may eventually implement something like this in the DSL, but so far now one has asked for it, and taking into consideration java programming power for abstractions, I currently don't see a clear scenario where to use it.
DSL also provides similar functionality with jsr223 sampler, pre & post processors using java lambdas, which in fact are just implementation of an interface which you can create a class for (in similar fashion as the one proposed by jmc). The DSL approach might not be a good fit (as is) for running tests in distributed fashion or remotely (eg: BlazeMeter), but that can be easily solved with some minor improvements (none has asked for it yet, so doesn't seem like something important right now).
in DSL we don't internally generate a JMX, so there is no need for such alterations. If you want to make an alteration of a element you just do it while you create it, or if you want to reuse some logic and alter it, you create a method or class which builds the base object and then another class/method that alters it. Interceptors and templates look like things that can be done by other means potentially more simple (as the ones I previously mentioned).

Some additional points that I see:

jmc documentation is currently (from my humble and debatable opinion) a little confusing, and the model might not be as simple for beginners. For example, it introduces new concepts like templates, interceptors & wrappers (I get it, the DSL has a similar internal concept, but is not something we particularly focus users attention on) that are not familiar for JMeter users nor for any other performance tester.
Here I think the main difference is the focus: jmc focuses on how to extend it, add custom logic and provides builders for most of jmeter features out of the box, while DSL focuses on giving simple short DSL to users encouraging good practices and avoiding common pitfalls, only implementing what seems to be necessary/required, moreover considering the change of paradigm between using JMeter in GUI mode vs using it from a programming language/IDE. As previously mentioned, in the DSL, abstraction and reusability are considered to be backed by general programming modularizing practices, and customization/extensibility can be achieved by some specific ways described in contributing guide or in some sections of user guide. We are also considering some customization features for near future release like this one, but that should target really specific needs. The idea behind the DSL is that in general users should do good enough with the DSL, and if something is missing, is better to report it/ask it and add it to the DSL. This way we keep the DSL simple for users, we give proper thought/analysis to each feature, while we also prioritize efforts on what is needed.
jmc syntax is in some cases more similar to JMeter, which might be more appealing in some cases to JMeter users. In the DSL we strive to give a proper balance to JMeter users and non JMeter users, taking the liberty in some particular cases to rename elements (like throughput controller, which in jmeter doc states the name might be confusing) to make it easier to new comers & to JMeter users as well.
jmc syntax is in general more verbose, as far as I have seen (and I guess is your main point in your first point), and in consequence you might end with things that are "harder" (totally subjective matter) to read. This point is also debatable, but in general the more code, the more to read, which means more time in maintenance and typing. This obviously has to balance with meaningful syntax that avoids confusions.
jmeter-java-dsl provides some built in abstractions and tools which currently jmeter-as-code and using native JMeter API do not provide. Eg: live dashboard, built in statistics results which can easily be used with usual assertions libraries, built in distribute and remote testing, etc.
jmc requires a JMeter home (which requires installation of jmeter, and previous setup). The DSL does not require any previous setup. This I think is also part of the focus: simplifying users work, instead of focusing on coverage, or being as "JMeter" centric in some way.
since most of jmc is auto generated, it would be easier to maintain. But the amount of generated code and potentially unused features might confuse users or require unnecessary maintenance (when features are duplicate). This is also another totally subjective point. In the DSL, we first balance pros/cons of each feature, requirements/needs, alternatives, and the provide custom and "optimal" (also totally subjective matter) user experience, including guidance both in javadocs and user guide. I think many of previously mentioned points are product from this decision and focus.

I would like to avoid a debate, and I totally recognize that many of the points that I previously mentioned might ignite some, but would like to see ways of collaborating and/or complement each other. I know this could be hard, due to different point of views, prioritization and past experiences. But in the end would be the best for the community.
I totally value the approach jmc has taken. I think is a matter of priorities/focus as I mentioned, and different people might prefer one approach over the other. For instance I think that jmc is currently a good way to get your JMeter code to java code as similar as possible to the test plan, and using existing jmeter installations. Users with immediate and very specific needs might prefer it. DSL should currently cover a big part of the needs, and as it progresses it is expected to cover more and more, providing a simpler syntax, so I think that users would prefer it thinking in the long term.
One option for users might be: checking the DSL, if something is not there ask for it, and in the mean time (if jmc is good enough), or ir the feature is decided to not be implemented (which should be rare), use jmc and eventually (if needed) move to the DSL.
How can we collaborate? Can you @anasoid propose changes to the DSL to improve it and simplify some of the scenarios you are trying to cover with jmc?  What ideas do you have that can help us better collaborate?
I see you have a DSL section, I think if jmc goes that way it will collide a lot with the DSL, maybe makes sense to keep it focused on giving simple migration to Jmeter users with a more direct API and unify efforts in jmeter-java-dsl to build a dsl that is targeted to users that prefer less code with potentially/momentarily less coverage, and requiring users more involvement with the project in jmeter-java-dsl than in jmc (asking them to submit issues, propose ideas, explain their needs, etc, before implementing a thoughtful DSL/API design)?
I see you also involved @vlsi, which I am not sure if has a defined position in this matter, but I know is talking in jmeter forums about implementing a DSL in jmeter itself. I am not clear if they have evaluated pros and cons of having it separate from JMeter yet, or if they plan to ask for jmeter-java-dsl to be moved to jmeter as initial draft or what :-). But in any case, I think unifying efforts would be awesome, and we can implement a solution that is generic enough regardless if users use groovy, java, kotlin, etc.
Do you have ideas or comments in this regard @vlsi?
Maybe is too soon to define what is the definitive mechanism, and maybe in the end there is room for having separate tools which complement each other.
I hope we can come up with new and great ideas, and get the best tool, not only for the community, but also for you and me (I work for Abstracta, who does extensive performance testing, so a having the best tool is of specially importance for us).
Regards, and thank you again for considering me and make me part of this discussion.

@rabelenda , @anasoid , @kirillyu it might work better if we organize a meetup to discuss things. I agree it would be great to build up a community rather than having N slightly different libraries.
Just in case, here are timeframes that work for me the best: https://doodle.com/mm/vladimirsitnikov/30min-meeting

I see you also involved @vlsi, which I am not sure if has a defined position in this matter

Here's my position:

Having something in-JMeter makes sense
Java and Groovy are great languages, however, I think they do not work great for JMeter DSL. Java is too strict, and Groovy is too flexible
I am determined to contribute Kotlin-based DSL to JMeter itself. It might be a little bit easier for me as I am a committer and a member of JMeter PMC.
It would be great to have more JMeter contributors, so if adding DSL to JMeter is appealing to you, it might be a nice opportunity to join forces
I appreciate both jmeter-as-code and jmeter-java-dsl, however, I think trying to squeeze DSL into Java is a dead-end. It works to a degree, however, it does not scale :-/
Frankly speaking, I'm puzzled. I see you both invested a lot in Java-based DSLs, however, I do not think either of the solutions is mergeable to JMeter itself. On the good side, you might know a lot of JMeter pitfalls related to DSL, so you might be able to catch design flaws early :)

In case you wonder, here's an example of how customization of Kotlin-based DSL could look like: https://github.com/Kotlin/kotlinx.html/wiki/Micro-templating-and-DSL-customizing
a) Common code can be extracted in a DSL-like helper method (search for LI.dropdownToggle)
fun LI.dropdownToggle(block : A.() -> Unit) {
    a("#", null, "dropdown-toggle") {
        attributes["data-toggle"] = "dropdown"
        role = "button"
        attributes["aria-expanded"] = "false"

        block()

        span {
            classes = setOf("caret")
        }
    }
}

a) Introducing a custom tag takes just a few lines of code:
// First of all, we have to define a tag type
class CUSTOM(consumer: TagConsumer<*>) :
        HTMLTag("custom", consumer, emptyMap(),
                inlineTag = true,
                emptyTag = false), HtmlInlineTag {
}

// We know that it is applicable to <div> only so let's declare it
fun DIV.custom(block: CUSTOM.() -> Unit = {}) {
    CUSTOM(consumer).visit(block)
}

That is it. It allows extending the DSL from external methods (e.g. from custom plugins).

As of now, I am playing with trivial DSL definitions, and the current unsolved question for me is "how to represent half-built nodes".
One of the solutions is to use TestElement from JMeter. It allows to instantiate elements like DebugSampler directly and populate its properties. On the downside, it would not allow "different output formats".
Another solution would be having some sort of dsl-only elements, and a set of converters (e.g. into JMeter elements or into something else).

/cc @smicyk from https://github.com/smicyk/groovy-jmeter, WDYT?

I've filed a draft PR: https://github.com/apache/jmeter/pull/678.

I think we are all agree to grouping effort to have a better tools.
Before i should explain my motivation for JMC vs GUI (Only the important points):

Working as teams it`is impossible or too difficult with Jmeter as in git you can't do a  merge of XML files.
Working on many projects in the same context (ecommerce) it was very difficult to reuse old test even they are very similar.

@vlsi JMC is not a DSL it's more a wrapper approach based on Lombok , and yes it's unfortunately  unmergeable in Jmeter core, and I think both JMC and jmeter-java-dsl are sensible to major evolution in Jmeter.
I think to have a long term solution we should start from Jmeter-core, and search to best approach to isolate GUI from core without breaking all existing plugins.
And for DSL or Wrapper approach i think that Wrapper should be on the bottom level and DSL use it to generate Jmeter object.
@vlsi  I have book a 30 min meeting tomorrow, I m flexible if you want to change it or @rabelenda @kirillyu want to be present and are available on different time.

a 30 min meeting tomorrow

Great. That is 24 Nov, 11:30 UTC

Working as teams it`is impossible or too difficult with Jmeter as in git you can't do a merge of XML files.
Working on many projects in the same context (ecommerce) it was very difficult to reuse old test even they are very similar.

I agree the current JMeter UI is not copy-paste friendly. It feels rigid when it comes to shuffling and copying the nodes.
Just in case, tools like JetBrains MPS make it possible to have both GUI and Git merge. See https://www.youtube.com/watch?v=xXEK_aY8wMM&t=56s :)

I think my presence will not bring much benefit. My spoken English is bad and in general I am ready to make any decision in this direction. :)

Hi all,
thanks for the invitation to the discussion. My thoughts about the idea:

In general, the approach in jmeter-groovy-dsl looks more like @vlsi shows in https://github.com/apache/jmeter/pull/678. As a matter of fact, building custom DSL in Groovy/Kotlin is kind of a thing in those languages and one of their strengths.
I don't know which approach might be the best as this is really a matter of taste for everyone (some people like one thing over another without any particular reason) but I think that separation of JMeter own code GUI vs. Engine and have kind of wrapper/builders to the engine part would help to create different DSL. Then it does not matter if you use Groovy/Kotlin/Ruby to create your own DSL for it. For example, in Groovy DSL you do not need the JMeter installation folder, all dependencies are downloaded as jars and any required *.properties files are "generated" for you, but it requires different hacks in the code, same goes for plugins or functions. So the engine builder with a clean API would be nice to have and might simplify building test and run it on different platforms and configurations.
I think my motivation at the beginning was a little bit different than Java counterparts. It was more to write scripts in the command line and execute quickly, rather to have them in JUnit as a part of application tests. This later changed as those tests were easy to include but again some hacks were necessary.
For Groovy/Kotlin DSL approach the proper names for keywords and properties (specification) is necessary e.g. testPlan,testGroup vs plan,group. In Groovy DSL I tried to make keywords as concise and short as possible but sometimes it was not really possible.

To sum up I believe that both approaches might be ok and they could be applicable on different layers. The Java part would hide the burden of building test nodes into the final test and execute them. The Groovy/Kotlin would be to define DSL and use Java to build test elements in an easy and concise way.

Hello,
Thank you for taking time to check on this and give your point of view.
Also for arranging the meeting. I had same idea, but mainly to know each other, that would be super nice. Regarding discussion about design decisions and potential direction I think is better to leave them written for reference, and for everyone be able to speak they part in and ordered fashion with proper analysis if needed.
Regarding the sample you provide @vlsi about HTML tags, for simple scenarios jmeter-java-dsl can be extended mostly the same way. You can even do it in a method in some cases without having to extend a class (lambdas), or implementing an interface, or extending a class, depending on the level of complexity you need. I think that languages like kotlin ease maintenance and simplify some tasks, but in the end what makes an API usable/enjoyable/popular is how well it fits the community that uses it and how well designed the API is for extensibility to avoid impacting user experiences with non backwards compatible changes.
Why do you say that Java would be a dead end, and does not "scale"? Can you be more specific about what you mean by "scale" and why you think is a dead end?
We all know there is a huge ecosystem of java libraries, apis, and dsl, many of which have flourished and evolved in a healthy ways. I think the main point here is API design decisions, and not a language by itself (which may help in some aspects, but does not necessarily drive the API design).
The key point should be, from my point of view, on implementing the API in an extensible and maintainable way, which again, there are innumerable examples in java ecosystem.
Additionally, if you build a nice java API, it should be easily usable and even enjoyable in other jvm languages like kotlin and groovy which already supports calling java code. We discussed about this on the jmeter-java-dsl issue you created, but seems your are determined on using Kotlin, and not consider providing sub optimal experience for java users (which I believe, from general polls and metrics about programming languages usage, is currently a lot bigger than kotlin one).
For instance, if you have a kotlin DSL like this:
@TestElementMarker
interface DslTestElement

@DslMarker
annotation class TestElementMarker

abstract class TestElementContainer : DslTestElement {

    private val children = mutableListOf<DslTestElement>()

    fun <C : DslTestElement> add(child: C, init: C.() -> Unit = {}): C {
        children.add(child)
        child.init()
        return child
    }

}

fun testPlan(init: DslTestPlan.() -> Unit): DslTestPlan {
    val testPlan = DslTestPlan()
    testPlan.init()
    return testPlan
}

class DslTestPlan : TestElementContainer() {

    fun run() {}

}

fun DslTestPlan.threadGroup(
        threads: Int,
        iterations: Int,
        init: DslThreadGroup.() -> Unit
): DslThreadGroup {
    return add(DslThreadGroup(threads, iterations), init)
}

class DslThreadGroup(threads: Int, iteration: Int) : TestElementContainer()

fun DslThreadGroup.httpSampler(url: String, init: DslHttpSampler.() -> Unit = {}): DslHttpSampler {
    return add(DslHttpSampler(url), init)
}

class DslHttpSampler(url: String) : TestElementContainer()

Which allows you to use it in kotlin like this:
import kotlindsl.*

testPlan {
    threadGroup(1, 1) {
        httpSampler("http://my.service")
    }
}.run()

In java actually requires this:
import static kotlindsl.JmeterDslKt.*;

testPlan(p -> { // requires this lambda declaration
  threadGroup(p, 1, 1, t -> { // requires the passing of parameter p
    httpSampler(t, "https://myurl", s -> null);
    return null; // requires returning something
  });
  return null;
});

In contrast with jmeter-java-dsl:
import static javadsl.JmeterDsl.*;

testPlan(
  threadGroup(1, 1
    httpSampler("https://myurl")
  )
).run();

Which is shorter, and doesn't require unnecessary ceremony which is not intuitive for java devs either, and even checking kotlin api from java code is not as easy to read for non Kotlin devs. Java devs might even not comfortable debugging some java code that then invokes kotlin and then potentially groovy.
These are the kind of things that I mention should be taken into consideration, some of which I have experienced in the past while trying to use kotlin based APIs from java code, making their usage more painful than java alternatives.
I believe having a solid core java api, and implementing on top of it thin layers (which may be autogenerated) that polish the experience to kotlin, groovy and other languages, looks to me to be a preferred path. Even though you would need to maintain java code instead of kotlin (which would be shorter), but this point may even be a pro or a con, depending to the target audience of maintainers your are considering.
Again, I really like Kotlin, and haven't settled yet with the approach to take about it in jmeter-java-dsl yet, but I think we should take all these points in consideration.
Regarding your puzzlement: I don't understand it, furthermore considering that you are determined to build a third option. Why do you say that are not mergeable? The second option you describe as dsl-only elements sounds like building something like jmeter-java-dsl but just in Kotlin. I understand you prefer kotlin, and have strong opinion on it's benefits, and you are determined to start something from the ground up with it, but I think we could do better by fostering a healthy Jmeter ecosystem of third party tools, and try helping existing solutions to improve, instead of reimplementing them.
I see you value our insights, and are making good efforts for us to be on the same page, but reimplementing something that the community is starting to evaluate and use, I think is not healthy for the general community and in good spirit with OSS culture. It would be awesome for JMeter to provide it, but maybe since we already have some alternatives makes sense to invest on them? and having them separate allows to polish the experience of devs without tying to much the implementation to JMeter internals?
Another option, that we may consider is just implementing another alternative, and let it mature, to see pros and cons, and see if each has its own niche, as I previously mentioned about jmeter-as-code and groovy-jmeter, but I tend to think that solutions would conflict more than collaborate.
Would be awesome to have an ecosystem of high collaboration, as I think it happens with jmeter plugins devs and jmeter contributors (I have seen several time plugin teams contributing to core Jmeter).
As a side matter, which is not directly related to this topic: you have sent some PR to JMeter including kotlin. Have you considered the additional complexity (for users and maintainers) and JMeter size that implies adding a new language and its libs? Each language requires some learning curve, and the more you add, even though you add flexibility, you also add complexity. Instead of using 1 language, you might end up using 3 in a test plan, which I don't think is preferable. Is there a plan in the long term to move to kotlin?
Thank you very much for reading this, and try understand other points of view. I hope we can come up with the best for the community and for the interests of everyone that has been involved in this discussion.
PS: I will join the zoom meeting and am eager to meet you guys and get to know you a little more 🙂

I think is not healthy for the general community and in good spirit with OSS culture. It would be awesome for JMeter to provide it, but maybe since we already have some alternatives makes sense to invest on them? and having them separate allows to polish the experience of devs without tying to much the implementation to JMeter internals?

That nails my puzzlement exactly.
Adding DSL to JMeter core is great as new core features and updates would get immediate support in DSL.
That is vital for the adoption of the DSL approach in my opinion.
However, creating DSLs in Java is complicated, and I would rather prefer refactoring JMeter core APIs rather than adding yet another Java-based DSL. The current JMeter API looks more like a poorman's DSL. I do not think adding "pretty Java DSL" is something users really needed.
Of course, the border between "TestElement API" and "DSL for test plan generation" is not easy to define, and one might say that jmeter-as-code or jmeter-java-dsl is the better JMeter API. However, it looks like that neither of the projects allow to implement new samplers, post processors, controllers, and so on. So jac and jjd do not look like a replacement of TestElement API 🤷

rabelenda: Why do you say that Java would be a dead end, and does not "scale"? Can you be more specific about what you mean by "scale" and why you think is a dead end?

import static javadsl.JmeterDsl.*;

testPlan(
  threadGroup(1, 1
    httpSampler("https://myurl")
  )
).run();

Even though this DSL looks good, I think it speaks to the wrong users.
You have a very limited set of syntax features (thanks to Java 8? 😆 ). For instance, what does 1, 1 mean?
Can you add 10 httpSamplers in a loop?
Can you add a custom naming scheme to make test results consistent?
AFAIK, one of the key features of JMeter UI is that it is somewhat friendly to non-programmers.
I would consider JMeter DSL to be a middle-ground between non-programmers and programmers.
Note: once you allow using a programming language (e.g. Go, JavaScript, Scala), you are not really restricted with JMeter, and there are plenty of options available.
It might sound like an arbitrary choice, however, I expect that Kotlin-based (and Groovy-based) DSLs are way easier to consume by non-programmers. For instance, they can use named parameters, they do not force you to put everything in a class (both Kotlin and Groovy allow top-level functions), and so on.

rabelenda: I believe having a solid core java api, and implementing on top of it thin layers (which may be autogenerated) that polish the experience to kotlin, groovy and other languages, looks to me to be a preferred path. Even though you would need to maintain java code instead of kotlin (which would be shorter), but this point may even be a pro or a con, depending to the target audience of maintainers your are considering.

I agree it would be great to have a solid Java API in JMeter, and I agree the current Java API is really complicated even for hardcore Java developers.
However, consider there are two tasks:

[ ] Rework JMeter Java API so it is easy to understand, easy to use, make it good enough for making DSL-like projects
[ ] Add DSL to the current JMeter

rabelenda: I understand you prefer kotlin, and have strong opinion on it's benefits, and you are determined to start something from the ground up with it, but I think we could do better by fostering a healthy Jmeter ecosystem of third party tools, and try helping existing solutions to improve, instead of reimplementing them.

Which one would you implement? Would you go with "reworking JMeter core APIs" or would you go with "adding a DSL on top of the existing codebase"?
I agree it would be great to rework JMeter Java API. However, that rework would bring virtually nothing to the current JMeter users. The rework would be hard since we should keep backward compatibility, and it unexpectedly might break plugins.
On the other hand, if JMeter adds DSL, it would be a user-visible feature that unlocks new possibilities.
That is why I prefer investing my time into DSL rather than "API refactoring". In other words, I would support both activities, however, I would favour "adding DSL".

Now's the tricky question: suppose there's Kotlin-based DSL in JMeter. Why would you even want to use it from Java?
 You can continue to use the old-school API and be done with it. Of course, with extra investments, the Kotlin-based DSL could be refined for better uses from Java (see how OkHttp migrated to Kotlin while keeping full backward compatibility with previous Java-based version), however, in the initial implementation of the DSL I would prefer to ignore uses from Java.
If you are an end-user, you might better use the DSL from Kotlin as it enables better ways to write the code, and so on.

rabelenda: As a side matter, which is not directly related to this topic: you have sent some PR to JMeter including kotlin. Have you considered the additional complexity (for users and maintainers) and JMeter size that implies adding a new language and its libs?

Just in case you missed it, JMeter build scripts use Kotlin for a couple of years now 😉 . Everybody who "maintains JMeter build", has to deal with Kotlin already.
If you ignore build scripts, JMeter code uses Java, Groovy, JavaScript, HTML, CSS, XLS, XSLT, and many other languages.
For instance, there's JMeter-specific JMX language with its own pitfalls. JMX (and the way XStream is configured) is way harder for maintenance than Kotlin code. Kotlin has documentation, you can find answers at StackOverflow, and so on. You just can't have all of that for JMeter-specific JMX language (and the related serialization-deserialization rules).
I do not agree with "JMeter is 100% Java".
JMeter is a mix of lots of languages and libraries.
Kotlin has great Java interop, it has a good backward compatibility story, it is readable, writable, and there's not much magic.
That is why I think "adding" Kotlin to JMeter is a non-issue really.

Hello,
Thanks for taking time to answer and reading my long comments 🙂

I would rather prefer refactoring JMeter core APIs rather than adding yet another Java-based DSL

That sounds awesome, but without modifying test element api, I currently don't see how you could do it, without a major undertaking. Additionally, plugins would need to be retrofitted as well to be used. In that scenario you could have a method to easily wrap/enrich/adapt plugins to be used with the DSL.

For instance, what does 1, 1 mean?

In some cases we opt to sacrifice readability for convention and compactness. That was a though decision, but we thought that in thread groups it would be quite natural for the numbers be threads and iterations. In any case, that can be easily changed to other approaches like fluent api. Potentially in that case would be longer, but in any case would be more natural to java devs than returning null, passing lambdas just for building things,  or passing parent element in builder method.

Can you add 10 httpSamplers in a loop?

You can. Not inline, but is as easy as to create a method for it. In any case in my years of Jmeter usage, and general development experience, I don't see a common case where this is actually helpful. And in general: simple cases should be simple to use, complex cases are good to be a little more complex. There is no need to make simple cases more complex for potentially more complex cases.

Can you add a custom naming scheme to make test results consistent?

What do you mean? 🙂 .
You can use any of programming languages features to define test elements label using whatever logic you define.

Which one would you implement? Would you go with "reworking JMeter core APIs" or would you go with "adding a DSL on top of the existing codebase"?

I am not certain right now, I think the best thing would be doing a POC of each alternative, tackling a sub domain of JMeter api that is representative enough (is the way the jmeter-dsl-started), and then generate a decision matrix with pros and cons an decide for one. I think having a DSL is basically what jmeter-java-dsl does, so you could compare it to it. We can also start branch in jmeter-java-dsl with a proposal for migrating it to kotling and then also compare pros and cons in a matrix and decide for the final approach (part of it I am doing it internally, but haven't yet explored all alternatives/ pros and cons in this regard).

Now's the tricky question: suppose there's Kotlin-based DSL in JMeter. Why would you even want to use it from Java?

If you have a java project would be simpler for maintenance to keep tests in java as well, mainly due to learning curve, introducing new people, handling two paradigms/languages is more complex than just one, language libraries and environment (ej: junit vs kotling test, and same for many other cases). In any case, my point is that it is nice for users to have a DSL for each language, I envision it as thin layers on top of a well stablished and compact API. And in general java API is easier/less verbose to use in Kotling and groovy, than kotlin in java and groovy.

see how OkHttp migrated to Kotlin

Hehe, is funny that you mentioned it, but this was one of the main kotlin based APIs that I used from Java and was really cumbersome/unnatural to use from Java.

Just in case you missed it, JMeter build scripts use Kotlin for a couple of years now 😉 . Everybody who "maintains JMeter build", has to deal with Kotlin already.

I know 🙂 . But is different to use it with a reduced DSL as is the one for gradle, than use it for "production code". Build logic is in general usually more static and requires less maintenance. In any case, I don't doubt on the capacity of JMeter maintainers, just saying that by adding additional languages you are rising the bar. Making it more complex for people to contribute, and I was specially thinking that if you keep including kotlin, without deprecating any of existing other jmeter internal languages/syntaxes (javascrit, beanshell, groovy, java), you are introducing more complexity (in addition to download size and "portability") of jmeter distributables.

I do not agree with "JMeter is 100% Java".
JMeter is a mix of lots of languages and libraries.

I didn't intend to mean that :-). But core logic is mainly Java. The other languages/idioms you mention are utility tools that users may use, but not part of core logic (of core framework, and each test element).
I see your point about kotlin, and am aware of most of its pros. I was just asking, because I feel Jmeter is quite loaded with programming languages, and some things can be just implemented with java/groovy instead of adding kotlin. But I guess you already evaluated pros and cons of adding another lang to the mix. Just wondering if makes at some point to reduce the general complexity that already resides in JMeter itself.
Thank you again for taking time, mental effort, and being open for all these questions and debate. 👍

my point is that it is nice for users to have a DSL for each language

I agree someone might need JMeter DSL for Java.
I agree someone might need JMeter DSL for Clojure.
I agree someone might need JMeter DSL for Groovy.
However, I truly think Kotlin-based DSL provides way better tooling, it provides nicer DSL, it is easier for newbies, it integrates with Java, there are people who know Kotlin and who do not know Java, and so on.

That sounds awesome, but without modifying test element api, I currently don't see how you could do it, without a major undertaking

"major undertaking" is possible. The thing is someone should be motivated to do that :)

In some cases we opt to sacrifice readability

With Kotlin named parameters are available, so the code might look like
  threadGroup(threads = 1, loops = 1
    children = httpSampler("https://myurl")
  )

I think having a DSL is basically what jmeter-java-dsl does

I think jmeter-java-dsl targets Java developers.
I assume the ones who can code in Java would pick up virtually any C-like syntax.
On the other hand, jmeter-java-dsl becomes quite an unusual subset of Java, and novices might struggle with it.
How do you even put a println log in the middle of this dsl?
testPlan(
  threadGroup(1, 1
    httpSampler("https://myurl")
  )
).run();

You can use any of programming languages features to define test elements label using whatever logic you define.

You can't add a dummy variable like String transactionPrefix = "createOrder" in the middle of
transaction(transactionPrefix,
                httpSampler(transactionPrefix + "items", "http://my.service/items"),
                httpSampler(transactionPrefix +"cardItems", "http://my.service/cart/items")

Of course, you might claim "no-one needs that", however, adding variables, adding dumb println, adding if (isDebugMode) {..., using well-known for, is really really helpful when it comes to exploring and debugging scripts.
Here's one more sample that declares a trivial load profile for open model thread group:
openModelThreadGroup {
    loadProfile {
        rate(10 / second)
        randomArrivals(5.minutes)
    }
…
}

What if I need a stepping profile with 5 steps?
openModelThreadGroup {
    loadProfile {
        for (i in 1..5) {
            rate((i*10) / second) // beginRate
            randomArrivals(5.minutes)
            rate((i*10) / second) // endRate
        }
    }
…
}

I can add a loop if I need it. I can add logging, I can extract loadProfile configuration into a separate method and so on.
I do not need commas, and I do not need semicolons

Hehe, is funny that you mentioned it, but this was one of the main kotlin based APIs that I used from Java and was really cumbersome/unnatural to use from Java.

Would you please provide an example?
https://square.github.io/okhttp/upgrading_to_okhttp_4/#upgrading-to-okhttp-4
They claim Binary compatibility, Java source compatibility, and Kotlin source compatibility.
Do you mean their claims are false?

I feel Jmeter is quite loaded with programming languages

Frankly speaking, I think many Groovy-based tests could be better written in Kotlin.

The other languages/idioms you mention are utility tools that users may use, but not part of core logic (of core framework, and each test element).

I mentioned the languages that JMeter maintainers have to touch while doing JMeter "maintenance".
For instance, a significant number of unit and integration tests in JMeter itself are written in Groovy. If some of them fail, I have to "know Groovy" in order to understand the way tests works.
Recently I've run into a Groovy-related test problem: https://github.com/apache/jmeter/commit/50d516765db0c5b776b81079036d76d44f573fd6
Groovy silently converted a closure into a boolean causing surprising behavior.
Kotlin is less surprise-inducing in that regard.

To be fair, I will add

  threadGroup(threads = 1, loops = 1
    children = httpSampler("https://myurl")
  )

The java version looks more interesting here in conjunction with the IDE. We write less and see the same

Thanks everybody for participating in the meetup.
I've shared the recording and my notes at dev@jmeter list: https://lists.apache.org/thread/bgy8fvz5j1tml1yl41l87cghztddn1kr
Feel free to subscibe.


Add Items, Skills and Artes XML to the repo

Also update TBL_All to have all shift-jis characters

@Fis-Ura Can you review my PR and see if files seems to have issues in it?
Thanks