Summary:
https://github.com/facebook/react-native/commit/c974cbff04a8d90ac0f856dbada3fc5a75c75b49 changed the border colors to be of UIColor instead of CGColor. This allowed working with dark mode to switch the border colors automatically. However, in certain situation the system can't resolve the current trait collection (see https://stackoverflow.com/a/57177411/2525941). This commit resolves the colors with the current trait collection to ensure the right colors are selected. This matches with the behavior of how the background color is resolved (also in displayLayer:).
## Changelog
[iOS] [Fixed] - Resolve border platform color based on current trait collection
Pull Request resolved: https://github.com/facebook/react-native/pull/32492
Test Plan: Same test plan as https://github.com/facebook/react-native/pull/29728
Reviewed By: sammy-SC
Differential Revision: D33819225
Pulled By: cortinico
fbshipit-source-id: 2f8024be7ee7b32d1852373b47fa1437cc569391
Summary:
changelog: Attempt to fix a crash during app termination on iOS in the new renderer
We need to stop all surfaces before it is terminated to prevent app from crashing.
The crash happens on background thread.
The app crashes because it is probably accessing static variable that has been deallocated by the main thread. How can main thread deallocate things when background thread is still running? Because main thread is attached to our app's process, background thread is provided by the system and continues to live.
Reviewed By: ShikaSD
Differential Revision: D33977161
fbshipit-source-id: 87546d7b70d1aa465e63f0d37b70bae1fffa2304
Summary:
D33740360 (https://github.com/facebook/react-native/commit/16ed62a850dd81bd9cc7f77ab3e77f42ed64b177) broke Explore VR on React Native. The app would go into a loop on boot and not finish mounting. This is probably a product code issue, but it's not a trivial issue to solve. Unlanding to unblock the RN migration.
Changelog:
[internal] internal
Reviewed By: mdvacca
Differential Revision: D33918026
fbshipit-source-id: cc77c70ece9994d82c91f7ae8783e959629e9cfb
Summary:
Before https://github.com/facebook/react-native/commit/f951da912dd8b4dc2b0d674f8f37f9d982a03c48 finding a system font used to return early. In order to allow variants, the referenced patch removed the early return so that variants could be applied later. However, there is no need to find the closest font as we already selected the proper system font. This also fixes a bug with setting a custom font handler via RCTSetDefaultFontHandler whos return could get overwritten by the closest font search.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Respect RCTSetDefaultFontHandler chosen font
Pull Request resolved: https://github.com/facebook/react-native/pull/32482
Reviewed By: ShikaSD
Differential Revision: D33844138
Pulled By: cortinico
fbshipit-source-id: 05c01fc358cd19f8be342218cdba944b303073ed
Summary:
changelog: [internal]
Yielding in RuntimeScheduler is shipped. This diff removes the gating around it.
Reviewed By: sshic
Differential Revision: D33740360
fbshipit-source-id: 267372e81e66dda96e451435954a7c3546cc6fbe
Summary:
…ansforms
On iOS, if a View is rotated with the a transform (e.g. <View style={{transform: {rotationZ: 5}}} />), the view has aliasing (see screenshot). Same for a skew transformation. We don't have the issue on Android
This behavior had originally being fixed by this PR https://github.com/facebook/react-native/pull/1999
However a new PR was merge ( https://github.com/facebook/react-native/pull/19360 ) that broke this. I think it was made to add antialiasing during perspective transforms but seems to have broken the antialiasing when rotationZ transforms
This PR adds back the antialising during rotation transform , while keeping it during perspective transform.
## Changelog
I changed the allowsEdgeAntialiasing condition, making it "true" when the m12 or m21 is not 0. From this article https://medium.com/swlh/understanding-3d-matrix-transforms-with-pixijs-c76da3f8bd8 , I've understood that in all rotation or skew transformations, m12 or m21 is different than 0 . In the other transformation (e.g. scale or translate) it stays at 0.
Although, I'm not a matrix transformation expert so I may be mistaken
Pull Request resolved: https://github.com/facebook/react-native/pull/32920
Test Plan:
I've written several views with all rotateX/Y/Z , skewX,Y and perpective transformation. Before the PR some transformation was showing aliasing on iOS (e.g. top-left view in the screenshot, don't hesitate to zoom in the image if you don't see it) and with this PR it does not have anymore
Before
After
Code I used to test
```
const commonStyle = {
width: 150,
height: 100,
backgroundColor: "red",
margin: 10,
}
const Test = () => (
<View style={{ flexDirection: "row" }}>
<View>
<View
style={[
commonStyle,
{
transform: [{ rotateZ: "4deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ rotateX: "30deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ rotateY: "30deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ rotateX: "30deg" }, { rotateY: "30deg" }, { rotateZ: "3deg" }],
},
]}
/>
</View>
<View>
<View
style={[
commonStyle,
{
transform: [{ skewX: "4deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ skewY: "4deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ skewY: "4deg" }, { rotateZ: "3deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ perspective: 1000 }],
},
]}
/>
</View>
</View>
)
```
Reviewed By: lunaleaps
Differential Revision: D33665910
Pulled By: sshic
fbshipit-source-id: 91163ec2a0897a73ddf0310d86afacea04b89bc7
Summary:
Fix for iOS displaying a RedBox for LogBox handled errors, this has been happening since RN 0.65 (in 64.2 and earlier, if it was handled by LogBox then it wouldn't trigger RedBox)
Fixes https://github.com/facebook/react-native/issues/32106
## Changelog
[iOS] [Fixed] - Stop RedBox from appearing for LogBox handled errors
Pull Request resolved: https://github.com/facebook/react-native/pull/32641
Test Plan: Manually tested. Seems to fix things (and RedBox still displays for things like 'Could not connect to development server') but I would appreciate RSNara or someone else who is more familiar with the code to confirm that the original switch was a mistake and not something deliberately changed.
Reviewed By: christophpurrer
Differential Revision: D33661481
Pulled By: cortinico
fbshipit-source-id: c9c262adb3f977ae3f13beb9575d3eaa2445f663
Summary:
Resolves this issue: https://github.com/facebook/react-native/issues/32304.
**NOTE:** This PR is based on a prior PR for this fix: https://github.com/facebook/react-native/pull/32305, I've co-authorized its creator for this change (paddlefish).
Without this change, calling to hide an alert, leaves a `UIWindow` that blocks user interactions with the screen.
The correct way to remove a `UIWindow` in iOS is to set its hidden property to `YES`. Also, it is required to remove all references to the window (the associated `windowScene` for example) and ARC will automatically free this `UIWindow`.
The line after this change, set the `_alertWindow` reference to `nil`, but the window is already associated with a scene (see the screenshots from [this PR](https://github.com/facebook/react-native/pull/32305#discussion_r720521707)). So we also need to remove the `windowScene` from that window, as recommended by Apple: https://developer.apple.com/documentation/uikit/uiwindowscene/3198091-windows.
>To remove the window from the current scene, or move it to a different scene, change the value of the window's windowScene property.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - remove alert's window when call to `hide`.
Pull Request resolved: https://github.com/facebook/react-native/pull/32833
Test Plan: See https://github.com/facebook/react-native/pull/32305
Reviewed By: hramos
Differential Revision: D33460430
Pulled By: lunaleaps
fbshipit-source-id: b13c2c7ee6404f1e1c787265bc4af8a31005bcf1
Summary:
For every direct and bubbling event, RCTComponentData (iOS-only) creates a {eventName}: true entry in the component's ViewConfig validAttributes. This entry is unnecessary, and creates a discrepancy between ViewConfigs on iOS vs Android.
This diff removes this entry for all events to:
1. Reduce bloat in native ViewConfigs
2. Create consistency betweeen Android and iOS.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D33303950
fbshipit-source-id: 870c8a2a6d41156ac89bd8554eb09f292bb6108e
Summary: Insert casts for implicit int -> CGFloat conversions. This warning category is generally benign and explicitly casting will preserve existing behavior.
Reviewed By: NSProgrammer
Differential Revision: D33303887
fbshipit-source-id: b21adbcf754e707adfe3f8eaa0fe9c3a65380cc5
Summary:
Renaming the `better` utilities to `butter`:
- to prevent claims that this library is superior to others - it really depends on use cases
- to indicate ease of use throughout the codebase, easily spread like butter
Changelog: [C++][Changed] Renaming C++ better util to butter, used by Fabric internals
Reviewed By: JoshuaGross
Differential Revision: D33242764
fbshipit-source-id: 26dc95d9597c61ce8e66708e44ed545e0fc5cff5
Summary: Changelog: [Internal] - Update the source of the changes in generated files, no longer bump-oss-version but set-rn-version
Reviewed By: sota000
Differential Revision: D33110408
fbshipit-source-id: 8cd5004f5d40dde82fe4d6271d5b8598cd27ca31
Summary:
changelog: [internal]
Just getting rid of some implicit type conversions and using std::max and std::min instead of macros.
Reviewed By: philIip
Differential Revision: D33161766
fbshipit-source-id: c72011c54f35a145afa236f1dc3d185b19e46cc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32775
Changelog: [Internal] Fix build issues for the new app template with the new architecture enabled
Reviewed By: philIip
Differential Revision: D33157325
fbshipit-source-id: ee63f38fbfc088ca193dfa1b48f4b6611257b787
Summary:
Changelog: [internal] Refactor RCTAppSetupUtils to c functions.
Since RCTAppSetupUtils doesn't retain any states, we don't need it to be a class.
Reviewed By: philIip
Differential Revision: D33084352
fbshipit-source-id: 1372a2737eafffa46ee6e5164a970dd12699c71c
Summary: Changelog: [internal] Changed teh new architecture flag in the new app template to RCT_NEW_ARCH_ENABLED
Reviewed By: philIip
Differential Revision: D33083694
fbshipit-source-id: f2cc6c564c724b4ebed7b465a533464b6717ac27
Summary:
Changelog: [internal] Added fabric option to the default app template.
Use RCT_TM_FABRIC_ENABLED C++ flag to enable fabric.
Reviewed By: sammy-SC
Differential Revision: D33052956
fbshipit-source-id: 28313829c80abcf02baa521bdb0b70213c94a97f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32752
Changelog: [internal] Add an optional support for Turbomodule. Define RCT_TM_FABRIC_ENABLED to enable the new architecture.
Reviewed By: philIip
Differential Revision: D33052777
fbshipit-source-id: 6d32790586bb51f9c9244344522c95245c912114
Summary:
Modernize our null annotations
From the swift blog:
This feature was first released in Xcode 6.3 with the keywords nullable and nonnull. Due to potential conflicts with third-party libraries, we’ve changed them in Xcode 7 to the _Nullable and _Nonnull you see here.
drop-conflicts
Reviewed By: cuva
Differential Revision: D33121042
fbshipit-source-id: 821f5ec858d9afd5bfb1d6081c669f4ca18a36ed
Summary:
changelog: [internal]
[CALayer opacity] is of type `float`, not `CGFloat`.
Reviewed By: philIip
Differential Revision: D33058967
fbshipit-source-id: 98b214e32f6d35e904a7abb0e01c2d01da50a285
Summary:
Changelog: [internal] Move initital setups in AppDelegate to util classes.
This will make it easy to apply the new architecture changes in the future.
Reviewed By: cortinico
Differential Revision: D33051517
fbshipit-source-id: 16e326b7816fae83df65450c545e7dce1a93b9d0
Summary:
The IDE warning suggests that passing folly::dynamic by value will create a copy on each call.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D32978154
fbshipit-source-id: a47a60c332a9d299eb2110d3537dfab0bc2398b6
Summary:
`_labelsForTags` is an array with string labels used only for local profiling, that we had to manually keep it in sync with `RCTPLTag`. Refactor so labels are assigned with switch instead.
Changelog: [iOS] Refactor: Assign string label to each case in RCTPLTag enum for startup performance logging
Reviewed By: fkgozali
Differential Revision: D32889043
fbshipit-source-id: 81da592a160a31b91e78289be0990cc2ff960f29
Summary:
changelog: [internal]
Introduce a way to execute `onKeyPress` synchronously. This feature is experimental and will be changed in the future. It is not decided if marking native events as "sync" is going to be path forward with synchronous access.
NOTE: This is experimental API.
Reviewed By: ShikaSD
Differential Revision: D32882092
fbshipit-source-id: 68c66a9bb7c97758219e085c88a77f3c475c1eb3
Summary:
Retrying D30015799 (https://github.com/facebook/react-native/commit/6e903b07fa8e8d9b78cae0e031bb8022f7a63195) with a fix where ScrollViewNativeComponent was missing the automaticallyAdjustKeyboardInsets prop.
----- Original Summary
Currently, ScrollViews provide the prop `keyboardDismissMode` which lets you choose `"interactive"`. However when the keyboard is shown, it will be rendered above the ScrollView, potentially blocking content.
With the `automaticallyAdjustKeyboardInsets` prop the ScrollView will automatically adjust it's `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) props to push the content up so nothing gets blocked.
* The animation curve and duration of the Keyboard is exactly matched.
* The absolute position of the ScrollView is respected, so if the Keyboard only overlaps 10 pixels of the ScrollView, it will only get inset by 10 pixels.
* By respecting the absolute position on screen, this automatically makes it fully compatible with phones with notches (custom safe areas)
* By using the keyboard frame, this also works for different sized keyboards and even `<InputAccessoryView>`s
* This also supports `maintainVisibleContentPosition` and `autoscrollToTopThreshold`.
* I also fixed an issue with the `maintainVisibleContentPosition` (`autoscrollToTopThreshold`) prop(s), so they behave more reliably when `contentInset`s are applied. (This makes automatically scrolling to new items fully compatible with `automaticallyAdjustKeyboardInsets`)
## Changelog
* [iOS] [Added] - ScrollView: `automaticallyAdjustKeyboardInsets` prop: Automatically animate `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) to avoid the Keyboard. (respecting absolute position on screen and safe-areas)
* [iOS] [Fixed] - ScrollView: Respect `contentInset` when animating new items with `autoscrollToTopThreshold`, make `automaticallyAdjustKeyboardInsets` work with `autoscrollToTopThreshold` (includes vertical, vertical-inverted, horizontal and horizontal-inverted ScrollViews)
Pull Request resolved: https://github.com/facebook/react-native/pull/31402
Test Plan:
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708680-9700aa80-a370-11eb-8016-e75d81a92cd7.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708699-9b2cc800-a370-11eb-976f-c4010cd96d55.MP4
</td>
</table>
### "Why not just use `<KeyboardAvoidingView>`?"
<table>
<tr>
<th>Before (with <code><KeyboardAvoidingView></code>)</th>
<th>After (with <code>automaticallyAdjustKeyboardInsets</code>)</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708749-abdd3e00-a370-11eb-8e09-a27ffaef12b8.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708777-b3044c00-a370-11eb-9b7a-e040ccb3ef8c.MP4
</td>
</table>
> Also notice how the `<KeyboardAvoidingView>` does not match the animation curve of the Keyboard
### Usage
```jsx
export const ChatPage = ({
flatListProps,
textInputProps
}: Props): React.ReactElement => (
<>
<FlatList
{...flatListProps}
keyboardDismissMode="interactive"
automaticallyAdjustContentInsets={false}
contentInsetAdjustmentBehavior="never"
maintainVisibleContentPosition={{ minIndexForVisible: 0, autoscrollToTopThreshold: 100 }}
automaticallyAdjustKeyboardInsets={true}
/>
<InputAccessoryView backgroundColor={colors.white}>
<ChatInput {...textInputProps} />
</InputAccessoryView>
</>
);
```
## Related Issues
* Fixes https://github.com/facebook/react-native/issues/31394
* Fixes https://github.com/facebook/react-native/issues/13073
Reviewed By: yungsters
Differential Revision: D32578661
Pulled By: sota000
fbshipit-source-id: 45985e2844275fe96304eccfd1901907dc4f9279
Summary:
changelog: [internal]
Background executor has been shipped on both platforms for a long time.
I've kept the flag around because I wanted to run tests and compare Concurrent Mode vs Background Executor. The intention was to see if we can get rid of Background Executor to simplify the threading model.
Since then, React team has moved away from Concurrent Mode towards more gradual rollout of concurrent rendering and it no longer makes sense to do this comparison. Right now, we don't have a concern with concurrent rendering and Background Executor. If we ever want to run the an experiment, this gating will need to be added again.
Reviewed By: javache
Differential Revision: D32674798
fbshipit-source-id: a1e51c9c5b8e48efa4cb0f25379d58e7eb80ccd9
Summary:
I've noticed that the `performance.now()` implementations differ on iOS and Android.
iOS:
```objc
PerformanceNow iosPerformanceNowBinder = []() {
// CACurrentMediaTime() returns the current absolute time, in seconds
return CACurrentMediaTime() * 1000;
};
```
Android:
```c++
double reactAndroidNativePerformanceNowHook() {
auto time = std::chrono::steady_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::nanoseconds>(
time.time_since_epoch())
.count();
constexpr double NANOSECONDS_IN_MILLISECOND = 1000000.0;
return duration / NANOSECONDS_IN_MILLISECOND;
}
```
For consistency, I thought why not just use the same implementation on both iOS and Android.
It also seems more logical to use Chrono on iOS, since it has nanosecond precision and we just multiply it to milliseconds, whereas `CACurrentMediaTime` multiplies to seconds, and we divide it down to milliseconds again.
## Changelog
(internal change only)
Pull Request resolved: https://github.com/facebook/react-native/pull/32695
Test Plan:
Run on iOS and Android:
```ts
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: feedthejim
Differential Revision: D32793838
Pulled By: ShikaSD
fbshipit-source-id: e7967780be95956a75a3a3757311af0077976d23
Summary:
The current implementation of the prelive composer is setting the RN override preference to nil when live shopping ends. However, if the user had a previously set appearance override, this would clear it out.
To resolve this, I cache the user's override preference before we override it, and restore it when live shopping ends.
Additionally, I'm adding a missing callback to restore the override pref when live shopping is dismissed, but not cancelled.
Changelog:
[ReactiveNative][Appearance] - Add function to retrieve overridden RN appearance
Differential Revision: D32564739
fbshipit-source-id: d0b4e06d2bbadad68f172d951609cba3e4587e5d
Summary:
The current implementation of `AccessibilityInfo.announceForAccessibility` will immediately interrupt any existing in progress speech with the announcement. Sometimes this is desirable behaviour, but often you will want to wait until existing speech is finished before reading the new announcement. This change gives us that option.
My personal use case for this feature is a custom text input. When typing on iOS with voiceover enabled, each character is read out after being selected. I wanted to add some additional information after each character to help with the context of what has changed in the input, but I didn't want to override the reading of the character itself.
This feature is supported natively on iOS by constructing an `NSAttributedString` with the property [`accessibilitySpeechQueueAnnouncement`](https://developer.apple.com/documentation/foundation/nsattributedstring/key/2865770-accessibilityspeechqueueannounce), so this change just adds an extra parameter to `AccessibilityInfo.announceForAccessibility` which controls the value of that property on the native side. Adding this as an extra optional parameter with false as the default ensures that existing uses of the function won't be affected.
Unfortunately, this feature doesn't appear to be supported on Android, so the new second property will be iOS only.
## Changelog
[iOS] [Added] - add new argument to announceForAccessibility to allow queueing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/32637
Test Plan:
I've updated the `announceForAccessibility` section in RNTester with multiple buttons to demonstrate the difference between `queue: false` (default) and `queue: true` and show they work as intended.
Here's the expectation for each button:
- "Announce for Accessibility Immediately": on press, should start reading the button label, then be interrupted by the announcement
- "Announce for Accessibility Queued": on press, should read the button label then read the announcement afterwards
- "Announce for Accessibility Queue Multiple": on press, should read the button label, then read three announcements sequentially, no interruptions
You can see the realisation of those expectations in the following video recorded on an iPhone 12 running iOS 15.0.2:
https://user-images.githubusercontent.com/14826539/142770536-d57bfd69-eba5-444d-9c89-4bf4851ea062.mov
I've also tested the same way on an iPhone 8 running iOS 13.4 and it works exactly the same.
Reviewed By: yungsters
Differential Revision: D32637989
Pulled By: philIip
fbshipit-source-id: 3e90add523f11eb0eb34ea623211249263f257e2
Summary:
changelog: [internal]
Attempt at fixing a crash in `Scheduler::uiManagerDidCloneShadowNode` by setting delegate to nullptr explicitly.
I don't think this will make a difference because `scheduler_` is released at the end of `dealloc` but it is worth a shot. Maybe some complex interaction between Obj-C and C++ comes into play here.
In this diff I also removed `_animationDriver = nullptr` because dealloc will do that automatically.
Reviewed By: philIip
Differential Revision: D32720901
fbshipit-source-id: 227ced2331384c47e8d15a323ee8a621bbb3d179
Summary:
Changelog:
[iOS][Fixed] This is a quick speculative fix since we know `CFRunLoopPerformBlock` does not push/pop an autorelease pool.
Reviewed By: appden
Differential Revision: D32657298
fbshipit-source-id: 4641ad89baf7889ba4bf80e6e64e26de02818cb8
Summary:
as title
in practice, this doesn't make any difference, but this is to follow the apple recommendation and for us to have a more consistent codebase.
https://developer.apple.com/library/content/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html
>The NS_ENUM macro helps define both the name and type of the enumeration, in this case named UITableViewCellStyle of type NSInteger. The type for enumerations should be NSInteger.
>Like enumerations, the NS_OPTIONS macro defines both a name and a type. However, the type for options should usually be NSUInteger.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32641990
fbshipit-source-id: 56e4cd44cdefe54f61c90844665a685ee2d6ffad
Summary:
a lot of unused code here, cleaning it up
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32640185
fbshipit-source-id: 2917b4e3ea9c08ccb520250de509f0253d5dae61
Summary:
here's a way we can mock C apis - however i am not sure if the flag i'm using is correct
used in D31949237
Changelog:
[General][Added] - add macros to be able to stub C functions in tests
Reviewed By: RSNara
Differential Revision: D31949238
fbshipit-source-id: 0f18a65f810f1b855dbc844f11f5a304c1e5ecea
Summary:
after D32591685, no one is using this. delete
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D32591686
fbshipit-source-id: 11ffb8cbf0fef605b7aefa47347db3ccc6e7d7fe
Danilo Bürger
Samuel Susla
Felipe Perez
CodemodService FBSourceClangFormatLinterBot
Mattéo Martin
Moses DeJong
Liam Jones
Pieter De Baets
Asaf Korem
Ramanpreet Nara
Paige Sun
Andres Suarez
Richard Howell
Kevin Gozali
Luna Wei
Sota Ogo
Phillip Pan
Adam Cmiel
Andrei Shikov
Marc Rousavy
Marc Rousavy
David Ashinsky
Peter Carpenter
Christoph Purrer
