text:
[Crash] stack overflow on call to Landroid/graphics/Paint;.getTextRunAdvance:FLIIIIILI

i run my program with react-native version 0.17.0 , and everything seem normal.
But when i upgrade to 0.18.0 , my program crash with following error
stack overflow on call to Landroid/graphics/Paint;.getTextRunAdvance:FLIIIIILI
seem like something change in react-native version 0.18.0 make it crash. how can i slove this?

I've also experienced this

This appears to be a known bug with TextView on Android: http://stackoverflow.com/questions/12849676/i-cant-figure-the-issue-with-a-stacktrace-error

Hmm there appears to be some sort of maximum depth to the view hierarchy on android. Coming up with a simple use case.

Ok so I made a pretty simple use case out of this. I started with v0.20.0 and used react-native init and all I did was change the index.android.js to the following
/**
 * Sample React Native App
 * https://github.com/facebook/react-native
 */
'use strict';
import React, {
  AppRegistry,
  Component,
  StyleSheet,
  Text,
  View
} from 'react-native';

class AwesomeProject extends Component {
  render() {
    return (
      <View style={styles.container}>
        <Text style={styles.welcome}>
          Welcome to React Native!
        </Text>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
        <View>
          <Text style={styles.instructions}>
            To get started, edit index.android.js
          </Text>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        </View>
        <Text style={styles.instructions}>
          Shake or press menu button for dev menu
        </Text>
      </View>
    );
  }
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#F5FCFF',
  },
  welcome: {
    fontSize: 20,
    textAlign: 'center',
    margin: 10,
  },
  instructions: {
    textAlign: 'center',
    color: '#333333',
    marginBottom: 5,
  },
});

AppRegistry.registerComponent('AwesomeProject', () => AwesomeProject);

After ~16 levels it causes the error above and the app crashes. Note this is on a Samsung Galaxy Tab running Android 4. So far every device I have on hand that uses Android 4 crashes. Same thing with any Genymotion emulators on Android 4.

Looks like this is a limitation of the call stack on Android?
http://stackoverflow.com/questions/16913317/create-the-ui-thread-manually-in-android-in-order-to-increase-its-small-stack-si
http://stackoverflow.com/questions/16843357/what-is-the-android-ui-thread-stack-size-limit-and-how-to-overcome-it

Yeah I'm honestly unconvinced there is much of a fix? I basically just used the inspector and flattened my view structure as much as I could so that I didn't hit this upper limit.
Might just be useful including in the Android docs that there is a limitation to the view tree depth on Android 4 that is roughly ~20 views in total before you overflow the call stack on rendering.

@ide I don't think there's really a fix for this as I've dug deeper and deeper. It's a limitation on the call stack size in later versions of Android. Maybe somehow in the CSS layout android code you limit or throw a warning?
I'd be happy to also just submit documentation on this so that others aren't caught unawares

We could try boosting the stack size since this code runs on a thread other than the UI thread: http://stackoverflow.com/a/19967816. A better solution is to try rewriting the code to use BFS instead of DFS but anyone want to give the stack depth tweak a shot?

I think this has been fixed with 0.27.

holy crap

authors: InnerPeace080 MITDelian ide


text:
[ListView & ScrollView] Don't respect LayoutAnimation

I was talking to @vjeux on IRC about this.
I was trying to animate the layout as the keyboard opens and as you can see in the video below the TextInput view is properly animating (sometimes 1 frame behind though) with the keyboard while the ListView instantly clips.
https://www.dropbox.com/s/iz1cm5p22ar9vfk/Screenflick Movie 7.mp4?dl=0
I tested by removing the ListView and replacing it with a plain ScrollView and setting the contentContainerStyle to solid red and basically the same thing happens. The contentContainer instantly clips and doesn't animate it's height.
Any ideas of suggestions?

:+1: curious to see what the solution is

:+1: Seeing the same thing here in 0.6.0-rc

Thank you for reporting this issue and appreciate your patience. We've  notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

#1366 landed right after this issue, let me know if it's still an issue and I can reopen it.

I'm still having this issue using 0.27.0 - am trying to animate a ScrollView and it just jumps to the new height instead of animating it. Changing the top position animates, but none of 'bottom', 'height', 'marginBottom' or 'paddingBottom' animate.

Surprisingly, this stays in 0.36.0 also. Any hacks?

@tadeuzagallo I think this is still an issue in 0.39 so this issue needs to be reopened.

I believe it'd be better to just open a new issue with more information rather than reopening a issue that's over an year old and has little context on it.

This is also an issue in react-native v0.44.0. Any fixes yet?

source: gharchive/issue

authors: andrewsnowden brentvatne dhrrgn facebook-github-bot-3 jgkim rishabhpoddar tadeuzagallo vaibhawc vishnevskiy

repo: facebook/react-native

license: MIT

license_type: permissive

license_source: github-api


