Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41358
This change expose a missing function to create Header Search Paths when a podspec can't depend on another one explicitly.
This also migrate the ruby code to this new function.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51068390
fbshipit-source-id: ba9e09cd2f0671a9f3f00cc72496a0d5682eeb90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41357
This change migrate React-RCTBlob to the new add_dependency to improve its compatibility with macOS and to remove some maintenance burden.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51030365
fbshipit-source-id: c4b9037d6d0223052d659c04a1f494508944ed2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41356
React-Core does not depends on any bit of ReactCommon, React-RCTFabric or React-NativeModuleApple, so I'm cleaning that up.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51030115
fbshipit-source-id: f87dbfe99e90d52cf8c07057be22cd024e38db42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41355
This change expose a new API to react_native_pod to add dependencies that automatically configure their search paths when using frameworksa and with multiple Apple platforms.
It also migrates React-RCTAppDelegate to this new mechanism to test that it works.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51029484
fbshipit-source-id: 77dfe85419d495f7327a2f484d33f9ed8701e00d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41354
In order to make the infra scalable and avoid a maintenance nightmare for macOS and future platform, we are introducing this function that automate adding a dependency to a podspec and it generates the required search paths.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51027343
fbshipit-source-id: 33ac4c07112eacb08067220397e38db0a19240fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41353
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
In order to make the infra scalable and avoid a maintenance nightmare for macOS and future platform, we are introducing this function that should factor out the platforms from the generation of header search paths.
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51026356
fbshipit-source-id: 7cf03601d94d7680f3fdfcaf52b2fd6bcd48c5b4
Summary:
This change allow our CI to run E2E tests using a specific tag in the commit message
## Changelog:
[Internal] - Allow to run e2e test using a specific tag in the last commit message
Pull Request resolved: https://github.com/facebook/react-native/pull/41308
Test Plan:
CircleCI is green
Tested interacting with the PR/branch
Reviewed By: NickGerleman
Differential Revision: D50975588
Pulled By: cipolleschi
fbshipit-source-id: 6318800d7e86e1cab394af2b320e280304189dd2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39036
Changelog: [General][Changed] Use `hermes-parser` instead of `flow-parser` to parse Flow Codegen specs.
`hermes-parser` is a WASM build of the Hermes parser (plus supporting code), maintained by the Flow and Hermes teams. It is the recommended way of parsing Flow code in Node and its benefits (compared to `flow-parser`) include better performance and improved type safety.
Here we update `react-native/codegen` to use `hermes-parser` instead of `flow-parser`. Both parsers produce ASTs that conform to the ESTree spec so this is mostly a drop-in replacement.
In future work we should be able to use the improved AST types available in `hermes-estree` to improve type safety within `react-native/codegen` itself.
Reviewed By: huntie
Differential Revision: D48384078
fbshipit-source-id: 310ad150ec62671ba395b0e2f6415ccae97ac04d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39035
Changelog: [General][Fixed] Flow syntax errors in Codegen specs are no longer ignored.
Instead of throwing errors like most parsers, the `flow-parser` package returns errors as part of the AST (along with a best-effort parse). It turns out that `react-native/codegen` ignores such errors and only detects a subset of them after the fact. Here we change the behaviour to immediately throwing a descriptive error message (containing the file name and a code frame).
**This change is theoretically breaking** for any published packages that already contain broken Flow code (that somehow doesn't happen to affect the Codegen output today). Hopefully, anyone using Flow-flavoured RN Codegen is also typechecking with Flow and/or building with Metro (which would both flag the same errors), so the impact should be fairly contained.
Reviewed By: huntie
Differential Revision: D48385786
fbshipit-source-id: c7e1f5fb64a61fb0eb9e9f8f7501b43264c9626c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41346
X-link: https://github.com/facebook/yoga/pull/1452
This removes the last remnant from `Yoga-interna.h`, `YGNodeDellocate()`. The API is renamed to `YGNodeFinalize` to give it the explicit purpose of freeing the node from a garbage collector, and made public with that documented contract.
With that, every top-level header is now a public API, and Yoga's JNI bindings do not need to rely on private headers anymore.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D51014340
fbshipit-source-id: 553f04b62c78b76f9102cd6197146650955aeec5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41305
X-link: https://github.com/facebook/yoga/pull/1448
This should not be part of Yoga's API. If benchmarks want to do this, they still can (though I don't know the ones we have for it are super valuable).
Reviewed By: javache
Differential Revision: D50963933
fbshipit-source-id: 6482bd269928188b6469a358ffde5c4f9f5f9527
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41301
Adding the new API for creating UIManager(`FabricUIManager`) for Fabric initialization:
```
createUIManager(ReactApplicationContext reactApplicationContext)
```
and `FabricUIManagerProviderImpl()` and making it also implement the `UIManagerProvider` interface
NOTE:
Letting the older implementations in place and will be removed once the references have been removed from the apps and similarly for old constructor `FabricUIManagerProviderImpl()` and similarly for old implement relationship with `JSIModuleProvider`
Changelog:
[Internal] internal
Reviewed By: javache, philIip, mdvacca
Differential Revision: D50783295
fbshipit-source-id: 767f27c7f0d42840a5dad693e98cf5b6a243f933
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41296
As part of adding new implementation for `FabricUIManagerProviderImpl` APIs renaming the old class `FabricJSIModuleProvider` -> `FabricUIManagerProviderImpl` so as to add the new APIs later and preserve history.
Changelog:
[Internal] internal
Reviewed By: philIip
Differential Revision: D50949208
fbshipit-source-id: b833c4783b383c175fa682c558d31d8ecfa9f0ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41364
Initializing UndefinedColor on iOS and Android is trivial because the platform color is an int32_t. On platforms where the HostPlatformColor header defines a color as a struct (e.g., Windows) it is less trivial to compose a constexpr for the undefined color representation to initialize this static const value with.
As it turns out, UndefinedColor is only used for operator bool in SharedColor, so it's reasonably safe to remove this "public" API (also good to limit the surface of SharedColor).
## Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D51073395
fbshipit-source-id: 375e43aa9a30d394d35ce2946224563738d8973c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41330
D41564032 made `console.log` (as well as `debug` and `info`) a noop in tests within the React Native repo. Here we allow them through while still throwing errors on `console.error` and `console.warn`.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51002264
fbshipit-source-id: 44ca8bef38695dd76fe509341adced887bef2e6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41293
X-link: https://github.com/facebook/yoga/pull/1446
NickGerleman pointed out that my recent changes to fix the slew of row-reverse problems in Yoga actually ended up regressing some parts. Specifically, absolute children of row-reverse containers would have their insets set to the wrong side. So if you set left: 10 it would apply it to the right.
Turns out, in `layoutAbsoluteChild` there were cases where we were applying inlineStart/End values to the flexStart/End edge, which can never be right. So I changed the values to also be flexStart/End as the fix here.
Reviewed By: NickGerleman
Differential Revision: D50945475
fbshipit-source-id: 290de06dcc04e8e644a3a32c127af12fdabb2f75
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41209
X-link: https://github.com/facebook/yoga/pull/1439
There are so many instances in this code base where we use the double negative of `!yoga::isUndefined(<something>)`. This is not as easy to read since because of this double negative imo. Additionally, sometimes we have really long chains like `!longVariableName.longFunctionName(longArgumentName).isUndefined()` and it is hard to see that this undefined is inverted.
This just replaces all instances of inverted `isUndefined()` with `isDefined()` so its easier to read.
Reviewed By: NickGerleman
Differential Revision: D50705523
fbshipit-source-id: edc7d3f2cbbae38ddaeb2030a419320caf73feff
Summary:
X-link: https://github.com/facebook/yoga/pull/1437
Pull Request resolved: https://github.com/facebook/react-native/pull/41208
Reading through the sizing logic and this seemed a bit redundant/confusing. Lets use the same function we just used for the main axis for the cross axis as well so people do not think its special. Also we will need one less variable. The reason this was done it seems is because we need the leading padding + border elsewhere so this is technically a few less steps but this is cleaner
Reviewed By: NickGerleman
Differential Revision: D50704177
fbshipit-source-id: 1a091edbfee6482a2bf472aca2980702bd75ad94
Summary:
When bridgeless is enabled, RN Tester New Architecture examples crashed with a StackOverflow Exception
The root cause of this issue is that MyLegacyViewManager is sending an event to JS during the execution of MyLegacyViewManager.createViewInstance() method.
This is a problem because the delivery of events depend on the "id" of the view, but the "id" of the view is set after MyLegacyViewManager.createViewInstance() finishes executing.
The documentations "implicitly" mentions to not set props during the execution of the ViewManager.createViewInstance() method:
https://reactnative.dev/docs/native-components-android#2-implement-method-createviewinstance
To fix this issue I'm removing the execution of the method that triggers the event.
bypass-github-export-checks
changelog: [Android][Fix] Fix rendering of 'RN Tester New Architecture examples' when bridgeless is enabled
Reviewed By: fkgozali
Differential Revision: D51047007
fbshipit-source-id: 17be493f79114fa402029063e79fabc1d90efc17
Summary:
`Activity` is the current candidate name. This PR starts the rename work
by renaming the exported unstable component name.
NOTE: downstream consumers need to rename the import when updating to
this commit.
DiffTrain build for commit https://github.com/facebook/react/commit/ce2bc58a9f6f3b0bfc8c738a0d8e2a5f3a332ff5.
Reviewed By: tyao1
Differential Revision: D50945046
Pulled By: kassens
fbshipit-source-id: be9b3254c7a98840b0769135770e9bf7858cf1a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41345
## Changelog:
[Internal] -
This API was already accessible on the Android platform, now other platforms (C++) would benefit from having it available as well.
Arguably, it's perfectly fine to have it as public class members - based on empiric experience with the use case we have had.
Reviewed By: christophpurrer
Differential Revision: D51031340
fbshipit-source-id: 0426deede5d9e5c552c92f8a25d30fe2274a1941
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41333
Enables the `sort-imports` lint rule introduced in D39907799 in ~all files, rather than just in `react-native/Libraries`.
We exclude only `packages/react-native/template`, in order to (1) minimise noise for projects that are tracking updates to the template, (2) avoid the possibility of something breaking if the `react-native` import isn't at the top of `template/index.js`, (3) avoid leaking a reference to `lint/sort-imports` to the template (which doesn't ship with this rule) via an ESLint suppression comment.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D51025811
fbshipit-source-id: a62b0d6ebc5323116a4b2f1b69c4e8d48cde3215
Summary:
Though not currently in use in the RN code, when `react-native-windows` tried to integrate changes up to 7/28/23 (see PR https://github.com/microsoft/react-native-windows/pull/11970) there happened to be a `??=` operator in the `virtualized-lists` package (see [diff here](https://github.com/facebook/react-native/compare/ccc50ddd2...c168a4f88#diff-abeff2daf5909e54a23562e43569de1d5b8db1d7170119eed485b618cdf04ec7R322)). (The offending line was removed in a later commit).
The default RNW engine is still Chakra and it couldn't handle the syntax. It looks like the `babel/plugin-proposal-nullish-coalescing-operator` plugin only handles `??`, so to handle `??=` I've added `babel/plugin-proposal-logical-assignment-operators`, which also happens to handle the logical assignment operators `||=` and `&&=`.
Closes https://github.com/facebook/react-native/issues/31704
## Changelog:
[GENERAL] [FIXED] - Add detection of logical assignment operators to `react-native-babel-preset`
Pull Request resolved: https://github.com/facebook/react-native/pull/39186
Test Plan: We started using these plugins in RNW's babel config to resolve the issue in our integrate PR.
Reviewed By: motiz88
Differential Revision: D50936554
Pulled By: rozele
fbshipit-source-id: 0a924b6085524d8c9551a158b91195b1f7448c19
Summary:
Last week, I modified the e2e script to make sure it was working properly with 0.73.
This change backport those changes in main
## Changelog:
[Internal] - Backport e2e script changes
Pull Request resolved: https://github.com/facebook/react-native/pull/41332
Test Plan: Tested locally
Reviewed By: dmytrorykun
Differential Revision: D51025796
Pulled By: cipolleschi
fbshipit-source-id: 89ecd3701eaac4ba4bdde2c640df45a158329158
Summary:
This PR fixes a small typo in `build-ios-framework.sh`
## Changelog:
[INTERNAL] [FIXED] - Typo in `build-ios-framework.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/41325
Test Plan: Check if correct error message is printed out
Reviewed By: dmytrorykun
Differential Revision: D51022361
Pulled By: cipolleschi
fbshipit-source-id: 93c3e85eff8e410bcb18302dcb3ac76583d6e304
Summary:
zfrankdesign reported that in RN 0.72.6, they receive warnings that some new props listed in the documents are missing:
View tabIndex https://reactnative.dev/docs/view#tabindex-android and Text userSelect https://reactnative.dev/docs/text#userselect. It seems the components accept these props but they were not typed.
## Changelog:
[GENERAL] [FIXED] - Missing typings for the props `tabIndex` for **View** and `userSelect` in the **Text** props were added.
Pull Request resolved: https://github.com/facebook/react-native/pull/41312
Test Plan:
1. Instantiate a component of type View
1.1. Should add the property tabIndex to the View component.
1.2. Should not see a warning about the missing tabIndex property.
2. Instantiate a component of type Text
2.1. Should add the property userSelect to the Text component.
2.2. Should not see a warning about the missing userSelect property.
Reviewed By: NickGerleman
Differential Revision: D50982156
Pulled By: lunaleaps
fbshipit-source-id: 75b55cfb897738be0cf426912a7c10c7412d5032
Summary:
Closes https://github.com/facebook/react-native/issues/41236
`setState` is not working properly for text inline image
## Fixed demo (please see the animation as in rendering pass rather than re-mounting pass)
https://github.com/facebook/react-native/assets/149237137/d4b894bf-2283-4963-8dc7-b8f5a9f81315
## How it works
**Background**
Inline views are not included in the Yoga node tree, rather, they are retained as attachments of `NSAttributedString` and are managed by the respective text fragment (`RCTTextShadowView`) that includes them (Code snippet 1).
```
<div layout="width: 393; height: 852; top: 0; left: 0;" style="" >
<div layout="width: 393; height: 852; top: 0; left: 0;" style="flex: 1; " >
<div layout="width: 393; height: 852; top: 0; left: 0;" style="flex: 1; " >
<div layout="width: 393; height: 241; top: 0; left: 0;" style="padding-top: 59px; " >
<div layout="width: 393; height: 50; top: 59; left: 0;" style="width: 100%; height: 50px; " >
<div layout="width: 393; height: 17.3333; top: 0; left: 0;" style="" has-custom-measure="true"></div>
</div>
<div layout="width: 393; height: 50; top: 109; left: 0;" style="width: 100%; height: 50px; " >
<div layout="width: 393; height: 17.3333; top: 0; left: 0;" style="" has-custom-measure="true"></div>
</div>
/* Text node that does not contain inline view that is supposed to be there */
<div layout="width: 393; height: 74.3333; top: 167; left: 0;" style="margin-top: 8px; " has-custom-measure="true"></div>
</div>
</div>
</div>
</div>
```
**Code snippet 1, output of YGNodePrint() in _normal layout_ flow**
The layout of such node is handled ad-hoc (_inline layout_) inside `RCTTextShadowView` (Code snippet 2)
```
/* Inline node is calculated on its own */
<div layout="width: 48; height: 48; top: 0; left: 0;" style="overflow: hidden; width: 48px; height: 48px; min-width: 0px; min-height: 0px; " ></div>
```
**Code snippet 2, output of YGNodePrint() in _inline layout_ flow**
**Problem description**
The issue happens when the sizes given by `setState()` are smaller than those in the last round `setState()`. Since the `min-width` and `min-height` are already populated (Code snippet 3) with greater values, the new layout pass gives rather a `noop`.
```
/* min sizes are greater than them in the new style */
<div layout="width: 48; height: 48; top: 0; left: 0;" style="overflow: hidden; width: 32px; height: 32px; min-width: 48px; min-height: 48px; " ></div>
```
**Code snippet 3, output of YGNodePrint() in _inline layout (issue)_ flow**
**Fix description**
This biased `min-width` and `min-height` are given using the **current frame size** (i.e., sizes set in the last round `setState()`) in the _inline layout_ (in `RCTTextShadowView` § Background), whilst the same parameters are given as ~~CGSizeZero~~ `_minimumSize` in _normal layout_ (§ Background).
The change of this PR is to unify this behavior of _normal layout_ by using ~~CGSizeZero~~ `_minimumSize` as the input also for _inline layout_.
## Changelog:
[IOS] [FIXED] - `setState` is not working properly for text inline image
Pull Request resolved: https://github.com/facebook/react-native/pull/41287
Test Plan:
- Using **rn-tester** for basic verification
- Complete plan: https://docs.google.com/spreadsheets/d/1QLuqNvqX0dM4K68ygRoHDR3S0wcK5umptmjoR7KtkaY/edit?usp=sharing
Reviewed By: cipolleschi
Differential Revision: D50967547
Pulled By: NickGerleman
fbshipit-source-id: b3b6d6919fd9d3302977dc771a41c22f7b796ba5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41309
Changelog: [Internal][Removed] CxxModuleWrapper.makeDSO is not actively used and has been replaced by TurboModule infra.
Reviewed By: NickGerleman
Differential Revision: D50878589
fbshipit-source-id: 9fd11c1ee860ea65f1e985a132de3216ed042752
Summary:
We're logging a systrace section that for some reason is breaking the data in application traces. That section isn't especially relevant so we can just remove it.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50939346
fbshipit-source-id: 350a528d83c6fe6e7100275644d3d02a96700e59
Summary:
This PR updates the internal version of cocoapods to 1.13, template already uses this version. I've also removed the root folder Gemfile as it's not necessary anymore.
## Changelog:
[INTERNAL] [CHANGED] - Update RNTester Cocoapods to 1.13
Pull Request resolved: https://github.com/facebook/react-native/pull/41248
Test Plan:
Check if cocoapods installs correctly by running:
1. `bundle install`
2. `bundle exec pod install`
Reviewed By: dmytrorykun
Differential Revision: D50972135
Pulled By: cipolleschi
fbshipit-source-id: b7d6a4671e641b7b8f50242a3374f623e023daf4
Summary:
This is not supported by any native implementation.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D50641812
fbshipit-source-id: e90a1998d2239b6f96c0c4db7b112f7e75cfc6dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41299
## Changelog:
It makes sense to keep Web Performance logging mechanism separate from the GlobalPerformanceLogger, removing.
Reviewed By: rubennorte
Differential Revision: D50930312
fbshipit-source-id: 3b76ff28eae8c5a2bf41faceb33cf188d8318610
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41294
Changelog: [Internal]
i believe this warning is outdated, i don't think having a custom initializer or exporting constants means that your module needs to be setup on main.
Reviewed By: cipolleschi
Differential Revision: D50919152
fbshipit-source-id: dc91af5fc88eca4f07a5f35adb888160b978cc38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41295
Changelog: [Internal]
modules will be setup on main queue for any the following criteria:
- override requiresMainQueueSetup and set it to yes
- have a method that starts with `init`
- have `constantsToExport` implemented
these methods return `NO` but don't fulfill the latter criteria, so we should just delete them
Reviewed By: cipolleschi
Differential Revision: D50919151
fbshipit-source-id: 662bd067a1bae0f81acfabfc95b2a2af0c0a3180
Summary:
## Changelog:
[Internal] -
There is no need for this feature flag anymore, cleaning up.
Reviewed By: rubennorte
Differential Revision: D50925309
fbshipit-source-id: 39ff3d1f85c1df5ba2be287d4b7df2a4222acdba
Riccardo Cipolleschi
Riccardo Cipolleschi
Moti Zilberman
Nick Gerleman
Luna Wei
Arushi Kesarwani
Eric Rozell
Joe Vilches
David Vacca
kassens (Meta Employee)
Alex Zelensky
Ruslan Shestopalyuk
George Zahariev
Jon Thysell (JAUNTY)
Oskar Kwaśniewski
szymonrybczak
Jorge Luis Calleja Alvarado
ehsemloh
Sam Zhou
Pieter De Baets
Samuel Susla
Rubén Norte
Phillip Pan
Rick