Consider generating your code into TypeScript

I'm looking at this project - https://github.com/mikestead/openapi-client - and considering whether it would be possible / useful to leverage TypeScript, since the other project can generate TypeScript. Unfortunately you emit a type number, which requires manual renaming of that interface in the TypeScript output.
When you transpile, this will emit a .d.ts file which can be specified via package.json - this will give really rich IntelliSense in supported editors.
This seems like it would also help address #115 as well.

I know this is closed, But i was wondering if you have considered publishing an @types/docusign-esign for NPM. This would greatly improve the dev experience. Thanks!

@types/docusign-esign for NPM would be very helpful.

☝

@acooper4960 the link seems to be broken

Any Update? Really sucks not have any intellisense.

@hypeofpipe  https://raw.githubusercontent.com/docusign/eSign-OpenAPI-Specification/master/esignature.rest.swagger-v2.1.json

@hypeofpipe @johnmeister @robpaveza if you drop the above json file into https://editor.swagger.io, you can get decently reasonable types

I have published the docusign-esign typings we used at https://www.npmjs.com/package/@types/docusign-esign

@equimbo Thank you for sharing your types, unfortunately the types are two major versions behind. Would you mind publishing an updated version to support version 7.x.x?


[PROPOSAL]: Obtain Enhanced Index Statistics

Goal
This design proposal is for implementing enhancement #146
We want to make it possible for a user to get some detailed statistics on existing Hyperspace indexes. These statistics summarize some important logical/physical properties of index and they can be useful for different scenarios on the user side s.a. deciding about triggering index optimization.
Current Situation
Currently, the only way for a user to get some information and statistics about existing indexes is by checking the output of Hyperspace.indexes API. This output lists below information for each index:

Index name
Indexed columns
Included columns
Number of buckets
Index schema
Index state

Proposed Changes
We propose to make two changes:

Introduce getIndexStat() API: This is a new API in Hyperspace that is invoked by user to obtain information and statistics on an index.
Extend the set of information and statistics that are already shown for indexes by adding more/richer details.

Note. This change does not add/modify existing index metadata. Those new statistics that are not explicitly captured in index metadata get computed and added to the output of getIndexStat(), as the API is invoked.
getIndexStat API
This new API is defined as:

def getIndexStat(indexName: String): DataFrame

Once user invokes getIndexStat API for a given index, Hyperspace uses the "latest stable"  index metadata to collect and compute required stats.

Note that no concurrency control happens as this command is running (i.e. It does not lock the index in a "transitioning" state according to Hyperspace concurrency model). As a result, if index gets changed during this time, those changes may or may not be included in the command output, depending on when they are added to the latest stable index metadata log.
Additional Index Information & Statistics
In addition to info/stats that are already available to user (listed above), we include below items to the output of getIndexStat:

Index kind
Number/Size of index files (latest version)
Number/Size of source data files (latest version)
Lineage enabled
Number of index versions
Number/Size of appended files
Number/Size of deleted files
Index root paths for active versions

Comments
c1. One stat that could be added is "index build time". A couple of points about it:

For a fresh index, which is an index that is created and has not been refreshed, "build time" is well-defined. It can be estimated using the difference between timestamps in index metadata logs of "creating" and "active" states. However, once the index goes thru one or more refresh cycles, it is not clear how the build time should be defined, as the index content is gradually/incrementally changed.
While reporting "build time" seems interesting, a major problem with it is its accuracy:

Build time is highly dependent on the the job specification and available resources when the index creation Spark job was running. In addition, potential failed executors or tasks could affect it significantly.
It is not clear what type of practical user scenario can benefit from it. It can not be used as a time estimate for a full refresh, as refresh in the full mode is suggested for an index which has gone thru significant source data changes and such changes affects the accuracy of an old build time (i.e. if refreshed in the full mode, index is going to be created on a pretty much different content now).

Finally, unlike most of other metrics, "build time" is a fairly straightforward metric to measure on the client side. It is also explicitly available in Spark history server logs that capture index creation job. Therefore, user can easily obtain it, if it is really needed.

c2. Another interesting stat to report is "index usage count": "How many times an index has been used in user(s) workload(s), over time?". A couple of points:

This metric needs proper definition. What does an "index usage" mean? Should we consider each and every time an index is picked by a Hyperspace rule as a hit count? Do we consider all queries or some of them? What if the query fails? What if some other optimization overrides an index leverage? These are some questions that should be precisely answered to define/add "index usage" as a reported metric.
All the info/stats that are included in getIndexStat output can be obtained directly from index metadata logs. The log gets updated each and every time a change happens in index that could affect any of these stats. However, "index usage count" is not captured in the index metadata and can not be computed from physical artifacts of an index (i.e. metadata logs, or index files). Updating index metadata during query optimization is not practical either, due to its expensive overhead. More discussion is needed on how such a "score" should be traced for an index, once "index usage" is defined precisely.

extended = true option seems unnecessary now. How about showing the total size under index director, not calculating only index data size of all versions?
And I think it would be good not to use Dataframe to show the results like indexes.show - it prints only a small part of the result strings. WDYT? @pirz

@sezruby

How about showing the total size under index director, not calculating only index data size of all versions?

Do you mean "Total size of index files (latest version)" which is already included in extended = false output?

it would be good not to use Dataframe to show the results

Using DF is a good option as it is an easy/standard way to make the output usable for consumer code for further filter/extend and using it for different purposes. That is why we decided indexes API output to be DF, in the first place.
Regarding "printing a small portion" concern, that happens due to the default truncation that Spark does on the output of show. You can force showing whole value for each DF field by setting truncate argument to false: i.e. by calling df.show(false).

Do you mean "Total size of index files (latest version)" which is already included in extended = false output?

Yes let's add extended mode later if it's necessary. I think it's for long results like all rootPaths of source / print all source file paths.

Using DF is a good option

Ok then using DF is fine. Thanks for letting me know about indexes.show(false).
How about add involved? versions for the latest index version which are linked by incremental refresh?
So that users can remove unused index versions.

How about add involved? versions for the latest index version which are linked by incremental refresh?

@sezruby - Can you plz explain above comment? Do you mean exploring index files and extract how many top-level version directories are involved? If yes, I am not sure what is the best way to capture/show them in the final DF. Probably a short example from you can help here.

Yes, specifically root paths of index content data. For example
ColumnName: "IndexDataRootPaths"
Value: path/to/indexName/v__=0, path/to/indexName/v__=1

Closed with #286

Closed with #286


Add link to webpage.

Add a link to the web page in the readme file and/or about text in github.

https://powerglovescl.wixsite.com/website


chore: Generate release notes for GitHub

This change is part of the following stack:

#50 ◀

#51

Change managed by git-spice.


freeze problem using vim-style substitution commands

On Ubuntu 20.04, Onivim 2 (0.5.9-nightly).
Attempting to perform a vim-style substitution command freezes my whole onivim2.
For example:
:%s/blip/blop/gc
freezes my whole editor. The only option I have then is to hard-kill the editor.

(that is a real problem in daily life as I rely quite a bit on these commands; does not seem that Crtl-H neither Ctrl-h bring up a substitution tool either).

Related to #1159 , https://github.com/onivim/oni2/issues/2965 , and #3145
I just  pushed up a fix recently to address the crash (because it's horrible to hit a crash in this path) - Onivim shows a warning now with #3145:

We still need to build the find-replace experience, though (ie, fully support the c flag)

Thanks :) . Yes, it is tough to have such a "muscle memory" thing crashing the editor, great with the warning :) . Looking forward to the full fix :) .


Replace PodSecurityPolicy with new policy API

The Kubernetes project will deprecate PodSecurityPolicy starting with 1.21.0, and then remove it entirely starting at 1.25.0. See:

https://github.com/kubernetes/kubernetes/pull/97171

This issue tracks the replacement of the existing kured PodSecurityPolicy implementation with its replacement. This KEP is an indication of where things are (probably) going:

https://github.com/kubernetes/enhancements/pull/2582

👍
Should we do this for 1.7.0, 1.8.0, or above? 1.7.0 supports 1.19 to 1.21 (and therefore will fall under the deprecated environment versions).
However, if there is no clear winner (as path to implementation), and that the winner is not backported to 1.19 or below, I suppose we should NOT move to a new solution anytime soon, else it will break our existing users.
PS: I am sorry if I am repeating what might be obvious here, it's just for reference/understanding for any contributor.

Above. The new API doesn't yet exist. :) So this is just a long-term trackin issue to ensure that the kured project is ready.

Yup that's what I understood, thanks for confirming.

I am marking this PR as "good first issue" for two reasons:

It indeed isn't too hard to implement :)
With this tag, our issue expiring bot will not expire this issue.

The new PodSecurity API is in beta now (with 1.23.0): https://kubernetes.io/blog/2021/12/09/pod-security-admission-beta/

HI! I'm new to this repo and would like to work on this, issue, I've gone through some of the code but couldn't find the exact file in which I have to make changes, could anyone please help me by telling the exact file path in which I have to make changes.

When Kubernetes 1.28 is out in about ten days and we release Kured 1.14.0 (with built-in k8s 1.27 support), we drop support for Kubernetes 1.25 which was the last release with PodSecurityPolicies, so we are safe to remove them from the chart.
The "Pod Security Standards" are mostly about the securityContextof the container, which can be configured in the helm-chart, so I think we don't really need to add some replacements on our side.
Thoughts on this? @jackfrancis @evrardjp


Fixes for AMSR2 monthly/aggregate runs

Fix issue with aggregate outputs being larger than expected and taking a long time to create
Remove seaice dependency and old/ dir in project root containing OBE comparison/visualization code. This allows the netCDF4 library to upgrade, resulting fixing error messages related to xarray and dask writing netcdf files to disk.
Add --end-year option for daily aggregate CLI
Make time an unlimited dimension in output aggregate files

We may yet need to simplify the surface_type fields. I'm not sure why they are increasing the size of the final netCDF file by...a factor of 12 or more(!)

This issue resolved by utlizing ncrcat instead of xarray to do the concatenation of individual daily/monthly files.


Forwarding mail from within webmail client not possible

Hi,
when trying to forward mail from within the included webmail client the "send" button gets greyed out when pressed and nothing further is happening.
Running with debug = true sheds no light on the issue and there are no strinking entries in the log files either.
However - all other webmail client functions seem to work perfectly fine.
The frontend (1.3.4) is served via apache.
Any ideas how to fix this?

