Summary:
ViewManagers are all BaseJavaModule, and thus have access to methods like `getReactApplicationContext`. We don't expose the appropriate constructors though to pass this context down from the base class.
Not a breaking change, as the no-arg constructor is still used implicitly.
Changelog: [Android][Fixed] ViewManagers can pass context to their base class.
Reviewed By: fabriziocucci
Differential Revision: D56804318
fbshipit-source-id: b0e6b15dfd7786073da058beccfaba2ff30daf5a
Summary:
In a future release of React Native, string refs will no longer be supported. This increases the severity of the `no-string-refs` lint rule to convey this.
Changelog:
[General][Changed] - `no-string-refs` is now a lint error
Reviewed By: kassens
Differential Revision: D56826663
fbshipit-source-id: 603f5b205bb9fd8a5dcb8ee917f6a2ba1ac47e6e
Summary:
Changelog: [Internal]
Updates the doc comment on `Function::createFromHostFunction` to
mention that (a copy of) the provided `std::function` may be destroyed
on an arbitrary thread, much like `HostObject` (where this is already
documented).
Reviewed By: neildhar
Differential Revision: D56628194
fbshipit-source-id: 1939602135e83a9c36896c395816054376026edc
Summary:
This change removes a couple of method from RCTHost which were not following the iOS convention for names.
We deprecated them in 0.74 and now that the branch is cut, we can remove them.
## Changelog:
[iOS][Breaking] - Remove `getSurfacePresenter` and `getModuleRegistry` from RCTHost
Reviewed By: sammy-SC
Differential Revision: D56633554
fbshipit-source-id: 88fd1525bfe68ca1f6c2d8403d0dec505a23e9f8
Summary:
We [received an issue](https://github.com/react-native-maps/react-native-maps/issues/5042) in OSS where a ViewManager was configured to be initialized on the main queue, but it wasn't.
This was creating a soft crash and showing a RedBox to the user.
The library was going through the Interop Layer.
This change makes sure that, if the ViewManager is configured to be setup in the main queue, we retrieve the constants from the Main Queue
## Changelog
[iOS][Fixed] - Extract the constants from ViewManagers in the UI Thread if needed.
Reviewed By: sammy-SC
Differential Revision: D56762253
fbshipit-source-id: ca807b34d6e61418da9fd6a639a05f3394879f7c
Summary:
Changelog: [internal]
Migrating this feature flag (which is currently unused) to the new system, so we can test it in production and ship it soon.
Reviewed By: NickGerleman
Differential Revision: D56766553
fbshipit-source-id: 42d44cdd163568564e789cdffe1683e78fe91b53
Summary:
This work is based on Ruslan's https://www.internalfb.com/intern/diff/D56185630/
Changelog: [Internal]
`Expectation`: In React DevTools, user should be able to select an element on screen and it will show you what React component rendered it. This doesn't work in RN app that is using JS navigation
`Root Cause`:
In Fabric, when we try to find `ShadowNode` in the `ShadowTree`, `pointerEvents` props are not considered during the lookup of node using coordinate. Hence, in React DevTools when we inspect element, it was hightlighting the overlay `View` with `pointerEvents` props `box-none` was getting highlighted instead of its children view in the hierarchy.
Reviewed By: javache
Differential Revision: D56334314
fbshipit-source-id: ebfe58c5a1516add347c2c21ab5d075f804df8a9
Summary:
This removes the bulk of code added in https://github.com/facebook/react-native/pull/39630.
We're not shipping it, as it caused performance regressions.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D56796936
fbshipit-source-id: 82f3a51cf145bc1695d70393e1f050685a1e6174
Summary:
Changelog: [General][BREAKING] Don't support 'float' enums in Turbo Modules
- The current implementation of 'float enums' in C++ does not work as invalid results are returned.
- At potential fix could still cause rounding errors when crossing language bounaries, e.g. `4.6` can become `4.5599999942..`
- C++ enum classes don't support float: https://eel.is/c++draft/dcl.enum#2.sentence-4
> The type-specifier-seq of an enum-base shall name an integral type; any cv-qualification is ignored.
Hence removing the feature of `float enums` for now
Reviewed By: NickGerleman
Differential Revision: D52120405
fbshipit-source-id: 3685ad0629e16ff9db424ba67e07d09df6027553
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44294
**Problem:**
It was discovered while testing 3 party library, generated member variables in a C++ `struct` in `Props.h` is not initialized.
Also `WithDefault` would not work as well.
(For the problematic case it was a `boolean` but would also apply to other primitive types.)
If there is no default initialization and the component prop is optional and the user of the native component does not set the prop then the variable is never initialized and this is problematic for primitive types in C++ where no initialization results in an undefined behavior.
**Proposed solution:**
(Following C++Core Guideline of [always initialize](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-always).)
Reusing `generatePropsString()` used by `ClassTemplate` to generate props for `StructTemplate` as well.
updated relevant test snapshots.
This change is only concerning the `Props.h` file.
**Changelog:**
[General][Fixed] - fixed `Props.h` created from codegen missing default initializers in C++ `struct`
Reviewed By: cipolleschi
Differential Revision: D56659457
fbshipit-source-id: 0d21ad20c0491a7e8bb718cd3156da65def72f23
Summary:
As of now, Apple does not respect privacy manifests added as cocoapods resource bundles. This forces react-native developers to manually copy `.xcprivacy` files content for each native dependency that accesses restricted reason APIs to the root file.
This PR adds an aggregation step that crawls through pod dependencies to collect all reasons into the root privacy info file.
## Changelog:
[IOS][ADDED] – Add privacy manifest aggregation.
Pull Request resolved: https://github.com/facebook/react-native/pull/44214
Test Plan:
When run on RNTester, it appends aggregated entries (while keeping existing ones) to existing .xcprivacy file without modifing .pbxproj:
When run on RNTester with the xcprivacy file removed from xcode beforehand, it creates a new .xcprivacy file, and adds it to Compile Bundle Resources in the same way as in the new template:
When run on RNTester with an empty .xcprivacy file, it appends aggregated entries from pods AND reasons for react-native core.
When run with `privacy_file_aggregation_enabled: false` in `use_react_native`, it falls back to existing behavior:
Reviewed By: cipolleschi
Differential Revision: D56481045
Pulled By: philIip
fbshipit-source-id: 1841bad821511c734d0cc0fcff5065ed92af76d8
Summary:
This enables to code-gen base C++ types for custom exported JS types from a RN TM spec - which have been previously excluded from code-gen as these aren't used in any function.
The only work around so far was to ‘register’ a random function using the custom type which should be used for RCTDeviceEventEmitter events
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D56685903
fbshipit-source-id: add9ca40018b91c9fca98609ba3d1f85d3affec1
Summary:
Changelog: [internal]
`LazyShadowTreeRevisionConsistencyManager` wasn't correctly updating the locked revision, because `emplace` is a no-op if there's already a value for the key in the `unordered_map`.
This fixes the issue and adds tests that actually showed it.
Reviewed By: sammy-SC
Differential Revision: D56761941
fbshipit-source-id: 340e9195b14460a591c48186bd365688c74ade04
Summary:
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Changelog: [Internal] Generated changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/44333
Reviewed By: cortinico
Differential Revision: D56756077
Pulled By: cipolleschi
fbshipit-source-id: 4e8d2f6b83499bd89d6a60de4eede385b7a8ac3c
Summary:
`RCTComposedViewRegistry` extends `NSMutableDictionary` which is a clustered class in iOS.
NSMutableDictionary is techncially an abstract class, but when instantiated by `[NSMutableDictionary new];` the system will return one of concrete classes that inherit from `NSMutableDictionary`, opaquely from the perspective of the caller.
By calling `super`, we are actually calling the not implemented method for the abstract class. If this happen, this can crash the app.
Given that the `RCTComposedViewRegistry` is extending the dictionary only for its interface but is using other mechanisms as storage, is it fair to return `NULL`if the storages don't have the requested view.
## Changelog
[iOS][Fixed] - Avoid calling abstract methods in RCTComposedViewRegistry
Reviewed By: cortinico
Differential Revision: D56755427
fbshipit-source-id: f5c56dc59ccc6b30c00199b4196c42eb9b021e2b
Summary:
I accidentally broke build_android.
Here the two fixes:
1. Make sure the constructor of PackageList2 are actually called `PackageList2`
2. Make sure the package of `OSSLibraryExamplePackage` is `com.facebook.react.osslibraryexample`
Changelog:
[Internal] [Changed] - Fix accidentally broken build_android job
Reviewed By: dmytrorykun
Differential Revision: D56756601
fbshipit-source-id: 862597ca829d702d880624d29276193f8548715d
Summary:
Changelog: [Internal]
The bodies of all `console` methods are currently written as lambdas within `installConsoleHandler` but actually capture nothing meaningful from that scope. This diff rewrites them as free functions instead.
To enable the "forwarding console methods" to be written as free functions, we also replace the runtime loop over `kForwardingConsoleMethods` with a compile-time equivalent using macros. (This technique is inspired by the Hermes source code, which uses it heavily for compile-time code generation.)
Reviewed By: huntie
Differential Revision: D56679956
fbshipit-source-id: babf368ecacb9dc426b2356a4a2091881ca1023e
Summary:
Changelog: [Internal]
Switches to constrained `auto` instead of `std::function` to represent intermediate function types in `RuntimeTargetConsole::installConsoleHandler`. This removes some indirection and potential runtime overhead.
Reviewed By: huntie
Differential Revision: D56675188
fbshipit-source-id: 76cbf8b8be9ca1a9466efbcd187bddd60c921019
Summary:
Changelog: [internal]
This migrates all the classes related to performance in `react-native/src/private` to use private fields instead of regular fields prefixed with `_`.
Reviewed By: yungsters
Differential Revision: D55931659
fbshipit-source-id: e8b2018048dbb6c8d6e8a4d143357bf2ac39dd1e
Summary:
Changelog: [internal]
Quick refactor to use private fields instead of fields with a naming convention, in classes in `react-native/src/private`.
Reviewed By: yungsters
Differential Revision: D56700382
fbshipit-source-id: ee0a7b30a9da20c31b92878be3316227b2d0a0c4
Summary:
Adds changelog for the 0.73.8 patch.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Add 0.73.8 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/44331
Reviewed By: cortinico
Differential Revision: D56753881
Pulled By: cipolleschi
fbshipit-source-id: eed053cd39a768d6acb40a037a4218ee5e1fbbf8
Summary:
Changelog: [internal]
We have a comment explaining how to update all generated files everywhere but here.
Reviewed By: NickGerleman
Differential Revision: D56717344
fbshipit-source-id: cc538e37dd6ab09f67d67bb13ce4e560870d44d0
Summary:
This diff is part of RFC0759
https://github.com/react-native-community/discussions-and-proposals/pull/759
Here I'm creating data classes that will allow us to parse the `config` JSON output.
Code is pretty straightforward and follows the structure as the `config` command output.
Changelog:
[Internal] [Changed] - RNGP - Autolinking - Add model classes for parsing the `config` output
Reviewed By: cipolleschi, blakef
Differential Revision: D55475595
fbshipit-source-id: 3457c008ff0c5bce2b47fd637c7b10a5e7427c01
Summary:
This diff is part of RFC0759
https://github.com/react-native-community/discussions-and-proposals/pull/759
Here I'm creating the `runAutolinkingConfig` task.
This task is responsible of either:
- Invoking the `npx react-native-community/cli config` command (or the one specified by the user)
- Copying the config output file specified by the user (if any).
The task re-executes only if any of the lockfile are actually changed otherwise it just returns as "UP-TO-DATE"
This allows us to
Changelog:
[Internal] [Changed] - RNGP - Setup the RunAutolinkingConfigTask to run the config command
Reviewed By: cipolleschi, blakef
Differential Revision: D55475596
fbshipit-source-id: 3c687f965c59eb82fc447546ebd936ba401f34f2
Summary:
Hermes' ConsoleMessage constructor now accepts StackTrace, so the construction can be done in one go.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D56738060
fbshipit-source-id: 709b47d8f9cf69994e4c5eaa4f9310e70a4d9ed0
Summary:
## Changelog:
[Internal]-
Even though `TextInput.autoCapitalize` is supposed to be cross-platform, on the C++ side of the props data structures it was only exposed as an Android-specific one.
This would have it still work on the iOS side (as the corresponding prop is passed to Objective C around the C++ structs anyway), however it may also cause subtle scenarios, whereas the prop changes dynamically on the iOS side, but this doesn't get reflected on the native side.
This change fixes this problem by simply hoisting the prop into the `BaseTextInputProps`, which makes it available across all platforms, as it should be.
Differential Revision: D56726940
fbshipit-source-id: 9ba18f1f92095874e07207650b46655c331f3e91
Summary:
RuntimeAdapter.h is only needed when using CDPHandler, which the new code path doesn't need.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D56738299
fbshipit-source-id: 8cb512a3dc8dc303851871021e04aab94aa25d1e
Summary:
`Response` is `Closeable`, so we must close it even if the download is no longer relevant. Found while running with StrictMode enabled and reloading quickly multiple times.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56629079
fbshipit-source-id: 041bf295313cbf78b7f2bb6580c50fdc2a324728
Summary: Changelog: [General][Removed] `launchId` query param for `/debugger-frontend` is no longer generated automatically for each `/open-debugger` call. Caller of `/open-debugger` is now responsible for generating the `launchId`, which will be passed along to `/debugger-frontend`.
Reviewed By: robhogan
Differential Revision: D55164645
fbshipit-source-id: b83303eda77b6fb86ebf50f699d9f308676533c6
Summary:
Supports the removal of Flipper from the template in 0.74, paried with additional blog post messaging: https://reactnative.dev/blog/2024/04/22/release-0.74#removal-of-flipper-react-native-plugin.
Changelog:
[General][Changed] - Update "Open Debugger" action to print extended Flipper guidance
Reviewed By: cipolleschi
Differential Revision: D56705236
fbshipit-source-id: d7e869625262ebb02bc2454c924f832cccfbcd31
Summary:
Just a minor fix to fix a missing space in the debug message.
Fixes a missing space in the message
```
Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'MmkvPlatformContext' could not be found. Verify that a module by this name is registered in the native binary.Bridgeless mode: false. TurboModule interop: false. Modules loaded: {"NativeModules":["PlatformConstants","LogBox","Timing","AppState","SourceCode","BlobModule","WebSocketModule","SettingsManager","DevSettings","RedBox","Networking","Appearance","DevLoadingView","UIManager","DeviceInfo","ImageLoader","LinkingManager"],"TurboModules":[],"NotFound":["NativePerformanceCxx","NativePerformanceObserverCxx","BugReporting","HeadlessJsTaskSupport","SoundManager","IntentAndroid","MmkvPlatformContext","MmkvCxx"]}
```
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - Fixed missing space in TurboModule.getEnforcing error message
Pull Request resolved: https://github.com/facebook/react-native/pull/44311
Reviewed By: christophpurrer
Differential Revision: D56702036
Pulled By: rshest
fbshipit-source-id: e339a6ee8c265b2c6d27184e8e9941f3f02e3c85
Summary:
## Changelog:
[Internal] -
I was looking at the logs, troubleshooting a non-dev build issue, and noticed a line:
```
I0429 15:56:42.107558 1874554880: Running "MyApplication
```
In `__DEV__` mode this usually continues with `" with ...`, but in release mode the closing quote was missing, which made me think there may be something going on garbling the log messages.
Which ultimately was a red herring, and it's just a bad formatting in the message in release mode, which this change fixes.
Reviewed By: zeyap
Differential Revision: D56704170
fbshipit-source-id: a28604fffec6be74733c8759f59ee52a67a81746
Summary:
Changelog: [Internal]
Fixes a crash that may happen on Android when the `inspectorEnableModernCDPRegistry` feature flag is true, and clarifies the documentation of `HostTarget::create()` to avoid similar issues in future integrations.
## Context
The executor provided to `HostTarget::create()` ("the inspector executor") is used throughout the CDP backend to schedule work on the inspector thread. (See also D53356953.) To facilitate this, the executor is a copyable `std::function`.
On Android, the executor is backed by a Java object, to which we hold a reference from C++ using JNI. This reference is expressed as a `facebook::jni::global_ref` which gets copied as part of the executor. (`global_ref` is a RAII wrapper around the `NewGlobalRef` / `DeleteGlobalRef` JNI functions.)
## The bug
All the *calls* to the inspector executor from C++ happen on threads that are already properly [attached to the JVM](https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#attaching_to_the_vm) ( = the UI thread / the JS thread) and are therefore allowed to make JNI calls. However, there are cases where a copy of the inspector executor may have its *destructor* run on an unexpected thread, namely the (Hermes) JS GC thread. (This happens when the executor itself is captured in a lambda that's stored in a `jsi::HostObject` or `jsi::HostFunction`, which is in turn [destroyed on the JS GC thread](https://github.com/facebook/react-native/blob/5a0ae6e2d9d7f2357f9ea6c5dc1d573233075326/packages/react-native/ReactCommon/jsi/jsi/jsi.h#L118-L126).) In such cases, the `DeleteGlobalRef` call mentioned above will crash, because the JS GC thread is not attached to the JVM.
## The fix
First, we document that copies of the inspector executor provided to `HostTarget::create` may indeed be destroyed on arbitrary threads. This is an unavoidable consequence of the existing design. Second, we adapt the Android integration to this requirement.
`fbjni` provides the [`jni::ThreadScope`](https://github.com/facebookincubator/fbjni/blob/968e3815f92aeb0670f5d88ae975fbbd47a4b482/cxx/fbjni/detail/Environment.h#L93-L123) RAII helper to manage attaching C++ threads to the JVM. If we had any explicit control over the setup and teardown of the JS GC thread, we could create a single `jni::ThreadScope` to globally ensure the safety of JS-finalizer-to-JNI calls in React Native. However, neither JSI nor the Hermes API provides such control.
Instead, we essentially resort to creating a temporary `ThreadScope` around each `DeleteGlobalRef` call where we don't control the calling thread. We do this using a new kind of JNI reference wrapper class called `SafeReleaseJniRef`. Retaining a `SafeReleaseJniRef` instead of a plain `global_ref` is all that's needed to make a particular reference safe to destroy on any thread.
Reviewed By: huntie
Differential Revision: D56620131
fbshipit-source-id: 0b6f32a7bd6477d0384af19c42e21d9242ce623d
Summary:
This gives Frameworks more control in selecting specific tasks and integrating the return types data in their UI. For example piping `stdout` to the user or using packages like [Listr2](https://www.npmjs.com/package/listr2) to run tasks in parallel and show progress.
The ordering is suggestive (but also enforced by some assertions). Frameworks are free to do what they want.
The order was implicit in the previous data structure with lists of Tasks, but made it difficult to tap into each async task.
I've also had to rework how we transpile the code if directly executed from the monorepo. This keeps our:
- flow types valid,
- allows the core-cli-utils package to be built (to generate TypeScript types and a valid npm module), and
- allows direct transpiled execution as a yarn script.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D56242487
fbshipit-source-id: a1a18f14a4aef53a98770462c8ebdef4111f0ab4
Summary:
Changelog: [Internal]
In the new CDP backend, calling any `console` method a second time involves a call to a moved-from `std::function`. This shouldn't work, and indeed results in an exception on some platforms, but isn't strictly an error according to the C++ standard: moving from a `std::function` leaves it in an [unspecified state](https://en.cppreference.com/w/cpp/utility/functional/function/function#:~:text=the%20call%20too.-,other,is%20in%20a%20valid%20but%20unspecified%20state%20right%20after%20the%20call.,-5), not necessarily an empty state, so (in particular) it's perfectly legal for the implementation to perform a copy instead of a move and leave the original variable intact.
(See [Compiler Explorer](https://godbolt.org/z/qoo5Mnd68) for proof that libc++ and libstdc++ differ on this - the former performs a copy, while the latter actually performs a move, resulting in a `std::bad_function_call` exception later.)
In the code in question, we're right to want to avoid a copy of the `body` function into the argument of `delegateExecutorSync` - only one copy of this function needs to exist at a time. But the correct way to avoid this copy is to capture `body` by reference, as we can do that repeatedly with no ill effects. (`delegateExecutorSync` is, as its name suggests, synchronous, so there are no lifetime issues.) Doing this also allows us to remove the use of `mutable` so the capturing is by *const* reference.
Reviewed By: sammy-SC
Differential Revision: D56673529
fbshipit-source-id: b235977b2fbc889462c4c78adfe41ae6f509e349
Summary:
changelog: [internal]
force_static doesn't need to be in here, let's remove it.
I change one module per diff. It makes it easier to land it and pinpoint where build failures are coming from.
Reviewed By: christophpurrer
Differential Revision: D56678530
fbshipit-source-id: c602e065d77fdd649c66ce2d26eee83428ef5ba8
Summary:
Resolved Pull request: https://github.com/facebook/react-native/pull/44296
changelog: [internal]
force_static doesn't need to be in here, let's remove it.
I change one module per diff. It makes it easier to land it and pinpoint where build failures are coming from.
Reviewed By: javache
Differential Revision: D56632286
fbshipit-source-id: e942603d3c69d9eebf4d3b64e2f73ee6a5df6de4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44295
changelog: [internal]
mapbuffer is only used on Android. Let's remove the option to have it compile on iOS.
Reviewed By: NickGerleman
Differential Revision: D56635289
fbshipit-source-id: 1a57c271d21b8aef81179d96b1a6832e7615dd27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44283
changelog: [internal]
force_static doesn't need to be in here, let's remove it.
I change one module per diff. It makes it easier to land it and pinpoint where build failures are coming from.
Reviewed By: christophpurrer
Differential Revision: D56630625
fbshipit-source-id: 069587893dbb8866d1a08de256b4612d60bcc3b8
Summary:
changelog: [Android][Fixed] - fix a crash in Modal component
Instance variable `propertyRequiresNewDialog` in `ReactModalHostView` controls if new dialog will be created on next `showOrUpdate` or not. It must be kept in sync with `dialog` ivar.
if `dismiss` is ever called from anywhere but `showOrUpdate`, the class gets into a state where the next `showOrUpdate` call will throw an error because dialog is set to null but `propertyRequiresNewDialog` stays false.
`dismiss` is called from three places: `showOrUpdate` (this is ok), `onDropInstance()` and `onDetachedFromWindow`.
The fix in this diff is to make sure propertyRequiresNewDialog is set to true when dialog is dismissed.
Reviewed By: alanleedev
Differential Revision: D56627522
fbshipit-source-id: e7a16cd022401a7a4a0fbf8fc71a2312d05fcb8e
Kudo Chien
Pieter De Baets
Tim Yung
Moti Zilberman
Samuel Susla
Riccardo Cipolleschi
Rubén Norte
Gijs Weterings
Soe Lynn
Nick Gerleman
Christoph Purrer
Jakub Piasecki
Alan Lee
aleqsio
hurali97
Nicola Corti
Thibault Malbranche
Danny Su
Ruslan Shestopalyuk
Edmond Chui
Nick Vlug
Alex Hunt
Marc Rousavy
Blake Friedman