-
Notifications
You must be signed in to change notification settings - Fork 103
In the swift program it works perfectly, don't you also have a test for Python? #478
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
question
❓ Further information is requested
Comments
I'm sorry I don't understand what this issue is describing, can you elaborate? Closing for now, but if you can provide more information we can consider reopening. |
grynspan
added a commit
that referenced
this issue
Oct 17, 2024
…S_SPAWNING`. This PR separates out our process-spawning code to be guarded by `SWT_NO_PROCESS_SPAWNING` instead of `SWT_NO_EXIT_TESTS`. We do this so that we can potentially use process spawning on platforms where exit tests are not supported for some other reason (such as the iOS/Android sandboxes) but process spawning is still internally possible. There are a few use cases we have for spawning processes that don't involve exit tests: - Calling out to `tar` to compress attachments (see #714) - Running non-Swift scripts in their interpreters (see #478) - Multi-process parallelism (the XCTest model) I took the opportunity to clean up WaitFor.swift a bit and rearrange code so that the "new platform, dunno who lives here" case should compile (although not function) out-of-the-box.
2 tasks
grynspan
added a commit
that referenced
this issue
Oct 17, 2024
…S_SPAWNING`. (#769) This PR separates out our process-spawning code to be guarded by `SWT_NO_PROCESS_SPAWNING` instead of `SWT_NO_EXIT_TESTS`. We do this so that we can potentially use process spawning on platforms where exit tests are not supported for some other reason (such as the iOS/Android sandboxes) but process spawning is still internally possible. There are a few use cases we have for spawning processes that don't involve exit tests: - Calling out to `tar` to compress attachments (see #714) - Running non-Swift scripts in their interpreters (see #478) - Multi-process parallelism (the XCTest model) I took the opportunity to clean up WaitFor.swift a bit and rearrange code so that the "new platform, dunno who lives here" case should compile (although not function) out-of-the-box. ### Checklist: - [x] Code and documentation should follow the style of the [Style Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md). - [x] If public symbols are renamed or modified, DocC references should be updated.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
This same test exists but what can I use for other languages like Python?
Expected behavior
No response
Actual behavior
No response
Steps to reproduce
No response
swift-testing version/commit hash
No response
Swift & OS version (output of
swift --version && uname -a
)No response
The text was updated successfully, but these errors were encountered: