Summary:
Add diffing to app bundle size reports.
## Changelog
[Internal] [Changed] - Add diffing to app bundle size reports
Pull Request resolved: https://github.com/facebook/react-native/pull/28284
Test Plan:
- App bundle size reports should now display a diff where available
- Right now, the database contains only one entry for the last known good iOS build
- Triggering a new build should not create additional comments
Reviewed By: cpojer
Differential Revision: D20450158
Pulled By: hramos
fbshipit-source-id: 720772275f24d3ff0a49705f4dada2efe2e99bd3
Summary:
Make the Android app bundle size report more legible, and update existing reports if possible.
## Changelog
[Internal] [Changed] - Update existing app bundle size report if possible
[Internal] [Changed] - Generate table for APK sizes report
Pull Request resolved: https://github.com/facebook/react-native/pull/28169
Test Plan:
- App bundle size reports should be updated when possible
- Android apk sizes should be reported using a table
Reviewed By: cpojer
Differential Revision: D20141490
Pulled By: hramos
fbshipit-source-id: 3fc1b808b27e893c0a3e4e34eafc39094448799c
Summary:
The PlatformConstants native module exposes the ability to query the React
Native version used to build native code. This is managed on iOS and Android by
a version bumping script, which replaces module code based on a template.
It is currently difficult to accurately determine this version for out-of-tree C++
platforms (I.e. React Native Windows). The version of upstream react-native we resolve to is ultimately
dependent on the version of react-native chosen a peer dependency, which is not
neccesarily constant given a build of react-native-windows.
We could try to hack around this, and make our native build try to reason about
the resolved pacakge for react-native using a lockfile, but a much cleaner
solution is to embed version into C++ code, similar to what is done for Android
and iOS. This change does that, adding a header with React Native version and
updating the build stamping script to write to it.
Usage sample:
```c++
constants["reactNativeVersion"] = folly::dynamic::object();
constants["reactNativeVersion"]["major"] = ReactNativeVersion.Major;
constants["reactNativeVersion"]["minor"] = ReactNativeVersion.Minor;
constants["reactNativeVersion"]["patch"] = ReactNativeVersion.Patch;
```
## Changelog
[General] [Added] - Stamp React Native Version Into C++ Code
Pull Request resolved: https://github.com/facebook/react-native/pull/28036
Test Plan: Validated that the bumping script will accurately update the header, can compile under both MSVC and Clang.
Differential Revision: D19865992
Pulled By: hramos
fbshipit-source-id: 9e0b8e9519015bb62c60b9935a234cd367a1926a
Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary:
Make the script ready for picking in 0.62.0-rc.3.
* Rename the script to remove ambiguity. “autolinking” is a CLI feature where 3rd-party pods are automatically discovered: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
* Make the Flipper version of the pods configurable, as requested [here](https://github.com/facebook/react-native/pull/28044#discussion_r378662636).
* Make RNTester’s Podfile use the same form as the template–including enabling Flipper by moving the CPP define into the right place in the Xcode project and out of the Podfile.
* Get rid of Podfile.lock thrashing by making the default CDN spec source explicit.
## Changelog
[iOS] [Changed] - Disambiguate autolinking-ios.rb script from CLI’s “autolinking” feature and bring RNTester & template in line.
Pull Request resolved: https://github.com/facebook/react-native/pull/28077
Test Plan: RNTester builds, as does a new application.
Reviewed By: PeteTheHeat
Differential Revision: D19956392
Pulled By: TheSavior
fbshipit-source-id: 6c800ddb646b49fc45c088978e2794cd7b60ea48
Summary:
We use this for RN tester but it is not currently included in npm releases. It cleans up the podfile a lot and will make adding / removing pods easier in the future since it won't require users to update their project.
## Changelog
[iOS] [Added] - Use autolink script in template on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/27984
Test Plan: Not sure if there is a way to end to end test this but I've been using this autolink script in my fork for a while.
Differential Revision: D19787729
Pulled By: cpojer
fbshipit-source-id: b843ea723085830f13e8f0149833d1beb1efdfac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/27783
Use Xcode 11.3.0 to run tests, using an iPhone 8 simulator running iOS 13.3.
Snapshot tests disabled as they're failing on Circle CI.
Changelog:
[iOS] [Changed] - Use Xcode 11.3 and iOS 13.3 simulator in iOS tests
Reviewed By: PeteTheHeat
Differential Revision: D19411972
fbshipit-source-id: 3ddef9e6fbdbd3c35271732fc6d6d74de099230e
Summary:
Use correct path to testNotUTF8Convertible which is being skipped.
## Changelog
[Internal] - Use correct path to testNotUTF8Convertible which is being skipped.
Pull Request resolved: https://github.com/facebook/react-native/pull/27767
Test Plan: Circle CI
Differential Revision: D19404469
Pulled By: hramos
fbshipit-source-id: 70cf06c90dac74ac7963b9a35a543e11b21ba471
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/27434
Pull Request resolved: https://github.com/facebook/react-native/pull/27295
- Use Xcode version 11.2.1 in both internal and external tests.
- Update snapshot reference images to use iPhone 8 test device.
Xcode 11.3.0 will be available in Sandcastle in the next week or so.
Changelog:
[Internal] - Bump Xcode version used in tests to 11.2.1.
[Internal] - Update iOS Snapshots.
Reviewed By: cs01
Differential Revision: D18849584
fbshipit-source-id: 9e3b92f080a4dc6a15dac0535b7562ff6a5c08a9
Summary:
The latest xcode version removed iPhone 6s, so we need to bump to the latest simulator listed that has 3d touch.
## Changelog
[General] [Fix] - Bump e2e simulator version
Pull Request resolved: https://github.com/facebook/react-native/pull/27733
Test Plan: - `yarn build-ios-e2e && yarn test-ios-e2e `
Reviewed By: hramos, sammy-SC
Differential Revision: D19345576
Pulled By: rickhanlonii
fbshipit-source-id: 428cb83ccb899409e972551f18df580174adee91
Summary:
React-native server-device connection must be via Wi-Fi. But if the OS-X server has LAN & Wi-Fi interfaces, then device bundle can be incorrectly configured to use LAN interface instead of Wi-Fi. This patch fix this issue. It greps for "baseT" (e.g. media: autoselect (1000baseT <full-duplex>)) and skip interface if it is.
## Changelog
[iOS] [Fixed] - Fix LAN instead of Wi-Fi device bundle configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/27575
Test Plan:
To reproduce an issue setup Mac OS 10.15.1 with LAN and Wi-Fi active interfaces. And connect
real device (not simulator).
And "ifconfig en0" in console should display LAN interface e.g.:
```
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=50b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV,CHANNEL_IO>
ether 78:7b:8a:d8:61:42
inet 10.15.61.16 netmask 0xffffff00 broadcast 10.15.61.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (1000baseT <full-duplex>)
status: active
```
"ifconfig eg1" in console should display WiFi interface e.g.:
```
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether 14:20:5e:03:5b:2a
inet6 fe80::10e6:1cb6:54ec:1b41%en1 prefixlen 64 secured scopeid 0x5
inet 10.15.91.27 netmask 0xffffff00 broadcast 10.15.91.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
```
In this case device bundle in react-native-xcode.sh script wood be incorrectly configured to use en0 (LAN interface) instead of en1(Wi-Fi) interface.
My patch fixes this issue.
fragment of script output before patch:
```
...
++ ipconfig getifaddr en0
+ IP=10.15.61.16
+ '[' -z 10.15.61.16 ']
+ '[' -z 10.15.61.16 ']'
+ echo 10.15.61.16
+ [[ -n '' ]]
...
```
After start project ob device we have time lag about 20s then debug out:
`
2019-12-20 16:58:57.530538+0300 AwesomeProject[4590:1923358] Task <164D9AB0-8473-4BA3-BD1A-EC0E92887C17>.<1> finished with error [-1001] Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={NSUnderlyingError=0x2838dc2d0 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}}, NSErrorFailingURLStringKey=http://10.15.61.16:8081/status, NSErrorFailingURLKey=http://10.15.61.16:8081/status, _kCFStreamErrorDomainKey=4, _kCFStreamErrorCodeKey=-2102, NSLocalizedDescription=The request timed out.}
`
fragment of script output after apply patch:
```
...
++ ipconfig getifaddr en0
+ IP=10.15.61.16
+ [[ -z 10.15.61.16 ]]
++ ifconfig
++ grep baseT
+ [[ -n media: autoselect (1000baseT <full-duplex>)
media: autoselect (100baseTX <full-duplex>) ]]
++ ipconfig getifaddr en1
+ IP=10.15.91.27
+ '[' -z 10.15.91.27 ']'
+ echo 10.15.91.27
+ [[ -n '' ]]
...
```
App start OK.
On iPhone /iPad simulator works too.
Differential Revision: D19200334
Pulled By: hramos
fbshipit-source-id: 22d791b657abd16a92d075515682b4fa961b489c
Summary:
Test results were being written to ~/reports/, while Circle CI was configured to look for these in ~/react-native/reports/.
This simple fix makes it so that Circle CI's test result tab can now display line-by-line results without the need to dig through log spew to understand which tests failed.
## Changelog
[Internal] [Fixed] - Generate test results in discoverable location (CI)
Pull Request resolved: https://github.com/facebook/react-native/pull/27435
Test Plan:
See https://app.circleci.com/jobs/github/hramos/react-native/7112/tests
Compare with any other run, where this tab would show an error message due to lack of test results.
Differential Revision: D19185408
Pulled By: hramos
fbshipit-source-id: 5481a13874bd078deba4a58ddb83dfdfe6845151
Summary:
iOS tests have been failing due to iOS 12.4 not being supported by Xcode 10.2.1. Bumping to 10.3 solves it.
Ideally, we'd bump to Xcode 11.2.1 and iOS 13.2.2. We can do this once all of our internal CI machines have Xcode 11.2.1 available.
## Changelog
[iOS] [Fixed] - Fix CI iOS tests by bumping Xcode version used in Circle CI
Pull Request resolved: https://github.com/facebook/react-native/pull/27356
Test Plan: Circle
Differential Revision: D18765501
Pulled By: hramos
fbshipit-source-id: 1a1ca78c5d8f8596476b0e56740ea1bdf7422161
Summary:
## Motivation
The concept behind JSCallInvoker doesn't necessarily have to apply only to the JS thread. On Android, we need to re-use this abstraction to allow execution of async method calls on the NativeModules thread.
Reviewed By: PeteTheHeat
Differential Revision: D17377313
fbshipit-source-id: 3d9075cbfce0b908d800a366947cfd16a3013d1c
Summary:
We used to generate the documentation for the website but moved the docs to another repo.
There is some work on the docs to be able to ingest info from this repo in order to go back to generating API information. The current thinking is we will generate this JSON file and the website repo will pull it in to generate the docs.
I plan to make the script run on CI and fail if the generated file isn't updated, in a follow up PR.
Reviewed By: zackargyle
Differential Revision: D17183936
fbshipit-source-id: 99ce3fa5d7becc0ef20df5d439b175eedbe546f3
Summary:
This pull request makes the following changes to the script `scripts/generate-rncore.js`:
* Adds a missing argument to the call of `generate-tests.js`
* Ran `chmod +x generate-rncore.sh` so the script is executable
## Changelog
[Internal] [Fixed] - Updated `generate-rncore.sh` for recent versions of codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/26477
Test Plan: `(cd scripts && ./generate-rncore.sh)` works perfectly now.
Differential Revision: D17439772
Pulled By: TheSavior
fbshipit-source-id: 141efc54aa45aa38dc537f65e425959666f33b3a
Summary:
Needed to capitalize the name, since this is the convention used elsewhere too
## Changelog:
[iOS] [Changed] - Renamed yoga podspec to Yoga
Reviewed By: shergin
Differential Revision: D17127104
fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
Summary: This bothers me, we renamed the project to drop the "Metro" a while ago.
Reviewed By: rubennorte
Differential Revision: D16831281
fbshipit-source-id: bb6de412eccda61b617580f3660e3e635f2d2815
Summary:
Yesterday we shipped hermesengine.dev as part of the current 0.60 release. This PR brings those changes to master.
## Changelog
[General] [Added] - Added support for Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/25613
Test Plan:
* CI is green both on GitHub and at FB
* Creating a new app from source can use Hermes on Android
Reviewed By: cpojer
Differential Revision: D16221777
Pulled By: willholen
fbshipit-source-id: aa6be10537863039cb666292465ba2e1d44b64ef
Summary:
As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context).
This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled.
However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries.
This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required.
This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors.
## Changelog
I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619.
Pull Request resolved: https://github.com/facebook/react-native/pull/25816
Test Plan:
Check `RNTesterPods` still works both with and without `use_frameworks!`:
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: hramos
Differential Revision: D16495030
Pulled By: fkgozali
fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
Summary:
This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349.
It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`.
The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` .
There are still a few breaking changes which I hope will be acceptable:
- `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path.
- ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967.
- ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled.
Still to do:
- ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by 33573511f0.
- I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? �
## Changelog
[iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks.
Pull Request resolved: https://github.com/facebook/react-native/pull/25619
Test Plan:
### FB
```
buck build catalyst
```
### Sample Project
Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed.
You can see that it works with these steps:
1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git`
2. `git checkout fix-frameworks-subspecs`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`
The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again.
### RNTesterPods
`RNTesterPodsPods` can now work with or without `use_frameworks!`.
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: PeteTheHeat
Differential Revision: D16465247
Pulled By: PeteTheHeat
fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
Summary:
^
No need for a constructor here.
Reviewed By: fkgozali
Differential Revision: D15056802
fbshipit-source-id: 32a2c541e5c1fa6336b7f6f2131772198740626c
Summary: For better compatibility re: https://github.com/facebook/react-native/pull/25393, this target should just use `RCTTypeSafety`
Reviewed By: PeteTheHeat
Differential Revision: D16210888
fbshipit-source-id: 6a55d631453cc420909247a7d5a64379587225b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25583
We now use CocoaPods for better maintainability.
Reviewed By: hramos
Differential Revision: D16193719
fbshipit-source-id: 26382f2da4eaba14a71771540b587fdc80b41108
Summary: TurboModule is now included by default, so no need to have a toggle in autolink script anymore.
Reviewed By: mdvacca
Differential Revision: D16173820
fbshipit-source-id: 215ce7d188ce526b5a71df881bdc992c1ef34b34
Summary:
This removes the `--projectRoot` flag in `launchPackager.bat` as it was removed, fixing [this bundler not opening issue on cli repo](https://github.com/react-native-community/cli/issues/484) when `yarn react-native run-android` is run.
This is Windows related only so should be only tested on Windows.
## Changelog
[Internal] [Fixed] - Fixed Metro Bundler not opening when running `yarn react-native run-android`
Pull Request resolved: https://github.com/facebook/react-native/pull/25517
Test Plan:
1. Create a new repo using `react-native init`
2. Edit the `launchPackager.bat` file
3. Run `yarn react-native run-android`
Differential Revision: D16162108
Pulled By: cpojer
fbshipit-source-id: c12d9853ad49f00d56b9a8254a5b2c40a358cb2e
Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs.
Reviewed By: PeteTheHeat
Differential Revision: D16043221
fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
Summary:
This PR adjusts rncore generation to the flow parser based approach introduced in 98b03fa.
## Changelog
[Internal] [Fixed] - Fix iOS build of RNTester with fabric_enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/25437
Test Plan:
As far as I see currently there's no automated testing for the RNTester build with `fabric_enbaled` set to `true`.
The quickest way to test this PR is building RNTester using cocoapods with `fabric_enabled`.
Differential Revision: D16071362
Pulled By: cpojer
fbshipit-source-id: 05d96686ea2d7c8c04f05eb7840c9eacff5a2738
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25416
Use CocoaPods-based RNTesterPods workspace to run iOS unit tests and integration tests.
This is necessary as new iOS projects now use CocoaPods by default. CocoaPods also powers the new package auto-linking feature.
In order to provide test coverage for this new default configuration, our iOS tests are being migrated to use a CocoaPods-managed RNTester workspace. This applies to both Circle CI, and Sandcastle.
Changelog:
[iOS] [Changed] - Use RNTesterPods for iOS Tests
Reviewed By: fkgozali
Differential Revision: D16052466
fbshipit-source-id: 724b0c51008882d3c06a9074693fe23e74abe86b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25416
Use CocoaPods-based RNTesterPods workspace to run iOS unit tests and integration tests.
This is necessary as new iOS projects now use CocoaPods by default. CocoaPods also powers the new package auto-linking feature.
In order to provide test coverage for this new default configuration, our iOS tests are being migrated to use a CocoaPods-managed RNTester workspace. This applies to both Circle CI, and Sandcastle.
Reviewed By: fkgozali
Differential Revision: D15958209
fbshipit-source-id: b51fb907812cb2d4d78cce445d39bc253ae5acf8
Summary:
We have too many options in the Dev Menu, and they're really hard to pick from. They're also somewhat conflicting. This replaces two menu choices that have a similar purpose (faster iteration cycle) with one.
"Fast Refresh" tries to only update the affected modules, but falls back to doing a full reload if the update can't be handled by the React components.
If for some reason you prefer the "Reload-on-Save" behavior, please:
- Reach out to me so I can learn more about your use case.
- As a workaround, you can add `if (__DEV__) require.Refresh.forceFullRefresh = true` to your app's entry point to always do a full refresh.
Also note that I only removed the user-facing part of "Reload-on-Save". So if you have automation depending on it, that's gonna keep working.
I moved it above Systrace since it's a more generic feature.
As a total aside nit, I renamed "Enable Inspector" and "Disable Inspector" to "Show Inspector" and "Hide Inspector" because... that's what those options do, really.
Reviewed By: rickhanlonii
Differential Revision: D15958697
fbshipit-source-id: 20e856d56f661fe4d39b5ab47d8c44754bf70f67
Summary: Fishhook was used to try to hide the log messages from RCTReconnectingWebSocket but that doesn't really work anymore. Deleting it now to unblock people trying to build for iOS 13.
Reviewed By: cpojer
Differential Revision: D15779390
fbshipit-source-id: ef18575d5d92ac374e189b1267dee3a9befc3551
Tommy Nguyen
Héctor Ramos
Michel Weststrate
Tommy Nguyen
Nick Gerleman
Rachel Nabors
Eloy Durán
Janic Duplessis
David Vacca
Kudo Chien
Héctor Ramos
Rick Hanlon
Oleg E. Bakharev
Ramanpreet Nara
Yoga Setiawan
Andres Suarez
Eli White
empyrical
Ram N
Christoph Nakazawa
cpojer
James Treanor
Min ho Kim
Kevin Gozali
Jeff Thomas
thecodrr
Richard Hyatt
Wojtek Czekalski
Daryl Johnas Sison
Dan Abramov
Mehdi Mulani