Hi, since this issue is related to the webmail, could you please create it into the appropriate repository ? https://github.com/modoboa/modoboa-webmail

Thanks.

Sorry - my bad.
I haven't noticed that theres a seperate repository. I'am new to this!


test.html Post returns 403 Forbidden

I just deployed the parse server example to Heroku and added a Mongo db via mLab. The server starts up and connects to my database with no errors but when i run the test I get 403. I'm not sure where to start troubleshooting this. Is it on the parse side or the mongo side?

never mind I just realized that I need to update the test script.js with my new app id


When jobname+matrix length exceeds 97 characters the job fails

With a jobname + martrix that exceeds  97 characters GHA truncates the job name/ inputs and adds an ellipses. This causes this job to fail

@c3charvat do you mean the job name field of the list job api response is truncated?

@qoomon its sadly behind a corporate wall. I have a fork out with actions on it that replicate the issue and a solution (i think)

@qoomon  PR is out

I'll make a release tomorrow

@qoomon Is you linked email address good? Id like to stay in touch until i can see if i can get the desired changes pushed through on actions/runner. I added more content at the request of someone on the issue: https://github.com/daleyjem/gh-job-id/issues/5

Is you linked email address good?
Should work. Otherwise have a look at https://qoo.monster for several contact options.

I'll make a release tomorrow

feel free to try version v2.1.0 or v2


[✨] Make it easier to get a hold of a manifest

Is your feature request related to a problem?
Let's say I want to call rederToString internally inside the application (For example, to send an email.) The renderToString needs a manifest; otherwise, it fails to render. There is no easy way to get a hold of the manifest in an existing application. (Specifically inside a RouteHandler)
Describe the solution you'd like
Some way to get a hold of the manifest inside the RouteHandler routeLoader$() etc...
Describe alternatives you've considered
importing
import { manifest } from '@qwik-client-manifest';

Does not work in dev mode because there is no manifest. In such a case it would be nice to get ahold of the symbolMapper
Additional context
No response

I have something in mind for this, it will be required for worker$(), and "client-side pausing"

@mhevery @manucorporat Hi, guys, any progress here? We met the same issues when we want to build a SSR service but we noticed that manifest is only generated when opts.target === 'client', which doesn't meet our need.
Thus, we also want to get a more easier way to generate the manifest and get it running on server, which might be capable for migration of qwik to express server without building qwik application from scratch.
Please have a look, thanks.

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.


[FEAT] - Integrate the Greenhouse UI container into the local environment

Priority
(Medium) I'm annoyed but I'll live
Description

As a Developer of Greenhouse I would like to spin up the Dashboard alongside the controllers, so that I can perform manual tests

The dev-env provids an easy way to spin-up and use the Greenhouse Dashboard. Due to technical restrictions this was only possible from within our corporate network. Now that the Container image for the Greenhouse Dashboard is publicly available, it should be revisited to integrate it with the localenv.
Acceptance Criteria

[ ] One command to spin up the Greenhouse Dashboard running against the KinD cluster hosting the Greenhouse operators
[ ] Update to the documentation page on how to run Greenhouse locally

Reference Issues
No response

superseded by #589


[Performance] JSI Storage implementation POC

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

This issue was created as a result of the conversation here: https://expensify.slack.com/archives/C01GTK53T8Q/p1628181643026200?thread_ts=1628106063.148700&cid=C01GTK53T8Q
What performance issue do we need to solve?

storage read/write times
React native bridge concerns

What is the impact of this on end-users?

app boot time
chat switch times

List any benchmarks that show the severity of the issue
Setup

from hash: aa1ba3c63e158f523ec8ff2f468b6c414a464360
see the setup instructions here: https://docs.google.com/spreadsheets/d/1o3JzaZSUbT9MittaHFWU0D7BwO68nfY7-_63CtJeJTg/edit#gid=892393956&range=A4
make sure you're always starting on the same report - I've hardcoded a reportID in initial Params for the Report Screen

Flows
Init - relaunch the app and use Onyx.printMetrics after everything is rendered
Chat switch - go back to LHN, use Onyx.resetMetrics now open a different Chat.  Extract a storage provider interface from the existing AsyncStorage usages in Onyx
Onyx interface with the native storage library is pretty simple get, set ,merge etc
We can make Onyx work with different providers of this interface

use Tencent on Android (and maybe iOS)
fallback to AsyncStorage for everything else

2. Work with different storage providers
To make different storage providers like AsyncStorage or MMKV work with Onyx we make a thin wrapper
implementing the storage interface in provider.native.js or provider.web.js - whatever is needed
Then in Onyx we import provider from './provider' and use the methods from the interface - get, set, merge
List any benchmarks after implementing the changes to show impacts of the proposed solution (if any)
Note: These should be the same as the benchmarks collected before any changes.

Web
iOS
Android
Desktop App
Mobile Web

Version Number: 1.0.83-0
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
View all open jobs on Upwork

Triggered auto assignment to @yuwenmemon (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

Exciting!
On Sat, Aug 7, 2021, 3:50 AM MelvinBot @.***> wrote:

Triggered auto assignment to @yuwenmemon https://github.com/yuwenmemon (
Engineering), see https://stackoverflow.com/c/expensify/questions/4319
for more details.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Expensify/App/issues/4492#issuecomment-894638439, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEMNUSOZCAWDVL5IOT7TO3T3UFXHANCNFSM5BXJLI2Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

To make different storage providers like AsyncStorage or MMKV work with Onyx we make a thin wrapper implementing the storage interface in provider.native.js or provider.web.js - whatever is needed. Then in Onyx we import provider from './provider' and use the methods from the interface - get, set, merge

Not to be a party pooper, but this feels a bit complicated. Can we maybe try to do this the simplest way possible and create a version of AsyncStorage that uses MMKV instead of calling the native modules?

I think you should just take a look at the PR: https://github.com/Expensify/react-native-onyx/pull/95
Picking a provider like this
storage/index.js
// index.native uses MMKV_Provider
import StorageProvider from './providers/AsyncStorageProvider';

const instance = new StorageProvider();

export default instance;

And then in Onyx.js use StorageProvider.get, StorageProvider.set and the rest of the methods is much simpler than modifying AsyncStorage internals.

Can we maybe try to do this the simplest way possible and create a version of AsyncStorage that uses MMKV instead of calling the native modules?

How is that the simplest way?
Creating a version of AsyncStorage that uses MMKV and JSI is a rewrite from scratch, and there is already 2 libraries that provide it
Implementing my proposal allows switching to Onyx to any storage library in a matter of minutes

If the point of this exercise is to prove that MMKV is valuable then we don't need the provider stuff for that. We could have just made MMKV_Provider.js a local replacement for AsyncStorage.
While we're on the subject though... how do I implement this to help test? There are no instructions on the linked PR.

We've captured benchmark data, did manual tests and it seems we're not getting any benefit from the JSI MMKV storage implementation ATM
In terms of "time to interactive" and "chat switch time" there's no obvious improvement
What we can continue with:

verify that the MMKV JSI implementation is faster than AsyncStorage https://github.com/Expensify/react-native-onyx/pull/95#issuecomment-895601482. We need to decide how to test this.
try a different KKMV JSI storage implementation (Very likely to have the same result)
revise the requested changes in the PR, but perhaps save it in a different branch for reference or future tests with other storages
something else or just close ?

Does everyone agree that it feels like we are missing a bottleneck that has nothing to do with storage and until we solve that we won't see the benefits of storage?
Proving that there is some benefit in isolation seems like it will tell us that things could be better, but we still need to fix "something" else about our Onyx design.
I'm not 100% sure what @quinthar had in mind here but it sounds like maybe we want to benchmark various parts of Onyx in isolation with different scenarios to see if there are any places where MMKV pulls out ahead of AsyncStorage and where there's no difference at all. And maybe in the latter cases we can rethink the design so that it can take advantage if MMKV's "faster storage".

Yep, that's exactly right.  Let's start with a bare-bones benchmark that
proves Tencent is faster than AsyncStorage in anything, and then bit by
bit add Onyx step by step until we figure out where Onyx introduces the
bottleneck.
On Tue, Aug 10, 2021 at 6:08 PM Marc Glasser @.***>
wrote:

Does everyone agree that it feels like we are missing a bottleneck that
has nothing to do with storage and until we solve that we won't see the
benefits of storage?
Proving that there is some benefit in isolation seems like it will tell us
that things could be better, but we still need to fix "something" else
about our Onyx design.
I'm not 100% sure what @quinthar https://github.com/quinthar had in
mind here
https://github.com/Expensify/react-native-onyx/pull/95#issuecomment-895527893
but it sounds like maybe we want to benchmark various parts of Onyx in
isolation with different scenarios to see if there are any places where
MMKV pulls out ahead of AsyncStorage and where there's no difference at
all. And maybe in the latter cases we can rethink the design so that it can
take advantage if MMKV's "faster storage".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Expensify/App/issues/4492#issuecomment-896416940, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEMNURYCJOFB76KQADJXMDT4HERVANCNFSM5BXJLI2Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

Does everyone agree that it feels like we are missing a bottleneck that has nothing to do with storage and until we solve that we won't see the benefits of *improved storage?

Yes, We've accumulated multiple clues about this. The problem doesn't seem to be storage access speed, but:

relaying storage data and updates to React
too much scripting (main thread time) spent by Onyx
Something else that chokes that app and everything going on Android

1. Relaying updates
We have plans like fill initial state sync from cache
One unexplored path ATM is "too many HOCs" could be causing an issue - each HOCs adds additional component and React lifecycle, it's own state  slice (copy) etc...
2. Too much scripting
The infrastructure that Onyx creates to manage the pub/sub might be taking too much main thread time or doing something that causes React to be slow.
We've already discovered and addressed the issue with "too many connections for the same key", but another thing that happens often is the keyChanged call (might actually be the most frequently called func) - it iterates the full list of connections instead of just the connections for the key that changed - that seems so plausible and unnecessary that I'll just open a ticket
3. Something else
The JSI storage had pretty much the same 2+ sec calls on the same places where AsyncStorage had those, but MMKV and JSI work differently
I think the "init" pattern we use might be too eager to load as much as possible in parallel and everything is getting in the way of everything else

Let's start with a bare-bones benchmark that proves Tencent is faster than AsyncStorage in anything

Ok I'm down for that, but it's still undecided how exactly we should go about this, I've already proposed the standalone app, but no one commented on that and so it's probably not the way to go

bit by bit add Onyx step by step until we figure out where Onyx introduces the bottleneck.

If Onyx is used in a isolated environment - at a small scale - it does not exhibit any problems.
Examples are Login/Register - on these screens the rest of the app is not loaded at all and they load fast and storage calls are super fast as well
One of my past proposals was to strip everything from the Authenticated app and start to put it back piece by piece and see how components affect TTI and interactions

The only thing related to the current ticket is benchmarking MMKV

The only thing related to the current ticket is standalone benchmarking MMKV
BTW there's already a benchmark made by the authors: https://github.com/mrousavy/react-native-mmkv#benchmark

The infrastructure that Onyx creates to manage the pub/sub might be taking too much main thread time or doing something that causes React to be slow.

Just speculating - but I wonder if the Onyx.connect() used outside of React components could be causing issues? Too many subscriptions in general could be affecting performance (pointless callbacks stored in memory, updating values for no clear reason, etc).
At the moment, a key change updates a value immediately instead of when it's needed. There are probably numerous places (mainly in the non React code but also in React components) where a store getter could replace a subscriber that updates a local variable. e.g. if we were working with redux there are cases for store.subscribe() and cases for store.getState() respectively.
Not too sure how to go about testing this. I think it might require an audit of all Onyx.connect() and many changes before we'd have any idea if it helps.

it iterates the full list of connections instead of just the connections for the key that changed - that seems so plausible and unnecessary that I'll just open a ticket

I agree this does seem unnecessary. I'd also kind of expect it would happen very fast unless there were thousands of connections, but not too sure.

I think the "init" pattern we use might be too eager to load as much as possible in parallel and everything is getting in the way of everything else

This feels really likely. Especially since we are not deferring any writes either. We try to read, write, and display UI all at once when the app inits. I wonder if it would help to take a less aggressive strategy when it comes to writing to storage? We've looked at batching reads - but what about deferring any writes until we're done reading and building critical UI? Seems like the work of writing could be batched/throttled by some amount and perhaps that will free the main thread up to do other things?

I've captured more data regarding withOnyx and I think an easy way to measure how much would initialising state from cache would help. I'm a bit lost if we already have a ticket about this change though, should I create one or there's an existing issue?

Some conversation has been happening here. If you want to create a new ticket with what you are thinking we can link it to that one.

Did a bit of basic testing with MMKV. It seems quite a bit faster than AsyncStorage for simple operations but only somewhat better (100ms or so improvement) for when you need to do a lot of stuff (e.g. read and write a ton of keys at once like we do when the app inits).
Here's the rough test I tried... I exported my entire localStorage to JSON and then tested how long it would take to write the entire contents w/ MMKV.set(), AsyncStorage (setItem + Promise), and AsyncStorage.multiSet() then performed a similar test for reading.
The results were kind of surprising in that while MMKV outperformed AsyncStorage in just about every category but it really really outperformed it in the case where many individual keys are set with AsyncStorage.setItem(). e.g. using AsyncStorage.setItem() to save each key took 6 seconds in total whereas MMKV performed the same task in 300ms.
Not sure how relevant this is for us since we are using multiMerge/multiSet via mergeCollection() but seemed interesting.

@kidroca Eep! 4 days overdue now. Issues have feelings too...

Yes, I've also observed that writing with AsyncStorage tends to be slower, merge and multiset as well
Something to note is that even though a write can be taking more time, the call is not blocking the UI
Something to consider with MMKV are the sync methods - these block the main thread, though it might not be an issue as we're writing to memory
A pro with MMKV is we would be able to drop some or all of the caching logic

we would no longer need to capture tasks as calls resolve immediately
we might not capture cache for the same reason, though then we'd need to JSON.parse every time we read a key

We've already discovered and addressed the issue with "too many connections for the same key", but another thing that happens often is the keyChanged call (might actually be the most frequently called func) - it iterates the full list of connections instead of just the connections for the key that changed - that seems so plausible and unnecessary that I'll just open a ticket

I've tracked keyChanged calls during app init and report switch
It turned out they aren't happening as often as I thought - about 20-25 for init and 8-10 for chat switching
The ones during init averaged a slower time of about 16ms per call, there's always 1 slow call of about 150ms (on a DEV build though), while for chat switches time never raised above 5ms
I've applied refactoring, where we store connections mapped by key, which allows to iterate less items, but it didn't seem to help much
I've also explored whether the setState calls in key(s)Changed aren't delaying things as they use the callback version, but they aren't

Yep, that's exactly right. Let's start with a bare-bones benchmark that proves Tencent is faster than AsyncStorage in anything, and then bit by bit add Onyx step by step until we figure out where Onyx introduces the bottleneck.

So far it looks like we know MMKV is faster general, but Onyx with MMKV didn't result in any noticeable improvement
If Onyx has a problem it's not tied to the underlying storage implementation but how it's used and how updates are translated to React
One thing left is to explore is rewriting withOnyx to use an aggregated storage provider
Another option is identifying other bottlenecks during app init

Kind of crazy idea, what if we take the opposite approach and make a fake
storage engine that is entirely in javascript, avoiding the bridge totally.
It would just have a large Json object that it is initialized with, and
then when requests are made to it it just looks up in response with that.
This would eliminate the bridge and the storage engine entirely from
testing, and would simply evaluate the overhead of Onyx itself, and all of
the promises and so forth.
It could be that all of the time lost is actually just in the use of our
promises, react components, etc.
On Wed, Aug 18, 2021, 4:43 PM Peter Velkov @.***> wrote:

Yes, I've also observed that writing with AsyncStorage tends to be slower,
merge and multiset as well
Something to note is that even though a write can be taking more time, the
call is not blocking the UI
Something to consider with MMKV are the sync methods - these block the
main thread, though it might not be an issue as we're writing to memory
A pro with MMKV is we would be able to drop some or all of the caching
logic

we would no longer need to capture tasks as calls resolve immediately
we might not capture cache for the same reason, though then we'd
need to JSON.parse every time we read a key

We've already discovered and addressed the issue with "too many
connections for the same key", but another thing that happens often is the
keyChanged call (might actually be the most frequently called func) - it
iterates the full list of connections instead of just the connections for
the key that changed - that seems so plausible and unnecessary that I'll
just open a ticket
I've tracked keyChanged calls during app init and report switch
It turned out they aren't happening as often as I thought - about 20-25
for init and 8-10 for chat switching
The ones during init averaged a slower time of about 16ms per call,
there's always 1 slow call of about 150ms (on a DEV build though), while
for chat switches time never raised above 5ms
I've applied refactoring, where we store connections mapped by key, which
allows to iterate less items, but it didn't seem to help much
I've also explored whether the setState calls in key(s)Changed aren't
delaying things as they use the callback version, but they aren't
Yep, that's exactly right. Let's start with a bare-bones benchmark that
proves Tencent is faster than AsyncStorage in anything, and then bit by
bit add Onyx step by step until we figure out where Onyx introduces the
bottleneck.
So far it looks like we know MMKV is faster general, but Onyx with MMKV
didn't result in any noticeable improvement
If Onyx has a problem it's not tied to the underlying storage
implementation but how it's used and how updates are translated to React
One thing left is to explore is rewriting withOnyx to use an aggregated
storage provider
Another option is identifying other bottlenecks during app init
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Expensify/App/issues/4492#issuecomment-901500633, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEMNUT2375NND6454RGRTLT5RAQ7ANCNFSM5BXJLI2Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

