[Android] Extreme lag after upgrade to 0.39.2 and 0.40.0

Description
Updating from 0.36.0 to 0.39.2 and 0.40.0 renders the app unusable after minimal interaction. The javascript thread slowly grinds to a halt until it becomes unresponsive. Native UI, such as scrolling or native animations is unaffected. Problem persists with 0.41.0-rc.0
It works perfectly well with 0.38.0
Reproduction
I managed to reproduce this in a freshly installed app with an infinite scroll list containing rows with images. With 0.40.0, the JS driven animation begins to lag after only ~150 items. WIth 0.38.0, animation stays smooth as long as there is no rendering.
See attached videos below:
0.38.0
0.40.0
Test app can be found here
A relative StackOverflow question.
Solution
I suspect the new C-based CSS implementation, as that is the only major change from 0.38 to 0.39. Another reason could be a problem with removeClippedSubviews.
Additional Information

React Native version: 0.39.2 / 0.40.0
Platform: Android
Operating System: MacOS

I've tracked down the commit responsible for this issue - Call handleUpdateLayout even if the content didn't change

Were you able to confirm that the slowdown is because of more onLayout callbacks happening without actual changes to layout?

@sahrens Yes, I built RN from source from the commit before and all was good ...

I can confirm this problem in my application, i have updated from 0.36 to 0.40 and UI becomes unusable after render 100 items in a simple listview where the rows are only text and image.
Today I have tested 0.41.0-rc.0 and master but problem is still present.

I have tested today 0.41.0-rc.1 - still the same.

I'm facing the same issue, any progress or workaround?