text:
[Webview]: set mediaPlaybackRequiresUserAction as true by default (io…

In documentation, the default value of mediaPlaybackRequiresUserAction is true. But in reality, on ios and android, this value is false.
So to fix it, i update default value for android webview and define default props for ios with mediaPlaybackRequiresUserAction to true.

The docs claim the default value to be false. This PR would change the current behavior.

https://facebook.github.io/react-native/docs/webview.html#mediaplaybackrequiresuseraction

Boolean that determines whether HTML5 audio and video requires the user to tap them before they start playing. The default value is true.

Where is the real documentation ?

I'm basing this purely on what your PR submitted (e.g. you did not mention the above in your original post).
I suggest verifying what the actual default behavior is, and updating the docs to reflect that (as opposed to switching the default behavior to match the docs).

Ok i understand what you mean but on IOS component, the documentation is:
  * Boolean that determines whether HTML5 audio and video requires the user
  * to tap them before they start playing. The default value is `true`.
  */
 mediaPlaybackRequiresUserAction: PropTypes.bool,```

My PR want just be coherent with website documentation and with the IOS component behavior.

source: gharchive/pull-request

authors: hramos julien-innovantic


text:
export Props types for end users

Related to #22100
When using Flow, it is handy to be able to inherit from Props type for components in user code because the typing can be stricter.
For example:
type SubmitButtonProps = $ReadOnly<{|
  ...TouchableHighlightProps,

  onPress: ?() => void,
  style?: ?ViewStyleProp,
  title: string,
|}>;

Test Plan:

[x]  npm run prettier
[ ]  npm run flow-check-ios
[ ]  npm run flow-check-android

Release Notes:
[GENERAL] [ENHANCEMENT] [Components/Touchable/TouchableBounce.js] - export Props Flow types
[GENERAL] [ENHANCEMENT] [Components/Touchable/TouchableHighlight.js] - export Props Flow types
[GENERAL] [ENHANCEMENT] [Components/Touchable/TouchableOpacity.js] - export Props Flow types

You can use Flow's React.ElementProps utility type:
type TouchableBounceProps = React.ElementProps<typeof TouchableBounce>

authors: TheSavior chuckhacker


text:
Lint: fix few "no-unused-var" warnings for imports

Summary
This small PR fixes few "no-unused-var" issues and  and removes two old entries for no longer existing files from the .eslintignore.
Changelog
[Internal] [Fixed] - Lint: fix few "no-unused-var" warnings for imports
Test Plan
Successfully run of yarn lint script. Warnings count has been reduced from 61 to 58.

Hi @appden, can I help you somehow with fixing the warning on the FB Internal pipeline?


text:
Remove need for each platform to implement ToastAndroid as UnimplementedView

Summary:
Today, any host platform implementation of React Native must add ToastAndroid.platform.js.

https://github.com/microsoft/react-native-macos/blob/main/Libraries/Components/ToastAndroid/ToastAndroid.macos.js
https://github.com/microsoft/react-native-windows/blob/0.71-stable/vnext/src/Libraries/Components/ToastAndroid/ToastAndroid.windows.js

Now they don't have to do it anymore.
Changelog:
[General] [Fixed] - ToastAndroid] Remove need for each platform to implement ToastAndroid as UnimplementedView
Differential Revision: D47744187

CC: @Saadnajmi / @chiaramooney


text:
Fixed Typo in QuickStart-GettingStarted.md

Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
Fixed typo.

By analyzing the blame information on this pull request, we identified @JoelMarcey and @hramos to be potential reviewers.

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

@denniske Once you sign the CLA, I will accept and land this. Thanks.

@JoelMarcey Signed it. Do I have to upload the PDF here?

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

@denniske Nope. All good.

@denniske Actually, we want this to go into master, not 0.27-stable. Can you make this PR be merged into master?


text:
Remove dependency on ocaml-re in the parser

cc @rickyvetter @bobzhang

Done.

repo: facebook/reason


text:
Preserve function body braces

This is an alternative to #1826 implementing just the brace preservation
code, to make it easier to be reviewed.
I think this is now in a better place to get into the codebase given
that we have Reason_attributes outside of Reason_pprint_ast and that
we now remove our own attributes before printing to OCaml.
I think we can probably refactor this code further in future PRs, as
well as add other stylistic preservation changes.

yayyyyyyy

Is it currently the case that these (and other stylistic attributes such as string "literal" attributes) are removed when the --print is binary? I believe that should be the case and would fix the other issues we've had with ppx plugins complaining.

@jordwalke yes, we remove literalAttrs from printing.
I agree with your comment that the name should probably be changed.

authors: anmonteiro jaredly jordwalke


text:
Update bspack workflow for distributing BS6 compatible artifacts

We need a way to easily distribute bspacked reason_api.ml and reason_binary.ml files for BuckleScript v6 and above (4.06), mostly because we want to keep the Reason JS playground bundle up to date with most recent Reason releases.
This PR keeps the original workflow alive (with slight adaptions in the README), but marks it as a legacy build workflow (BuckleScript will not support 4.02 in the future). Right now the 4.02 bspack instructions fail, mostly due to breaking updates to Reason, but it's still good to keep everything around for now.
The new workflow is introduced as bspacks/reason_bspack406.sh script, which needs BSPACK_EXE to be defined (pointing to a locally built bspack for now). Example usage calls can be found in the script comments.
Also, the 406 script takes the version from the reason.json file (since it looks like the source of truth for Reason version numbers). Easier for the user to not make mistakes.
Any feedback would be valuable.
@thangngoc89

@jordwalke I think this is ready to be merged. I looked through @jaredly's old PR regarding his esy setup (#2153), but it seems that 1) there's still something broken with the menhir dep 2) it's a more complex change for me and I can't tell how much effort it will take to get this working without shaving a yak.
This solution is definitely working for BS contributors (the target group of this change anyways). Happy to improve things in the future as soon as we figured out what is needed?

Sounds good! If the bs-contributors are happy with the workflow, then it does the job well! Most important thing is that it's correct. Thanks for the contribution.

Thanks @ryyppy

authors: jordwalke ryyppy


text:
KeyError: 'caller_port'

When using:
sapp --tool=mariana-trench analyze .
I got error:
/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sqlalchemy/orm/relationships.py:1994: SAWarning: Setting backref / back_populates on relationship Run.issue_instances to refer to viewonly relationship IssueInstance.run should include sync_backref=False set on the Run.issue_instances relationship.  (this warning may be suppressed after 10 occurrences)
util.warn_limited(
/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sqlalchemy/orm/relationships.py:1994: SAWarning: Setting backref / back_populates on relationship IssueInstance.run to refer to viewonly relationship Run.issue_instances should include sync_backref=False set on the IssueInstance.run relationship.  (this warning may be suppressed after 10 occurrences)
util.warn_limited(
2022-06-01 20:47:21,491 [INFO] Parsing analysis output...
Traceback (most recent call last):
File "/Users/shijian03/.venvs/mariana-trench/bin/sapp", line 8, in
sys.exit(cli())
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 1130, in call
return self.main(*args, **kwargs)
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 1055, in main
rv = self.invoke(ctx)
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 1657, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 1404, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 760, in invoke
return __callback(*args, **kwargs)
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/decorators.py", line 84, in new_func
return ctx.invoke(f, obj, *args, **kwargs)
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 760, in invoke
return __callback(*args, **kwargs)
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/cli_lib.py", line 208, in analyze
pipeline.run(analysis_output, summary_blob)
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/init.py", line 363, in run
next_input, summary = step.run(next_input, summary)
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/base_parser.py", line 236, in run
self.analysis_output_to_dict_entries(
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/base_parser.py", line 188, in analysis_output_to_dict_entries
for typ, key, e in self._analysis_output_to_parsed_tuples(inputfile):
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/base_parser.py", line 135, in _analysis_output_to_parsed_tuples
for e in entries:
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/mariana_trench_parser.py", line 351, in parse
yield from self.parse_handle(handle)
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/mariana_trench_parser.py", line 367, in parse_handle
for postcondition in self._parse_postconditions(model):
File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/mariana_trench_parser.py", line 528, in _parse_postconditions
port=Port.from_json(generation["caller_port"], "source"),
KeyError: 'caller_port'
Looking forward to hearing from you.
Thanks!

When using:
sapp --tool=mariana-trench analyze . I got error: /Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sqlalchemy/orm/relationships.py:1994: SAWarning: Setting backref / back_populates on relationship Run.issue_instances to refer to viewonly relationship IssueInstance.run should include sync_backref=False set on the Run.issue_instances relationship. (this warning may be suppressed after 10 occurrences) util.warn_limited( /Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sqlalchemy/orm/relationships.py:1994: SAWarning: Setting backref / back_populates on relationship IssueInstance.run to refer to viewonly relationship Run.issue_instances should include sync_backref=False set on the IssueInstance.run relationship. (this warning may be suppressed after 10 occurrences) util.warn_limited( 2022-06-01 20:47:21,491 [INFO] Parsing analysis output... Traceback (most recent call last): File "/Users/shijian03/.venvs/mariana-trench/bin/sapp", line 8, in sys.exit(cli()) File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 1130, in call return self.main(*args, **kwargs) File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 1055, in main rv = self.invoke(ctx) File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 1657, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 1404, in invoke return ctx.invoke(self.callback, **ctx.params) File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 760, in invoke return __callback(*args, **kwargs) File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/decorators.py", line 84, in new_func return ctx.invoke(f, obj, *args, **kwargs) File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/click/core.py", line 760, in invoke return __callback(*args, **kwargs) File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/cli_lib.py", line 208, in analyze pipeline.run(analysis_output, summary_blob) File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/init.py", line 363, in run next_input, summary = step.run(next_input, summary) File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/base_parser.py", line 236, in run self.analysis_output_to_dict_entries( File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/base_parser.py", line 188, in analysis_output_to_dict_entries for typ, key, e in self._analysis_output_to_parsed_tuples(inputfile): File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/base_parser.py", line 135, in _analysis_output_to_parsed_tuples for e in entries: File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/mariana_trench_parser.py", line 351, in parse yield from self.parse_handle(handle) File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/mariana_trench_parser.py", line 367, in parse_handle for postcondition in self._parse_postconditions(model): File "/Users/shijian03/.venvs/mariana-trench/lib/python3.9/site-packages/sapp/pipeline/mariana_trench_parser.py", line 528, in _parse_postconditions port=Port.from_json(generation["caller_port"], "source"), KeyError: 'caller_port'
Looking forward to hearing from you. Thanks!

I have met the same issue. Any suggestion ？

I resolved this issube by:

uninstall fb-sapp : pip uninstall fb-sapp
git clone https://github.com/facebook/sapp.git
cd sapp
python3 setup.py install

I think sapp in pypi is not up to date,mybe.

Hey @Securee and @koftnt, if you rerun MT on your code with the latest version of MT and run sapp analyze on the output from MT. Does this issue still reproduce on the latest version of fb-sapp (0.5.3)?

authors: 0xedward Securee koftnt

repo: facebook/sapp


text:
Fix 'ci' command

Prior this change, rome ci was not running the tests.
Closes #233

This is great, thank you! I didn't think of wrapping it this way.

rome ci is failing presumably because rome test doesn't actually throw a DiagnosticPrinter and instead prints it's own message when there's no diagnostics. Might be best to leave the throw new Error('Expected a printer'); line out. rome test should really just be throwing the DiagnosticPrinter anyway and customizing the footer output.

Thank you!

authors: ooflorent sebmck

repo: facebookexperimental/rome


text:
negative average_MDE for positive EffectSize in GeoLiftMarketSelection()

Hi
I want to understand - is it OK to get negative average_MDE values from GeoLiftMarketSelection() for positive EffectSize?
If yes - what does it actually mean?
This is what I got for my sample data:

ID
Location
Duration
EffectSize
Power
AvgScaledL2Imbalance
Investment
AvgATT
Average_MDE

1
market1
15
0.25
1
0.9307789
4614.375
21.429641
0.26419807

2
market2
15
0.10
1
0.6999374
299.250
-2.473729
-0.07795269

3
market3
15
0.25
1
0.9676958
5476.875
20.864286
0.34615385

4
market4
10
0.40
1
0.7422721
984.000
-2.621508
-0.05400550

Hi @vpatcera I believe this is related to the high imbalance/poor fit between test and synthetic control. You can see that your AvgScaledImbalance is very high (closer to 0, better). I also recommend you to review al the details of the https://facebookincubator.github.io/GeoLift/docs/GettingStarted/Walkthrough/ to help you to design a good GeoLift experiment. I'm closing this issue for now. Thank you.

authors: JussanN vpatcera

repo: facebookincubator/GeoLift


text:
Fix *args typing validation

We were not correctly handling this case that is contained in the added test.
Along the way:

I separated logic regarding signature validation & type validation.
Changed methods to have proper names.
Got rid of the ugly dependency on unittest's _must_skip private method.

Decoupled this logic from both signature & type validation.
The new method _skip_first_arg must be called from inside _wrap_signature_and_type_validation because if it is done from other functions that need its return, the patch will already be in place, and it'll not work.

Credits to @deathowl for helping with all the debugging and ground work prior to this PR.

I like how 0.01% coverage change breaks the signal... this is literally less than 2 lines.

repo: facebookincubator/TestSlide


text:
Add default ES6 export

Required for some build configurations.
For example with this it's possible to use idx with Typescript as is with following typing:
declare module "idx" {
    function idx<T, R>(props: T, getPath: (props: T) => R): R;
    export default idx;
}

Typescript usage example with strict null checks:
import idx from "idx";

interface IState {
    foo?: {
        bar?: {
            baz?: number;
        };
    };
}

const state: IState = {};

var num = idx(state, _ => _.foo!.bar!.baz);

Thanks!

authors: epeli zertosh

repo: facebookincubator/idx


text:
#78 Automatic detection of data aggregation for creating weekly seasonality

#78

Changed setup_dataframe, so that if minimum difference between two  dates of data is more than 7 days then weekly seasonality is not created
This will rectify the error in plot_component, when weekly aggregated data is used. For more detail refer to issue #78

Raising another pull request to fix issue with this pull request

repo: facebookincubator/prophet

license_source: bigquery


text:
Try expression get different results between common and simplified

Description
https://app.circleci.com/pipelines/github/facebookincubator/velox/21710/workflows/86857f51-983b-4a03-b644-0996c72ca7d9/jobs/136753/steps
Error Reproduction
Archive.zip
Relevant logs
I20230317 21:58:04.646764 229221 ExpressionVerifier.cpp:290] Persisted input: --fuzzer_repro_path /tmp/fuzzer_repro/velox_expressionVerifier_wIuXgl --input_path /tmp/fuzzer_repro/velox_expressionVerifier_wIuXgl/input_vector --sql_path /tmp/fuzzer_repro/velox_expressionVerifier_wIuXgl/sql --lazy_column_list_path /tmp/fuzzer_repro/velox_expressionVerifier_wIuXgl/indices_of_lazy_columns --complex_constant_path /tmp/fuzzer_repro/velox_expressionVerifier_wIuXgl/complex_constants
terminate called after throwing an instance of 'facebook::velox::VeloxRuntimeError'
  what():  Exception: VeloxRuntimeError
Error Source: RUNTIME
Error Code: INVALID_STATE
Reason: Different results at idx '19': '5 elements starting at 0 {1 elements starting at 0 {G+&f4D>N?"e}R~W,alIlSc?@f7Gas'k.U:'|DBR.1B}3Q,Rxsi6"r5@dBPr#MK*;d)t8s[TBgp[?B4GPVZ=D=sM"><9ks&}, 1 elements starting at 1 {Qauw7,_MWbfuJ[y'T/WIP+hroho\(LZTL&h6qx|IS4]?&??#MOFi4Xw'I}, 1 elements starting at 2 {null}, 1 elements starting at 3 {null}, 1 elements starting at 4 {null}}' vs. '5 elements starting at 0 {1 elements starting at 0 {lar"("c1", "lpad"("c2", "bitwise_or"('2062551296'::INTEGER, "multiply"("subscript"("c3", '125'}, 1 elements starting at 1 {Qauw7,_MWbfuJ[y'T/WIP+hroho\(LZTL&h6qx|IS4]?&??#MOFi4Xw'I}, 1 elements starting at 2 {null}, 1 elements starting at 3 {null}, 1 elements starting at 4 {null}}'
Retriable: False
Expression: left->equalValueAt(right.get(), i, i)
Function: compareVectors
File: ../../velox/expression/tests/ExpressionVerifier.cpp
Line: 61
Stack trace:
# 0  _ZN8facebook5velox7process10StackTraceC1Ei
# 1  _ZN8facebook5velox14VeloxException5State4makeIZNS1_C4EPKcmS5_St17basic_string_viewIcSt11char_traitsIcEES9_S9_S9_bNS1_4TypeES9_EUlRT_E_EESt10shared_ptrIKS2_ESA_SB_
# 2  _ZN8facebook5velox14VeloxExceptionC1EPKcmS3_St17basic_string_viewIcSt11char_traitsIcEES7_S7_S7_bNS1_4TypeES7_
# 3  _ZN8facebook5velox17VeloxRuntimeErrorC2EPKcmS3_St17basic_string_viewIcSt11char_traitsIcEES7_S7_S7_bS7_
# 4  _ZN8facebook5velox6detail14veloxCheckFailINS0_17VeloxRuntimeErrorERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEEvRKNS1_18VeloxCheckFailArgsET0_
# 5  _ZN8facebook5velox4test12_GLOBAL__N_114compareVectorsERKSt10shared_ptrINS0_10BaseVectorEES7_
# 6  _ZN8facebook5velox4test18ExpressionVerifier6verifyERKSt10shared_ptrIKNS0_4core10ITypedExprEERKS3_INS0_9RowVectorEEOS3_INS0_10BaseVectorEEbSt6vectorIjSaIjEE
# 7  _ZN8facebook5velox4test16ExpressionFuzzer2goEv
# 8  _ZN8facebook5velox4test16expressionFuzzerESt13unordered_mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt6vectorIPKNS0_4exec17FunctionSignatureESaISD_EESt4hashIS8_ESt8equal_toIS8_ESaISt4pairIKS8_SF_EEEm
# 9  _ZN12FuzzerRunner3runERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmRKSt13unordered_setIS5_St4hashIS5_ESt8equal_toIS5_ESaIS5_EES7_
# 10 main
# 11 __libc_start_main
# 12 _start

This one looks fixed? cant repro

authors: Yuhta laithsakka

repo: facebookincubator/velox


text:
Enhance AggregationFuzzer to test on plans for global aggregation on an empty input

Description
Such plans return the default value of the aggregate. This is NULL for most aggregates. But some aggregates do return a reasonable value e.g. count will return 0.
The fuzzer test would ensure that all aggregates can handle such queries.
@mbasmanova

@aditi-pandit Can we  write a unit test to handle this ? We can get all the aggregation function signatures , create an empty row vector for input type and test it out. One can have a default mapping as a part of this unit test , which any new aggregate  would need to update.
I feel fuzzer is wrong test here since we arent fuzzing anything here and just validating behavior and thus a unit test seems more appropriate.

@kgpai : I agree this is not a traditional fuzzer test as there really isn't any fuzzing here.
Though at a high level, it seems to fit in the line of the testing which is the intent of the fuzzer.
The reason this combination of empty input matters for each function is to check if the default value it returns for empty input is consistent with Presto. So it fits somewhere into the line of testing you'll are doing. The general feeling was that we could avoid redoing a similar setup by adding this code here.
Do you still feel that we should separate this test ?

authors: aditi-pandit kgpai


text:
-l seems to go into deadlock

Hi, I'm able to train models with -g, but when I try to train on my local machine with multiple GPUs with -l, the model doesn't start training after the commands for hydra are printed, and a few jobs are spawned only on GPU 0. It seems to be some deadlock caused by submitit/hydra. Do you know what is going on here? Any help is greatly appreciated!

Can you check your RAM once? Maybe the videos loaded are occupying the RAM completely.

Hi @haofengac apologies for the delay in responding. So when running locally, no logs will be printed to the shell -- they will get stored in the output directory (which should be somwhere in BASE_RUN_DIR in launch.py). However all the GPUs should get used etc, maybe look at the stored stdout/stderr logs to see if something went wrong?

Hi @rohitgirdhar, thanks for the reply! I called with the command CUDA_VISIBLE_DEVICES=0,1,2,3 python launch.py -c expts/09_ek55_avt.txt -l. For the log, I've only got these 4 warnings:
`[2022-02-01 15:22:12,259][py.warnings][WARNING] - /sailhome/haofeng/anaconda3/envs/avt/lib/python3.7/site-packages/torchvision/init.py:78: UserWarning: video_reader video backend is not available. Please compile torchvision from source and try again
warnings.warn(message)
[2022-02-01 15:22:12,259][py.warnings][WARNING] - /sailhome/haofeng/anaconda3/envs/avt/lib/python3.7/site-packages/torchvision/init.py:78: UserWarning: video_reader video backend is not available. Please compile torchvision from source and try again
warnings.warn(message)
[2022-02-01 15:22:12,548][py.warnings][WARNING] - /sailhome/haofeng/anaconda3/envs/avt/lib/python3.7/site-packages/torchvision/init.py:78: UserWarning: video_reader video backend is not available. Please compile torchvision from source and try again
warnings.warn(message)
[2022-02-01 15:22:12,553][py.warnings][WARNING] - /sailhome/haofeng/anaconda3/envs/avt/lib/python3.7/site-packages/torchvision/init.py:78: UserWarning: video_reader video backend is not available. Please compile torchvision from source and try again
warnings.warn(message)The output ofnvidia-smiis as follows:+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.84       Driver Version: 460.84       CUDA Version: 11.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  Tesla V100-SXM2...  On   | 00000000:06:00.0 Off |                    0 |
| N/A   37C    P0    55W / 300W |   4127MiB / 32510MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   1  Tesla V100-SXM2...  On   | 00000000:07:00.0 Off |                    0 |
| N/A   36C    P0    43W / 300W |      3MiB / 32510MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   2  Tesla V100-SXM2...  On   | 00000000:0A:00.0 Off |                    0 |
| N/A   35C    P0    43W / 300W |      3MiB / 32510MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   3  Tesla V100-SXM2...  On   | 00000000:0B:00.0 Off |                    0 |
| N/A   36C    P0    43W / 300W |      3MiB / 32510MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A    773590      C   ...onda3/envs/avt/bin/python     1031MiB |
|    0   N/A  N/A    773591      C   ...onda3/envs/avt/bin/python     1031MiB |
|    0   N/A  N/A    773592      C   ...onda3/envs/avt/bin/python     1031MiB |
|    0   N/A  N/A    773593      C   ...onda3/envs/avt/bin/python     1031MiB |
+-----------------------------------------------------------------------------+`
It seems that the four jobs are all spawned on the first GPU although there are 4 available, and it is stuck like this forever. Do you know what's going on here? Thanks!

@haofengac you can check the logs in .submitit folder (in OUTPUT directory) in log.err (for errors) or log.out(for other logs).
For the GPU usage, not sure why the distributed training is not working :/

Hi @haofengac unfortunately I don't have a good sense of what might be going on either. Maybe try to submit a 1 GPU job and see if that works at least? (prints logs and starts training)

@haofengac Hi, I'm facing with same issue as you. Since I've tried installing torchvision with source,
I'm facing with another issue( have to install pytorch version v1.12.1-rc5 but have know idea how to do).
Did you solved your problem?
Working on local with several GPU is essential to me but can't solve this problem

@haofengac @rohitgirdhar hi, I've solved this issue with changing num_workers to 0.
If you change
workers : 10 to 0
in AVT/conf/data/default.yaml , you can use multiple gpu at local.
But you have to see logs from OUTPUT directory.

authors: Anirudh257 haofengac jinwooahnKHU rohitgirdhar sanketsans wasabipretzel

repo: facebookresearch/AVT


text:
Confuse about compute_partitions_fast in shape context.py

pretrain/contrastive_scene_contexts/lib/shape_context.py Line 89-90
maskUp = rel_trans[:,:,2] > self.r1
maskDown = rel_trans[:,:,2] > self.r1
maskUp and maskDown are same.   Is there existing some mistakes?

hi,
thanks for pointing it out, it was due to some copy-paste error during the code refactoring, we will fix it soon.


text:
Bug in install.py?

Out Major League Hackers found that the config file isn't generated.

The issue is that base.py is imported before config.py is generated, and base.py attempts to import a config.py.
https://github.com/facebookresearch/dynabench/blob/d5b9c56928b3b0513ee09f0741fee48f58e4c6a1/api/install.py#L14
https://github.com/facebookresearch/dynabench/blob/d5b9c56928b3b0513ee09f0741fee48f58e4c6a1/api/models/base.py#L9

authors: TristanThrush kokrui

repo: facebookresearch/dynabench


text:
How to reproduce MSA Transformer?

Hi, I read paper <MSA Transformer>, which achieves an exciting results.
However, I don't know how to reproduce the result show in paper ?
Could somebody help me to do this, thank you ~

Hi @HelloCodingWorld163 , thanks for your interest!
Here's an example notebook using the MSA Transformer weights we released, which can be used to reproduce the unsupervised contact predictions on any MSA.
Let me know if you have any more questions!

repo: facebookresearch/esm


text:
 cause training crash

Bug Description
In app/asr(previously wav2letter++), when I try to train data with "<unk>" token, I'll got crash on following code
//app/asr/data/Utils.cpp

  auto lit = lexicon.find(word);
  if (lit != lexicon.end()) {
    if (lit->second.size() > 1 &&
        targetSamplePct >
            static_cast<float>(std::rand()) / static_cast<float>(RAND_MAX)) {
      return lit->second[std::rand() % lit->second.size()];
    } else {
    // crash here, when encountering word "<unk>". Because lit->second is empty.
      return lit->second[0];
    }

After some study, following is what I got:
In .tokens/.lexicon file generation(use utilities/prepare_librispeech_wp_and_official_lexicon.py from wav2letter++ repo), we explicitly exclude "<unk>", so we do not have "<unk>" in .tokens/.lexicon file
And before training, we first load lexicon file, create a LexiconMap object. In load operation, we explicitly add "<unk>" to LexiconMap and set its spelling empty. Why set "<unk>" spelling to empty?  That's the crash reason.
  // Insert unknown word. Note kUnkToken="<unk>"
  lexicon[kUnkToken] = {};

Then we create Dictionary from LexiconMap object, also set Dictionary's defaultIndex to "<unk>" index.
So when encountering "<unk>", it will just crash. I think set "<unk>" spelling to "<unk>"  will solve this problem

@xuqiantong do you know why we set the  to empty ?

Anyone? Got some suggestions or explanation?

Yea, indeed, your case is reproducible. But could you tell us why do you want to have exactly  token in the transcriptions? Actually, if you look at the logic right below in https://github.com/facebookresearch/flashlight/blob/1b6eb18f1747078368c27fcad81e4bb5e338c7fd/app/asr/data/Utils.cpp#L51-L66, you can see that we support to either ignore those unknown words or fall back to use letters as their spelling.
So, why do you want to include  in targets?

I got it. So what is your suggestion if we have '' token in training data? Is it OK just ignore it? Or maybe we should take a special strategy about it?

Seems like <unk> is not showing up in the comments. :p
But yea, I think it is OK to simply ignore those tokens, by either removing them completely or keeping them as they are originally in targets.
Closing for now. Feel free to reopen this issue, when it becomes a major use case.

authors: avidov xuqiantong zjuturtle

repo: facebookresearch/flashlight


text:
CI: adapt to be consistent with habitat-api

Motivation and Context
Doing the same as here: https://github.com/facebookresearch/habitat-api/commit/dd75f18fb81e00810126a46c23c812e75230e86f#diff-1d37e48f9ceff6d8030570cd36286a61
How Has This Been Tested
I expect the CI to not be red anymore.

@mosra thanks for fixing this!

authors: mathfac mosra

repo: facebookresearch/habitat-sim


text:
Save 25% of memory usage on vertex position buffer (PTex Mesh)

Motivation and Context
As titled.
Using Vector3 instead of Vector4 for a vertex position in PTex mesh

Reduce memory footprint

How Has This Been Tested
local test with utility viewer.

Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have completed my CLA (see CONTRIBUTING)
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

This PR is ready to be reviewed. Thanks.

Will the shader need to change here: https://github.com/facebookresearch/habitat-sim/blob/master/src/shaders/ptex-default-gl410.vert#L1 ?

Will the shader need to change here: https://github.com/facebookresearch/habitat-sim/blob/master/src/shaders/ptex-default-gl410.vert#L1 ?

Oh, this is because OpenGL will fill the 4th component, w, with 1.0 automatically for the user if only a 3-dimensional vertex position is provided. I did not realize it would cause confusion here.
If you really feel bad about it, maybe I can change it to vec3. Then the following code will be modified as:
gl_Position = MVP * vec4(position, 1.0);

@mosra: Do you think it is necessary?

No, keep the position as vec4. That's what I'm doing for magnum's builtin shaders as well.

Oh, this is because OpenGL will fill the 4th component, w, with 1.0 automatically for the user if only a 3-dimensional vertex position is provided. I did not realize it would cause confusion here.

Ah, I didn't realize OpenGL would do that.  How nice of it :)
No need to change it as people will rarely actually look at the shaders themselves, I just wanted to check for my own knowledge.

You may be able to get a really nice speedup if you used the mmapped buffer directly instead of copying vertex attributes a vertex at a time.

@msbaines That's precisely what I'm working on to enable with the asset import rework (happening in https://github.com/mosra/magnum/pull/371 -- description might be a bit outdated tho). Together with that we could get rid of all the copies of data stored CPU-side.

Together with that we could get rid of all the copies of data stored CPU-side.

For vertices at least, we do need CPU-side copies for #333

Together with that we could get rid of all the copies of data stored CPU-side.

For vertices at least, we do need CPU-side copies for #333

Ah. Very good point. I already broke this once optimizing mesh loading:) You could still keep a CPU-side copy around with mmap. You'd just need to manage the file handle and mapping.
We really need to write tests for this behavior to avoid breaking it.

Codecov Report

Merging #348 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #348      +/-   ##
==========================================
- Coverage   56.72%   56.71%   -0.01%
==========================================
  Files         151      151
  Lines        6740     6741       +1
==========================================
  Hits         3823     3823
- Misses       2917     2918       +1

Impacted Files
Coverage Δ

src/esp/gfx/PTexMeshShader.h
0% <ø> (ø)
:arrow_up:

src/esp/assets/PTexMeshData.h
0% <ø> (ø)
:arrow_up:

src/esp/assets/PTexMeshData.cpp
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 175ea23...5be86cb. Read the comment docs.

authors: bigbike codecov-io erikwijmans mosra msbaines


text:
Model Checkpoint NOT saved, Eval Loss "Inf"

System Info
torchrun
--nproc_per_node 3
llama_finetuning.py
--enable_fsdp
--low_cpu_fsdp
--use_peft
--dataset custom_dataset
--peft_method lora
--model_name /Llama-2-13b-chat-hf
--pure_bf16
--dist_checkpoint_root_folder /dist_chkpt_root_folder
--output_dir /llama-recipes/models"
Information

[ ] The official example scripts
[ ] My own modified scripts

🐛 Describe the bug
The following is a snippet of the last few lines of the log files for the llama-2-13b-chat fine-tuned on the custom dataset, The training finished; however, the eval loss shows to be inf
And the model checkpoint was not saved, and I did not see any error message either. Any help will be appreciated. I spent four days of computing on training, and it got wasted.
........
Epoch 3: train_perplexity=1.3212, train_epoch_loss=0.2786, epcoh time 112076.98777786875s
Key: avg_train_prep, Value: 1.387495994567871
Key: avg_train_loss, Value: 0.3265116214752197
Key: avg_eval_prep, Value: nan
Key: avg_eval_loss, Value: inf
Key: avg_epoch_time, Value: 110888.28061801738
Key: avg_checkpoint_time, Value: 0.00011723674833774567
Error logs
And the model checkpoint was not saved, and I did not see any error message either. Any help will be appreciated. I spent four days of computing on training, and it got wasted.
........
Epoch 3: train_perplexity=1.3212, train_epoch_loss=0.2786, epcoh time 112076.98777786875s
Key: avg_train_prep, Value: 1.387495994567871
Key: avg_train_loss, Value: 0.3265116214752197
Key: avg_eval_prep, Value: nan
Key: avg_eval_loss, Value: inf
Key: avg_epoch_time, Value: 110888.28061801738
Key: avg_checkpoint_time, Value: 0.00011723674833774567
Expected behavior
The model checkpoint should have been saved in the mentioned output directory

Hi, the eval loss being inf will prevent saving the checkpoint as we compare against an initial best eval loss of inf
Comparison is here
Initial best eval value here
To better investigate the issue you can deactivate the comparison with the best value in the source file to get a checkpoint and then run an eval manual to figure out why your eval loss is inf on your data.

I tried commenting out the valid loss, and the training finished, however when saving the checkpoint, OOM was raised,
evaluating Epoch: 100%|██████████| 1/1 [00:12<00:00, 12.43s/it]
eval_ppl=tensor(1.5420, device='cuda:0') eval_epoch_loss=tensor(0.4330, device='cuda:0')
we are about to save the PEFT modules
Traceback (most recent call last):
File "/../llama-recipes/llama_finetuning.py", line 253, in
fire.Fire(main)
.................................................
torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 2.00 MiB. GPU 0 has a total capacty of 79.15 GiB of which 2.06 MiB is free. Including non-PyTorch memory, this process has 79.13 GiB memory in use. Of the allocated memory 77.91 GiB is allocated by PyTorch, and 187.64 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF
Exception raised from malloc at ../c10/cuda/CUDACachingAllocator.cpp:1438 (most recent call first):

any solution now? Same problem

authors: iisleepalot mreso shailja-thakur

repo: facebookresearch/llama-recipes


text:
Training finishes immediately without reporting "finished" (finetuning for a new dataset)

❓ Questions and Help
Hi there,
I am trying to fine-tune a pre-trained model for one sequence of the AICity challenge with only two classes from the Coco dataset ('background' and 'car'). I kept the 'category_id': 3 for all car annotations and defined the categories list with only one dictionary for the class car, following the detection-specific format on top of the fields included as default (info, licenses, etc.) :
"categories": [{"id": 3, "name": "car", "supercategory": "vehicle"}]

The main steps I followed to be able to fine-tune to my dataset, were:

Follow all the steps in #521 (including trimming the pre-trained model' last layer and linking that to the training config file)
Also changed the checkpoint.py function as in #273

However, when I run the training script as:
python tools/train_net.py --config-file configs/caffe2/ours_e2e_faster_rcnn_R_50_FPN_1x_caffe2.yaml

the training script loads the correct config file and displays the complete list of training params (pre-defined + default ones) with the correct value, that is, those modified by the config remain the same (e.g.: MODEL.ROI_BOX_HEAD.NUM_CLASSES: 2, and WEIGHT pointing to the correct path of the trimmed weights) and then it starts training but prints the following and exits:
loading annotations into memory...
Done (t=0.01s)
creating index...
index created!
2019-03-22 11:39:58,913 maskrcnn_benchmark.trainer INFO: Start training
max_iter(len(data_loader)) = 90000
start_iter: 0
getting item 34
getting item 292
getting item 87
getting item 157
getting item 262
getting item 325
For (enumerate(data_loader, start_iter):
images.image_sizes: [torch.Size([750, 1333])]
targets: (BoxList(num_boxes=2, image_width=1333, image_height=750, mode=xyxy),)
target: BoxList(num_boxes=2, image_width=1333, image_height=750, mode=xyxy)
getting item 270
getting item 203
getting item 298

By taking a look at the log.txt saved in the output directory I set, the prints "getting item NUM", do not appear so that makes me think it is related to the format of the annotations (conflicting with Coco format) but I could not find where this is printed from. (**)
Another thing to (maybe) consider is that I trimmed the weights as follows (with this script):
!python trim_detectron_model.py \
--pretrained_path /root/.torch/models/_detectron_35857345_12_2017_baselines_e2e_faster_rcnn_R-50-FPN_1x.yaml.01_36_30.cUF7QR7I_output_train_coco_2014_train%3Acoco_2014_valminusminival_generalized_rcnn_model_final.pkl \
--save_path ../weights/trimmed_weights/trimmed_e2e_faster_rcnn_R_50_FPN_1x_OURconfig.pth \
--cfg ../configs/caffe2/e2e_faster_rcnn_R_50_FPN_1x_caffe2.yaml

where the pretrained weights for FasterRCNN R-50 FPN1x were downloaded from here and the configuration file is the one used in the demo which downloads the weights mentioned above.
Notice that when trimming, the config file did not specify NUM_CLASSES: 2, etc., I did that only in the one passed to training (I do not know if that is the right way or not).
To check this, I will try to only load from the pre-trained weights, the model itself and not the solver configuration, etc. as suggested in #372 (*).
The config file provided for training is adapted from the one used in trimming and looks like this:
MODEL:
  META_ARCHITECTURE: "GeneralizedRCNN"
  WEIGHT: "/content/drive/ColabNotebooks/maskrcnn-benchmark/weights/trimmed_weights/trimmed_e2e_faster_rcnn_R_50_FPN_1x_ogconfig.pth"
  BACKBONE:
    CONV_BODY: "R-50-FPN"
  RESNETS:
    BACKBONE_OUT_CHANNELS: 256
  RPN:
    USE_FPN: True
    ANCHOR_STRIDE: (4, 8, 16, 32, 64)
    PRE_NMS_TOP_N_TRAIN: 2000
    PRE_NMS_TOP_N_TEST: 1000
    POST_NMS_TOP_N_TEST: 1000
    FPN_POST_NMS_TOP_N_TEST: 1000
  ROI_HEADS:
    USE_FPN: True
  ROI_BOX_HEAD:
    POOLER_RESOLUTION: 7
    POOLER_SCALES: (0.25, 0.125, 0.0625, 0.03125)
    POOLER_SAMPLING_RATIO: 2
    FEATURE_EXTRACTOR: "FPN2MLPFeatureExtractor"
    PREDICTOR: "FPNPredictor"
    NUM_CLASSES: 2
DATASETS:
  TRAIN: ("aicity_2019_train", )
  TEST: ("aicity_2019_val", )
DATALOADER:
  SIZE_DIVISIBILITY: 32
SOLVER:
  BASE_LR: 0.0001
  WEIGHT_DECAY: 0.0001
  STEPS: (70000,)
  IMS_PER_BATCH: 1
  MAX_ITER: 90000
TEST:
  IMS_PER_BATCH: 1
OUTPUT_DIR: "/content/drive/ColabNotebooks/maskrcnn-benchmark/results/AICITY_finetuning_FastRCNN/"

I attach the complete log below in case it may be helpful.
log.txt
PS: I am working in Google Colab with 1 GPU.
Any help would be appreciated,
Thanks in advance,
Ferran.
(*) UPDATE: I tried to trim the model with the same config file as the one provided for training but the result is the same print out (with different indexes because samples are pick randomly). I also noticed that only 8 "getting item..." statements are printed, which has to be related to the batch size being equal to 8, I guess.
(**) UPDATE2: I added a couple of print outs to display information about image_list, boxlist and starting and maximum iterations (length of the data_loader). I have also been able to correctly load and display my annotations on some images by using the CocoAPI in Python so it is unlikely related to the annotations format.

Hi  @fperezgamonal,
I think the trimmed model is loaded properly according to the log and the problem could be the dataset format.
This is what I will do. Using the Pythong Debug to check what the images and annotations feed to the network.
If you are familiar with the Python debug, setting a stopping point at here to see the what the images and annotations.  Then run line by line to see when the program break.  For example, in forwarding passing or backpropagation.

Hello @chengyangfu ,
Sorry for the late reply but we were trying to make this code work for a Master project and we had to finish more work as well. I'll definitely try your suggestion if I use Mask R-CNN in the future to see where the fork to add a new dataset breaks.
I close this issue but feel free to re-open it if you think it is better for other users.
Thanks!

authors: chengyangfu fperezgamonal

repo: facebookresearch/maskrcnn-benchmark


text:
Remove apex dependency after PyTorch 2.0?

This is to look into whether or not we still need to use apex for speedups if out-of-the-box PyTorch 2.0 may "just work".  Will require benchmarking at a few different scales to confirm.

@suchenzang are there any specific benchmarks that we would be interested in running? I am thinking about the generation wps benchmark introduced here: https://github.com/facebookresearch/metaseq/pull/240

@igormolybogFB I would also run a small training baseline run too (and confirm that numerics mostly match).  And ideally a few steps of a > 100B run would be great too, pending compute availability.

First step - moving apex dependency into metaseq first for parity (can remove kernels one by one if throughput is the same using PyTorch 2.0): https://github.com/facebookresearch/metaseq/pull/697

authors: igormolybogFB suchenzang

repo: facebookresearch/metaseq


text:
EncodedVideo.from_path() returns No such file in Python 3.7.6

I'm getting this error

FileNotFoundError: [Errno 2] No such file or directory

from EncodedVideo.from_path() although the file exists. I believe it may be related to this bug; I'm using Python 3.7.6.

After some experimenting, I think the problem may not be my Python version but my path. Does EncodedVideo.from_path() not work if the path is a symbolic link?

repo: facebookresearch/pytorchvideo


text:
Add parameter and docstring for recommendation UDFs

Here: https://github.com/facebookresearch/torcharrow/blob/a8205776ba862f046bc661a69d9297a41c6c9a23/torcharrow/functional.py#L140-L207
Example is bucketize:
https://github.com/facebookresearch/torcharrow/blob/a8205776ba862f046bc661a69d9297a41c6c9a23/torcharrow/functional.py#L109-L137
This helps render better docs:

cc @YLGH

Resolved via https://github.com/facebookresearch/torcharrow/pull/341

repo: facebookresearch/torcharrow


text:
Fixes for pytorch tests - 1/n

Multiple changes in one PR (happy to break it down if needed)

Filter torch.testing
Adding is_complex, and is_contiguous
Do not raise Dynamo assertion when Torch operation itself raises assertion. This is for cases like follows. Created a new type of assertion - TorchRuntimeError.

import torch
import torchdynamo

def fn(x, y):
    try:
        x.expand_as(y)
    except RuntimeError:
        return False
    return True

x = torch.randn(4)
y = torch.randn(10)
ref = fn(x, y)

with torchdynamo.optimize("eager"):
    res = fn(x, y)

print("Success")

Xref - https://github.com/facebookresearch/torchdynamo/issues/69

repo: facebookresearch/torchdynamo


text:
Train SimCLR on 1 gpu Colab Fatal error -- HOOKS.Tensorboard not found

Instructions To Reproduce the 🐛 Bug:

what changes you made (git diff) or what code you wrote

ran copy of Train SimCLR on 1-gpu with VISSL tutorial on Colab. Same behavior if I ran without making a copy.

what exact command you run:
https://colab.research.google.com/drive/1Rt3Plt3ph84i1A-eolLFafybwjrBFxYe?usp=sharing
what you observed (including full logs):

!python3 run_distributed_engines.py \
    hydra.verbose=true \
    config=quick_1gpu_resnet50_simclr \
    config.DATA.TRAIN.DATA_SOURCES=[synthetic] \
    config.CHECKPOINT.DIR="./checkpoints" \
    config.HOOKS.TENSORBOARD_SETUP.USE_TENSORBOARD=true

####### overrides: ['hydra.verbose=true', 'config=quick_1gpu_resnet50_simclr', 'config.DATA.TRAIN.DATA_SOURCES=[synthetic]', 'config.CHECKPOINT.DIR=./checkpoints', 'config.HOOKS.TENSORBOARD_SETUP.USE_TENSORBOARD=true', 'hydra.verbose=true']
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/hydra/_internal/config_loader_impl.py", line 513, in _apply_overrides_to_config
    OmegaConf.update(cfg, key, value, merge=True)
  File "/usr/local/lib/python3.7/dist-packages/omegaconf/omegaconf.py", line 590, in update
    root[key_] = {}
  File "/usr/local/lib/python3.7/dist-packages/omegaconf/dictconfig.py", line 259, in __setitem__
    key=key, value=value, type_override=ConfigKeyError, cause=e
  File "/usr/local/lib/python3.7/dist-packages/omegaconf/base.py", line 101, in _format_and_raise
    type_override=type_override,
  File "/usr/local/lib/python3.7/dist-packages/omegaconf/_utils.py", line 629, in format_and_raise
    _raise(ex, cause)
  File "/usr/local/lib/python3.7/dist-packages/omegaconf/_utils.py", line 610, in _raise
    raise ex  # set end OC_CAUSE=1 for full backtrace
omegaconf.errors.ConfigKeyError: Key 'HOOKS' is not in struct
	full_key: config.HOOKS
	reference_type=Any
	object_type=dict

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "run_distributed_engines.py", line 194, in <module>
    hydra_main(overrides=overrides)
  File "run_distributed_engines.py", line 172, in hydra_main
    cfg = compose("defaults", overrides=overrides)
  File "/usr/local/lib/python3.7/dist-packages/hydra/experimental/compose.py", line 37, in compose
    with_log_configuration=False,
  File "/usr/local/lib/python3.7/dist-packages/hydra/_internal/hydra.py", line 512, in compose_config
    from_shell=from_shell,
  File "/usr/local/lib/python3.7/dist-packages/hydra/_internal/config_loader_impl.py", line 156, in load_configuration
    from_shell=from_shell,
  File "/usr/local/lib/python3.7/dist-packages/hydra/_internal/config_loader_impl.py", line 277, in _load_configuration
    ConfigLoaderImpl._apply_overrides_to_config(config_overrides, cfg)
  File "/usr/local/lib/python3.7/dist-packages/hydra/_internal/config_loader_impl.py", line 518, in _apply_overrides_to_config
    ) from ex
hydra.errors.ConfigCompositionException: Could not override 'config.HOOKS.TENSORBOARD_SETUP.USE_TENSORBOARD'.
To append to your config use +config.HOOKS.TENSORBOARD_SETUP.USE_TENSORBOARD=true

please simplify the steps as much as possible so they do not require additional resources to
run, such as a private dataset.

Expected behavior:
If there are no obvious error in "what you observed" provided above,
please tell us the expected behavior.
Environment:
Provide your environment information using the following command:
wget -nc -q https://github.com/facebookresearch/vissl/raw/master/vissl/utils/collect_env.py && python collect_env.py

-------------------  ---------------------------------------------------------------
sys.platform         linux
Python               3.7.10 (default, May  3 2021, 02:48:31) [GCC 7.5.0]
numpy                1.19.5
Pillow               7.1.2
vissl                0.1.5 @/usr/local/lib/python3.7/dist-packages/vissl
GPU available        True
GPU 0                Tesla T4
CUDA_HOME            /usr/local/cuda
torchvision          0.6.1+cu101 @/usr/local/lib/python3.7/dist-packages/torchvision
hydra                1.0.6 @/usr/local/lib/python3.7/dist-packages/hydra
classy_vision        0.6.0.dev @/usr/local/lib/python3.7/dist-packages/classy_vision
tensorboard          1.15.0
apex                 0.1 @/usr/local/lib/python3.7/dist-packages/apex
cv2                  4.1.2
PyTorch              1.8.1+cu102 @/usr/local/lib/python3.7/dist-packages/torch
PyTorch debug build  False
-------------------  ---------------------------------------------------------------
PyTorch built with:
  - GCC 7.3
  - C++ Version: 201402
  - Intel(R) Math Kernel Library Version 2020.0.0 Product Build 20191122 for Intel(R) 64 architecture applications
  - Intel(R) MKL-DNN v1.7.0 (Git Hash 7aed236906b1f7a05c0917e5257a1af05e9ff683)
  - OpenMP 201511 (a.k.a. OpenMP 4.5)
  - NNPACK is enabled
  - CPU capability usage: AVX2
  - CUDA Runtime 10.2
  - NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_70,code=sm_70
  - CuDNN 7.6.5
  - Magma 2.5.2
  - Build settings: BLAS_INFO=mkl, BUILD_TYPE=Release, CUDA_VERSION=10.2, CUDNN_VERSION=7.6.5, CXX_COMPILER=/opt/rh/devtoolset-7/root/usr/bin/c++, CXX_FLAGS= -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_KINETO -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter -Wno-unused-variable -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow, LAPACK_INFO=mkl, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, TORCH_VERSION=1.8.1, USE_CUDA=ON, USE_CUDNN=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=ON, USE_NNPACK=ON, USE_OPENMP=ON,

CPU info:
-------------------  ------------------------------
Architecture         x86_64
CPU op-mode(s)       32-bit, 64-bit
Byte Order           Little Endian
CPU(s)               2
On-line CPU(s) list  0,1
Thread(s) per core   2
Core(s) per socket   1
Socket(s)            1
NUMA node(s)         1
Vendor ID            GenuineIntel
CPU family           6
Model                79
Model name           Intel(R) Xeon(R) CPU @ 2.20GHz
Stepping             0
CPU MHz              2199.998
BogoMIPS             4399.99
Hypervisor vendor    KVM
Virtualization type  full
L1d cache            32K
L1i cache            32K
L2 cache             256K
L3 cache             56320K
NUMA node0 CPU(s)    0,1
-------------------  ------------------------------

When to expect Triage
VISSL devs and contributors aim to triage issues asap however, as a general guideline, we ask users to expect triaging in 1-2 weeks.

Hi @duane-edgington , thank you for reaching out about this. It seems like the issue is coming from

the command you are using installs VISSL pip packages - which is from Feb'21
the code is running the master commands where the HOOKS.TENSORBOARD_SETUP change was done.

To solve this:

in the tutorial, can you install VISSL from source instead: https://github.com/facebookresearch/vissl/blob/master/INSTALL.md#Install-from-source-in-PIP-environment and then try the command. This way your VISSL version and the commands will be in sync

NOTE also that we will work on releasing the new VISSL pip packages so that everything is in sync.

Thank you for the timely response. I will try your solution, and look forward to your new pip package releases as well.
From: "notifications" @.>
To: "facebookresearch/vissl" @.>
Cc: "Duane Edgington" @.>, "Mention" @.>
Sent: Wednesday, June 16, 2021 6:51:53 AM
Subject: Re: [facebookresearch/vissl] Train SimCLR on 1 gpu Colab Fatal error -- HOOKS.Tensorboard not found (#337)
Hi [ https://github.com/duane-edgington | @duane-edgington ] , thank you for reaching out about this. It seems like the issue is coming from
1. the command you are using installs VISSL pip packages - which is from Feb'21
2. the code is running the master commands where the HOOKS.TENSORBOARD_SETUP change was done.

To solve this:
1. in the tutorial, can you install VISSL from source instead: [ https://github.com/facebookresearch/vissl/blob/master/INSTALL.md#Install-from-source-in-PIP-environment | https://github.com/facebookresearch/vissl/blob/master/INSTALL.md#Install-from-source-in-PIP-environment ] and then try the command. This way your VISSL version and the commands will be in sync

NOTE also that we will work on releasing the new VISSL pip packages so that everything is in sync.
—
You are receiving this because you were mentioned.
Reply to this email directly, [ https://github.com/facebookresearch/vissl/issues/337#issuecomment-862398837 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AC5RY7BJLBFEQXSETDQNW5DTTCT7TANCNFSM46NB5YMA | unsubscribe ] .

Hi @duane-edgington , thank you for reaching out about this. It seems like the issue is coming from

the command you are using installs VISSL pip packages - which is from Feb'21
the code is running the master commands where the HOOKS.TENSORBOARD_SETUP change was done.

To solve this:

in the tutorial, can you install VISSL from source instead: https://github.com/facebookresearch/vissl/blob/master/INSTALL.md#Install-from-source-in-PIP-environment and then try the command. This way your VISSL version and the commands will be in sync

NOTE also that we will work on releasing the new VISSL pip packages so that everything is in sync.

Building from source indeed solves the problem.
I tried the approach with regards to this notebook as well as other tutorial notebooks too.
Let me know if an update has to be made, I will gladly get it done!

Thank you for the update. I spent time yesterday and this morning trying to install VISSL from source using PIP in the notebook, but I was unsuccessful in solving the problem (i.e. the notebook would still not run, and would fail on import vissl.
Can you send me the cells or complete notebook with the successful install of VISSL and other needed packages so the tutorial notebook will execute with current packages, and everything in sync?
This is very frustrating for a newbie trying to learn the framework...
thank you
Duane Edgington
[ @.*** | @.*** ]
github duane-edgington
From: "notifications" @.>
To: "facebookresearch" @.>
Cc: "Duane Edgington" @.>, "Mention" @.>
Sent: Thursday, June 17, 2021 11:37:58 AM
Subject: Re: [facebookresearch/vissl] Train SimCLR on 1 gpu Colab Fatal error -- HOOKS.Tensorboard not found (#337)
Hi [ https://github.com/duane-edgington | @duane-edgington ] , thank you for reaching out about this. It seems like the issue is coming from
1. the command you are using installs VISSL pip packages - which is from Feb'21
2. the code is running the master commands where the HOOKS.TENSORBOARD_SETUP change was done.

To solve this:
1. in the tutorial, can you install VISSL from source instead: [ https://github.com/facebookresearch/vissl/blob/master/INSTALL.md#Install-from-source-in-PIP-environment | https://github.com/facebookresearch/vissl/blob/master/INSTALL.md#Install-from-source-in-PIP-environment ] and then try the command. This way your VISSL version and the commands will be in sync

NOTE also that we will work on releasing the new VISSL pip packages so that everything is in sync.
Building from source indeed solves the problem.
I tried the approach with regards to this notebook as well as other tutorial notebooks too.
Let me know if an update has to be made, I will gladly get it done!
—
You are receiving this because you were mentioned.
Reply to this email directly, [ https://github.com/facebookresearch/vissl/issues/337#issuecomment-863472660 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AC5RY7BWAV4CRC4GIVMKHZTTTI6INANCNFSM46NB5YMA | unsubscribe ] .

Hi @duane-edgington, can you take a look at: https://github.com/facebookresearch/vissl/pull/347, to see if this fixes your issue?

Thank you for the note.
No, I still have the same kind of error.
Cell 2 error
Successfully installed torch-1.9.0
WARNING: The following packages were previously imported in this runtime:
[torch]
You must restart the runtime in order to use newly installed versions.
upon restart, I get the following error in cell 3

ImportError Traceback (most recent call last)
[ https://localhost:8080/# |  ] in  () 1 import vissl 2 import tensorboard ----> 3 import apex 4 import torch
5 frames
[ https://localhost:8080/# | /usr/local/lib/python3.7/dist-packages/apex/amp/_amp_state.py ] in  () 12 import collections . abc as container_abcs 13 else : ---> 14 from torch . _six import container_abcs 15 16
ImportError : cannot import name 'container_abcs' from 'torch._six' (/usr/local/lib/python3.7/dist-packages/torch/_six.py)
--------------------------------------------------------------------------- NOTE: If your import is failing due to a missing package, you can
manually install dependencies using either !pip or !apt.
To view examples of installing some common dependencies, click the
"Open Examples" button below.
From: "notifications" @.>
To: "facebookresearch" @.>
Cc: "Duane Edgington" @.>, "Mention" @.>
Sent: Monday, June 28, 2021 7:24:12 AM
Subject: Re: [facebookresearch/vissl] Train SimCLR on 1 gpu Colab Fatal error -- HOOKS.Tensorboard not found (#337)
Hi [ https://github.com/duane-edgington | @duane-edgington ] , can you take a look at: [ https://github.com/facebookresearch/vissl/pull/347 | #347 ] , to see if this fixes your issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, [ https://github.com/facebookresearch/vissl/issues/337#issuecomment-869730242 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AC5RY7DUCHI2KVEBW66WEHDTVCAYZANCNFSM46NB5YMA | unsubscribe ] .

https://github.com/facebookresearch/vissl/pull/347#issuecomment-870067084
User-verified Fix addressed in #347
CC : @iseessel @prigoyal

@duane-edgington @pranavsinghps1 We have updated the tutorial to be in working order: https://vissl.ai/tutorials/Train_SimCLR_on_1_gpu_V0_1_6 in our latest vissl release: https://github.com/facebookresearch/vissl/releases/tag/v0.1.6

authors: duane-edgington iseessel pranavsinghps1 prigoyal

repo: facebookresearch/vissl


text:
Python 3.7 support

Looks like we aren't going to get lucky and have 3.7 just work ☹ .  I'm trying to get acquainted with these issues early so when 3.7 goes live, I'll be ready.
Issues seem to be be contained to bre and seem to deal with escaped characters again.  Not sure what Python is doing in regards to escapes, but it looks like there is more work to be done:
                else:
                    try:
>                       this = chr(ESCAPES[this][1])
E                       KeyError: '\\c'

I understand what is happening now.  The re template parser is choking on unexpected replace back references.  We only use \c, \l, and \C...\E and \L...\E which are used for capitalizing replace chars or spans.  I may have to implement a more creative way to accomplish this.

It should be noted that only re has issues with this.  The regex module still handles this with no issues.

This is tricky as it seems we that re arbitrarily fails on any escape that is followed by an ASCII character in parse_template.  Why only ASCII, I'm not sure.  So we need to make sure they are escaped passing through somehow that passes, but be able to find them afterwards.

So, after thinking about this, I think the best way to approach this is to preprocess and apply upper and lower case back references to the template before sending through sre_parse.parse_template. We can change case of literals, and then take note of the group slots that we must change on replace.  This will allow us to completely eliminate the need to pass our back references through sre_parse.  By time sre_parse gets the template, it will be transformed into a standard template and we should have all the information we need.
This is probably the way it should have always been, oh well.  This will be a bit of work, but I'm glad I caught it now rather than later.  At least now there is a good chance I'll have this done by 3.7 release.

This is now working on 3.7 dev.

Why only ASCII, I'm not sure.

Because giving new meaning to escape sequences consisting of a backslash following an ASCII letter is a safe way to introduce new features. It is possible that special escape sequences \x, \u, \U, \N etc could be supported in future in re replacement strings. This can leads to producing unexpected results if they are silently accepted in previous versions. Raising deprecation warnings in 3.5 and 3.6 and errors in 3.7 will allow to add new escape sequences in 3.8 or 3.9 with minimal harm. This is a long term plan.

@serhiy-storchaka Thanks for the explanation!  Wasn't sure why the change occurred, but that makes sense.  I've avoiding that path now, so I shouldn't run into the issue anymore, but it is nice know.

authors: facelessuser serhiy-storchaka

repo: facelessuser/backrefs

license: mit


text:
Include templating support

This PR includes support for templating.
This means it can build different versions of the image with the same file, which can be configured via buildinfo.json.
Note that it is still missing logic to push tags, as well as the adaption of the watchdog.

I will take care about the watchdog, if this got merged

I will take care about the watchdog, if this got merged

It would be really great if you could take care of that, I'm not really proficient in Go and my PR would likely get ugly.
However, from my point of view both repos are tightly coupled and merging this PR would break the watchdog, which is why I would like to ask you to start working on the watchdog before this gets merged.
Furthermore these were the requirements I had in mind for the watchdog:

Write the new buildinfo.json (obviously)
Include proper support for the stable tag and don't alias it to latest (which is why I made this PR in the first place)
Adapt README.md modifications. Here I included comments <!-- start autogeneration tags --> and <!-- end autogeneration tags --> which should be markers for those parts which get generated by the watchdog.

It would be great if you take these into account. Please tag me when you are finished, I'll happily review your PR.

Should be ready now. Tell me if you want to have some squashed commits as my history is a bit messy.

I just squash it when the updater part is cleared.

Was there a reason why jinja2 templating was used to generate a Dockerfile with the sha1 and version added in? From what I can tell it would keep the layer caching for all the previously published images. If that is not a concern, then docker build-args could be used instead to populate the env variables:
ARG VERSION
ENV VERSION=${VERSION}

This would result in the jinja code not being needed.

I see, i think i missed that, could you try to generate the image by using build-args?

The reason is mostly that templating was the easiest solution that came to my mind for solving that mess we had before. Docker build-args also work and seem like the cleaner solution here, so feel free to go for it :+1:

authors: Fank StopMotionCuber SuperSandro2000 perobertson

repo: factoriotools/factorio-docker


text:
filter is empty

Hey! I am fairly new to Nest and server side programming in general so I apologise if the situation I am stuck at is just a small error on my part. I am trying to filter files by the email id of the user they were created by and am hence using encodeURI(http://localhost:3000/uploads/?filter={"userId":{"$eq":${user.email}}}&page=0&limit=2) as my url for the get request. However, for some reason my filter is always empty. Would love some help with this. Thanks!
Repo link: https://github.com/upneet2213/file-server-v2

Hello,
We have the same issue with the filter, we tried URL-encoding the filter parameter it didn't work.
We're using Nest.js 9

We've found the solution in this way, it seems the problem was because of the validation pipe name usage, simply update your controller like this and it'll work:
   // first add ValidationPipe import from @nestjs/common
   import { Get, Param, Query, ValidationPipe } from '@nestjs/common';

   // change library validation import like this
   import { ValidationPipe as ParseFilterPipe } from '@forlagshuset/nestjs-mongoose-paginate';

   // update query validator like this
     async filterAsync(
    @Query( new ValidationPipe({ transform: true,}),
                  new ParseFilterPipe(YourCollectionProperties))
    collectionDto: CollectionDto,
  ): Promise<CollectionResponse ...

repo: fagbokforlaget/nestjs-mongoose-paginate


text:
use Go validator

use Go validator instead multiple conditions
Originally posted by @juliensie in https://github.com/fairhive-labs/preregister/issues/17#issuecomment-1222178973

blocks ECDSA/HMAC tests => sponsor is not set in reference tokens !

test issues in crypto package...

Update ecdsa_test.go and hmac_test.go files

sponsor variable has been updated to valid ETH address 0xD01efFE216E16a85Fc529db66c26aBeCf4D885f8 => reference tokens must be regenerated !

repo: fairhive-labs/preregister


text:
Falco pods failing in RHEL 8.10

We have been trying to install falco helm chart on RHEL 8.10. After a few seconds the pod go into init error and then they are not visible in any of the namespaces. Following is the configuration on which we were trying to install the falco charts.
Error:
Defaulted container "falco" out of falco, falcoctl-artifact-follow, faclo-driver-loader (init), falco-artifact-install (init)
Error from server (Bad request) container "faclo" in pod "xxxx-falco-zw3rr" is waiting to start: PodInitializing
Event Details:
Type             Reason                  Age           From.                                      Message
Warning       Backoff                  80s           kubelet                 Back-off restarting failed container falco-driver-loader in pod (some_pod)
OS Details:
NAME="Red Hat Enterprise Linux"
VERSION="8.10 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.10"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.10 (Ootpa)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:8::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
Kernel Version:  4.18.0-553.5.1.el8_10.x86_64
Kubernetes Version: 1.29.3
CPU: 8 cores
Memory: 16 GiB

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

repo: falcosecurity/charts


text:
ROADMAP: Improved Falco Outputs

Description: The goal behind this idea is to improve the available options for sending alerts from Falco when a security violation occurs inside a container. Currently outputs are limited to stdout, files, syslog, and executing a program. We’d like to offer more output options such as: NATS.io, Kafka, gRPC, Google Pub/Sub, AWS SNS, HTTPs Webhooks, etc.
Recommended Skills: C/C++ experience, working with external libraries, working knowledge of message queues and modern Pub/Sub systems.
Mentor(s): Mark Stemm (@mstemm), Loris Degioanni (@ldegio), Michael Ducy (@mfdii)

This pr (#523) shows how to implement an output handler. It also shows how to leverage C++ functions in Lua which makes it easier to use C/C++ libraries for the output destination.

Hello, I'd like to contribute to this idea, can someone give me advice on how to get start with the project :) Thanks!

@laphets I've made sure that we have issues tagged with help wanted. These are various issues we need fixed and might provide a better opportunity to get started with the project. Also there are rules you can contribute to in the falcosecurity/profiles repo. For adding additional output destinations, you should review #523 to understand what code changes need to be made to add an output. Feel free to ping me on Slack if you have more questions.
A GRPC output might be a good start. We are investigating the idea of using sidecar containers to provide the various output destinations for Falco and being able to tie the containers together with GRPC would be better than the current implementation of a named pipe.

@mfdii I think that the output of this will be to implement a gRPC streaming service to stream events.
In that way we can decouple completely Falco from its outputs by having plugins implement the client part in any language with gRPC support.

For following up some discussions we had on Slack, here a quick schema about basic principles I had in mind.  A lot are inspired by my falcosidekick with some enhancements I wanted to add (queues + gRPC)

Feel free to discuss about and challenge.
The main challenge will be to formalize and standardize how we implement plugins, those could be in any language, only interfaces matters and that let anybody write and propose a new output.

/kind design

authors: Issif fntlnz laphets leodido mfdii

repo: falcosecurity/falco


text:
Patching the CMake to respect $FALCO_VERSION

Signed-off-by: Kris Nova kris@nivenly.com

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

/kind flaky-test

If contributing rules or changes to rules, please make sure to also uncomment one of the following line:

/kind rule-update

/kind rule-create

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area engine

/area rules

/area deployment

/area integrations

/area examples

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

Welcome @kris-nova! It looks like this is your first PR to falcosecurity/falco 🎉

@kris-nova: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: leodido
If they are not already assigned, you can assign the PR to them by writing /assign @leodido in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kris-nova: There is not a label identifying the kind of this PR.
Please specify it either using /kind <group> or manually from the side menu.
In case you do not know which kind this proposal is please mention the maintainers using @team/maintainers.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fntlnz
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [fntlnz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 5021372516c8385ecd8fb55a17f0f8160f756aa4

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fntlnz, leodido
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [fntlnz,leodido]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

be65690 Merge branch 'dev' into bpf-version-patch

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

authors: kris-nova poiana