This is pretty much the cache object that we currently have
Disabling cache clearing would resolve every request from cache and never go through the bridge
I've tried this in the past, there wasn't much improvement during init - the improvement is only for the chat switches happening after (we've added LRU cache which has this improvement and allows clearing cache)
To make this exactly as what you suggest we can also disable writing to storage and just interact with cache
This experiment we would need to initialize cache from storage. And this would fall to the batching and the multi-get category optimizations that we wanted to avoid in the first place (for the current issue scope)
We need to read everything from storage and put it in cache as otherwise the app would start in a logged out state and would also have to fetch everything from the network
I don't think the experiment would reveal anything that we don't already know.
There are slow sync calls taking between 200ms to 1000ms that are not interacting with storage at all, it seems to be the result of the main (the JS) thread getting blocked as it consistently happens during init

Kind of crazy idea, what if we...

Kind of crazy idea, what if we take the opposite approach and make a fake storage engine that is entirely in javascript, avoiding the bridge totally. It would just have a large Json object that it is initialized with, and then when requests are made to it it just looks up in response with that. This would eliminate the bridge and the storage engine entirely from testing, and would simply evaluate the overhead of Onyx itself, and all of the promises and so forth. It could be that all of the time lost is actually just in the use of our promises, react components, etc.

We've made some improvements to App and Onyx and we've also have a new more consistent benchmark process so it might be worth it to redo the JSI benchmark

Nothing new to report here, I need some internal feedback to proceed

@kidroca 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

@marcaaron
In not sure how to continue here,
We've made the POC, had some observations, tried different items.
At the time the POC didn't bring much improvement
JSI storage can help in other areas like dropping cache altogether as values can be read directly from storage
In the mean time I've worked on file handling in Onyx which uses the same storage provider concept to deliver separate handling between native and web - that work will allow us to add the MMKV storage whenever we want if we decide to

@kidroca Eep! 4 days overdue now. Issues have feelings too...

@kidroca 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

@kidroca 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

Dropping this to weekly as it doesn't seem like there is a clear consensus how to proceed or close.

I've posted on slack about this ticket, but it didn't get any attention.
I'll try again next week

Yes can you please bump that thread? Android performance is light years
beyond what it was before, which was entirely unusable. But it's still not
necessarily fast.
On Sat, Sep 11, 2021, 10:26 AM Peter Velkov @.***>
wrote:

I've posted on slack about this ticket, but it didn't get any attention.
I'll try again next week
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Expensify/App/issues/4492#issuecomment-917442959, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEMNUUW5FDPVM6QHMGKVZ3UBOGNRANCNFSM5BXJLI2Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I thought the idea was to test how much MMKV and JSI would improve things.
In terms of TTI there were no improvements, no noticeable improvement for chat switches as well.
So we started to look elsewhere
Since the benchmark here, there were some updates that improved the app as you've noticed, IMO the ticket can continue to explore another storage library or re-run the benchmarks to see if something changed on that front
The work done here is handy as it allows us to easily swap and try different storage solutions  and we're applying the concept for file handling #3867.
We can relatively easy try different native storage libraries if we want to explore that path.

I thought the bottleneck was storage and particularly the react-native bridge, but even when we skipped it entirely the performance is just slightly faster.
Overall my opinion is that the solution to Android performance is not in the storage library that we use. We have other paths to explore let's do that and come back here

It's seems we don't have a ticket dedicated on Android performance, we have a few [Performance] tickets that cover all platforms (e.g. multiget and batching).
We can open a separate ticket for Android, but wouldn't it be better to handle "leads" in slack and then open specific tickets (Pretty much like how this ticket came to existence)
I can go thought the suggestions that we didn't try here and post them on slack so we can create tickets for the ones that do pickup

...

Yes can you please bump that thread? Android performance is light years
beyond what it was before, which was entirely unusable. But it's still not
necessarily fast.

I like the idea of summarizing what outstanding ideas we haven't explored.
Also, what's the latest on the big core react native upgrade to (I think?)
deprecate the bridge and go to JSI for everything?
On Mon, Sep 13, 2021, 7:08 AM Peter Velkov @.***> wrote:

I thought the idea was to test how much MMKV and JSI would improve things.
In terms of TTI there were no improvements, no noticeable improvement for
chat switches as well.
So we started to look elsewhere
Since the benchmark here, there were some updates that improved the app as
you've noticed, IMO the ticket can continue to explore another storage
library or re-run the benchmarks to see if something changed on that front
The work done here is handy as it allows us to easily swap and try
different storage solutions and we're applying the concept for file
handling #3867 https://github.com/Expensify/App/issues/3867.
We can relatively easy try different native storage libraries if we want
to explore that path.
I thought the bottleneck was storage and particularly the react-native
bridge, but even when we skipped it entirely the performance is just
slightly faster.
Overall my opinion is that the solution to Android performance is not in
the storage library that we use. We have other paths to explore let's do
that and come back here
It's seems we don't have a ticket dedicated on Android performance, we
have a few [Performance] tickets that cover all platforms (e.g. multiget
and batching).
We can open a separate ticket for Android, but wouldn't it be better to
handle "leads" in slack and then open specific tickets (Pretty much like
how this ticket came to existence)
I can go thought the suggestions that we didn't try here and post them on
slack so we can create tickets for the ones that do pickup
...
Yes can you please bump that thread? Android performance is light years
beyond what it was before, which was entirely unusable. But it's still not
necessarily fast.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Expensify/App/issues/4492#issuecomment-918229736, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEMNUR7XSZJWHH44SEOB73UBYAVHANCNFSM5BXJLI2Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


regex only selects last match in paragraph

in
		String testXML = "<div>"
				+ "<p> lorum conducted with Q = 300 and more lorum n = 123 lorum the study n = 250 was </p>"
				+ "<p> try p < 0.01 </p>"
				+ "<p> dummy </p>"
				+ "<p> this is another Q = 23 to test </p>"
				+ "</div>";

searched with
  <regex fields="foo pre number post">[nQ]\s*=\s*[0-9]+</regex>

in the first sentence only finds the last match
<results title="statistics">
 <result pre=" lorum conducted with Q = 300 and more lorum n = 123 lorum the study "
   name0="number" value0="n = 250" post="was "
    xpath="/*[local-name()='html'][1]/*[local-name()='body'][1]/*[local-name()='div'][1]/*[local-name()='p'][4]"/>
 <result pre=" this is another " name0="number" value0="Q = 23" post="to test "/>
</results>

The last sentence was fine.

?Duplicate?

Sorry - still open


[Storage] Added OAuth support for Files (#25280)

API changes have been detected in Azure.Storage.Files.Shares. You can review API changes here
API changes
+         public ShareClient(Uri shareUri, TokenCredential credential, ShareClientOptions options = null);
+         public ShareDirectoryClient(Uri directoryUri, TokenCredential credential, ShareClientOptions options = null);
+         public ShareFileClient(Uri fileUri, TokenCredential credential, ShareClientOptions options = null);
+         public ShareServiceClient(Uri serviceUri, TokenCredential credential, ShareClientOptions options = null);


update-display process hangs occasionally and sigtimedwait timeout is not handled

Unfortunately the update-display process hanged once again, now in the EPD_IT8951_Clear_Refresh function call. (See the gdb outputs of slow-movie-player and update-display below this paragraph.) Moreover, since I forgot to handle timeout of sigtimedwait in Display::update, the service did not stop, therefore the same image was displayed on my e-paper device for about a week and unfortunately that caused burn-ins on it.
$ sudo gdb -ex 'set pagination off' -ex 'attach 105040' -ex 'thread apply all bt full' -ex 'detach' -ex 'q'
GNU gdb (Debian 10.1-1.7) <IP_ADDRESS>10103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 105040
[New LWP 105053]
[New LWP 105054]
[New LWP 105055]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
0x0000007fb4e74e80 in __GI___sigtimedwait (set=0x7fdbed8760, info=0x7fdbed87e0, timeout=0x7fdbed86d0) at ../sysdeps/unix/sysv/linux/sigtimedwait.c:29
29	../sysdeps/unix/sysv/linux/sigtimedwait.c: No such file or directory.

Thread 4 (Thread 0x7f9eea11c0 (LWP 105055) "python3"):
#0  syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
No locals.
#1  0x0000007fad6979a0 in ?? () from /lib/aarch64-linux-gnu/libtbb.so.2
No symbol table info available.
#2  0x0000007fad6979d0 in ?? () from /lib/aarch64-linux-gnu/libtbb.so.2
No symbol table info available.
#3  0x0000007fb50f3648 in start_thread (arg=0x7f9eea0ac0) at pthread_create.c:477
        ret = <optimized out>
        pd = 0x7f9eea0ac0
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {548126987740,<PHONE_NUMBER>16,<PHONE_NUMBER>14,<PHONE_NUMBER>76,<PHONE_NUMBER>15,<PHONE_NUMBER>96, 0,<PHONE_NUMBER>52,<PHONE_NUMBER>88,<PHONE_NUMBER>88,<PHONE_NUMBER>08,<PHONE_NUMBER>0549434241, 0,<PHONE_NUMBER>0153395057,<PHONE_NUMBER>935480832,<PHONE_NUMBER>818648883,<PHONE_NUMBER>678344192,<PHONE_NUMBER>713539729,<PHONE_NUMBER>713539729, 0, 0, 0}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#4  0x0000007fb4f12c1c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
No locals.

Thread 3 (Thread 0x7f9f6a21c0 (LWP 105054) "python3"):
#0  syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
No locals.
#1  0x0000007fad6979a0 in ?? () from /lib/aarch64-linux-gnu/libtbb.so.2
No symbol table info available.
#2  0x0000007fad6979d0 in ?? () from /lib/aarch64-linux-gnu/libtbb.so.2
No symbol table info available.
#3  0x0000007fb50f3648 in start_thread (arg=0x7f9f6a1ac0) at pthread_create.c:477
        ret = <optimized out>
        pd = 0x7f9f6a1ac0
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {548135380444,<PHONE_NUMBER>32,<PHONE_NUMBER>30,<PHONE_NUMBER>92,<PHONE_NUMBER>31,<PHONE_NUMBER>00, 0,<PHONE_NUMBER>52,<PHONE_NUMBER>44,<PHONE_NUMBER>92,<PHONE_NUMBER>12,<PHONE_NUMBER>0549434241, 0,<PHONE_NUMBER>0178556785,<PHONE_NUMBER>935480832,<PHONE_NUMBER>818648883,<PHONE_NUMBER>678344192,<PHONE_NUMBER>713539729,<PHONE_NUMBER>713539729, 0, 0, 0}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#4  0x0000007fb4f12c1c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
No locals.

Thread 2 (Thread 0x7f9fea31c0 (LWP 105053) "python3"):
#0  syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
No locals.
#1  0x0000007fad6979a0 in ?? () from /lib/aarch64-linux-gnu/libtbb.so.2
No symbol table info available.
#2  0x0000007fad6979d0 in ?? () from /lib/aarch64-linux-gnu/libtbb.so.2
No symbol table info available.
#3  0x0000007fb50f3648 in start_thread (arg=0x7f9fea2ac0) at pthread_create.c:477
        ret = <optimized out>
        pd = 0x7f9fea2ac0
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {548143773148,<PHONE_NUMBER>32,<PHONE_NUMBER>30,<PHONE_NUMBER>92,<PHONE_NUMBER>31,<PHONE_NUMBER>04, 0,<PHONE_NUMBER>52,<PHONE_NUMBER>44,<PHONE_NUMBER>96,<PHONE_NUMBER>16,<PHONE_NUMBER>0549434241, 0,<PHONE_NUMBER>0170180465,<PHONE_NUMBER>935480832,<PHONE_NUMBER>818648883,<PHONE_NUMBER>678344192,<PHONE_NUMBER>713539729,<PHONE_NUMBER>713539729, 0, 0, 0}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#4  0x0000007fb4f12c1c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
No locals.

Thread 1 (Thread 0x7fb4e3e040 (LWP 105040) "python3"):
#0  0x0000007fb4e74e80 in __GI___sigtimedwait (set=0x7fdbed8760, info=0x7fdbed87e0, timeout=0x7fdbed86d0) at ../sysdeps/unix/sysv/linux/sigtimedwait.c:29
        _sys_result =<PHONE_NUMBER>3709551612
        sc_cancel_oldtype = 0
        sc_ret = <optimized out>
        result = <optimized out>
#1  0x00000000004318d4 in ?? ()
No symbol table info available.
#2  0x00000000004b279c in ?? ()
No symbol table info available.
#3  0x000000000049c258 in _PyEval_EvalFrameDefault ()
No symbol table info available.
#4  0x00000000004b1a48 in _PyFunction_Vectorcall ()
No symbol table info available.
#5  0x0000000000498218 in _PyEval_EvalFrameDefault ()
No symbol table info available.
#6  0x00000000004b1a48 in _PyFunction_Vectorcall ()
No symbol table info available.
#7  0x0000000000498218 in _PyEval_EvalFrameDefault ()
No symbol table info available.
#8  0x00000000004964f8 in ?? ()
No symbol table info available.
#9  0x0000000000496290 in _PyEval_EvalCodeWithName ()
No symbol table info available.
#10 0x00000000005976fc in PyEval_EvalCode ()
No symbol table info available.
#11 0x00000000005c850c in ?? ()
No symbol table info available.
#12 0x00000000005c2520 in ?? ()
No symbol table info available.
#13 0x00000000005c8458 in ?? ()
No symbol table info available.
#14 0x00000000005c7c38 in PyRun_SimpleFileExFlags ()
No symbol table info available.
#15 0x00000000005b7afc in Py_RunMain ()
No symbol table info available.
#16 0x0000000000587638 in Py_BytesMain ()
No symbol table info available.
#17 0x0000007fb4e60e18 in __libc_start_main (main=0x587538 <_start+56>, argc=2, argv=0x7fdbed9368, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:308
        self = <optimized out>
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {6916816, 0, 5797120, 0, 0, 0, 0, 0, 0, 0,<PHONE_NUMBER>20,<PHONE_NUMBER>0521706253, 0,<PHONE_NUMBER>9163372737, 0, 0, 0, 0, 0, 0, 0, 0}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x8d5100<EMAIL_ADDRESS>0x587534 <_start+52>}, data = {prev = 0x0, cleanup = 0x0, canceltype = 9261312}}}
        not_first_call = <optimized out>