Have no idea what to do. It actually forced me to stop working on  my project(( I have no time to dig into debugging and so on. If you figure out something, please let me know too.

Вторник, 31 января 2017, 17:05 +03:00 от Neo<EMAIL_ADDRESS>I'm facing the same issue, any progress or workaround?
—
You are receiving this because you commented.
Reply to this email directly,  view it on GitHub , or  mute the thread .

two screenshots of android profiler:

I want to add my voice to this chorus. I upgraded from 0.34.1 to 0.40. I was pleasantly surprised by some of the improvements (Dailymotion working well within the Webview, some keyboard problems fixed, screen rotation with better behavior) but then I realised the performance drop. I was close to releasing my app but the problem is so bad I have to wait. Still waiting. Coded as a stop-gap a simple page trick with only 50 elements per page to ensure smooth scrolling and touch responses. And this is is on a Samsung S6. Performance is significantly worse on lower-end/older devices.
This is an extremely serious, almost fatal issue for many projects. I hope it gets fixed very soon.

We're seeing the exact same issue here as well, iOS works fine, Android has become very laggy post update.

Same here
@sahrens Any Idea who is the right person to approach with this issue?

Same here. We had to downgrade to 0.38.

And same here. Hopefully this can be addressed soon.

@K-Leon I think that @astreet is the author of a commit (https://github.com/facebook/react-native/commit/d63ba47b59e3261403800c1f741d979a089efb48) introducing the new CSS engine.

This wouldn't be related to that commit -- it's more likely related to https://github.com/facebook/react-native/pull/11222 (is anyone able to try reverting that locally and see if the problems go away?)
I'll post internally and try to get someone on it.

The commit of #11222 was cherry-picked into 0.38 and 0.39. People are reporting this doesn't happen on 0.38. Maybe this in not the root cause?

0.38.0 is different from 0.38.1
I haven't test the reverting thing, but I have to say there are a lot of layout issues on Android when I'm trying to implement a HTML render, then I switched to Nodes which is still experimental and all the LAYOUT DON'T UPDATE issues on Android are gone.
But when I upgrade my app to the latest version of RN, I scroll a list to load more data, the following interactions become so buggy that there is nearly no response on touch, and I have to wait for several seconds

Reverting that commit makes quite a large difference to us - I'm not 100% certain that performance is back to what it was before 0.39 - we'll continue testing.

which commit should I revert to temporarily fix the problem?

It depends of your RN version as it was cherry-picked in the previous releases:
>0.40: https://github.com/facebook/react-native/commit/fb230000a8d70fbc1e4c6ccfd9470de838554371
0.39: https://github.com/facebook/react-native/commit/4cd4b4b92207d0d77ef73374a6ba111103a7156d
0.38 https://github.com/facebook/react-native/commit/9a13def8b6fbb2ae3d1f31f63066f87527e56fcd

I have a fix in review internally that I'll hopefully get in today. I'll make sure it gets cherry-picked into the next release.

@astreet
Cool! Maybe It is worth to cherry-pick the fix into some older releases, too? Still many apps use 0.39 or 0.38 because of breaking changes in 0.40.

I'm not sure on the feasibility of that, @mkonicek?

Fix is in: https://github.com/facebook/react-native/commit/15429e333f8fd80c4778f222058dbb16278cf625
Let's make sure it doesn't break anything internally and then we can see about getting it cherry-picked.

Just tested the fix on my repro repo with the bug and it works!
I hope the performance problem is solved for the others and both world will be happy 👍

Yes, I kept your original PR in mind :) Thanks for checking and reporting back!

Seems that this commit cannot fix my issue. My issue is that after scrolling a large list for a while, the touch response is extremely slow, the Touchable onPress event was triggered after I physically pressed the screen for 3-4 seconds.  The JS thread fps dropped to 30 fps while I am scrolling the list.
RN: 0.40
Dev mode: off

@ming436534: and that was a regression upon upgrading 0.39.2 to 0.40.0?
@sdcooke: can you verify that this fix improves your perf issues in the same way the revert did?

Hi @astreet Thank you for the fix. I too had performance issue with my app. I would like to know how do I get the fix for my app. My react-native version is 0.41.2. Do I just upgrade the react-native?

@astreet this fix has the same impact as reverting.

@KakarN You'll probably need to wait until the next release of react native, or build the master version from source. We haven't yet released a new build that has this fix but I'll make sure we do soon.

oK @astreet  Will be waiting for it. Thanks again.

@ming436534 : aah. that was exactly my issue. Bil lag after 50-100 components (with external images) The press is acknowledged immediately (I can see it with a console log) but it would take 3-4 (or more) seconds before displaying what it is supposed to. I really hope @astreet 's fix solves it and makes it to 0.42. Otherwise, I'll revert to 0.38 :(. I can't wait much longer before launching the app.
(PS: Can anyone suggest an easy (read not too painful) way to downgrade RN? I'm looking it up but so far, I'm not sure which way to go.)

@astreet any plan to make a cherry-pick?

Unfortunately, no: See @mkonicek's post here: https://www.facebook.com/groups/react.native.community/permalink/931576460311266/
It looks like this could potentially be a breaking change for libraries that are dependent on the previous over-zealous onLayout behavior.

Is there a fix available 1 March?

The fix will show up in v43 (the march 2017 release): see https://github.com/facebook/react-native/releases

The 0.43 RC will likely be available around 9am CET (Central European Time)

I have updated to v0.43.0-rc.0 and it's still very slow. ListView gives a lot of lagg.

@sahrens: there might be other listview lag issues besides the one I fixed. Do we have any public resources for people to be able to debug?

Could be a million things. General Android performance tooling? Is there a public fbsystrace equivalent? If the issue is just JS, you can try adding
require('InteractionStallDebugger').install();

To their bundle.

I also upgraded to v0.43.0-rc.0, like @RichardLindhout. If anything, it felt even slower. With 0.41, my Galaxy S6 was fine with 50 items per page, now it's around 25 (more than that and I have to wait 4-5 seconds before getting a display). My items render as a picture, some text and icons, and are connected to redux. So not the simplest components but still, the same that used to fit perfectly by hundreds in ListView 0.34.1 version.
I'm now trying to make FlatList work. Having some issues with it but I haven't tried hard enough yet.
My last hope before seppuku :-D

@sahrens it performs just normal on ios. Before I updated to later versions of React Native the app performed not the same as (a recyclerview in Android) but still it worked wel enough. Now when I scroll the listview my whole app (only on Android) becomes just not usable all the buttons and navigation are slow. When I select items in the listview they become selected after sometimes 10 seconds. If I don't scoll they are just fast. @ksegla Let me know if that change does make a difference!

 Once I realised my mistake, FlatList was actually simple to use (though I had to bind the render function in order to see my component props).
FlatList does seem a lot faster (though it seems that it just skips out rendering components when you scroll too fast). Bad news is: the problem is still there. It takes even longer to respond to touches. I no longer think it's a ListView or FlatList problem only. It may be something deeper. I spent quite some time experimenting with 0.42 and the prerelease 0.43. ListView, FlatList. Worse response times than 0.41. So I just rolled back to 0.41, where at least my 50-component-a-page-trick consistently holds: quasi-immediate feedback-and-activity after fast scrolling 50 components and pressing one. 0.42 and 0.43 were taking much longer.
As @sahrens said, it may be a million of things. I will try his suggestion (since the fps drop only affects JS) but I'm now thinking that either it's something very specific on our side and eventually we'll figure out a way to adapt to the new RNs or it's a big thing that will prompt major changes once more developers switch to the newest versions. If I uncover anything new, I will report it here or may be we should create a new issue (?). @ramilushev Did 0.42 or 0.43-rc solve your original issue?

@ksegla Could you do a git bisect to isolate the bad commit?

@ksegla I can confirm that the issue is not fixed. Tested with 0.43.0-rc.0 with the test app from the OP (found here).
For the lazy - It's basically an infinite list with items consisting of images, and an absolute positioned block that is animated constantly from left to right with a JS driven animation (see videos from OP).
The JS driven animation (native is perfectly fine) is completely blocked for a few seconds after rendering of new items in the list has finished. Not only that, but after it resumes, it's frame-rate seems to drop proportional to the amount of rendered items. I'll upload a video shortly.

Same issue here after upgrading to 0.40+
Our brownfield app uses a ListView mounted with 1000 placeholders (~20 are rendered on mount). It is immediately slow to respond to touch event (~2 or 3 seconds). When scrolling, the datafetching and the placeholders replacement takes a huge amount of time.
I have spied the MessageQueue and it looks like every message needs a considerable effort to be read (Android monitor shows that the device CPU rates 40% until the MessageQueue is not empty).
I can see that @astreet fix https://github.com/facebook/react-native/commit/15429e333f8fd80c4778f222058dbb16278cf625 (cherry-picked in the 0.43 branch) removes unnecessary onLayout which lightens the queue, but I can't feel any noticeable UI improvements. The real problem is still here.

What messages are you seeing in your queue? Do you have a app I can repro with?

@K-Leon My app depends on some libraries that are having hard time with downgrading (some radical adaptation to the breaking changes in 0.40, I guess). So even reverting to 0.38.0, which seems to be a safe version to start the bisect with, proved painful with errors here and there. Right now, real work is breathing down my neck so I don't have the time to go full app debugging or coding/experimenting with simple examples.
-- This sounds like "I don't wanna do the work. I'd rather come here and whine about the issue" :-) but it's true

We're having trouble reproducing the lag being described here.
Can you provide more details? The bridge messages @astreet asked for, what hardware and API version you're running on, and anything else you can think of? Do other react native apps work ok on your device, like the Exponent app? Facebook marketplace? Li.st?

I have attempted to debug this issue using the InteractionStallDebugger  in our own app, it looks like NavigationExperimental or Native Animation changes may be the cause of the stalls.
NavigationTransitioner is the top "time waster" when using the tool:

Inclusive wasted time (ms)
Instance count
Owner > Component
Render count

1956
8
NavigationTransitioner > View
8

I'm not certain this is the cause yet, I will try to reproduce in an example project.

Bridge messages
@sahrens @astreet The messages are pretty the same between my brownfield app and the test app linked in the OP.
I'm able to repro the lag on my Samsung SM-G930F (Galaxy S7) using Android 6.0.1, API 23. Other RN apps work well, the test app using version 0.38 works well too.
I've ran the test app in RN 0.40.0 and save the full output when scrolling from index 250 to 300.
Here is some samples from the output:
JS animation of the orange bar
03-08 12:37:31.860 9886-23047/com.zero40app I/ReactNativeJS: N->JS : JSTimersExecution.callTimers([[3709]])
03-08 12:37:31.860 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.updateView([230,"RCTView",{"transform":[{"translateX":44.06070971011271}]}])
03-08 12:37:31.870 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.updateView([232,"RCTView",{"transform":[{"translateX":44.06070971011271}]}])
03-08 12:37:31.880 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.updateView([233,"RCTView",{"transform":[{"translateX":44.06070971011271}]}])
03-08 12:37:31.880 9886-23047/com.zero40app I/ReactNativeJS: JS->N : Timing.createTimer([3710,1,1488973051891,false])

A bunch of these while I touch the screen:
03-08 12:37:33.340 9886-23047/com.zero40app I/ReactNativeJS: N->JS : RCTEventEmitter.receiveEvent([5,"topScroll",{"responderIgnoreScroll":true,"target":5,"layoutMeasurement":{"height":507.4285583496094,"width":411.4285583496094},"contentSize":{"height":77440,"width":411.4285583496094},"contentOffset":{"y":75053.7109375,"x":0},"contentInset":{"right":0,"left":0,"bottom":0,"top":0}}])
03-08 12:37:33.360 9886-23047/com.zero40app I/ReactNativeJS: N->JS : RCTEventEmitter.receiveEvent([5,"topScroll",{"responderIgnoreScroll":true,"target":5,"layoutMeasurement":{"height":507.4285583496094,"width":411.4285583496094},"contentSize":{"height":77440,"width":411.4285583496094},"contentOffset":{"y":75100.859375,"x":0},"contentInset":{"right":0,"left":0,"bottom":0,"top":0}}])
03-08 12:37:33.380 9886-23047/com.zero40app I/ReactNativeJS: N->JS : RCTEventEmitter.receiveEvent([5,"topScroll",{"responderIgnoreScroll":true,"target":5,"layoutMeasurement":{"height":507.4285583496094,"width":411.4285583496094},"contentSize":{"height":77440,"width":411.4285583496094},"contentOffset":{"y":75146.2890625,"x":0},"contentInset":{"right":0,"left":0,"bottom":0,"top":0}}])
03-08 12:37:33.400 9886-23047/com.zero40app I/ReactNativeJS: N->JS : RCTEventEmitter.receiveEvent([5,"topScroll",{"responderIgnoreScroll":true,"target":5,"layoutMeasurement":{"height":507.4285583496094,"width":411.4285583496094},"contentSize":{"height":77440,"width":411.4285583496094},"contentOffset":{"y":75187.7109375,"x":0},"contentInset":{"right":0,"left":0,"bottom":0,"top":0}}])
03-08 12:37:33.410 9886-23047/com.zero40app I/ReactNativeJS: N->JS : RCTEventEmitter.receiveEvent([5,"topScroll",{"responderIgnoreScroll":true,"target":5,"layoutMeasurement":{"height":507.4285583496094,"width":411.4285583496094},"contentSize":{"height":77440,"width":411.4285583496094},"contentOffset":{"y":75229.7109375,"x":0},"contentInset":{"right":0,"left":0,"bottom":0,"top":0}}])
03-08 12:37:33.430 9886-23047/com.zero40app I/ReactNativeJS: N->JS : RCTEventEmitter.receiveEvent([5,"topScroll",{"responderIgnoreScroll":true,"target":5,"layoutMeasurement":{"height":507.4285583496094,"width":411.4285583496094},"contentSize":{"height":77440,"width":411.4285583496094},"contentOffset":{"y":75269.7109375,"x":0},"contentInset":{"right":0,"left":0,"bottom":0,"top":0}}])
03-08 12:37:33.450 9886-23047/com.zero40app I/ReactNativeJS: N->JS : RCTEventEmitter.receiveEvent([5,"topScroll",{"responderIgnoreScroll":true,"target":5,"layoutMeasurement":{"height":507.4285583496094,"width":411.4285583496094},"contentSize":{"height":77440,"width":411.4285583496094},"contentOffset":{"y":75306,"x":0},"contentInset":{"right":0,"left":0,"bottom":0,"top":0}}])
03-08 12:37:33.460 9886-23047/com.zero40app I/ReactNativeJS: N->JS : RCTEventEmitter.receiveEvent([5,"topScroll",{"responderIgnoreScroll":true,"target":5,"layoutMeasurement":{"height":507.4285583496094,"width":411.4285583496094},"contentSize":{"height":77440,"width":411.4285583496094},"contentOffset":{"y":75343.4296875,"x":0},"contentInset":{"right":0,"left":0,"bottom":0,"top":0}}])
03-08 12:37:33.480 9886-23047/com.zero40app I/ReactNativeJS: N->JS : RCTEventEmitter.receiveEvent([5,"topScroll",{"responderIgnoreScroll":true,"target":5,"layoutMeasurement":{"height":507.4285583496094,"width":411.4285583496094},"contentSize":{"height":77440,"width":411.4285583496094},"contentOffset":{"y":75378.5703125,"x":0},"contentInset":{"right":0,"left":0,"bottom":0,"top":0}}])
03-08 12:37:33.500 9886-23047/com.zero40app I/ReactNativeJS: N->JS : RCTEventEmitter.receiveEvent([5,"topScroll",{"responderIgnoreScroll":true,"target":5,"layoutMeasurement":{"height":507.4285583496094,"width":411.4285583496094},"contentSize":{"height":77440,"width":411.4285583496094},"contentOffset":{"y":75412.5703125,"x":0},"contentInset":{"right":0,"left":0,"bottom":0,"top":0}}])

Mount of a ListView item:
03-08 12:37:33.980 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10768,"RCTView",1,{"alignItems":"stretch","height":150,"marginBottom":10,"justifyContent":"center"}])
03-08 12:37:33.990 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10769,"RCTView",1,{"height":20,"backgroundColor":-16711936,"alignItems":"center","justifyContent":"center"}])
03-08 12:37:33.990 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10770,"RCTText",1,{"lineHeight":20,"color":-40121,"accessible":true,"allowFontScaling":true,"ellipsizeMode":"tail"}])
03-08 12:37:33.990 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10772,"RCTRawText",1,{"text":"484"}])
03-08 12:37:33.990 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.setChildren([10770,[10772]])
03-08 12:37:33.990 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.setChildren([10769,[10770]])
03-08 12:37:33.990 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10773,"RCTView",1,{"flexDirection":"row","flexGrow":1,"backgroundColor":-65536,"flexWrap":"wrap","alignItems":"flex-start"}])
03-08 12:37:33.990 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10774,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053983"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.000 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10775,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053984"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.000 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10776,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053985"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.000 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10777,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053985"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.000 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10778,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053986"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.000 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10779,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053986"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.010 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10780,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053987"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.010 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10782,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053988"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.010 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10783,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053988"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.010 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10784,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053989"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.020 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10785,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053989"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.020 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10786,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053990"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.020 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10787,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053991"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.020 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10788,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053991"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.020 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.createView([10789,"RCTImageView",1,{"width":100,"height":100,"overflow":"hidden","borderWidth":1,"borderColor":-16744448,"shouldNotifyLoadEvents":false,"src":[{"uri":"http://lorempixel.com/400/400?date=1488973053992"}],"loadingIndicatorSrc":null}])
03-08 12:37:34.030 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.setChildren([10773,[10774,10775,10776,10777,10778,10779,10780,10782,10783,10784,10785,10786,10787,10788,10789]])
03-08 12:37:34.030 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.setChildren([10768,[10769,10773]])
03-08 12:37:34.030 9886-23047/com.zero40app I/ReactNativeJS: JS->N : UIManager.manageChildren([6,null,null,[10768],[484],null])

Some undesirable layout events (31 occurrences of this one in the full output):
RCTEventEmitter.receiveEvent([5,"topLayout",{"target":5,"layout":{"height":507.4285583496094,"width":411.4285583496094,"y":0,"x":0}}])

