Summary:
# Problem
We calculate `stateRevision_` in constructor from children, but children change after shadowNode is initialised and before it is sealed. So the `stateRevision_` we calculate in constructor can be incorrect.
# Solution
Recalculate `stateRevision_` whenever children change. This can happen in two methods `ShadowNode::replaceChild` and `ShadowNode::appendChild`. This diff implements this solution.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D19813840
fbshipit-source-id: 8fc3b6601e4618f4ee5b322eebc230e0bbb92e3a
Summary:
Before this change the Element<> API didn't allow to specify state objects and crashed during instantiation of non-null states.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19816358
fbshipit-source-id: 95ba5e03ea98c0260593462146e8523c95245e2b
Summary:
This pull request fixes a few `#include`s in the Fabric source:
* Changes `<Glog/logging.h>` to `<glog/logging.h>` in two files, which was an issue for case-sensitive file systems
* In `ParagraphProps.cpp`, changes the include of `attributedstring/primitives.h` from a relative style to a more absolute style.
## Changelog
[Internal] [Fixed] - Fabric: Fix various includes
Pull Request resolved: https://github.com/facebook/react-native/pull/27947
Test Plan: Fabric compiles perfectly, and the Fabric test suite passes.
Reviewed By: shergin
Differential Revision: D19788148
Pulled By: sammy-SC
fbshipit-source-id: 30a297e8aea50c7c7fd5f48745edf04811a6bdbd
Summary:
This pull request fixes the CXX stub for `TextLayoutManager`. The signature for `TextLayoutManager::measure` changed slightly, and this patch updates the stub to reflect that.
## Changelog
[Internal] [Fixed] - Fabric: Fix CXX Stub for TextLayoutManager
Pull Request resolved: https://github.com/facebook/react-native/pull/27948
Test Plan: Fabric compiles, and the Fabric test suite passes.
Reviewed By: shergin
Differential Revision: D19788207
Pulled By: sammy-SC
fbshipit-source-id: 8f42cca0be99022b038742728ad4fec6c04d5cf0
Summary:
This change removes the concept of `StateTarget`, replacing its role with `ShadowNodeFamily`.
When `StateTarget` was built, we didn't have a concept of `Family`, and when we added it we introduced a retain-cycle: ShadowNode -> Family -> StateTarget -> ShadowNode. This diff fixes that.
This change does not change conceptually how the state behaves, it just adjusts internal machinery.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19799013
fbshipit-source-id: c1360bfbf6b8ac34e2a856a40047eafeb50ed070
Summary:
Before this change, the concrete component-specific data/payload object associated with a State was stored inside a templated subclass as a normal instance variable; after the change, it's stored as a shared pointer inside the base class. The original motivation was that storing that inside subclass saves us one shared pointer and one heap allocation.
This approach overcomplicated a lot of things and all possible savings are probably compensated with additional complexity (we have to have templated state-update lamdas in subclasses and so on). And to update the data in the previous approach we need to create a shared pointer to data anyway.
This change will allow future improvements in the coming diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19799014
fbshipit-source-id: 287ed939353ba58d9e434d1502ecfbb208c6daa5
Summary:
Only use State Reconciliation during certain commits from ReactJS, not during State commits or others
The idea is that this will have better perf, since many types of commits don't need State Reconciliation at all.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19794999
fbshipit-source-id: 336325f225d993a6aae9f55cb95a7a2b38a6d853
Summary:
This implements proposal #2 in our State architecture doc: https://fb.quip.com/bm2EAVwL7jQ5
Problem description: see the text in the comment of TreeStateReconciliation.h
Solution: see also comments in TreeStateReconciliation.h.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D19617329
fbshipit-source-id: 845fb5fe27f2591be433b6d77799707b3516fb1a
Summary:
Systraces were disabled a year ago in D14019272 because we suspected they can negatively affect perf. We don't think this is the case anymore.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19786284
fbshipit-source-id: 185ed45b134fdcadf131cfddfcf8faf37537a684
Summary:
These props are applied to `View`, therefore they most not be a part of base text attributes, so we reset them.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19764144
fbshipit-source-id: a0d2900e3161c47b83114360c843fa85a4389f8a
Summary:
Of course, compare_exchange_strong didn't actually do what I wanted.
Using a mutex is simpler and actually has the semantics we want: atomically get the current value, compare, and bail if the value is the same, or swap and continue.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19754451
fbshipit-source-id: 6b0aef217b235959af683ec5e31b07a0dd7bb040
Summary:
- We use a fork of Microsoft's react-native-windows which uses a fork of Facebook's react-native
- YGValue.h does not compile with Clang on Windows
- This change should fix that
- I want to put the change here so that it bubbles back to our fork > https://our.intern.facebook.com/intern/diff/D19656093/
#Changelog:
[General][Fixed] Make YGValue.h compile with Clang on Windows
Reviewed By: SidharthGuglani
Differential Revision: D19717489
fbshipit-source-id: ad867ecaf910bb64a777a06c656a1867bb15484b
Summary:
The documentation in two out of the three variants of `Function::callWithThis` incorrectly stated that the `this` value was to be `undefined` instead of set to `jsThis`, which contradicts the point of the `callWithThis` method existing in the first place. This diff fixes that issue.
Changelog: [General] [Fixed] - Fix documentation comments for HermesJS's `Function::callWithThis` method to accurately reflect how `this` is handled.
Reviewed By: jbower-fb
Differential Revision: D19714074
fbshipit-source-id: 123688c1f7e578d6356bec54604fb6e30f06b0b1
Summary:
Simple hack to prevent duplicate onLayout events from being emitted to JS.
Because of the addition of State Reconciliation to the Fabric lifecycle (see previous diff), in certain circumstances entire subtrees can be relayed-out many, many times even though they aren't changing. For JS product code that responds to every onLayout and forces a ReactJS tree commit (see: some usages of VirtualizedList) this can cause an async infinite loop of commits and layouts even though the tree and the LayoutMetrics aren't actually changing. Even though nothing is changing, it can still cause serious performance regressions and even some bugs since the internals of various state machines may assume onLayout won't be called many times.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19715280
fbshipit-source-id: d879e24f1c7b1f710ad430b7473aa9293d093dea
Summary:
Adding a `.clang-tidy` to a bunch of dirs under `react-native-github/ReactAndroid` and `react-native-github/ReactCommon`.
I don't want to add a single `.clang-tidy` at the root because we'll need more fine-grained control over what checks are enabled in different parts of the codebase; for example, fabric will and TM will probably have more checks enabled than older parts of the codebase that we're not actively modernizing, and the Hermes team probably wants its own config to be consistent with the rest of their codebase.
Starting off each `.clang-tidy` by only enabling clang-diagnostic; this is just to test that it's working. In the future, we'll work with the community to gradually enable more checks.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19705749
fbshipit-source-id: 979cea053b645ac4a9790340033bfcfb49ca0f97
Summary:
Changelog: [internal]
`ShadowNodeFamily` can be used as target in state updates instead of `ShadowNode`.
Reviewed By: shergin
Differential Revision: D19517428
fbshipit-source-id: 6831357e749239d5afec1dfd2d44a26ca6553e51
Summary:
Changelog: [internal]
Merges all of responsibilities of `StateCoordinator` into `ShadowNodeFamily`.
Reviewed By: shergin
Differential Revision: D19500104
fbshipit-source-id: f31ffded5a840e722fd898eef6a9f52cd2186df7
Summary:
This is a quite fragile and important part of the render engine. We need to dirty Yoga node only in cases where a change affects layout. In the case of over-dirtying, we can kill performance. In the case of under-dirtying, we can produce an incorrect layout.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596279
fbshipit-source-id: 9f2ac67c44cb35c8ba44be1025b94b7921b74e17
Summary:
This is aligned with all simular changes that we do for `*Props` types (see D19583582 and D19390813).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596281
fbshipit-source-id: 283b89c65504e20a461b12c2d1218325c6621dd8
Summary:
Reasons:
* The name of the method now better represent what it's doing;
* It exposes information about "dirty" state of the node without opening actual `LayoutableShadowNode` protected APIs;
* It's a tiny bit faster now because it checks the flag before calling Yoga.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596282
fbshipit-source-id: 3d87d9d5ba20bb8e360683f149b5ebf90beecd65
Summary:
After D19565499, the `LongLivedObjectCollection` will be cleared on the JS thread when the jsi::Runtime is deleted. This diff makes it so that we never hold strong references to `CallbackWrapper`s in our Android TurboModules infra. Therefore, we can leverage the changes in D19565499 to ensure that our `jsi::Function`s are deleted before the `jsi::Runtime`.
## Caveat
If you delete a TurboModule by itself, it's jsi::Functions that haven't been invoked won't be released. This is also the case for iOS. I plan to fix this for both iOS and Android at a later point in time.
Changelog:
[Android][Fixed] - Refactor jsi::Function cleanup in TurboModules
Reviewed By: mdvacca
Differential Revision: D19589151
fbshipit-source-id: efa3cc6c83634014159ac7500dcf6bef9c925762
Summary:
It makes perfect sense because `Builder` builds totally new shadow trees, so those are not sealed or used by anyone yet.
Assigning it to const shared pointer will do logical sealing (and it does not requires const-cast).
Fewer const-casts in the code, fewer bugs.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596284
fbshipit-source-id: 75d1c706034958ba7e4bc80a68af75a57c46eb6f
Summary:
Before this change `Element<X>` cannot have children of `Element<Y>` which was wrong because we don't have such limitation in Fabric.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596283
fbshipit-source-id: 9002f5dd42b3d05e7cf492499499399c97b58152
Summary:
Changelog: [Internal]
# Analysis
Measure returns following values for `frame.y` when tapping item in bottom sheet.
Fabric 412.33331298828125.
Paper 49.
In Paper, the frame.y returned is the position of tapped item in bottom sheet relative to the bottom sheet itself, which is correct.
This can happen in both BottomSheet and Modal.
# Why it happens?
In [UIManager.getRelativeLayoutMetrics](https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactCommon/fabric/uimanager/UIManager.cpp?commit=a372cf516ba1245ad9462e68376ee759c118a884&lines=172-181) if `ancestorShadowNode` is nullptr we populate `ancestorShadowNode` with `rootShadowNode` for the surface.
Problem is that BottomSheet that is presented, is not a separate surface. This means that we climb up the shadow node hierarchy all the way to root shadow node and keep adding offsets. Even though we should stop when we hit shadow node representing BottomSheet.
# How could be this fixed?
I think we should add a new shadow node trait that would mark node as root node. As we are traversing the shadow node tree upwards and adding offset of that node, once we hit a node that is "anchor", we would immediately stop the traversal.
This solution is inspired by Paper where the node representing BottomSheet has a special flag which marks it as "root" node.
accepttoship
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19640454
fbshipit-source-id: bde623b1f41a9745a41f0aada7221bf924fad453
Summary:
## Description
You're not supposed to hold on to JSI objects (ex: `jsi::Function`) past the point where their `jsi::Runtime` is deleted. Otherwise, we get a dangling pointer crash, like this: T60262810! Historically, this cleanup problem has always been really tricky to get right. With this diff, I hope to fix that problem once and for all by deleting all `jsi::Function`s when we delete the global `__turboModuleProxy` function.
## Current Setup
- The TurboModules infra uses weak references to `CallbackWrapper`s to hold on to the `jsi::Function`s passed from JS to ObjC.
- The LongLivedObjectCollection holds on to strong references to `CallbackWrapper`s. This ensures that the `jsi::Function`s aren't deleted prematurely. This also means that we can use `LongLivedObjectCollection` to delete all `CallbackWrappers`.
- `TurboModuleBinding` is the abstraction we use to install the global `__turboModuleProxy` function. It is owned by `TurboModuleManager`, and `TurboModuleManager` uses it to clear all references to `jsi::Function`s, when we delete all NativeModules.
## Solution
1. Transfer ownership of `TurboModuleBinding` from `TurboModuleManager` to the `__turboModuleProxy` function.
2. Clear the `LongLivedObjectCollection` when `TurboModuleBinding` is deleted.
Changelog:
[iOS][Fixed] - Clear all held jsi::Functions when jsi::Runtime is deleted
Reviewed By: JoshuaGross
Differential Revision: D19565499
fbshipit-source-id: e3510ea04e72f6bda363a8fc3ee2be60303b70a6
Summary:
Changelog: [Internal]
Exposes `synchronouslyWaitForStage` to `RCTFabricSurface`.
This is a first step towards having screenshot tests rendered with Fabric.
Reviewed By: shergin
Differential Revision: D19603837
fbshipit-source-id: 26c14cf3bbd67fea96319ff08d3321557ddcdd9c
Summary:
We are deprecating SharedShadowNode in favor of ShadowNode::Shared, the previous diff already removed most of the usages of SharedShadowNode
changelog: [internal]
Reviewed By: shergin
Differential Revision: D19217718
fbshipit-source-id: 1b7cd1af0ecdc6112befdc45c1dd0fca5012ab21
Summary:
ShadowNode::Shared and SharedShadowNode represent the exact same type. Nowadays we use ShadowNode::Shared instead of SharedShadowNode.
This diff replaces usages of SharedShadowNode for ShadowNode::Shared in the fabric folder.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D19217717
fbshipit-source-id: 112331b22251aa3a3d5e183395c54f2ca0f56e47
Summary:
Here is a mutation test for the Diffing algorithm that we use to diff ShadowNode trees and flatten them. As a side-effect, it also "tests" that Concurrent Yoga does not crash and produces decent cloning requests.
The test works this way:
1. We create a random ShadowNode tree;
2. We create a View tree from that that we continue to maintain;
3. We apply random mutation on this;
4. We layout the tree;
5. We generate the mutation instruction comparing a previous tree with a new one;
6. We apply mutations on the first tree;
7. We generate a new tree from scratch;
8. We compare the new tree with the tree updated with mutations and expect equivalence;
9. Repeat a million times.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19357714
fbshipit-source-id: 04765ede87d91180952ae650ff0d505dfac2ed8e
Summary:
In my app I have a case where I need to pass a very large string (45MB) between JS and native. This is obviously suboptimal, but… this is where I'm at.
The main bottleneck to doing this turned out to be `jsi`'s `JSStringToSTLString()`, which was extremely slow. In my case, 4.7s to execute. After this change, 204ms.
I don't really know C++, so I'm not sure this code is 100% correct and safe, and I bet it could be done even better by avoiding the extra memory allocation (would shave off another 70ms).
## Changelog
[General] [Changed] - Make JSStringToSTLString 23x faster
Pull Request resolved: https://github.com/facebook/react-native/pull/26955
Reviewed By: shergin
Differential Revision: D19578728
Pulled By: motiz88
fbshipit-source-id: 2fbce83166953ce928f0a6aa36eed710bfe05383
Summary:
Changelog: [internal]
1. Creates `ShadowNodeFamily` inside `ComponentDescriptor`.
2. As a side effect of this, we no longer need `ComponentDescriptor::createEventEmitter` so it is removed.
This is a step in order to merge `StateCoordinator` into `ShadowNodeFamily` and use it as target for state updates.
Reviewed By: shergin
Differential Revision: D19514906
fbshipit-source-id: 04ad3c621886be56925acd76f9b35a09d8c5e15a
Summary:
Changelog: [internal]
1. Use `ShadowNode::Shared` instead of `SharedShadowNode`.
2. Initialise `ShadowNodeFamily` before `ShadowNode`.
Why?
This is a step in order to merge `StateCoordinator` into `ShadowNodeFamily` and use it as target for state updates.
Reviewed By: shergin
Differential Revision: D19471399
fbshipit-source-id: 2f67901c901349d238c711f9eeaadb19fe7c1110
Summary:
Changelog: [internal]
1. Moves `ShadowNode::getAncestors` to `ShadowNodeFamily`.
2. Exposes shadowNode's family through `ShadowNode::getFamily()`.
# Why?
This is a first step in order to merge `StateCoordinator` into `ShadowNodeFamily` and use it as target for state updates.
Reviewed By: shergin
Differential Revision: D19465188
fbshipit-source-id: b5a3625aa21c040301259de02beedbf97e11f20e
Summary:
`SnapToInterval` is a Float in JavaScript, if we pass it and try to convert it to Int, it crashes in C++.
exception
> libc++abi.dylib: terminating with uncaught exception of type folly::ConversionError: Loss of precision during arithmetic conversion: (long long) 1.15
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19580509
fbshipit-source-id: f705f92953195a9e034f6ce3fe7a077007d5212d
Summary:
Collecting Telemetry is a crucial part of building a performant UI framework; we do that but we need to improve it to make the data more reliable, actionable and trustful.
Now we collect time points as the number of milliseconds from the start of the CLOCK_MONOTONIC epoch. That's fine but it also has problems:
Sometimes a millisecond is an eternity. We have only 16 (or fewer) of them on each frame. What if some operation takes 1ms (according to telemetry) but we have to run it a dozen times? Does it mean that it's 12 ms in total? So, we lack precision.
This is not type-safe. Do you know how many milliseconds in a microsecond? I don't. We multiply that on magical constants hoping that we copied that from some other place right.
The current implementation is not cross-platform. We have ifdefs for iOS and Android and Unix and Windows (which is now implemented).
So, this diff replaces that with using `std::chrono` which is part of the standard library that designed to fix all those concerns. We also define our type-aliases on top of that to express our concrete constrains:
We use `std::chrono::steady_clock` as the base clock which is according to the standard using `clock_gettime(CLOCK_MONOTONIC, ... )` if available. So, it's fast and compatible (the same under the hood) with Android infra.
We use nanoseconds when we store time durations (TelemetryDuration type).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19184569
fbshipit-source-id: 7a44688f4bb3bfc6e3009874f0075c531c8569a1
Summary:
Some tests which will be useful for the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19482255
fbshipit-source-id: 3384662477f750620a37acc4a277a55c2dbd8d0e
Summary:
This is a part of migration staterted in D19390813.
There is no need to have those as `const`. The whole `*Props` object is usually `const` (and when it's not, props should not be too).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19583582
fbshipit-source-id: 9c680268f944cdf08669fce7e997b05f23a02667
Summary:
Fixes https://github.com/facebook/react-native/issues/27137
This PR fixes an issue on iOS where RCTTextView height is not calculated as it should for some fonts where font `leading` attributed is not equal to zero, which results in wrong baseline alignment behaviour.
The fix for this is by setting `usesFontLeading` property of `NSLayoutManager` to `NO`, which results is a layout behavior that is similar to `UILabel`
Probably the documentation for `usesFontLeading` describes why UILabel has a different (correct) layout behavior in that case
> // By default, a layout manager will use leading as specified by the font. However, this is not appropriate for most UI text, for which a fixed leading is usually specified by UI layout guidelines. These methods allow the use of the font's leading to be turned off.
## Changelog
[iOS] [Fixed] - Fix RCTTextView layout issue that happens on some font with `leading` attribute not equal to zero, which causes wrong base-alignment layout
Pull Request resolved: https://github.com/facebook/react-native/pull/27195
Test Plan:
Below are the test results before and after the change, and comparing that to native UILabel behavior.
The test is done with using system font and custom font (`GothamNarrow-Medium`) and font size 50
[GothamNarrow-Medium.otf.zip](https://github.com/facebook/react-native/files/3832143/GothamNarrow-Medium.otf.zip)
```js
const App: () => React$Node = () => {
return (
<View style={{flex: 1, margin: 40, flexDirection: 'row', justifyContent: 'center', alignItems: 'baseline'}}>
<View style={{width: 30, height: 30, backgroundColor: 'lightgray'}} />
<Text style={{fontSize: 50, backgroundColor: 'green', fontFamily: 'GothamNarrow-Medium'}}>{'Settings'}</Text>
</View>
);
};
```
-------
### Before the fix
<img width="962" alt="Screenshot 2019-11-11 at 16 53 26" src="https://user-images.githubusercontent.com/5355138/68601049-dd778780-04a3-11ea-879e-cc7b4eb2af95.png">
-----
### After the fix
<img width="944" alt="Screenshot 2019-11-11 at 16 55 11" src="https://user-images.githubusercontent.com/5355138/68601180-1d3e6f00-04a4-11ea-87bc-61c6fa2cdb18.png">
-----
### Using `UILabel`
<img width="805" alt="Screenshot 2019-11-11 at 16 59 28" src="https://user-images.githubusercontent.com/5355138/68601487-b2d9fe80-04a4-11ea-9a0f-c025c7753c24.png">
Differential Revision: D19576556
Pulled By: shergin
fbshipit-source-id: 4eaafdab963c3f53c461884c581e205e6426718a
Summary:
This change will keep project consistency.
This change repeat the previous commit 582738bdc8.
That was created by sammy-SC and reviewed by shergin
That changed
* `ASSERT_TRUE` -> `EXPECT_TRUE`
* `ASSERT_NEAR` -> `EXPECT_NEAR`
* `ASSERT_EQ` -> `EXPECT_EQ`
That said
> 1. Replace ASSERT_* with EXPECT_*. Assert is a fatal assertion. Expect is non-fatal assertion. So if assert fails, tests do not continue and therefore provide less information.
>
> 2. Rename tests in `RawPropsTest.cpp` from `ShadowNodeTest` to `RawPropsTest`.
>
> Source: https://github.com/google/googletest/blob/master/googletest/docs/primer.md#basic-assertions
## Changelog
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/27850
Differential Revision: D19568014
Pulled By: shergin
fbshipit-source-id: 7c22cd1c7ec919675e834a060bd5e681d43a8baf
Summary:
The reason for this change is that it is the primary root that we want people to be using and the naming should reflect that.
#nocancel
build-break
overriding_review_checks_triggers_an_audit_and_retroactive_review
Changelog: [Internal]
Oncall Short Name: fbobjc_sheriff
Differential Revision: D19431128
fbshipit-source-id: c7208e20ed0f5f5eb6c2849428c09a6d4af9b6f3
Summary:
Fix initial width measurement of AndroidTextInput.
The lifecycle here between measure and layout is a little wacky. I put this in comments too, but:
1. Measure is called first. It's marked as const so it can't call updateStateIfNeeded.
2. Layout is called immediately after. It's not const so it calls updateStateIfNeeded.
3. The state is updated, but it's not part of a commit, it just mutates the node in-place.
4. If the node isn't dirtied again, measure won't be called again.
For completeness: I did try calling `dirtyLayout` in the `layout` method. That does not work.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19549803
fbshipit-source-id: f3798e10dca2edacb364cc5b53f58f091de5e4d0
Samuel Susla
Valentin Shergin
empyrical
Joshua Gross
Christoph Purrer
Pieter De Baets
Gabriel Nunes
Emily Janzer
Ramanpreet Nara
Moti Zilberman
Pasquale Anatriello
David Vacca
Mike Vitousek
Radek Pietruszewski
Kevin Gozali
Ahmed Ibrahim
Yuki Ueda
Josh Leibsly