#18 0x0000000000587534 in _start ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Detaching from program: /usr/bin/python3.9, process 105040
[Inferior 1 (process 105040) detached]

$ sudo gdb -ex 'set pagination off' -ex 'attach 105060' -ex 'thread apply all bt full' -ex 'detach' -ex 'q'
GNU gdb (Debian 10.1-1.7) <IP_ADDRESS>10103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 105060
Reading symbols from /opt/slow-movie-player/update-display...
Reading symbols from /lib/aarch64-linux-gnu/libm.so.6...
Reading symbols from /usr/lib/debug/.build-id/8d/efd8eb01d73f30848d9656f10df58465ab9a2e.debug...
Reading symbols from /lib/aarch64-linux-gnu/libpthread.so.0...
Reading symbols from /usr/lib/debug/.build-id/e5/a4fbb31ac8f9324067dd30930fee0eb32a490f.debug...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Reading symbols from /lib/aarch64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/bc/b0be0a4d5929b9244446b6e495b05fd335a306.debug...
Reading symbols from /lib/ld-linux-aarch64.so.1...
Reading symbols from /usr/lib/debug/.build-id/0c/157faa0bf57d35e8fa64ccb41135d5ee593b4e.debug...
0x000000557d94935c in bcm2835_peri_read (paddr=0x7fb8f17034) at bcm2835.c:212
212	       ret = *paddr;

Thread 1 (Thread 0x7fb9d17040 (LWP 105060) "update-display"):
#0  0x000000557d94935c in bcm2835_peri_read (paddr=0x7fb8f17034) at bcm2835.c:212
        ret = 268599807
#1  0x000000557d94971c in bcm2835_gpio_lev (pin=24 '\030') at bcm2835.c:345
        paddr = 0x7fb8f17034
        shift = 24 '\030'
        value = 268599807
#2  0x000000557d9439b8 in EPD_IT8951_Clear_Refresh ()
No symbol table info available.
#3  0x000000557d941c04 in display_4bpp_image ()
No symbol table info available.
#4  0x000000557d94150c in main ()
No symbol table info available.
Detaching from program: /opt/slow-movie-player/update-display, process 105060
[Inferior 1 (process 105060) detached]

I have tried to do full refresh-es to mitigate the effects of the display burn-in but it did not help. I have disassembled and assembled the picture frame and I may have damaged the device since it displays images with some artifacts now.
Until I get a new display, I will do the following:

Make sure that the service is always restarted, whatever happens.
Set a timeout for the slow-movie-player.service start in case of the initial screen clearing hangs.
Decrease the default refresh_timeout from 300 seconds to 180 seconds as recommended on the Waveshare wiki.
Add zoom functionality image processing to avoid using black bars as padding.
Handle sigtimedwait timeouts in Display::update.

I have implemented the aforementioned changes on the further-improvements branch and I will be running the display for a couple of weeks with those changes.
On top of that, I will do some experiments with putting the e-paper device into sleep between refresh operations as mentioned on the Waveshare wiki:

During the standby process (that is, after the refresh operation), it is recommended that the customer set the e-ink screen to sleep mode, or power off (the power supply part of the ink screen can be disconnected with an analog switch) to reduce power consumption and prolong the life of the e-ink screen. (If some e-ink screens are powered on for a long time, the screen will be damaged beyond repair.)

However, it mentions standby (poweroff) process and I am not sure that if I have to call another init after putting the display into sleep mode. So, there are a couple of things I have to look into regarding this change.


☂ Functionality for v0.1

Language support
This is a rough checklist of language features for which we should support Go to Def/Find Refs in a v0.1 release of scip-clang.
Very important