Those events are removed by 15429e3 (not 100% sure, I checked that 2 days ago by adding a onLayout event on my ListView item, not by spying the queue), but as you can read from the output, those events are literally drowned in the flood of messages.

cc @janicduplessis

I've investigated the problem with a simplified version of the OP test app: https://gist.github.com/ncuillery/0b576650cebb34317e4c953e0efb56d5
I've removed the animation and replaced all the images with Text elements to be sure that it has nothing to do with Fresco and image loading. I've also activated the spy on the MessageQueue.
I think I have a scenario that isolate the problem:

Run the app with Android Studio
Open the Android monitor in Android Studio
Open the perf monitor in app
Scroll to index 500 (when the loading of further items tends to be slow on my device)
Wait for the UI to be responsive (I've added a Toast when touching the first blue Text element)
Scroll to top as fast as your finger can do!

👉 The UI isn't responsive for a long time, the Touchable element has no effect.
👉 The CPU is busy at 20% continuously
👉 No message appears in logcat, absolutely nothing is logged in the MessageQueue
👉 The in-app Perf monitor shows UI thread at ~56fps and JS thread at ~16fps
Finally, after an important amount of time (could be more than 1 minute), it seems that the system gets unblocked:

The UI is responsive again, the toast shows up immediately after touching
The CPU becomes idle:
I can see the bridge messages in logcat again
The JS thread is back to ~55fps

Scrolling back to index 500 produces the exact same situation.
When I follow the same scenario with 0.38.0. There is no JS thread drop rate when scrolling fast. The CPU turns idle as soon as I stop scrolling.
With 0.39, the behavior is the same as 0.40.
In conclusion, I would say that the problem appears in 0.39.0. It seems that a time-consumer (and CPU-consumer) task is triggered when scrolling the ListView, this task makes the bridge completely stuck until it is finished. That's why any feature requiring a communication via the bridge (JS anim, datafetching, navigation, rendering components, ...) is affected.

I had observed a similar bug in our app where transition between screens was taking almost 5-7 seconds. On enabling spy mode, I found out that MessageQueue was blocked for exactly the same duration. So there was certainly some operation happening on the JS thread that blocked the UI updates (and everything else) until it finished.

This is how we figured out the actual code causing the delay:

Filter out the MessageQueue logs from LogCat

As soon as the blocking starts, isolate the recently logged statements just before blocking happened (refer screenshot)

Now carefully observe those isolated logs. There is a strong probability that some event got triggered from there, that resulted in this blocking operation. In our case, as shown in the attached image, we were triggering an event as soon the active screen went into onPause state (onDisappear). That event triggered a callback which executed a heavy synchronous operation on JS thread. This resulted in a significant delay in the opening of the next screen

After optimising that callback method’s code, everything started working fine

Lesson: It is really really important that any necessary synchronous operation that we may want to perform, should happen on the native side. JS thread should exclusively be for UI.

+1

I have tested also on 0.43.rc0 and 0.43.rc1 and it is still happening (super slow responsiveness in ListView).
On 0.38 it is fine.
I also tried with a new FlatList and VirtualizedList components and the rendering is still really slow.
Hope this helps.

@astreet @ncuillery @ericvicenti I looked at the changelog for 0.39 and what seemed like the biggest change is the move to c++ based css layout (yoga). With that in mind I ran the test app and tried pausing the debugger during the lag to check out what the threads where doing at that time and something that came out is that the native-modules thread was always running jni_YGNodeCalculateLayout. I added some logs to UIManagerModule#onBatchComplete, where this function is called from and the results are interesting.
Here is logs when scrolling early when the ListView renders few items https://gist.github.com/janicduplessis/01fa5d19052f7054199f5280842a9be9. Looks good, now let's compare to when the ListView is rendering about 300 items.
https://gist.github.com/janicduplessis/6e18bed6f888aeca8209c0e85ffc40a0
I annotated this one with what I was doing. You can see we receive the touch event from native to JS and it is processed in about 100ms and JS responds by show a toast. Now the native module thread seems completely stuck processing layout events and finally after 8 seconds the breakpoint I put in ToastModule.java is hit.
Looks like the issue is that we are spending a huge amount of time doing layout on the native-module thread which blocks other native modules from doing their thing.
Questions / potential solutions

Why are we doing layout on the native-modules thread, was it like this before 0.39? This could be moved to thread separated from the other native modules.
Why is layout so slow? Looks like we are doing something wrong. Recalculating layout when adding new views in the list should not take many batches of over 50ms.

Nice find. I forwarded this thread to the yoga team at FB, but it would be nice if you could do some more analysis. Can you run a performance profiler while it's busy and see what function calls are hot? Profiling c++ code on Android is a bit tricky, but there are some tools:
https://android.googlesource.com/platform/system/extras/+/master/simpleperf/README.md
https://google.github.io/fplutil/android_ndk_perf.html
Etc

Seems like this is a RN issue with the yoga integration (becuase it only shows up on android). I'll look into it next week.

Nice find Janic, seems like strong evidence the native modules thread is being backed up. If it's an issue with layout, then moving layout to another thread unfortunately won't help with click latency since that will almost definitely need to do a layout itself. Can you share the code you used to collect those logs and I'll look into whether it seems we're doing more layouts than expected/if they're particularly more expensive? Also, just to be clear, this same code doesn't have this issue on iOS, right?

@astreet I haven't tested on iOS but according to this thread it happens on iOS only. I simply logged the time it took to run dispatchViewUpdates here https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/react/uimanager/UIManagerModule.java#L533

@janicduplessis sorry, I meant can you link the code for the test app you were using?

Is this still a problem in android and iOS?

@astreet I used the code provided by ncuillery in this gist https://gist.github.com/ncuillery/0b576650cebb34317e4c953e0efb56d5

@emilsjolander and I investigated, this is two different issues compounding on each other:

There was a regression with the switch to native Yoga where, even though a layout hierarchy would be cached, we still copy the outputs from C to Java for the entire tree. This doesn't really show up for smaller screens, but for listviews with hundreds of rows, this could take upwards of 50ms.
When we switched to the new C++ bridge, an optimization got removed where we wouldn't call onBatchComplete when there weren't actually any native modules calls (e.g. if we made a JS module call but JS didn't call any native modules).

These two combined so that on each frame, the scroll event from the list view would trigger an onBatchComplete in UIManager, which would trigger a re-layout (cached, so no actual layouting would happen), but then we'd spend 50ms+ copying the entire layout result into Java.
I'm currently landing a very simple diff that fixes 2. which for me which largely mitigates the problem. @emilsjolander will still be working on a fix for 1. this week hopefully since that's still bad, so I expect both fixes to be landed by next week.
Thanks @ncuillery and @janicduplessis for providing a repro and doing investigation!

BTW, a good way to investigate these issues yourself without having to put a bunch of logging statements in your code is to use Systrace. I wrote a guide to doing that here: https://facebook.github.io/react-native/releases/0.31/docs/android-ui-performance.html
As an example, here's the trace I captured scrolling through the app in the repro.

It shows the native module thread being backed up with layout calls (as Janic was able to gather as well). This is also why it's so important to have a good repro we share -- that way we can look at the exact issue people are running into with certainty :)

Fix for the missing bridge optimization is in master now: https://github.com/facebook/react-native/commit/c8d922b4670127c417d744a0a1412cc6ad961fef . This should help fix the majority of them problems people were seeing. Yoga fix will be landing soon.

Hi @astreet ,
Is there a way to cherry-pick this fix into 0.43.rc instead of waiting for 0.44.0rc version?

And 0.42.2 😉

ping @grabbou

Hey @grabbou ,
Is there a way to include this fix into 0.43.rc release instead of waiting for the next one?
As you can see from the comments, this is a really important performance fix.
Thanks :)

Yeah, I am back to work tomorrow and will release important updates. The
conference trip distracted me a bit.
On Thu, Mar 16, 2017, 18:37 Arsen Ghazaryan<EMAIL_ADDRESS>wrote:

Hey @grabbou https://github.com/grabbou ,
Is there a way to include this fix into 0.43.rc release instead of waiting
for the next one?
As you can see from the comments, this is a really important performance
fix.
Thanks :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/11809#issuecomment-287134554,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWcxvcj-OUJmsc6_5ncCMbDs-ef7uaMks5rmXNsgaJpZM4Lfm7J
.

0.43.0-rc.3 released with the fix

Yoga fix has not landed yet. Hopeing today

Thanks a lot!
Now, let's wait for the Yoga fix :)

Yoga fix had to be reverted as it broke some unexpected things. We will work on getting it in as soon as possible.

Thanks for the update.

I just wanted to thanks all the people involved in this ticket. I have to release a new version of my app in 2 weeks and was going crazy with the 10fps + 20% constant cpu usage. You're geniuses.
Have a nice week!

@emilsjolander Any update on the yoga fix?

Still working on it

Yoga fix has now landed

You rock @emilsjolander !

I'll cherry pick that were it makes sense. Not sure if it's already in
latest RC, I think I picked it just before it landed.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/11809#issuecomment-291224259,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWcxgQu6d9mcoY7xE4K_X1_UuBRLoAsks5rsTT2gaJpZM4Lfm7J
.

great work @emilsjolander and Yoga 🎉
The fix should be cherrypicked into v0.43.1, if it is not already in v0.43.0 ?
cc @grabbou

Hey @emilsjolander
Will this have any affect on IOS side also?
It will be great if you could provide a PR/Commit so we can see the files it is touching.
Thank you!!!

No effect on iOS.
Commits:
https://github.com/facebook/yoga/commit/5884ab7b76a66b2a5b22a8ebd164f7a9b8f551ed
https://github.com/facebook/yoga/commit/5112564f083422194cdb1baf1a97c0308cbc14cb

Many thanks! Any chance this could find its way into 0.43.1?
Or should we fork RN and Yoga and build RN with Yogas patch?

I'll cherry-pick it into 0.43.1 as well, but I'll do it tomorrow from
office. Depending on your time-zone, it might be there when you wake up :)
On Mon, 3 Apr 2017 at 21:09 Atticus White<EMAIL_ADDRESS>wrote:

Many thanks! Any chance this could find its way into 0.43.1?
Or should we fork RN and Yoga and build RN with Yogas patch?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/11809#issuecomment-291243101,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWcxs4p2VdZamwHUy_2wFQBo2OTJtmrks5rsUQGgaJpZM4Lfm7J
.

I tested in 0.44.0-rc.0 and its fixed, thanks! :)

Hey @grabbou
Just wondering if you had time to cherry-pick it into 0.43.1 ?

@grabbou I noticed 0.43.1 didn't include the yoga fixes, is it possible to cherry pick them or do they depend other commits?
The matching commits in React native are:
https://github.com/facebook/yoga/commit/5884ab7b76a66b2a5b22a8ebd164f7a9b8f551ed = https://github.com/facebook/react-native/commit/759b8ccf71ccf9a017be186327eb8701e760b21a
https://github.com/facebook/yoga/commit/5112564f083422194cdb1baf1a97c0308cbc14cb = https://github.com/facebook/react-native/commit/f1371ec24c7fbe66ec80690f8dc7636dd30dbb3e

Yeah, I've already talked to Emil about that. Will release one more version
later today
On Wed, Apr 5, 2017, 11:05 Andrew Jack<EMAIL_ADDRESS>wrote:

@grabbou https://github.com/grabbou I noticed 0.43.1
https://github.com/facebook/react-native/commits/0.43-stable didn't
include the yoga fixes, is it possible to cherry pick them or do they
depend other commits?
The matching commits in React native are:
facebook/yoga@5884ab7
https://github.com/facebook/yoga/commit/5884ab7b76a66b2a5b22a8ebd164f7a9b8f551ed
= 759b8cc
https://github.com/facebook/react-native/commit/759b8ccf71ccf9a017be186327eb8701e760b21a
facebook/yoga@5112564
https://github.com/facebook/yoga/commit/5112564f083422194cdb1baf1a97c0308cbc14cb
= f1371ec
https://github.com/facebook/react-native/commit/f1371ec24c7fbe66ec80690f8dc7636dd30dbb3e
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/11809#issuecomment-291799789,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWcxk5zfKD_hRk8hWwtOx3lf5gC-1dMks5rs1lqgaJpZM4Lfm7J
.

@hey @mizinin, don't be confused anymore!
PS. 0.43.2 is now on Circle and should be on npm in like two hours. If anyone wants this to be cherry-picked into old release, please find the ticket [XXX] commits to cherry-pick and leave a note there.

Having said so, can this issue be closed now?

I have tested this and can confirm it is fixed. A big thanks to everyone involved!!! You can close this.

Are you sure this is fixed? I have just finished converting a screen from using ListView to SectionList and it has gone into completely unusable mode on my physical Android 5.0.1 device.
I'm on react-native v0.43.3.
It initializes slowly, taking at least 5 seconds for the initial render, then in the perf monitor the JS thread says -2.1 fps (yes, with a minus).
During this time the app is completely locked up, except for scrolling the list, which seems to work.
The -2.1 fps situation clears itself after 20+ seconds and returns to 60 fps
One interesting thing is that if I enable Remote JS Debugging the app never goes below 60 fps and everything is super fast. Also GenyMotion is super fast as well, just the device has issues (but now when JS is running via remote JS).
Any clues?

@andreialecu this issue affected ListView and SectionList similarly I believe, so if you weren't seeing any issues on ListView then my guess is you accidentally introduced some weird perf regression with your transition to SectionList.  The fact that the debugger makes a difference also implies a different issue.
If you can't sort out the problem, can you provide a repro case/sample code?

It seems like switching JS Dev mode to off helped the problem somewhat, as did removing a few console.log statements I had and disabling redux-logger.
Now it renders almost instantly (or at least without any perceived lag), but the JS thread still stalls bouncing between -2.1 fps, 2.1 fps for close to 10 seconds until it recovers.
All my section headers and list items are PureComponents.
However, if I trim down the renderItem to a simple <Text>Hello World</Text>, it seems to take around 1 second to recover.
The original list item component itself is not super complicated, but has several nested <View>s. I did notice that the more I strip it down, the better performance gets.
This didn't seem to be as much of a problem with ListView.
And if I run it with Remote JS Debugging, it is instant, not exhibiting the problem even with the original renderItem, it never drops below 55fps - not even for a milisecond.

Alright, I kept the code for the ListView and it is identical to the SectionList implementation, but it runs much faster and never drops a frame.
However, now that I got rid of the console.log statements and redux-logger, I see that the issue I was experiencing wasn't this one. I confused the slowness from https://github.com/evgenyrodionov/redux-logger/issues/32 with an issue in react-native rendering.
It still seems like SectionList and/or FlatList have problems, but probably unrelated to this particular issue.

I'm still having the weird issue that @andreialecu discussed earlier using 0.43.3.  On a physical device our app seems to run incredibly slow becoming unresponsive unless I have remote debugging turned on.
Without remote debugging I will drop to -2.0  fps for 10-20 seconds and then will come back up.  During this time the app is not responsive.  When I turn on remote debugging I average 50-60 fps.
I do not have any console.logs or redux logger turned on. I have also created a new react-native project and moved my files over with the same issues.  At first I thought it could be a redux / data store issue problem.  The only problem i see with that is iOS would be affected also.
Any help / ideas would be appreciated.
react-native 0.43.3
react 16.0.0-alpha.6
react-navigation 1.0.0-beta.7
redux 3.5.2