[x] Local variables (https://github.com/sourcegraph/scip-clang/pull/113)
[x] Function parameters (https://github.com/sourcegraph/scip-clang/pull/113)
[x] Data members (https://github.com/sourcegraph/scip-clang/pull/131)
[x] Ordinary named functions and methods (https://github.com/sourcegraph/scip-clang/pull/122)
[x] Operators (https://github.com/sourcegraph/scip-clang/pull/122)
[x] Explicitly written constructors (approximate: https://github.com/sourcegraph/scip-clang/pull/163)
[x] Types (enums, classes, structs, unions) (https://github.com/sourcegraph/scip-clang/pull/98, https://github.com/sourcegraph/scip-clang/pull/80, https://github.com/sourcegraph/scip-clang/pull/116)
[x] Type aliases (https://github.com/sourcegraph/scip-clang/pull/135)
[x] Forward declarations (https://github.com/sourcegraph/scip-clang/pull/148)
[ ] Hover docs: type information
[x] Hover docs: doc comments
[x] Adoption docs

Important

[x] Namespaces (https://github.com/sourcegraph/scip-clang/pull/76)
[x] Namespace aliases
[x] Template parameters (https://github.com/sourcegraph/scip-clang/pull/133)
[x] Macro names (https://github.com/sourcegraph/scip-clang/pull/61, https://github.com/sourcegraph/scip-clang/pull/78)
[x] Global variables (https://github.com/sourcegraph/scip-clang/pull/131)
[x] #include pragmas (https://github.com/sourcegraph/scip-clang/issues/107, https://github.com/sourcegraph/scip-clang/pull/166)
[x] ~Full and partial template specializations~ Moved out of v0.1 to https://github.com/sourcegraph/scip-clang/issues/278

Low importance (for MVP)

Synthesized constructors

Navigation in macro body

Build system support

[x] Indexing in parallel locally using compile_commands.json https://github.com/sourcegraph/scip-clang/pull/8
[x] Graceful handling for hangs/slow indexing - #20
[ ] Graceful handling for unknown compiler flags
[x] GCC-based builds https://github.com/sourcegraph/scip-clang/issues/177 (https://github.com/sourcegraph/scip-clang/pull/178)
[x] Graceful handling for compilation errors

Closing this since v0.1 is released. The type information problem is tracked in #327


Adding component tests to Client/Pro

Dependency checks should be added to Account model

adding delete function to client -> delete also profile
adding delete function to professional -> delete also profile
adding tests for the filter methods

This issue raised on PR #44

Resolved


using fetch instead http

Hi @mkloubert
At last versions used FetchModule instead Http.
So I replaced it in plugin.
Could you approve it and update npm package.
Thanks

@whins, @pedromorgan is right, you might want to remove the import statement to http


[BUG] Please Fix : The Song stayed the same when already at another song (macOS)

I'm so tired to connect/disconnect it like every 10 mins because it like freezes so much.
@kkevinm can you do something, It's been bugging me alot thanks. If you can fix it

The version I'm using is the latest version

I have the same issue, but I am having trouble trying to reproduce it. I think one way to reproduce it is by leaving the Rich Presence running and then letting the computer go to sleep. When I wake up the computer and playing music again, it usually freezes.
I will update here if I can find a more reliable way of reproducing it

I'm also having related issues, but they seem to happen inconsistently so I can't pin down the problem. Also it only seems to happen when running the .app (but not the .jar file, for example)? Honestly, I have no clue, but something's up for sure.

Tried to do some testing, and it seems that whenever I pause the music for more than 2 mins, unpausing the music would not update the rich presence. I wonder if it might be something like Mac OS automatically disconnects the app for saving resources?

Tried to do some testing, and it seems that whenever I pause the music for more than 2 mins, unpausing the music would not update the rich presence. I wonder if it might be something like Mac OS automatically disconnects the app for saving resources?

Yeah yeah me too

But mine's not sleeping and it just frozed. Hmmn

@kkevinm welp. I just opened up the app and I played the first song, It frozed at the first song that I played

Yeah, it seems to be random when it happens. For now try using version 1.5.4, that one shouldn't have issues.

I have the suspect that the culprit could be App Nap: when an application is hidden or behind others, this feature will put it to sleep preventing it from updating the rich presence (I checked in the Activity Monitor and indeed App Nap kicks in shortly after the app is put in the background). I'll see if it's possible to prevent this.

ok thanks

yeah
I'm thinking of reverting too

Downgraded to 1.5.4 and can confirm it does not fix the issue.

Downgraded to 1.5.4 and can confirm it does not fix the issue.

Oh really. I didn't do it yet cuz trying to test it out and report bugs

This is my summary of v1.5.6
Bugs EVERY TIME that I used it

imma try the .jar for a few days and report back

@kkevinm you're right
I use .jar and it just runs smooth as you told me.
Perfect.

welp. still bugging
hmmm
ahhh

I can suggest trying to disable App Nap and see if that solves the issue. How you do it is open the Terminal.app and paste this line: defaults write NSGlobalDomain NSAppSleepDisabled -bool YES, then hit Enter (you may have to restart the computer for the change to take effect). If you want to re-enable it, paste the same line but using NO instead of YES. If this doesn't work, then I really don't know.

I've used the jar version in windows+mac
just a few errors sometimes.
the jar is the best to use for now @kkevinm as you told us

rarely bugged as I say

yeah
ill try the app later this night

@kkevinm as i tried it for 2 days, i have not found any freezes
I disabled the app nap and it works

Ah all right, that's what I thought. I'll see if it can be fixed without having to do that, but meanwhile I'll add that to the FAQ.

Okay so I've tested it quite extensively and it seems like disabling App Nap does indeed make the app work as intended. For now I'll close this, since it's technically solved, but I'll see if there's a way to prevent it without having to disable App Nap.


Installation with portainer

Hi,
I would like to install this docker under Portainer, however, I don't understand how to choose the computer.csv file directory.
For other docker, we need to use /config, and set the path to our server, but with this docker image, it doesn't work. I also tried /app, doesn't work.
I also tried to install it with docker command lines, but I can't find the directory of computer.csv on my disk...
Could you tell how can we choose the file directory, or where the computer.csv file is stored to be able to edit it with my computers name ?
Thanks

you need to map container file /app/computer.csv to a local volume
-v $(pwd)/externall-file-on-host.csv:/app/computer.csv


Re-render causes document to disappear

Check PR for detailed information -> https://github.com/cyntler/react-doc-viewer/pull/29

@griffenr Thanks so much! Merged! ;)

@griffenr I revert your dispatch(updateDocumentNumber()); in 1.4.5.
It is not working for me.
I see invalid current file no and my next/back arrows don't work.

Can you provided steps to re-create this issue? I did some testing of my own by reworking the demo component and didn't notice any issues. I would like to try and get this resolved :)

@griffenr I use Safari browser so I checked there. I have to check in Chrome additionally.
All what I did:

I added next file to the documents array in demo.tsx
I started demo app by npm start

When I switched the document with arrows, the wrong number of the current document was quickly shown (usually 0).

@cyntler I am unable to test this in Safari so if you could confirm in Chrome that would be great. I cloned the 1.4.4 tag just to make sure I had the exact same code you did and am still not getting any errors and everything appears to be working fine.

@griffenr Yes! In Chrome it is working fine.

@griffenr I don't think we need those two dispatches:
        dispatch(updateDocumentNumber());
        dispatch(
          updateCurrentDocument({
            ...currentDocument,
            fileType: contentType || undefined,
          })
        );

Can't we merge this into one dispatch as it was before? updateCurrentDocument is updating state.currentFileNo. I don't understand we need this second dispatch.
Can you explain?

@cyntler When a re-render is triggered, it will default the document to the one specified in the initialActiveDocument prop. Without this updateDocumentNumber dispatch, it will not sync the current page number to the correct page. I highly recommend setting up the demo.tsx file to contain a button that will trigger a re-render of the page so you can see this in action. Below I have pasted the code for the demo.tsx file that I'm using to test.
import React from "react";
import { createRoot } from "react-dom/client";
import DocViewer from ".";
import { DocViewerRenderers } from "./plugins";
const App = () => {
const [ test, setTest ] = React.useState( false );
const docs = [
{ uri: require("./examples/pdf-file.pdf") },
{ uri: require("./examples/png-image.png") },
];
return (
<div style={ { background: test ? "blue" : "green" } }>
<button onClick={ () => setTest( !test ) }>Re-render
<DocViewer
documents={docs}
initialActiveDocument={docs[1]}
pluginRenderers={DocViewerRenderers}
config={{
noRenderer: {
overrideComponent: ({ document, fileName }) => {
const fileText = fileName || document?.fileType || "";
if (fileText) {
return no renderer for {fileText};
}
return no renderer;
},
},
loadingRenderer: {
overrideComponent: ({ document, fileName }) => {
const fileText = fileName || document?.fileType || "";
if (fileText) {
return loading ({fileText});
}
return loading;
},
},
}}
/>

);
};
const rootElement = document.getElementById("root");
if (rootElement) {
const root = createRoot(rootElement);
root.render();
}

@griffenr OK! Now I understand this problem. I am looking for a solution.

@griffenr OK, it looks like it has been fixed at PR: https://github.com/cyntler/react-doc-viewer/pull/35.
Check it in v1.5.1. I am interested if it will be working for you.
As you can see at the PR - a solution for this issue was changing case SET_ALL_DOCUMENTS: { case in the reducer.


fix: wrong import

Just a lil change on the import of trace_skeleton to make the example code work.

Thanks!


After upgrading to react-native 0.59 iOS build fails

🐛 Bug Report
After updating to react-native 0.59 and trying to build the app for iOS I get the following error:

Build input file cannot be found: '/app/node_modules/react-native/ReactCommon/yoga/yoga/YGFloatOptional.cpp'

What's strange to me is, that I can't find this file here either in the current master: react-native/tree/master/ReactCommon/yoga/yoga (only YGFloatOptional.h)
To Reproduce
We upgraded a mid sized project from 0.57.7 → 0.59.
Expected Behavior
Build should run through just fine like it did before.
Environment
  React Native Environment Info:
    System:
      OS: macOS 10.14.3
      CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
      Memory: 2.95 GB / 32.00 GB
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 10.15.1 - /var/folders/1r/ymkpxdlj21lb638kzp4jxvwm0000gn/T/yarn--1552463658468-0.20119758467048565/node
      Yarn: 1.13.0 - /var/folders/1r/ymkpxdlj21lb638kzp4jxvwm0000gn/T/yarn--1552463658468-0.20119758467048565/yarn
      npm: 6.4.1 -<EMAIL_ADDRESS>      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
      Android SDK:
        API Levels: 23, 24, 25, 27, 28
        Build Tools: 23.0.1, 23.0.3, 24.0.1, 25.0.0, 27.0.3, 28.0.3
        System Images: android-24 | ARM 64 v8a, android-24 | ARM EABI v7a, android-24 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom_64
    IDEs:
      Android Studio: 3.3 AI-182.5<IP_ADDRESS>64788
      Xcode: 10.1/10B61 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.8.3 => 16.8.3
      react-native: 0.59.0 => 0.59.0

I have just reproduced this issue with XCode: 10.1 and RN 0.59.0.

Hmm, I have just upgraded from 0.58.4 to 0.59, cleaned build directories in XCode and I was able to run both debug and archive the app. I am using XCode 10.1.
My upgrade strategy:

Bump dependencies according to most recent stable version.
Walk through each compare in https://github.com/react-native-community/rn-diff-purge and apply it manually.

Wondering if everything might work for me because I had working 0.58.4 and just applied new stuff on top of it?

I managed to make it work with XCode 10.1 by enabling legacy build. Related to #19573

I think using legacy build is not the best suggestion / option to get things work from now on, I find a proper way to fix my problem with xcode 10 on a different issue that I'm forgot.

I'm getting the same issue upgrading from 0.57.8 -> 0.59.1.
Looking at a fresh 0.59.1 init there is no YGFloatOptional.cpp file.

Add these lines to your Podfile:
  pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
  pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec'
  pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'

and run
pod install

@jpudysz Yeah that worked after migrating to cocoapod and opening the XCode project with the .xcworkspace file.
Should legacy (no-cocoapod) linking be deprecated ?

@jpudysz Worked for me too. Surely this can't be the proper solution though right? This seriously bloats the project. Pods/boost-for-react-native is 160.8MB

Thanks @jpudysz . Following your solution, I then get the following error:
'folly/Portability.h' file not found in JSBundleType.h
Does anyone know what's going on?
Many thanks.

After trying what feels like pretty much everything, RN standard upgrade, git upgrade tool, applying diff patch I ended up recreating a completely new project and doing the extremely tedious work of rebuilding the code base. They say it'll be better from 0.59 on.. hopefully they're right about that

I just upgraded from 0.59.0 to 0.59.1 and it worked for me

I upgraded too but with no luck so far.

I had the exact same issue. The good old rm -rf node_modules && npm i and cleaning the build folders did it for me

After using 'npm audit fix', my 'react-native' are upgraded automatically to version 0.59 and I can't not build my project.
Solution: Downgrade version to lower one.
npm install react-native@<version>
example : npm install<EMAIL_ADDRESS>

I've tried updating from 0.58.4 manually (following rn-diff-purge changes) but I'm also facing this problem with RN 0.59.0 or 0.59.1

Yeah we had YGFloatOptional.cpp until 0.58 https://github.com/facebook/react-native/blob/0.58-stable/ReactCommon/yoga/yoga/YGFloatOptional.cpp
What the heck is going on here?

Got the same issue with 'folly/Portability.h' after upgrading from 0.58.4 to 0.59.0 and 0.59.1
What is weird, is that XCode states after compile that Portability.h is not found, but in the editor, it gets all types define in the header...

File failing to compile is RCTJavasScriptLoader.mm in the React library.

I got the same issue..., Every time there is some issue with upgrades in react native so tired..

The file seems to be deleted from the yoga project:
https://github.com/facebook/yoga/commit/96d93f29826257ff6e9bb6c19211adb423029c29

I gave up, I deleted all links to node_modules from Pods file then delete node_modules and build directory and re-installed anything then finally built successfully again.
This is so exhausting.

@jvandenaardweg I think you're right that it's a caching issue.
For me what worked was deleting my Xcode's derived data folder and restarting Xcode.
rm -rf ~/Library/Developer/Xcode/DerivedData
Once I restarted, I attempted a build and it failed and prompted me to close and reopen my xcode workspace. Once I did that, I tried to build again and it worked.

Alright folks, I think this issue is generally about build cache issues from upgrading (from reading the posts ) - so if you have issues, I think it can generally be fixed by:

Cleaning Derived data in Xcode
rm -rf node_modules; rm -rf Pods then re-install
Using react-native upgrade x.y.z

This is pretty much the same for every version, I bet. I would maybe look into making an issue on the react-native-cli about improving this and maybe running some of the commands itself.

Does anyone have a specific reproduction step for this?

I was also seeing the #include <folly/Portability.h> error. The issue in my case were missing subspecs in the podfile.
It builds fine for me with:
  pod 'React', :path => '../node_modules/react-native', :subspecs => [
    'Core',
    'CxxBridge', # Include this for RN >= 0.47
    'DevSupport', # Include this to enable In-App Devmenu if RN >= 0.43
    'RCTText',
    'RCTNetwork',
    'RCTWebSocket', # needed for debugging
    'RCTImage',
    'RCTWebSocket', # Needed for debugging
    'RCTAnimation', # Needed for FlatList and animations running on native UI thread
    # Add any other subspecs you want to use in your project
  ]

  pod 'yoga', :path => '../node_modules/react-native/ReactCommon/yoga'

  # Third party deps podspec link
  pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
  pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec'
  pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'

"Between react-native 0.57.8 and 0.58.5 there is one big change that was added in the Xcode project is that you have to add JavaScriptCore.Framework to the Linked FrameWorks and Libraries" - https://stackoverflow.com/questions/54843771/xcode-archive-build-failed-with-react-native-project

@jvandenaardweg answer:
rm -rf $TMPDIR/metro-* && rm -rf $TMPDIR/haste-* && watchman watch-del-all && npm cache clean --force && npm cache verify && rm -rf ios/build && rm -rf node_modules/ && npm i
Did the work for me.
It's really frustrating as other say, needing to guess what its breaking a code that was working before.
Also on Android I had to upgrade Build Gradle version to work again.

needing to guess

We know that upgrading has been a long lasting pain for the community so starting v0.59 we have introduced a new flow via the new CLI.
That said we have been writing the breaking changes in the changelog and in the releases tab so there is no real guessing needed.
Anyway, closing since this is clearly related to upgrading - also, in general you can use rn-diff-repo to check for all the necessary steps when upgrading.

Hello,
After lots of digging, I've managed to get why I got the issue. Cleaning the cache and everything didn't fix the problem for me and I was still having the #include <folly/Portability.h>.
It was compiling fine for the React project under my project, but failing to compile for the Pods I have.
Even after adding the Folly/glog/DoubleConversion pods, I was still having the problem.
I then amended the React.podspecs file to edit the Core subspec
After adding the Folly reference to the pod_target_xcconfig, it was compiling without any other issues.
ss.pod_target_xcconfig  = { "HEADER_SEARCH_PATHS" => "\"$(PODS_TARGET_SRCROOT)/ReactCommon\"  \"$(PODS_ROOT)/Folly\"" }

And here is the full podfile I have
ENV['COCOAPODS_DISABLE_STATS'] = 'true'

target 'CryptoReact' do
  platform :ios, '9.0'

  pod 'CodePush', :path => '../node_modules/react-native-code-push'
  pod 'Firebase/Core', '~> 5.14.0'

  pod 'react-native-sqlite-storage', :path => '../node_modules/react-native-sqlite-storage'
  pod 'yoga', :path => '../node_modules/react-native/ReactCommon/yoga/yoga.podspec'
  pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
  pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec'
  pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'
  pod 'react-native-randombytes', :path => '../node_modules/react-native-randombytes'
  pod 'RNVectorIcons', :path => '../node_modules/react-native-vector-icons'
  pod 'react-native-splash-screen', :path => '../node_modules/react-native-splash-screen'
  pod 'RNLocalize', :path => '../node_modules/react-native-localize/ios'
  pod 'react-native-camera', :path => '../node_modules/react-native-camera'
  pod 'RNPermissions', :path => '../node_modules/react-native-permissions'
  pod 'react-native-keep-awake', :path => '../node_modules/react-native-keep-awake'
  pod 'SwiftyJSON', '4.2.0'
  pod 'Charts', '3.1.1'
  pod 'Fabric', '~> 1.9.0'
  pod 'Crashlytics', '~> 3.12.0'
  pod 'Firebase/Performance', '~> 5.14.0'
  pod 'Firebase/Auth', '~> 5.14.0'
  pod 'lottie-ios', :path => '../node_modules/lottie-ios'
  pod 'lottie-react-native', :path => '../node_modules/lottie-react-native'
  pod 'react-native-webview', :path => '../node_modules/react-native-webview'
  pod 'RNScreens', :path => '../node_modules/react-native-screens'
  pod 'ReactNativeExceptionHandler', :podspec => '../node_modules/react-native-exception-handler/ReactNativeExceptionHandler.podspec'
  pod 'RCTRestart', :path => '../node_modules/react-native-restart/ios'
  pod 'react-native-version-number', :path => '../node_modules/react-native-version-number'
  pod 'RNBackgroundFetch', :path => '../node_modules/react-native-background-fetch'

  pod 'React', :path => '../node_modules/react-native', :subspec => [
    'Core',
    'ART',
    'cxxreact',
    'CxxBridge', # Include this for RN >= 0.47
    'DevSupport', # Include this to enable In-App Devmenu if RN >= 0.43
    'RCTText',
    'RCTNetwork',
    'RCTWebSocket', # needed for debugging
    'RCTImage',
    'RCTWebSocket', # Needed for debugging
    'RCTAnimation', # Needed for FlatList and animations running on native UI thread
    'RCTPushNotification',
    # Add any other subspecs you want to use in your project
  ]
end

swift4 = ['Charts']

post_install do |installer|
installer.pods_project.targets.each do |target|
  target.build_configurations.each do |config|
    if swift4.include?(target.name)
      config.build_settings['SWIFT_VERSION'] = '4.1'
    end
  end
end
end

I'm on the same situation. I've upgraded from  0.57 to 0.59 following react native diff and everything worked perfectly until I upgraded 0.58.6 to 0.59.
I've tried everything on this thread with no luck, the 'folly/Portability.h' file not found error just doesn't want to go away.
Rolling back to 0.58.6 works perfectly but the moment I update to 0.59.0 or 0.59.1 the error appears.

I realize that my post was very unclear... Sorry about that. Here is the diff file that should make it more explicit for people having issue with 'folly/Portability.h'
Try making the following modification to nodes_modules/react-native/React.podspec file, at least in my case it has worked ! I can now compile my project and launch it without problems.
diff --git a/node_modules/react-native/React.podspec b/node_modules/react-native/React.podspec

s.subspec "Core" do |ss|
[...]
     ss.header_dir           = "React"
     ss.framework            = "JavaScriptCore"
     ss.libraries            = "stdc++"
-    ss.pod_target_xcconfig  = { "HEADER_SEARCH_PATHS" => "\"$(PODS_TARGET_SRCROOT)/ReactCommon\"" }
+    ss.pod_target_xcconfig  = { "HEADER_SEARCH_PATHS" => "\"$(PODS_TARGET_SRCROOT)/ReactCommon\"  \"$(PODS_ROOT)/Folly\"" }
   end

Doing what @aaska said plus adding
pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'   pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec'   pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'
to the Podfile and pod installing them worked for me.

After using @jpudysz, @jvandenaardweg and @johnryan tips, it build for me also.
Thanks guys!

@th3ac3 that solved the issue for me. Thank you!

none of them worked

@jvandenaardweg I think you're right that it's a caching issue.
For me what worked was deleting my Xcode's derived data folder and restarting Xcode.
rm -rf ~/Library/Developer/Xcode/DerivedData
Once I restarted, I attempted a build and it failed and prompted me to close and reopen my xcode workspace. Once I did that, I tried to build again and it worked.

Thanks, I did that  and it worked again.

So after following the upgrade diff to 59.1 (using rn-diff-purge), I still had the same issues as everyone here (YGFloatOptional.cpp error first, and then the folly/Portability.h error). However, none of the solutions worked by itself, so this is what I did to resolve the issues:
# Clean caches/build folder/existing pods
rm -rf node_modules
rm -rf ~/Library/Developer/Xcode/DerivedData
rm -rf ios/build
rm -rf ios/Pods

# Reinstall deps
npm install

Then updated my Podfile to the following:
# Uncomment the next line to define a global platform for your project
# platform :ios, '9.0'

target 'CityChallenge' do
  # Uncomment the next line if you're using Swift or would like to use dynamic frameworks
  # use_frameworks!

  pod 'React', :path => '../node_modules/react-native', subspecs: [
    # Comment out any unneeded subspecs to reduce bundle size.
    'Core',
    'CxxBridge', # --> I was missing Cxxbridge here, may have resolved the issue for me as well
    'DevSupport',
    'RCTActionSheet',
    'RCTAnimation',
    'RCTBlob',
    'RCTCameraRoll',
    'RCTGeolocation',
    'RCTImage',
    'RCTNetwork',
    'RCTPushNotification',
    'RCTSettings',
    'RCTTest',
    'RCTText',
    'RCTVibration',
    'RCTWebSocket',
    'RCTLinkingIOS'
  ]

  pod 'yoga', :path => '../node_modules/react-native/ReactCommon/yoga'

  # Third party --> This bit is also new
  pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'

end

After that I reinstall the pods
cd ios
pod install

After that the project started building successfully again

In my case i just forgot to did the step:

if you are an iOS developer, you'll need to manually link JavaScriptCore.framework when upgrading; this can be done via Xcode, and following the steps shown here.

example
after i did that, xcode just compile ok

None of the above worked for me

check this out: https://github.com/facebook/react-native/issues/18408#issuecomment-386696744
it solved the issue for me.

put this in console -> xcrun -k --sdk iphoneos --show-sdk-path
if the answer is
xcrun:_ error: SDK "iphoneos" cannot be located
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: unable to lookup item 'Path' in SDK 'iphoneos'
then put this sudo xcode-select --switch /Applications/Xcode.app
Then install pod again

This answer worked for me. On top of all the things mentioned above in this thread, I needed re-open the terminal that my metro bundler was running.

downgrade to     "react-native": "0.57.4", than it works again

downgrade to "react-native": "0.57.4", than it works again

I don't think downgrading to this version is the best way @miukki. This version brings 64-bit support for Android apps and you need it as a future requirement to publish apps (info here).

Hey after approaching all of solutions above i caught another error

ld: warning: directory not found for option '-F/Users/pumeo/Library/Developer/Xcode/DerivedData/GreenPlanet-cekcooliietupofcqlsnkupeolal/Build/Products/Debug-iphonesimulator/React'
ld: framework not found React
clang: error: linker command failed with exit code 1 (use -v to see invocation)

when I inserted the post_install
anyone can help please?
Im using hackintosh

@Pumeo1010, please stay on topic.
On topic: if this issue is closed, what's the resolution? I've tried everything above and got it working somehow (don't know what did the trick). Now I had to re-built and ran into the same issue once again and whatever I try can't get it to work anymore.

I am trying to upgrade React Native from 0.57.8 to 0.59.9 almost two days. I have tried all the solutions above this comment but still got same errors. Duplicate symbols, headers not found, YGFloatOptional.cpp. I created a new React Native project with cli and then copy my existing project files to the new project and i applied the differences with the help of rn-diff-purge. Again with this way too i got many different build errors and finally I gave up! I love v0.57.8

So after following the upgrade diff to 59.4 (using rn-diff-purge), I still had the same issues as everyone here (YGFloatOptional.cpp error first, and then the folly/Portability.h error). However, none of the solutions worked by itself, so this is what I did to resolve the issues:
# Clean caches/build folder/existing pods
rm -rf node_modules
rm -rf ~/Library/Developer/Xcode/DerivedData
rm -rf ios/build
rm -rf ios/Pods

# Reinstall deps
npm install

Then updated my Podfile to the following:
# Uncomment the next line to define a global platform for your project
# platform :ios, '9.0'

target 'CityChallenge' do
  # Uncomment the next line if you're using Swift or would like to use dynamic frameworks
  # use_frameworks!

  pod 'React', :path => '../node_modules/react-native', subspecs: [
    # Comment out any unneeded subspecs to reduce bundle size.
    'Core',
    'CxxBridge', # --> I was missing Cxxbridge here, may have resolved the issue for me as well
    'DevSupport',
    'RCTActionSheet',
    'RCTAnimation',
    'RCTBlob',
    'RCTCameraRoll',
    'RCTGeolocation',
    'RCTImage',
    'RCTNetwork',
    'RCTPushNotification',
    'RCTSettings',
    'RCTTest',
    'RCTText',
    'RCTVibration',
    'RCTWebSocket',
    'RCTLinkingIOS'
  ]

  pod 'yoga', :path => '../node_modules/react-native/ReactCommon/yoga'

  # Third party --> This bit is also new
  pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'

end

After that I reinstalled the pods
cd ios
pod install

Only then the project started building successfully again

@Hless Hi. I tried your solution. Here is my Podfile
//This time the build fails because of duplicate symbols.
target '..' do
   # this is very important to have!
   rn_path = '../node_modules/react-native'
   pod 'yoga', path: "#{rn_path}/ReactCommon/yoga/yoga.podspec"
   pod 'React', path: rn_path, subspecs: [
     'Core',
     'CxxBridge',
     'RCTActionSheet',
     'RCTAnimation',
     'RCTGeolocation',
     'RCTImage',
     'RCTLinkingIOS',
     'RCTNetwork',
     'RCTSettings',
     'RCTText',
     'RCTVibration',
     'RCTWebSocket'
   ]

   pod 'RNImageCropPicker', :path =>  '../node_modules/react-native-image-crop-picker'

   pod 'AppCenter/Crashes', '~> 1.12.0'
   pod 'AppCenter/Analytics', '~> 1.12.0'
   pod 'AppCenterReactNativeShared', '~> 1.11.0'
   pod 'Fabric'
   pod 'Crashlytics'
  # Uncomment the next line if you're using Swift or would like to use dynamic frameworks
  # use_frameworks!

  platform :ios, '9.0'
  pod 'react-native-webview', :path => '../node_modules/react-native-webview'
  pod 'react-native-document-picker', :path => '../node_modules/react-native-document-picker'

  pod 'react-native-video', :path => '../node_modules/react-native-video'

  pod 'RNReanimated', :path => '../node_modules/react-native-reanimated'

  pod 'rn-fetch-blob', :path => '../node_modules/rn-fetch-blob'

  pod 'react-native-netinfo', :path => '../node_modules/@react-native-community/netinfo'

  pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'

end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    if target.name == "React"
      target.remove_from_project
    end
  end
end

But this time build fails because of duplicate symbols error. I found this solution and now it builds successfully. But now I have another problem. Once I run the application it crashes immediately. I found the error reason in debug area of Xcode and it is
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[RCTRootView reactTag]: unrecognized selector sent to instance 0x7fbf02c05530'
the solution to this problem is the opposite of the other solution. What a bad upgrading story. :(

Finally I successfully built iOS project and run it on simulator without any errors after hard working on upgrade progress. First I applied diffs with the help of rn-diff-purge then I applied @Hless' solution at the end I faced with duplicate symbols error and by following steps on this solution I fixed them also now project is working  correctly.

Resolved with the following :
rm -rf node_modules
rm -rf ios/Pods
rm ios/Podfile.lock
rm -rf ~Library/Developer/XCode/DerivedData
Then I reinstalled my dependencies (npm & pod) and it worked :)

rm -rf ~Library/Developer/XCode/DerivedData

the right line will be: rm -rf ~/Library/Developer/Xcode/DerivedData

Every time I encounter a hair-pulling issue with RN giving me some nonsense error message, I go on a desperate github hunt for solutions. Most of the time the solution is delete cache, delete derived data, reopen Xcode, clear build folders etc. Over the years I've put together this bash script that I've added as an npm script in my package.json. Now my first goto solution for most issues is npm run clear.
// package.json
{
  "scripts": {
    "clear": ". scripts/Clear.sh",
  }
}

// scripts/Clear.sh
#!/bin/bash

echo "rm -rf ios/build..."
rm -rf ios/build

echo "rm -rf android/app/build..."
rm -rf android/app/build

echo "Removed all Xcode derived data..."
rm -rf ~/Library/Developer/Xcode/DerivedData

echo "rm -rf lib... (for Flow)"
rm -rf lib

echo "watchman watch-del-all..."
watchman watch-del-all

echo "rm -rf node_modules..."
rm -rf node_modules

echo "npm install..."
npm install

echo "rm -rf $TMPDIR/ react-*..."
rm -rf $TMPDIR/ react-*

echo "rm -rf $TMPDIR/haste-map-react-native-packager-*..."
rm -rf $TMPDIR/haste-map-react-native-packager-*

just pod install will work

please. downgraded  Xcode 10.1

Another react-native link helped me. :(

React Native is unsustainable, 100 resolutions offered for every bug someone encounters. One change and the entire build process, boilerplate and reason to use react native falls apart. How can companies truly add this development process to a product pipeline. ridiculous!!!!

They say it'll be better from 0.59 on.. hopefully they're right about that
@philipaarseth I hope you ate your words when 0.60 came out 😆

I have seen this in other threads before, but running the following solved the issue for me:
cd node_modules/react-native/scripts
./ios-install-third-party.sh

I thought this had been fixed in 0.59 or before and I remember seeing it running automatically in some builds, but looks like there are still cases where it's missing.
Definitely worth including in the troubleshooting section of your project, since this is not the first time I see this happening.

Run this command: $ conda deactivate

Resolved with the following :
rm -rf node_modules
rm -rf ios/Pods
rm ios/Podfile.lock
rm -rf ~Library/Developer/Xcode/DerivedData

Then I reinstalled my dependencies (npm & pod) and it worked :)

There are a lot of solutions available on the internet but it’s your job to decide which solution is applicable to your situation. While searching for this issue I found a lot of stupid/misleading answers. One of them was, and I quote,
https://medium.com/@harekarpranit/resolving-cocoapods-issues-in-react-native-project-59386a3900f7

@jpudysz thanks, it works for me.
my error log is :
The following commands produced analyzer issues:
Analyze /Users/superqa/jenkins/workspace/xxxxx-xxxx-iOS-new/node_modules/react-native/ReactCommon/yoga/yoga/Yoga.cpp normal arm64
Analyze Base/RCTModuleMethod.mm normal arm64
(2 commands with analyzer issues)

Android works really perfectly, just iOS... :-(
It gets fairly difficult when having lots of 3rd party dependencies.

in my case, Xcode just did an automatic update and produced such problem.
what i did to solve the problem was:
cd ios
rm -fr Pods
rm Podfile.lock
pod install
reinstall the Pods and Podfile solved my problem

clear derived data
cd ios
remove Pods and Podfile.lock
pod install

I've done all of the above steps, gotten the build working, and now I get this error. FWIW I am upgrading from Xcode 10.1 -> 11.1 AND i am upgrading react native from 0.57.8 -> 0.59.9
dyld: Library not loaded: @rpath/XCTest.framework/XCTest
  Referenced from: /Users/par/Library/Developer/CoreSimulator/Devices/2B68242E-D2AF-49A4-9AEA-C320820D8D2F/data/Containers/Bundle/Application/E665681B-C213-42C0-9A51-746B4CA17599/Kismet.app/Kismet
  Reason: image not found

I was also seeing the #include <folly/Portability.h> error. The issue in my case were missing subspecs in the podfile.
It builds fine for me with:
  pod 'React', :path => '../node_modules/react-native', :subspecs => [
    'Core',
    'CxxBridge', # Include this for RN >= 0.47
    'DevSupport', # Include this to enable In-App Devmenu if RN >= 0.43
    'RCTText',
    'RCTNetwork',
    'RCTWebSocket', # needed for debugging
    'RCTImage',
    'RCTWebSocket', # Needed for debugging
    'RCTAnimation', # Needed for FlatList and animations running on native UI thread
    # Add any other subspecs you want to use in your project
  ]

  pod 'yoga', :path => '../node_modules/react-native/ReactCommon/yoga'

  # Third party deps podspec link
  pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
  pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec'
  pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'

I had an issue getting glog to install, ended up having to issue this command sudo xcode-select  --switch /Applications/Xcode.app/ pretty sure because I was running Xcode from a different directory, then moved it into my /Applications directory, and the tooling was all messed up.

@jenskuhrjorgensen your rm command is removing the whole $TMPDIR because of a space you have in there.

@jduffy7 There is probably no reason for doing that. Thx, it's been corrected!

@jenskuhrjorgensen Thank you!!!!!

Running pod update worked for me.

Any update .. ?

Above solutions did not work, the following worked for me:
cd ios
pod repo update
pod update

try with: https://react-native-community.github.io/upgrade-helper/

@khanguslee I do it but sadly it's won't build
and got this error
** BUILD FAILED **

The following build commands failed:
PhaseScriptExecution [CP]\ Check\ Pods\ Manifest.lock /../ios/build/music/Build/Intermediates.noindex/music.build/Debug-iphonesimulator/music.build/Script-C5D676D55145145333E00AC9.sh
(1 failure)

The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.

A quick google search with your error message gives me a solution here.


[ Fabric ] Update feature/fabric220 with feature/helm3 branch

Changelog

update feature/fabric220 with feature/helm

Reviewed by
@suvajit-sarkar @jagpreetsinghsasan

There are conflicts


Shortcuts won't open

I've had big problems with both pcsx2 and ice, both yesterday and today, but those problems were fixable.
Now I've got a new problem that has been super annoying for hours....
It happened after the new Windows update though.
Everything in Ice is as it should be, all the .txt files are correct (in my opinion) and Ice adds the titles of the games to steam, but with a folder for icon. And when I try to open it just open the correct pcsx2 directory window.. I've tried to change the "startup location" in steam but without success :(
Please help, I'm going mental over here

@elliebelliebooh what fixed the issue for you?

@nateberkopec actually, just removing the shortcuts from Steam, getting mad at my computer and restarting everything, and launching ICE again and then it just worked 👍