@joshualcoffee Can you take and post a systrace (see https://github.com/facebook/react-native/issues/11809#issuecomment-287029912)?

@astreet  Sure thing.  I have created a few videos of a scaled down app vs a larger app.
https://www.dropbox.com/s/ay4mtejsxcmc8xx/2017_04_20_07_05_54.mp4?dl=0
This shows a scaled down app without using debug mode.  You can see the frames drops to -2.1 and locking the device for a very short period.
https://www.dropbox.com/s/bh2dkjd8svh00uf/2017_04_20_07_08_23.mp4?dl=0
This shows the scaled down app using debug mode.  You can see frames only drop for brief periods to draw / redraw elements.  Also page transition are smooth.
https://www.dropbox.com/s/9qu0o93naqfsjmk/2017_04_20_07_14_57.mp4?dl=0
Production app with async calls and more elements to render.  This shows both debug mode and non debug mode.  You can see the device stays locked up for a time period without debug mode turned on.
Systrace:
https://www.dropbox.com/s/ztwulxavy7915hm/trace.html?dl=0
Nothing stands out to me other than my mqt_js thread does not seem to look like the one you pictured.

@joshualcoffee are you using the new FlatList? In my app, as previously mentioned, ListView performs better, however once I scroll down so that new elements are being rendered, I still notice slowdowns that do not occur when Remote JS Debugging is on.
In general, the entire app seems slightly faster with Remote JS Debugging than without, so I'm not sure why that would happen. I'm on a low powered Android device, but you would think that marshalling to the PC back and forth would negate any performance differences the PC would have compared to the device.
There is also a related react-navigation issue here: https://github.com/react-community/react-navigation/issues/706 which I also believe to be react-native related.

It's not surprising at all that that things would be faster with remote debugging compared to running on a slow Android device. The marshaling overhead is actually quite small compared to the computation.

Ahhh well that's good to know.  I think the issue is comparing it to developing on iOS.  Typically you will get slower performance when you have remote debugging on during iOS simulation.  If this is typical than disregard my comments.
FlatList still seems to be a huge issue for android.  Following up what @andreialecu, I had to switch back to ListView as the performance for FlatList was horrible.  Im pretty sure I can get around most of the performance issues by fine tuning my connected components.  I'm noticing re-renders when there should not be any.

Hey guys I'm noticing the exact thing @joshualcoffee is after upgrading to 0.43.4. Unusable slow performance but only on an iOS physical device in debug mode, yet turning on remote debugging actually solves the issue.
Only using <ListView />s
Did the fix mentioned above land in 0.43.4 or 0.44.0 or not at all yet? Thanks for the help!
react-native 0.43.4
react 16.0.0-alpha.6

Hello. I`ve same issue.
On android JS thread says -2.1 fps (yes, with a minus).
Downgrade react-native to 0.38.1 help me (but i want latest rn =))

I have a problem. This code is running correctly in SE but other scrollable tab has lag in other simulators. Why? This is interesting event.
react-native: 0.44.2
react-native-scrollable-tab-view: 0.7.4


bazel extractor doesn't handle empty srcs attribute. [phab:T118]

Created by hanwen at 2016-04-04 13:30:55:
$ cat lib/jgit/BUILD
..
java_library(
name = "jgit",
exports = ["jgit//jar"],
)
$ cat kythe/BUILD
package(
default_visibility = [ "//visibility:public" ])
java_import(
name="jar",
jars = ["bazel_java_extractor.jar"])
java_binary(name = "java_extractor",
runtime_deps = [":jar"],
main_class = "com.google.devtools.kythe.extractors.java.bazel.JavaExtractor",
)
action_listener(
name = "extract_kindex",
extra_actions = [":extra_action"],
mnemonics = ["Javac"],
visibility = ["//visibility:public"],
)
extra_action(
name = "extra_action",
cmd = "$(location :java_extractor) $(EXTRA_ACTION_FILE) $(output $(ACTION_ID).java.kindex) $(location :vnames.json)",
data = [":vnames.json"],
out_templates = ["$(ACTION_ID).java.kindex"],
tools = [":java_extractor"],
)
$ bazel build -s --experimental_action_listener=//kythe:extract_kindex gitiles-servlet:servlet
=>
(cd /home/hanwen/.cache/bazel/_bazel_hanwen/02a2d1f21f16c0d4f7890328f21d4ade/gitiles &&
exec env -
PATH=/home/hanwen/bin:/home/hanwen/go/bin:/home/hanwen/vc/go/bin:/home/hanwen/bin:/home/hanwen/go/bin:/home/hanwen/vc/go/bin:/home/hanwen/bin:/home/hanwen/go/bin:/home/hanwen/vc/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/bin/bash -c 'bazel-out/host/bin/kythe/java_extractor bazel-out/local_linux-fastbuild/extra_actions/kythe/extra_action/lib/ow2/0072b812d4a7a5ca515575fbe6eb9cab.xa bazel-out/local_linux-fastbuild/extra_actions/kythe/extra_action/lib/ow2/0072b812d4a7a5ca515575fbe6eb9cab.java.kindex kythe/vnames.json')
ERROR: /home/hanwen/vc/gitiles/lib/jgit/BUILD:10:1: Executing extra_action //kythe:extra_action on //lib/jgit:jgit failed: bash failed: error executing command /bin/bash -c ... (remaining 1 argument(s) skipped).
Exception in thread "main" com.google.devtools.kythe.extractors.shared.ExtractionException: no sources to analyze
at com.google.devtools.kythe.extractors.java.JavaCompilationUnitExtractor.extract(JavaCompilationUnitExtractor.java:246)

hanwen wrote at 2016-04-04 13:33:48:
hum - the formatting is all snafu here.
See also: https://gist.github.com/hanwen/ce58f0105e175a6c5e281908fbde5eba

fromberger wrote at 2016-04-07 15:41:08:
I'm not clear on what an indexer is even supposed to do with a library that has no sources. I don't disagree that the extractor should be resilient to that—but this may be a case where the correct answer is to not emit an index file at all.
In the case of JAR files, we will probably want to do something similar to what we did internally, and extract the dependent class files to avoid redundancy in the output. But I think that's more or less orthogonal.

hanwen wrote at 2016-04-07 15:45:31:
if it doesn't generate an index file, then Bazel gets upset because the promised artifact isn't there.

fromberger wrote at 2016-04-07 15:51:02:
Yes, but it can generate an empty file—we just filter those out when uploading the .index files for processing.

hanwen wrote at 2016-04-07 16:28:47:
With this patch I was able to run Gitiles through Kythe. Do you want me to try your suggestion? I have no special preferences; whatever works and gets this fixed quickly.

fromberger wrote at 2016-04-07 16:32:06:
What patch do you mean?

hanwen wrote at 2016-04-07 16:33:42:
#1118

hanwen wrote at 2016-04-07 16:33:58:
phabricator - how does it work?

fromberger wrote at 2016-04-07 16:40:42:
I think that should be OK. It means we'll wind up with some useless compilations, but it doesn't break any fundamental assumptions AFAICS.

hanwen wrote at 2016-04-19 13:19:33:
I'll mark this as resolved, but any update on when the 0.0.21 will be released?


[bug] Not working for nested component inside component

The "React Extract" action is not available when I select JSX from a nested component. I have many nested components that I would like to extract, but this extension is not working in those cases.
Example:
export function VerifyEmail() {
    const [name, setName] = useState('');

    function Welcome() {
        return (

Hello, {name}

        );
    }

    return (

            <Welcome />

Please verify your email to continue

    );
}

Hi @GorvGoyl, thanks for reporting this bug.
I believe I have overlooked this scenario. I'll keep this thread updated according to my findings and fixes.

Fixed in 757002a and made available in v0.10.0.
In fact, this was not a bug, but a bad feature: early in this project I decided to use the vscode diagnostics as a way to filter out unintended selections. But it might well be the case that someone wants to extract a code with warnings or errors and that should ultimately be the user's the decision. In v0.10.0 that is the case.


Date comparison issue

Hi, this is showing nothing:
TASK FROM "journal"
WHERE date(file.name) = date(today)

This is showing all the files tasks:
WHERE date(file.name).toString = date(today).toString

The files inside journal directory follows the "2021-09-21" format. I've tried with javascript and it shows today's items, but clicking on the checkboxes is only working for the first 2 or 3 tasks, something is making it unresponsive because the note is not updated, even worst with nested lists:
const today = luxon.DateTime.now().toISODate()

dv.taskList(
  dv.pages('"journal"')
    .file
    .where(i => i.name == today)
    .tasks
)

The dataview query at the top doesn't work because task queries don't currently add file metadata (so file.name doesn't exist), but that is being fixed when 0.4.11 releases.
As for the unresponsiveness at the bottom, it's hard to say - do you get logs or errors of any sort when you try to check/uncheck the boxes?

No messages on the console at all. What would be the way then to show todays tasks with the regular (not javascript) version?


Page titles in a browser

HTML title should different with each page in a browser. Now it says "TaxonWorks" in each title.

Has been done for a while.


Fixed an API misconnect ('release, not destroy')

Simple issue, simple fix... Pool.destroy calls 'release' on its Pool object; 'destroy' was implemented on Pool, but not 'release'. 'Release' nomenclature sounds more appropriate (and I don't see any knock on issues), so I've changed the function name here.

It is a good idea , but I have to think I used it elsewhere？


Persistent mock GRBL controller

Save position and state to a file. This will allow doing some more advanced testing

Out of scope for now


Unnecessary padding for messages

Currently in master we have unnecessary padding for messages. I can't reproduce this bug on stable/1.4.x branch and on v1.4.1 tag.

Fixed in #2442


[BugFix] fix paimon jni reader error when select all the columns

Why I'm doing:
What I'm doing:
Fixes #issue
#30930
What type of PR is this:

[ ] BugFix

Does this PR entail a change in behavior?

[ ] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:
Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Fix crash with null callee

Issue
This PR fixes issue https://github.com/godotengine/godot/issues/40942.
Summary
Malformed call expressions that create GDScript::CallNode instances with callee == nullptr are possible.  An example of such a malformed expression is var crash = ()(1).  When these cases happen during editing, the editor crashes.
The PR fixes the bug by:

Adding an accessor GDScript::CallNode::get_callee_type which checks for nullptr and returns Type::NONE in that case.
Refactoring the code, where sensible, to use the new accessor.
Adding manual nullptr checks where using the accessor didn't make sense.

This should be solved just by adding null checks where relevant and avoiding the whole block. For instance if the callee is nullptr in the reduce_call() function it should just bail out early. It should not keep trying to find the type of a callee that isn't there. Same applies to other checks of the callee type.
This only happens when the parse tree is ill-formed, which happens when the code is not syntactically correct (e.g. when doing code completion on partially written code), so there's no harm in bailing out early.

@vnen I've cleaned up the code to simplify and minimize the use of get_callee_type.
As for reduce_call specifically, I considered short-circuiting the function with something like:
if(p_call->callee == nullptr) {
	// Invalid call. Error already sent in parser.
	// TODO: Could check if Callable here too.
	p_call->set_datatype(GDScriptParser::DataType::UNRESOLVED);
	mark_node_unsafe(p_call);
	return;
}

I rejected the idea due to the complexity of the function and potential unwanted side effects of the change.  I'm new to this codebase and don't know the subtleties of the systems involved.
I also added better error reporting in GDScriptParser::parse_grouping.  The parser was reporting Expected closing ")" after grouping expression. when an empty grouping expression was encountered.  Now it reports Expected grouping expression. which seems more clear to me.

Yikes.  I'll clean up this git history.  Boo for bringing in master in an unclean way!


Migrate to Swift banner - Cookiebot

@meols The "powered by Cookiebot" logo is hidden from the dialog now.

@padms - great that the logo is hidden. Can you please make the change in the cookie banners to not have preferences, statistics or marketing pre-ticked from 1 January, we will not wait for confirmation from legal for this.

@meols It must be done manually from cookiebot console .. on Jan 1

@padms - OK :smile: If you're not working 1 Jan, please do the cookie banner update 31. Dec (or 30 Dec if you're off 31.)


Command new seems to be more idiomatic than create.

This is more of a question which might stem from a bit of bias, but to me it seems like new would be more idiomatic than create in our command line tool.
Some other tools use init like git, npm, and Bower, but this doesn't really fit our description.
new is used in Rails, Play, Hanami, Cargo, only to name a few. The only tool I know that uses create is homebrew.

Thanks for the suggestion. The flutter tool help output is pretty good, seems like it's clear to users what to do. We don't yet have evidence that this is tripping up users in the wild, but something we should keep our eyes open for. We might even have most users run this command via the IDE's GUI in which case the name of the command might be hidden.
I'm inclined to leave it as "create" for now.

The only reason why I thought about opening this question is because changing it after 1.0 would be a pain.

We could always alias it if we need to change it.

Good point.
I'm inclined to close this issue. We have some time before 1.0 so we can revisit if we get feedback from our early testers.


Support for grpcio-aio (Async gRPC)

Is your feature request related to a problem? Please describe.
We're currently in the process of moving from our PHP based Legacy/Monolith system to a Python based Micro-services environment with a React Micro-frontend. We've been using New Relic for our performance monitoring, logging, alerts, profiling, problem debugging, etc. We've been noticing that we're having performance issues with our services at high traffic load and have been looking at ways to improve performance. One of the things that was identified that would improve performance, would be switching from using synchronous grpc to asynchronous grpc (https://grpc.github.io/grpc/python/grpc_asyncio.html). During the process of prototyping and testing grpcio-aio and trying to debug and profile, we found that no data was being sent to New Relic APM. We were able to see the container and see it's CPU/Memory usage and such, but no info regarding requests was being captured at all.
This is obviously a huge problem for us, since we're heavily integrated into New Relic at the moment and moving to grpcio-aoi is something we definitely want to move toward as not doing so means, we can't start migrating customers from the legacy enviroment to our new Micro-services environment, so not being able to use grpcio-aio with New Relic is huge road block for us and something we need to resolve ASAP.
Feature Description
The same support we have for gRPC to be replicated Async gRPC
Describe Alternatives
N/A
Additional context
I have logged this via New Relic support too, feature request: PYTHON-I-151. They said it would be beneficial to post the request here too.
Priority
Blocker

I mean, it would still be nice it it was supported...

I've also migrated from sync gRPC to async gRPC and lost my metrics 😞

Is anyone going to look at this issue?

Is there any update on this?


[BUG] Cursor class is inside message buffer class

Describe the bug

1Cursor class is in side message buffer class, although the message buffer don't use its inner cursor and the cursor is using message buffer that it gets as input instead its own message buffer. It makes things unclear and other bugs (In other issues I will open)
To Reproduce

Expected behavior

there are three options (from better to worth in my opinion):

instead of cursor class, to have in the message buffer variable of m_cursor_pos (That is what I suggesting)
Have the cursor class be separated
Cursor class will use the message class it is inside of.

Screenshots

Desktop (please complete the following information):

OS:
eRPC Version:v1.9.0

Steps you didn't forgot to do

[X] I checked if there is no related issue opened/closed.
[X] I checked that there doesn't exist opened PR which is solving this issue.

Additional context

@MichalPrincNXP @Hadatko any thoughts?

HI @amgross thank you for all your inputs. I think that what you proposed here https://github.com/EmbeddedRPC/erpc/issues/282 will work nice. We can remove m_remainig and use MessageBuffer variables which can be accessed already like getLength() for write and getUsed for read.
Here it is your 3. bullet. I think i like it a bit more than 1. bullet.

OK, I can live with bullet 3.
I prefer instead of uint8_t *m_pos; to have uint16_t m_offset;, I think it is better to have just one pointer to the buffer and everyone will take offset from it, what do you think?
Also if we want to keep the nested classes, we can use m_buffer->m_used instead of m_buffer->getUsed()

https://github.com/EmbeddedRPC/erpc/pull/378 ;)


MA-1903 removed About this Course text

Addresses https://openedx.atlassian.net/browse/MA-1903

:+1:


[NIH-PLUG+EGUI] How to scale interface? egui_ctx.set_pixels_per_point(2.0) has no effect.

Hi there. I'm pretty new in Rust and audio in general.
Recently i made simple app in egui - calculator, and able to do interface scaling through
egui_ctx.set_pixels_per_point(5.0);
works fine.
So i tried same in egui+nih-plug:
        create_egui_editor(
            self.params.editor_state.clone(),
            (),
            |_, _| {},
            move |egui_ctx, setter, _state| {
                egui::CentralPanel::default().show(egui_ctx, |ui| {
                    // TODO: this is not working
                    egui_ctx.set_pixels_per_point(5.0);
                    // configure_text_styles(egui_ctx);

And it's do not has visible changes. What i'm doing wrong?

egui_baseview would need to support scaling first. I added the functionality needed for that to baseview, but noone really uses egui_baseview so that would need to be updated to support it first (and it needs to be updated in general).

ah got it.
Is there fundamental difference between baseview and eframe?

Eframe uses winit for window creation. Anyways, this is not a NIH-plug issue so I'll close this. Feel free to create an issue on the egui_baseview if you want to see this get fixed.


ACS Commons data importer not importing the correct jcr:primaryType from the speadsheet

Required Information

[6.5.15 ] AEM Version, including Service Packs, Cumulative Fix Packs, etc: _______
[ 4.11.2] ACS AEM Commons Version: _____
[not tried the latest ] Reproducible on Latest? yes/no

Expected Behavior
I have been trying to import pages through the attached spreadsheet but the data importer is not picking up the jcr:primaryType from the spreadsheet. It is instead creating the default value (sling:Folder) or whatever you provide for the "Structure node type"
Actual Behavior
jcr:primaryType column values are ignored and the default structure node types are created instead
Steps to Reproduce
Tested it on AEM 6.5.15 with ACS Commons 4.11.2
Links
Data Import City Pages Test_Single_Updated.xlsx

@eagleinhills Have you tested this on the latest ACS AEM commons version? Please share in case it is happening on the latest version as well.


15 add poc disclaimer 2

Related to:

#15

Added a warning disclaimer to the README as well:

It should be well visible that the example strategies are not production-ready (yet).


[RFC] Add new flag "flaky" for marking bisection result as ignore.

During bisection in case of several bugs with different symptoms are
reproduced or bug does't reproduce on every VM it gets flagged as
flaky. When bisection is completed result marked as flaky is
verified. This is done either by testing found commit or re-running
the bisection. If verification indicates bisection result is not
correct it's bisection results are marked as ignore and not reported
further.

I wonder on what percent of bisections this verification will be triggered. Any difference in testing results on any commit look like a pretty easy to trigger criteria. Please asses on some recent bisection logs.
We already don't mail inconclusive bisection results, so I would prefer if we don't spend more time on them. Bisections already take lots of time and inconclusive especially tend to take more (e.g. due to more tests/broken builds). And here we repeat the whole process (potentially up to 12h) so for no benefit in reporting quality. Most likely majority of them will be just killed on timeout and we won't get any result at all.
For conclusive bisections it seems that "different reports" and "some runs are ok" may need to be handled differently. Consider we are getting different crashes (e.g. a race). What's the point in retesting? We will get the same different crashes again.
I see how this makes sense for "some runs are ok" results.
An alternative may be to detect that the bug is flaky during bisection (say if we get less than some threshold of crashes, e.g. 5 or less out of 10) and then if we will ever get 0/10, we kick off another 10 runs to double check this result. This may have a potential for arriving at the correct result, not just marking a result as flaky (potentially even a correct result). Have you considered this or any other alternatives? Which one is better?

I wonder on what percent of bisections this verification will be triggered. Any difference in testing results on any commit look like a pretty easy to trigger criteria. Please asses on some recent bisection logs.

Syzkaller is currently considering runs as "bad" if there is any crash. If crashes are different and caused by two or more bugs originated from different patches, bisection will provide one of these commits. Now if the original crash report seems to be something very different from what bisection found the result will be suspected being wrong. This was my idea of marking it as flaky. One solution could be to store original crash and also compare against that during bisection.

We already don't mail inconclusive bisection results, so I would prefer if we don't spend more time on them. Bisections already take lots of time and inconclusive especially tend to take more (e.g. due to more tests/broken builds). And here we repeat the whole process (potentially up to 12h) so for no benefit in reporting quality. Most likely majority of them will be just killed on timeout and we won't get any result at all.

Ok, didn't realize this one. Makes sense to drop inconclusive result from this patch.

For conclusive bisections it seems that "different reports" and "some runs are ok" may need to be handled differently. Consider we are getting different crashes (e.g. a race). What's the point in retesting? We will get the same different crashes again.

Now as you pointed out that inconclusive could be dropped from the patch completely: What do you think verifiying conclusive bisect result always? That is anyways only two runs. Culprit commit and it's parent. If verification fails we could mark it as flaky?

I see how this makes sense for "some runs are ok" results.
An alternative may be to detect that the bug is flaky during bisection (say if we get less than some threshold of crashes, e.g. 5 or less out of 10) and then if we will ever get 0/10, we kick off another 10 runs to double check this result. This may have a potential for arriving at the correct result, not just marking a result as flaky (potentially even a correct result). Have you considered this or any other alternatives? Which one is better?

See my comment above. I currently like more the idea to verify always and mark as flaky based on that.

Syzkaller is currently considering runs as "bad" if there is any crash. If crashes are different and caused by two or more bugs originated from different patches, bisection will provide one of these commits. Now if the original crash report seems to be something very different from what bisection found the result will be suspected being wrong. This was my idea of marking it as flaky. One solution could be to store original crash and also compare against that during bisection.

If I am reading it correctly, this implement will affect other cases and will not necessary detect the case you are aiming at.
If we have 2 bugs, one usually dominates -- on a particular commit we trigger one or the other (rarely a mix of both). Since we are looking only at result for a single test at a time, we may well conclude that it's not flaky if we are hitting 2 different bugs.

For conclusive bisections it seems that "different reports" and "some runs are ok" may need to be handled differently. Consider we are getting different crashes (e.g. a race). What's the point in retesting? We will get the same different crashes again.

Now as you pointed out that inconclusive could be dropped from the patch completely: What do you think verifiying conclusive bisect result always? That is anyways only two runs. Culprit commit and it's parent. If verification fails we could mark it as flaky?

I dunno. We already did this test during the bisection. Hard to say if repeating the same test will help or not without any data.
And it's also completely not helpful for the case you stated as the motivation for this change above. So what exactly are we trying to do? ;)

Syzkaller is currently considering runs as "bad" if there is any crash. If crashes are different and caused by two or more bugs originated from different patches, bisection will provide one of these commits. Now if the original crash report seems to be something very different from what bisection found the result will be suspected being wrong. This was my idea of marking it as flaky. One solution could be to store original crash and also compare against that during bisection.

If I am reading it correctly, this implement will affect other cases and will not necessary detect the case you are aiming at.
If we have 2 bugs, one usually dominates -- on a particular commit we trigger one or the other (rarely a mix of both). Since we are looking only at result for a single test at a time, we may well conclude that it's not flaky if we are hitting 2 different bugs.

I'm currently looking at reproducer that can be found in syzkaller-repros and is named as "ce692a3aa13e00e335e090be7846c6eb60ddff7a" there. That is repeating several different memory leaks during bisection on same commit and it's bisection is failing. I can give you an answer how common this is, but I've seen this with other reproducers as well.

For conclusive bisections it seems that "different reports" and "some runs are ok" may need to be handled differently. Consider we are getting different crashes (e.g. a race). What's the point in retesting? We will get the same different crashes again.

Now as you pointed out that inconclusive could be dropped from the patch completely: What do you think verifiying conclusive bisect result always? That is anyways only two runs. Culprit commit and it's parent. If verification fails we could mark it as flaky?

I dunno. We already did this test during the bisection. Hard to say if repeating the same test will help or not without any data.
And it's also completely not helpful for the case you stated as the motivation for this change above. So what exactly are we trying to do? ;)

I'm trying to minimize reporting wrong bisection results. Rather discard the result than report it if suspected it's wrong.
You are right on this. This patch doesn't solve this case. It's separate topic. If we wan't to continue approach where we first flag as flaky based on detection and then verify later  we should leave out flagging flaky if several different crashes are reported and only flag cases that are hard to reproduce.
I don't think git bisect verifies whether bisect succeeded or not. One wrong "good" verdict during bisection will cause wrong result. This could be easily detected by running verification as it is done in my patch for flaky conclusive results. What do you think?

You are right on this. This patch doesn't solve this case. It's separate topic. If we wan't to continue approach where we first flag as flaky based on detection and then verify later we should leave out flagging flaky if several different crashes are reported and only flag cases that are hard to reproduce.

I am a bit lost then. You said this case is the motivation for marking commits as flaky, but also this change does not resolve this case in any way...

I don't think git bisect verifies whether bisect succeeded or not. One wrong "good" verdict during bisection will cause wrong result. This could be easily detected by running verification as it is done in my patch for flaky conclusive results. What do you think?

I meant that git bisect does exactly what verifyConclusiveBisectResult does. If it arrives at commit X, it means we tested commit X and the test failed and tested the previous commit and it did not fail. Otherwise git bisect would point at X.

You are right on this. This patch doesn't solve this case. It's separate topic. If we wan't to continue approach where we first flag as flaky based on detection and then verify later we should leave out flagging flaky if several different crashes are reported and only flag cases that are hard to reproduce.

I am a bit lost then. You said this case is the motivation for marking commits as flaky, but also this change does not resolve this case in any way...

I meant at the time of writing the code I was thinking marking this kind of result as flaky would prevent reporting it. As you pointed, it doesn't. This is due to fact that verification will indicate that case is not flaky.
Motivation for flagging/verification approach generally was inconclusive result. Not every inconclusive result can be verified because it's very time consuming. I.e. mark as flaky if results are not consistent and only verify flagged results. Now as you pointed out there is no need to care about inconclusive results as they are not reported anyways this motivation is not true anymore.

I don't think git bisect verifies whether bisect succeeded or not. One wrong "good" verdict during bisection will cause wrong result. This could be easily detected by running verification as it is done in my patch for flaky conclusive results. What do you think?

I meant that git bisect does exactly what verifyConclusiveBisectResult does. If it arrives at commit X, it means we tested commit X and the test failed and tested the previous commit and it did not fail. Otherwise git bisect would point at X.

Yes it does. How about if test at commit X doesn't fail due to flaky bug? We could catch this by verifying and repeating this test once more before reporting, no?

I meant that git bisect does exactly what verifyConclusiveBisectResult does. If it arrives at commit X, it means we tested commit X and the test failed and tested the previous commit and it did not fail. Otherwise git bisect would point at X.

Yes it does. How about if test at commit X doesn't fail due to flaky bug? We could catch this by verifying and repeating this test once more before reporting, no?

Yes, I replied to this part in the last paragraph of:
https://github.com/google/syzkaller/pull/2030#issuecomment-671283425
But the criteria for triggering this additional testing seems wrong.
And we already verified it 10 times, not just once. So why 20? Why not 5 or 30? Also why not doing this right during bisection?

I meant that git bisect does exactly what verifyConclusiveBisectResult does. If it arrives at commit X, it means we tested commit X and the test failed and tested the previous commit and it did not fail. Otherwise git bisect would point at X.

Yes it does. How about if test at commit X doesn't fail due to flaky bug? We could catch this by verifying and repeating this test once more before reporting, no?

Yes, I replied to this part in the last paragraph of:
#2030 (comment)
But the criteria for triggering this additional testing seems wrong.
And we already verified it 10 times, not just once. So why 20? Why not 5 or 30? Also why not doing this right during bisection?

Ok, I see. How about if we take your idea of marking bug as flaky if we get >= 50 % "good" results at some commit. Then we have at least three options how to handle this flag:

Check the flag at the end of bisection and verify as done in current patch and prevent reporting result
Re-test every "good" verdict during bisection. Continue bisection and report as currently
Re-test every "good" verdict during bisection. If we get conflicting result break bisection and fail the bisection.

Without thorough evaluation safest option is 2. What do you think?

I meant that git bisect does exactly what verifyConclusiveBisectResult does. If it arrives at commit X, it means we tested commit X and the test failed and tested the previous commit and it did not fail. Otherwise git bisect would point at X.

Yes it does. How about if test at commit X doesn't fail due to flaky bug? We could catch this by verifying and repeating this test once more before reporting, no?

Yes, I replied to this part in the last paragraph of:
#2030 (comment)
But the criteria for triggering this additional testing seems wrong.
And we already verified it 10 times, not just once. So why 20? Why not 5 or 30? Also why not doing this right during bisection?

Ok, I see. How about if we take your idea of marking bug as flaky if we get >= 50 % "good" results at some commit. Then we have at least three options how to handle this flag:

Check the flag at the end of bisection and verify as done in current patch and prevent reporting result
Re-test every "good" verdict during bisection. Continue bisection and report as currently
Re-test every "good" verdict during bisection. If we get conflicting result break bisection and fail the bisection.

Without thorough evaluation safest option is 2. What do you think?

I agree 2 looks like the best option.
However, instead of re-trying I would bump number of VMs per test from 10 to 20 if we suspect the crash is flaky.
It can also make sense to do the bump if we did not reproduce the crash on the original commit with 10 VMs. If we get 0 crashes on the original commit, we can bump number of VMs to 20 and retry the initial commit. But that's the only case we will be retrying.

I meant that git bisect does exactly what verifyConclusiveBisectResult does. If it arrives at commit X, it means we tested commit X and the test failed and tested the previous commit and it did not fail. Otherwise git bisect would point at X.

Yes it does. How about if test at commit X doesn't fail due to flaky bug? We could catch this by verifying and repeating this test once more before reporting, no?

Yes, I replied to this part in the last paragraph of:
#2030 (comment)
But the criteria for triggering this additional testing seems wrong.
And we already verified it 10 times, not just once. So why 20? Why not 5 or 30? Also why not doing this right during bisection?

Ok, I see. How about if we take your idea of marking bug as flaky if we get >= 50 % "good" results at some commit. Then we have at least three options how to handle this flag:

Check the flag at the end of bisection and verify as done in current patch and prevent reporting result
Re-test every "good" verdict during bisection. Continue bisection and report as currently
Re-test every "good" verdict during bisection. If we get conflicting result break bisection and fail the bisection.

Without thorough evaluation safest option is 2. What do you think?

I agree 2 looks like the best option.
However, instead of re-trying I would bump number of VMs per test from 10 to 20 if we suspect the crash is flaky.
It can also make sense to do the bump if we did not reproduce the crash on the original commit with 10 VMs. If we get 0 crashes on the original commit, we can bump number of VMs to 20 and retry the initial commit. But that's the only case we will be retrying.

Latest version attempts to implement your ideas. Please check.


Add Cratecode

Cratecode uses GPT-4 to provide a programming assistant and to automatically generate help articles. Both are free (although a signup is required). Here's some demo links:

https://cratecode.com/info/javascript-create-element - AI generated help article.
https://www.youtube.com/watch?v=gbn058nB1FM - Programming assistant demo.

I considered putting this under Coding Assistant, but I feel that it's more geared towards helping you write production code than learning how to program--which is what this one does. Please let me know if a different category would fit better!

Thanks! Looks awesome 👍

@uellenberg are you the creator of Cratecode? I created a twitter profile for ai-collection and I want to tweet about it and mention the creator.
@kerbelp

Yes I am, and I'd definitely appreciate a shout out :heart:
My twitter handle is @juellenberg, and Cratecode's is @cratecode.
I recently (today, actually :laughing: ) finished up an aggregation page for all of the AI-generated content: https://cratecode.com/info. This is a set of AI-generated articles about programming topics (header images are also AI-generated). These articles are created when:

Someone asks the AI Assistant for help and it links to an article.
An AI-generated article links to an article that doesn't exist yet.
Someone searches for an article on the topic.

If you're interested in this (outside of Twitter), here's a little write-up I made that talks about the process behind it: https://cratecode.com/news/gpt-4-auto-articles.
Cheers!


fixbug: #2008

chain test - 'interprets ((->) r) as a monad' is failing
changing from
var bound = R.chain(f, h);
to
var bound = R.chain(h, f);

Have you looked at #1937, @sagifogel?

No.


Add undo and redo alternative

A client asked for the more traditional variants of the undo icon. I thought I'd submit it as a PR but feel free to just close it if you feel that the current one is enough.

Nice one! I like these much better than the current ones. Maybe the lower part could be just a bit shorter though?

@lscheibel Love the alternatives!

@karsa-mistmere Yes agreed, I updated the PR


CARDS-1800: Computed questions fail to evaluate with invalid question names

Created a new --test form (Backend Computed Test) and a new test user (computedtestuser, password testpassword. This form contains 2 computed questions that would fail previously due to requiring invalid variable names (2question and question 3).
To test the frontend code, create and complete a Backend Computed Test form as admin or the regular testuser and verify that Question 2 and 3 Computed work properly. To test the backend code, sign in as computedtestuser and create a Backend Computed Test. Observe that the computed questions are not visible, as this user does not have access to these specific questions, forcing the backend to complete them. Complete the visible questions, save the form then sign in as admin to verify that the computed questions worked fine.

Fixed Marta's comments, adding an information node with testing instructions and fixed the label in the test form

Something broke in the PROMs questionnaires, the scores and interpretations are no longer getting computed.

Fixed in 24da841.


add: kcp.py to readme

Added a Python project for the protocol. Missing a Chinese translation (hence a draft PR).
Also normalised line endings in the readme.

Why did you close it?

Wasn't sure if readme additions were being accepted. Still requires a Chinese translation as well. Able to reopen if if they are being accepted.

OK, I will update the Chinese documentation later.


TPS Cut in half when using external storage on Actually Additions small storage crates.

With the setup in the attached picture the tps is cut in half.  When the controller is removed tps instantly jumps to 20.

Version (Make sure you are on the latest version before reporting):  Unable to change version its in a modpack, but the latest version changelog doesn't show anything that would affect.
Minecraft: 1.10.2
SpongeAPI: 6.0.0-SNAPSHOT-cebc736
SpongeForge: 1.10.2-2098-6.0.0-BETA-1823
Minecraft Forge: <IP_ADDRESS>9

Refined Storage: refinedstorage-1.1.2

Does this issue occur on a server? Yes
Find also attached the warmroast showing a profile of the problem.

@ProsperCraft Does this issue occur WITHOUT Sponge? Make sure you test that.

Verified its not only Sponge - With Sponge-

WIthout Sponge-

I'm here to report a similar issue. I'm also using external storages. However my are connected to a couple basic drawers.
I had really bad lag in my world, and didn't know what caused it. Today I found out that I have the external storages connected to the drawers with a priority of 1, i.e. I wanted RS to store everything that comes into the system in the drawers instead of the disks. When I change the priority to 0, the lag goes away.


Revert: remove create property page

Proposed Changes

L1: It is possible to make property on stakes.social, link to create property page
L2: link to niwa.xyz

Implementation

Thanks for the great repair!
Can you change this "Submit an application" link to something like "GitHub"? Because the invite request flow is no longer needed.

Can you change this "Submit an application" link to something like "GitHub"? Because the invite request flow is no longer needed.

👍 I'll change it to "GitHub".
It's linked to /ethereum/invite/github, do I need to change it to /ethereum/create/github?
@aggre

It's linked to /ethereum/invite/github, do I need to change it to /ethereum/create/github?

Yeah, I meant so!


"make test" not passed on osx

os version: osx 10.10.2
luajit version: 2.0.3
do: make test
got:
Linking C shared module luv.so
[100%] Built target luv
ln -sf build/luv.so
build/luajit tests/run.lua
build/luajit: error loading module '/luv' from file './/luv.so':
dlsym(0x7f8033404bd0, luaopen_/luv): symbol not found
stack traceback:
[C]: at 0x010696fc70
[C]: in function 'require'
tests/run.lua:7: in main chunk
[C]: at 0x0106936350
make: *** [test] Error 1

Are you still getting this is latest luv?  I can't reproduce it locally.


Non-destructive XenoArch Research

About the PR

Ultimately, destroying artifacts in order to get points from them hasn't been majorly beneficial for science. Due to the sheer overwhelming value of points, especially with the relatively low number of artifacts per round, players are incentivized to simply get through the graph as quick as possible rather than engaging with any of the effects in a meaningful way.
By changing the point process to be nondestructive, players can enter a state of post-point-clarity where they can actually do interesting and fun things with the artifacts that they've spent time researching.
Media

https://user-images.githubusercontent.com/98561806/231911325-2bc862e7-5ad4-4656-aa15-e37636875e30.mp4

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl:

tweak: The research team in the XenoArcheology lab have discovered how to extract points from artifacts without breaking them.

renamed "Points" to "Extract"

since extract isnt dangerous why is the button still red

Do you still get the same amount of points if you extract after each node, compared to only extracting at the end?

Do you still get the same amount of points if you extract after each node, compared to only extracting at the end?

yes, it's the same amount


Configuring custom listeners with dynamic addresses

I'm trying to enable a WebSockets over SSL listener using VerneMQ on Kubernetes (with multiple replicas, as per the Helm chart) and I'm running into issue.
It should be as simple as adding a new listener:

listener.wss.default = ip:port

But, because of the way the docker image currently works, it's not that simple.
The listeners for tcp, ws, vmq and http are configured by the vernemq.sh startup script and this does work, but, as the other issues have also pointed out, there doesn't seem to be an easy way to add additional listeners while keeping the IP addresses dynamic.
I'm aware that there are similar issues - #48, #107, and probably others - that touch this subject in some ways, but the solutions given there unfortunately don't work for me. They seem to come down to either mounting a local configuration file, vernemq.conf.local, or to defining the listener through environment variables, in both cases with a known, static IP, or <IP_ADDRESS>.
Unfortunately, neither of those will work in a dynamic environment, like Kubernetes, as each pod gets assigned a dynamic IP address on creation, and listening on <IP_ADDRESS> doesn't work if we want clustering.
Having thought of it some more, I'd like to propose a small addition to the vernemq.conf.local implementation: I think it would help if the startup script were to do an in-place substitution of a known string (for example, {IP_ADDRESS}) with the IP address of the host.
A configuration like the one below would then work and could still be updated on startup, while respecting and not touching the other (custom) values:
...
listener.wss.default = {IP_ADDRESS}:8080
...

I'd be happy to work this out and make a pull request if anyone feels this is something that you'd be interested in. I'd love to elaborate on the idea too in case there are doubts or questions.

I have a similar problem with clustering in kubernetes. I need to make a few changes to the standard vernemq.conf so I opted for the vernemq.conf.local way. Unfortunately there is no way to replace at least the IP-address of the listener.vmq.clustering which breaks clustering in kubernetes for me completely.
Like @bverhoeven above, I would suggest reusing an already used mechanism from the vernemq.sh and replace a predefined string via an sed command after the copy from vernemq.conf.local to vernemq.conf.
I have submitted #142 for this. Please let me know if this suits your requirements or if it needs any refining or if this idea is totally beside the point ;) .

I suppose we can close this as #142 was merged.

I thank you very much if you add this lines it is simple use
if [ -z "$DOCKER_VERNEMQ_LISTENER__WSS__DEFAULT" ]; then
   echo "listener.wss.default = ${IP_ADDRESS}:8080" >> /vernemq/etc/vernemq.conf
fi


Do not embed MSD firmware into rpiboot binary

Although the binary has been altered to support reading firmware files from
arbitrary directory and default MSD firmware is always installed into
/usr/share/rpiboot/msd, there is still a copy of MSD firmware linked directly
into the rpiboot binary, bloating it for more than 500 kB without a strong
reason.
This commit makes this optional and alters Makefile in a way it is built
without the embedded firmware by default.
Signed-off-by: Ondřej Caletka<EMAIL_ADDRESS>

This sounds like a great contribution in a long time. :-)
thanks. have a nice day. keep up the great work. 👏
ret394

footer -
Someone on the Internet - Please add some desktop Ubuntu OS to NOOBs list to help the unfortunate RPi users. For example - XFCE, LXDE, LXQT.
Use-case priority - XFCE first.
Thanks. 😹😹😹

This PR appears to change the default behaviour to exclude the MSD_FIRMWARE which is presumably why it hasn't been merged.
It the PR was changed to so that excluding the MSD_FIRMWARE was an option then I think it would be accepted. e.g.
make EMBED_FIRMWARE=0


In scan mode narrator focus separately navigates to function number.

A team member will update this issue with more details soon.

This is your friendly Microsoft Issue Bot. I created this issue automatically as requested by a team member.


Carousel CSS doesn't load properly in dev

The css imports don't seem to work in dev when using it outside of this repo. It looks like the css loads during SSR but the hydration seems to wipe it out.
Not 100% sure what to do here, some options:

copy + paste the CSS into the style block
import it and use postcss to inline it - but then there will be warnings about unused styles..
Just document that you need to import the css when using the component
Create a tailwind plugin to and just get it to spit out the css - seems weird but we might want a tailwind plugin later on anyway?
replace swiper with something else, custom or otherwise

I'm up for replacing swiper if you can find an alternative.


src/cmsnamed.c: fix Multilocalized test on big-endian platform

Noticed single test failure on pwerpc64, powerpc and PA-RISC
(all plaforms are big-endian):
Checking Multilocalized profile ...FAIL!
Multilocalized profile:

It's caused by endianness-depedent result of
strTo16 / strFrom16 functions.
Tweaked those functions to always construct
big-endian Country and Language codes.
Signed-off-by: Sergei Trofimovich<EMAIL_ADDRESS>

Fixed in GIT, thanks!


[Bug]:

What happened?
Unsure of root cause but receive this message periodically:
Getting tunnel URLs...
    Error: Failed to connect to docker proxy at https://preevy_proxy-platform-
    feat-pr-review-stacks-d52axemz.livecycle.run/: 500: Internal Server Error

Any tips on how to debug? It's always after an environment exists (successful deploys) but beyond that Im not sure what triggers the issue nor how to resolve. So far, I've destroyed the instance manually and re-ran preevy up but the problem persists. Will update as I discover more but would appreciate any help diagnosing in the mean time.
Add screenshots
Some more output in case useful
#66 DONE 0.1s
 Network platform_default  Creating
 Network platform_default  Created
 Volume "platform_storage"  Creating
 Volume "platform_storage"  Created
 Volume "platform_postgres"  Creating
 Volume "platform_postgres"  Created
 Container platform-db  Creating
 Container platform-preevy_proxy-1  Creating
 Container platform-frontend  Creating
 Container platform-redis  Creating
 Container platform-db  Created
 Container platform-frontend  Created
 Container platform-redis  Created
 Container platform-worker  Creating
 Container platform-preevy_proxy-1  Created
 Container platform-backend  Creating
 Container platform-worker  Created
 Container platform-backend  Created
 Container platform-preevy_proxy-1  Starting
 Container platform-db  Starting
 Container platform-frontend  Starting
 Container platform-redis  Starting
 Container platform-db  Started
 Container platform-preevy_proxy-1  Started
 Container platform-redis  Started
 Container platform-worker  Starting
 Container platform-backend  Starting
 Container platform-frontend  Started
 Container platform-backend  Started
 Container platform-worker  Started
Preview environment platform-feat-pr-review-stacks provisioned at: <IP_ADDRESS>
- Getting tunnel URLs...
✖ Getting tunnel URLs...
    Error: Failed to connect to docker proxy at https://preevy_proxy-platform-
    feat-pr-review-stacks-d52axemz.livecycle.run/: 500: Internal Server

Steps to reproduce the behavior
Not yet but will provide if I can determine them
Expected behavior
preevy up reproduces the environment without issue
What OS are you seeing the problem on?
Linux
Additional context
Using AWS Lightsail
Record

[X] I agree to follow this project's Code of Conduct

A little more info, preevy down, preevy purge, and manually deleting the instance from AWS UI doesn't seem to resolve the error which leads me to suspect its on the preevy side of the fence.

preevy ls output
preevy ls
 Env Driver ID Location State
 ─── ───────── ──────── ─────

Hey @iamjaredwalters, thanks for reporting the issue.
It seems we have a problem with zombie tunnels (that's why using a new --id did the trick), we're working on understanding the root cause and apply a fix.

Fixed in #227