Regression in argument/parameter types in 2.6.x-dev DDC

Hi there!
We have been smoke testing app builds at Workiva over the past week or so using 2.6.0-dev.7.0. We have noticed a consistent build failure stemming from the typing system.
I have created a reduced test case here: https://dartpad.dartlang.org/6c04d83abb0ce4786974f7a2bb7e23a1
As you can see in dartpad, the program compiles with no trouble using version 2.5.2.
However, if I try to compile the same program by running pub run build_runner build using the 2.6.0-dev.7.0 release, I get the following error:
Error compiling dartdevc module:package_name|web/main.ddc.js

web/main.dart:20:57: Error: The argument type 'FooComponent' can't be assigned to the parameter type 'BaseUiComponent<Null>'.
 - 'FooComponent' is from 'main.dart'.
 - 'BaseUiComponent' is from 'main.dart'.
    return customRenderer(propsInstance, stateInstance, this);
                                                        ^

I would expect this to work without it crashing as it did in prior Dart releases. Is this seen as a bug or as a side effect of an intentional change?

If I'm reading the Dart Language Specification correctly, reporting the error is the intended behavior in the example above.  The reason is that providing missing parameters to generic typedefs is made dependent on how the type parameters of the typedef occur in the type it's describing.
Type CustomReaderFunction in the signature of render is missing type arguments, and they are provided by the algorithm described in section 14.3.2 The Instantiation to Bound Algorithm.  In the notation of the algorithm, we have U1,0 = UiProps, U2,0 = UiState, U3,0 = BaseUiComponent<T>, and V0 = CustomRenderFunction<UiProps, UiState, BaseUiComponent<T>>.  The condition for step 1. aren't met, so we move to step 2. where to obtain V1 from V0 we substitute T with Null in V0 because it's in a contravariant position there.  The position is contravariant as per section 14.1 Variance of the spec.
I landed a CL some time ago to make the CFE compliant to the spec in this regard.

Agreeing entirely with @stefantsov about the explanation, I can add that the instantiation to bound algorithm is intended to produce a common supertype of all the possible types of instances of the given generic type, except that this is not possible in some cases.
So, e.g., if C is a generic class taking one type argument, the raw type C will generally desugar to a parameterized type C<T> such that every instance of C has a type which is a subtype of C<T>.
In some cases that's easy (for C<X extends num> {} we just choose num as the type argument). An example where it is not possible is typedef F<X> = X Function(X). With that declaration, F<T1> and F<T2> are just unrelated for any pair of distinct types T1 and T2, so there is no type T0 such that F<T0> is a common supertype.
The rule that cycles are eliminated in contravariant positions by Null serves to make the outermost type more general than any actual value the given type variable could have, such that we get this common supertype.
In the given example this means that it is necessary to pass the type argument as in BaseUiComponent<FooProps> in order to get a type for customRenderer which is not a common supertype. This is inconvenient because it is a breaking change and because FooProps occurs twice, but the trade-off is that instantiation to bound more consistently produces a common supertype (which makes the outcome of using a raw type more predictable).
Another matter is that it would be convenient to use a type alias to eliminate the redundancy:
// This feature is planned, but not yet implemented.
typedef BaseUiRenderFunction<TProps extends UiProps, TState extends UiState> =
    CustomRenderFunction<TProps, TState, BaseUiComponent<TProps>>;

We could then express the type as BaseUiRenderFunction<FooProps, FooState>.

Smaller reproduction here:
class A<T extends num> {}
typedef void F<T extends num, C extends A<T>>(T p, C c);

void test(F f) {
  f(3, A<num>());
}
void main() {
}

I would expect this to work without it crashing as it did in prior Dart releases. Is this seen as a bug or as a side effect of an intentional change?

cc @eernstg
If I'm reading this correctly, I believe that this is a result of a change in the specification landed late last year.  It looks like we are in an inconsistent state with the implementations though: the CFE has changed this, but the analyzer has not.  In either case, we should have explicitly rolled this out as a breaking change.
We will need to either:

roll back the CFE change re-land it after a breaking change announcement (preferably with the analyzer synced up)
roll forward (fix the analyzer)
roll back the specification change

@robbecker-wf how bad of a break is this?  Are you seeing widespread breakage in packages/apps?
I'm guessing we haven't seen any internal breakage because of this, since we now have all compilers on the CFE internally?

@leafpetersen wrote:

but the analyzer has not [implemented this yet]

It was a very long process to get this change landed, and the fact that there was essentially zero breakage internally played an important role. This was before we had a breaking change process.
I consider the more consistent behavior of the algorithm (which makes it simpler to explain what it does) a benefit, but we may of course need to go through a breaking change process if it turns out to be more breaking than expected.

how bad of a break is this?
It was not great, but we've verified that we can fix it. Since it seems to be only us reporting this as a problem, it was hard to get in initially and it's been in for a long time .. I would lean toward fixing it forward by having the analyzer be consistent with CFE.

Maybe there are already things happening to accomplish this, but it seems it would be very beneficial to get things in place to ensure more consistency between the various pieces. We've been heavily affected by differences between the analyzer and compilers, and between the different compilers.

@eernstg @leafpetersen @stefantsov
We have found a workaround for our libs that only requires a change at the typedef itself - not in any of the implementations that utilize the typedef.  So at this point - we're ok with you guys moving forward / not reverting.
Its very encouraging to hear that you have implemented a breaking change review process / release process to prevent these types of breakages in minor releases in the future.  In the past, there have been a number of them - specifically around the behavior of generic parameters - that have cost Workiva a tremendous amount of time and money to either work around, troubleshoot in an effort to get a fix, or both.
With this change in particular - I'd like to request that the analyzer behavior be updated to match what the compiler does.
In general - with any of these types of changes - and with the handful of open issues that center around the compile time behavior of DDC differing from what the analysis server does - some amount of "good faith" is lost.  One of the biggest "selling points" of the Dart 2 release was the concept of a "common" front-end.  The idea that - if the analyzer didn't complain, DDC wouldn't either.  However, there have been numerous examples since the release of Dart 2 that call into question whether that "commonality" is something that is stable that consumers can truly rely on in their developer ecosystems.  Furthermore, there continue to be major differences between the JS that is generated by the DDC versus Dart2js - which causes more pain for consumers - especially very large ones like Workiva.

how bad of a break is this?

Compared to the OOM errors that continue to crop up in tests, and now in non-test dart2js compilations - its miniscule.  The memory issues are much more concerning, IMO.

@robbecker-wf wrote:

We've been heavily affected by differences between the analyzer
and compilers, and between the different compilers

That is definitely a kind of problem that shouldn't exist, but we know it does come up. The 'common' in 'common front end' would be very helpful in this respect, as more and more parts of the tool chain use it. Some elements will remain incompatible even then, e.g., computations using web numbers respectively vm numbers in Dart will not behave identically.
@aaronlademann-wf wrote:

a "common" front-end .. However .. there continue to be major differences

Thanks for emphasizing this point again, it is obviously important.
The common front end is widely used in our tools, but the analyzer has its own static analysis. The analyzer needs to do much more recovery work when it performs an analysis on a program with missing parts or errors of any kind, so the transition where the analyzer switches over to use the common front end is quite complex and will not happen in the near future. With respect to the differences between DDC and dart2js I don't know the details so I can't comment on that (and similarly for the memory issues).
But with respect to the change to instantiation to bound I hear support for moving forward:

I would lean toward fixing it forward by having the analyzer be consistent with CFE

I'd like to request that the analyzer behavior be updated to match what the compiler does.

Given that we have a fix on our end for the compiler crash and the work going forward is on the analyzer, should this issue be closed and a new one to track the analyzer fix be made?

@leafpetersen, @munificent, @lrhn, can we decide on the next step for this at the language meeting on Wednesday?

I'd be interested to hear back after today's meeting if this is discussed.

There is general support for moving forward and implementing the change in the analyzer, but we need to scrutinize a couple of other changes that may be related.


Auto-semicolon at the end of return statements changes semantic.

TypeScript Version:  4.0.5

Search Terms:
return semicolon
Code
function hello(x,y) {
	return /* (x>5) && */
		   (y<6) &&
		   (x+y<12);
}

I know commenting out code is bad practice, but don't we all do that occasionally.
In this case, I wanted to quickly remove one clause from a list of conditions, which for clarity had been written one per line
(clauses can be long).
Expected behavior:
The produced .js should match the .ts.
Actual behavior:
This nightmarish-to-debug monstrosity is produced instead:
function hello(x, y) {
    return; /* (x>5) && */
    (y < 6) &&
        (x + y < 12);
}

Note the addition of the semicolon after the return, a slight change of semantics.
Specifically instructing the function to return a boolean (adding ":boolean") will still not save you from this, either.
Removing the comment does not fix the problem. Uncommenting it produces the expected correct result.
It looks like TypeScripts just adds a semicolon after any return statement followed by no code before an end-of-line, regardless of what follows in the next line.
I don't understand. Why should end-of-lines matter? Isn't that incredibly dangerous to do? What am I missing?
Playground Link:
https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABACwKYBt1wBQA8A0AngJQDeAUAJABOqUI1SiA9AFR4B8ArMYgGR9EiVsyqUhQ7IQA8ANl4CxlPAGpCAXnUB2YgG5yAX3LkhQA
Related Issues:
Edit: for clairty.

The produced .js should match the .ts.

The produced .js does match the .ts. This is just how JavaScript behaves. Even when the semicolon is not inserted the function will still return undefined.
What you want would require to emit different JavaScript than your TypeScript (removing the newline), and this is deifnitely out of scope of TypeScript.

The compiler actually warns you about the issue with the unreachable code detection.

Thank you!  I wasn't aware of that JavaScript behavior
(wow, that's ugly -- JavaScript never stops to amaze me, I keep making wrong assumptions about its basic level of decency; thanks TypeScript again, I guess!).
Closing the issue.


[OSDEV-1004] Update the connection configs for opensearch to enable local development

[OSDEV-1004] Update the connection configs for opensearch to enable local development

Utilized environment variables to disable authentication for OpenSearch during local development, as the authentication isn't necessary.

Need to test it on dev env.


[BUG] ... Ready to Assign Colour no longer works

Describe the bug
Since the URL change, I have got that part fixed up and most things are being recognised again, But "Emphasize Available to Assign" function is not working
It remains as the default colours instead of Yellow

Same here.

Some more information. I have updated to 3.6.0 and everything else works but the "Emphasize Available to Assign" I am using Chrome that I just updated.

Hey @wyvernvenners  the fix for this should be in our current release! If you notice the issue still exists and you're definitely running the newest version of the toolkit, please reopen! Thanks!
Please note, all browser can take up to an hour to provide updates to all users. You can force an update if it's available for you by going to chrome://extensions and clicking the "Update" button. Firefox users can go to about:addons, click the setting cog, and click "Check for updates...".


cmd/go: fuzz docs should update TB doc to say “T, B, and F.”

% gotip doc testing.TB
...
    TB is the interface common to T and B.

should say “T, B, and F.”
/cc @golang/fuzzing

Checking in on this issue as it's labeled a release blocker for Go 1.18. Is there any update?

@cherrymui , @julieqiu
I gave a try to fix this issue.  I made the changes and raised a Gerrit review.
But I need help is testing these changes. Is there a guide that I can follow to test out the fix.
Thanks


[TS migration] Migrate 'NetworkConnection.js' lib to TypeScript

Details

Migrated  NetworkConnection.js lib to TypeScript
Fixed Issues

$ https://github.com/Expensify/App/issues/24898
PROPOSAL: https://github.com/Expensify/App/issues/24898
Tests

Log in
Launch console, and filter logs by NetworkConnection text
Refresh the app and verify if network connection logs appear in the controls
Turn off and then turn on internet connection and verify if app reconnected to the network and if new logs appeard in the console

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Sam as Tests

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

https://github.com/Expensify/App/assets/39538890/82acd0eb-f9cb-49ea-913b-4464ba4ff859

Mobile Web - Chrome

https://github.com/Expensify/App/assets/39538890/5ffa495f-e6b5-4947-9be3-575a1e8bd5c6

Mobile Web - Safari

https://github.com/Expensify/App/assets/39538890/47b1948c-63f6-4831-9e02-2b88ed9c1c4c

Desktop

https://github.com/Expensify/App/assets/39538890/56282eda-10bb-411f-b20b-1f552bd7d606

iOS

https://github.com/Expensify/App/assets/39538890/652b4bba-a0f4-4f7c-a17c-5d36226abec6

Android

https://github.com/Expensify/App/assets/39538890/2f19a9cb-71b8-4427-9209-1b9a8cb40ff6

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

Bit a race condition happening, the checklist was completed and the check was re-run but this was not indicated correctly on the issue prior to merge.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/robertjchen in version: 1.3.81-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/robertjchen in version: 1.3.83-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Add Dockerfile

Add first step to create docker image
I need to automate the docker image publishing but for now it should be ok it is published on https://hub.docker.com/repository/docker/zelldon/zeebe-hazelcast
This makes it possible to test the c# connector with test container etc.

I think we can automate the Docker build and push either using the Zeebe CI or Github Docker actions.

Agree but had no time yesterday :) I will do when I have more time


Support functions detection

When using exported functions like iterable_to_array() from https://packagist.org/packages/bentools/iterable-functions, those packages are marked as unused. Is it possible to add the detection?

So far, this is known limitation mentioned in readme:

Function and constant usages are not analysed
Therefore, if some package contains only functions, it will be reported as unused

I have few ideas how to implement that, but I'm not sure those will be viable...

Understand.
Thanks for the great tool anyways, exceeded expectations!
On Sun, Feb 18, 2024, 20:13 Jan Nedbal @.***> wrote:

So far, this is known limitation mentioned in readme:
Function and constant usages are not analysed
Therefore, if some package contains only functions, it will be reported as
unused
I have few ideas how to implement that, but I'm not sure those will be
viable...
—
Reply to this email directly, view it on GitHub
https://github.com/shipmonk-rnd/composer-dependency-analyser/issues/67#issuecomment-1951418235,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACQAJO5JKHZ5H6BO6BYSU3YUJHF7AVCNFSM6AAAAABDOA7L4CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGQYTQMRTGU
.
You are receiving this because you authored the thread.Message ID:
@.***
com>

Implemented, ready in 1.5.0 :tada:


[cmake] do FetchContent or find_package() for jrl-cmakemodule

@nim65s

merging because Windows isn't real


Theme submission: MyBlog

Theme submission
Please make sure that you have read the theme submission guidelines before submitting a theme. The guidelines provide all relevant information and requirements that have to be fulfilled before the submission. We strongly suggest that you test your theme with the Hugo Themes Build Script before submitting the theme for review. If a submission does not meet the criteria mentioned in the README it will be closed. You may re-submit once you fix the problems with your submission. However, please note that we have limited resources and can not provide help for general web development issues. For Hugo support questions please refer to the dedicated support forum.
Please tick the relevant boxes for your theme in the checklist below:
Link to my theme repository: https://github.com/wisnuwiry/personal-site
I made sure that...

[x] the repository contains a good README.md describing my theme
[x] an open source license has been added to LICENSE.md
[x] all metadata have been added to theme.toml
[x] screenshots have been added in the images/ folder with the required dimensions
[x] in case I'm using a customized demo via the exampleSite folder that

[x] https://example.com is set as base url in exampleSite/config.{toml, yaml, json} to avoid the abuse of unused domains
[x] I tested that my theme's demo works with the content directory of gohugoio/HugoBasicExample

[x] I tested my theme against the gohugoio/HugoBasicExample

[x] I've checked the developer tools' console in my browser for error messages

[x] in case my theme is using Hugo Pipes features like toCSS and PostCSS that I have committed the /resources directory with all generated assets, for my theme to work in the basic version of Hugo

N.B. By submitting a theme to the Hugo Themes Showcase you understand that you need to maintain your theme. If a theme demo breaks and remains broken then at some point it will be removed from the list without prior warning. If you no longer wish to maintain a theme please let us know.
New themes will usually be promoted on Hugo's official Twitter account. If you would like to be mentioned in the tweet please add your Twitter username to this submission.
Link to my Twitter account (optional): https://twitter.com/wisnuwiry
Feel free to ask questions. We're glad to help.

Hi @wisnuwiry, thank you for your submission. Before we can add your theme to the directory please fix the following issue:

[ ] errors in the config.toml of your sample content (un-set items like fb_admins should either be commented out or have an empty ("") value)

HI @davidsneighbour ,
Thank you for telling me, for the existence of BUG.
I've updated my repo, and I've checked and it worked.

HI @davidsneighbour ,
Thank you for telling me, for the existence of BUG.
I've updated my repo, and I've checked and it worked.


Messaging for "Hide for Monetized Users" is inaccurate when user is monetized

Assumption: A page/post is set to Split Content and has a Hide for Monetized Users block.
As a web monetized user viewing the Latest Posts page, I see a message that the post has content for Coil Members only, when really the content is hidden from me.

I also question why I'm seeing a padlock on this type of post. What's the use case for showing a page/post as locked when all I have to do is sign out of Coil to see the content?

@melissahenderson lets follow up with Fabian on this one, we may just need to update the ux a little.


Add editor setting for AcceptDialog OK/Cancel buttons positioning

The position (left/right) of the Cancel and OK buttons in AcceptDialog
are DisplayServer specific, as Windows uses OK/Cancel and macOS uses Cancel/OK.
Linux/X11 currently uses the macOS convention which is also the GTK+/GNOME one,
though it's not consistent with Qt/KDE applications which follow the Windows
convention.
Since that can't satisfy everyone, it's best if it's configurable also for the
editor (it's already configurable for the project).
Fixes #59379.

@bruvzg I used "OK First" instead of "OK Left" assuming that this would be handled with UI mirroring too for RTL, but it doesn't seem to be (at least from a quick look at scene/gui/dialogs.cpp). I don't know if it should be, we'd have to check e.g. Arabic on Windows and macOS.
Also, I find this whole swap_cancel_ok API in AcceptDialog a bit hacky (and badly named as it doesn't tell users swapping from what to what, i.e. that the "reference" unswapped positions are the GNOME/macOS ones). And on Linux one could make a case to have the behavior DE-dependent so that on predominantly Qt-based KDE it would follow the Windows convention... but that's a mess (and as a KDE user I wouldn't like the behavior to change now that I'm used to OK on the right).

I used "OK First" instead of "OK Left" assuming that this would be handled with UI mirroring too for RTL, but it doesn't seem to be (at least from a quick look at scene/gui/dialogs.cpp). I don't know if it should be, we'd have to check e.g. Arabic on Windows and macOS.

There's no need for extra code in the scene/gui/dialogs.cpp, RTL layout will mirror the underlying box container.

As discussed in PR review meeting, I'll update this to also change the project setting to use an enum like done here for the editor setting.
Might also research whether we should auto-detect the preferred style on X11.

I'm not finding time to rework this and handle the project setting, which would turn out to be a big rabbit hole as there's a lot of inconsistencies in our handling of OK/Cancel to handle to do this right.
So I think this could be merged as it improves the situation for the editor somewhat, which is the main Godot project where the position of such buttons matters and might need to be customized by the user.

Cherry-picked for 3.6.


CI: Add Cygwin CMake run

Copied from MehdiChinoune's MSYS CMake CI run.

In local tests running only nc_test4_tst_filter, the test hangs for half an hour before being mostly killed, although ncfilteravail continues taking up CPU in the background afterward.


Allow passing env vars to verifiable build container

Is there much else you still want to add to this PR? It looks pretty reasonable to add.
Also

don't forget to run cargo fmt
please add a note to the changelog as well

Should be ready now

Looks like a clippy lint still needs to be satisfied or excepted somehow. https://github.com/coral-xyz/anchor/actions/runs/3742902170/jobs/6354794762


Replacing the IDA frontend dependency a.k.a. Uncle Dave wants YOU for Binnavi!

Greetings, all Binnavi enthusiasts
Binnavi is now finally open source but it lacks an open disassembler frontend and a decompiler to be usable as a standalone reversing tool. Currently (the latest version of) IDA Pro is required to import a binary into Binnavi which is a huge limitation. It has always been.
Luckily, there are some people who want to solve this, some by throwing money at it: https://twitter.com/capstone_engine/status/634034005294215169 and others who want to throw conference tickets and Miami beaches: https://lists.immunityinc.com/pipermail/dailydave/2015-August/000987.html and São Paulo parties: https://lists.immunityinc.com/pipermail/dailydave/2015-August/000990.html at it.
They want YOU!  Let's use this momentum to solve the IDA issue.
I was planing to work on a disassembler frontend for Binnavi as I could reuse code from the Bindead project: https://bitbucket.org/mihaila/bindead/ but it will take some time to finish such a thing if done at least half-right. So with the current hype I figured that it is wiser to try to involve everybody (yeah, bikeshedding!) who wants to help with the design, coding or testing.
Implementing a disassembler involves many tedious tasks and in this case we also need to implement the control flow reconstruction and a database writer so having many people working on it will speed up the process remarkably. But don't hesitate as most of the above already exists in parts but it still has to be put together and be brought to a usable state. The biggest argument though is that most good disassemblers and decompilers out there implement some heuristics and black art somewhere. That's what makes them good ones! Collecting this trickery in a wiki and trying to include it in Binnavi would make this project worth more than all that 1000 single tools out there.

Now to my proposal. Let's use this as a meta-issue for coordination and spin different issues from it for the subtopics and separate tasks. Next we could use the wiki to collect all the final decisions from the various upcoming discussions. That way people can have a look at the current status/consensus  without having to wade through lots of different discussion threads on the issue tracker.
Some ideas for the first steps. Let's brainstorm the currently existing free (and open) projects for each of the required components and collect these in the wiki. Next we need to decide how to interface existing or new code components with the current Binnavi API and any modifications that might be necessary in the latter.
Note however that before this leads to endless bikeshedding the imperative is that everyone can implement things their way if they disagree with something. There may coexist N disassemblers and M decompilers (plugins ftw!). None should be killed prematurely. The main intention here is to avoid a duplication of effort for all the problems that will come along the way. Further it should serve as documentation and as a knowledge base, i.e. the wiki.
I will describe my thoughts on the disassembler and existing work soon in a separate issue. See you there.
Bye,
Bogdan

As promised I wrote down my initial thoughts on potential disassemblers for Binnavi and what needs to be done in this #28 issue. Now I want some comments :smiley:
Some less elaborate thoughts on decompilers will follow some other day.
Bye,
Bogdan

Awesome !
Bogdan Mihaila<EMAIL_ADDRESS>schrieb am Do., 3. Sep. 2015 um
13:58 Uhr:

As promised I wrote down my initial thoughts on potential disassemblers
for Binnavi and what needs to be done in this #28
https://github.com/google/binnavi/issues/28 issue. Now I want some
comments [image: :smiley:]
Some less elaborate thoughts on decompilers will follow some other day.
Bye,
Bogdan
—
Reply to this email directly or view it on GitHub
https://github.com/google/binnavi/issues/25#issuecomment-137416830.

The BinNavi project is no longer under active development.


github-release for new organisation.

I am able to work with this github-release for my user account.
But, I need to automate upload release and binary to separate development organization's repo. And, We can't create GITHUB_TOKEN key for organization in github.
So, is there a way to get it done?

I'm actually not sure, I've never worked with Github organisations in this way before. I do think some sort of token will be required, as github-release needs to have permissions. Perhaps you can create a reduced-privilege token?

afaik releases and assets are always still done by a user, as member of organization, and not by the organization as entity

Seems like @mfonville has more experience with the GH API. I'd suggest creating a robot/fake user and add it to your organization, in order to perform changes.


Data races tests and fixes

Here are some new tests to detect data races based on your existent tests.
Also included several fixes for those.
More tests in the same style should be written to cover the entire package.

You should make pull-request with working on $GOPATH/src/github.com/mattn/anko not $GOPATH/src/github.com/leonelquinteros/anko :)

Okay, I'll rebase your pull-request and re-make this as your's.

Merged. https://github.com/mattn/anko/commit/a8c68fa2983e7dd5d3472992b1fbe2f7c44261f0
Thanks.

Sorry, i edited from my fork as i was already using it on my project.
I'll check now and re-fork to continue using mattn import path

No prob! :)


Nuclear Operatives on-station nuke should not be movable/the on ship nuke should be significantly lighter

Description
This has become an increasing problem in nukie rounds that I've witnessed. I'm going to be clear - it's not fun for anyone, nukies or crew. It removes the drama and turns it into a deathmatch as the nukies have basically nothing better to do other than mow down crew members and search the station aimlessly. They have no way of finding the nuke as there is 0 way of locating the on station nuke when it is moved.
The on ship nuke is liable to be stolen by any number of goblins. It is extremely heavy, enough so to deter any nukies from bringing it (because they have to babysit it constantly due to how slow it is and moving it through space takes literally multiple minutes because maneuvering it is a pain in 0g and it's not very movable on station either) but it's not heavy enough to stop station goblins from taking it.
The cool moments get absolutely ruined by the round going stale because ops have basically won (most of the crew are dead) but the nuke has been moved by people to be somewhere absolutely ridiculous. The on station nuke shouldn't even be out of the vault.
So I think that any of three things needs to happen:

The on station nuke is made immovable or larger/heavy, something to deter it at least from being taken out of the vault.

Alternatively, make it so the nuclear operatives have some way of locating it (second pinpointer function?)

The nukie on ship nuke needs to be made significantly lighter, maybe slightly more than a crate, to make it actually feasible to bring with them on an attack on the station.

Sorry if this isn't the right format or how you use issues - if it is, I'll close it and not do this again.

Their speed is 1.3m/s when dragging the nuke which doesn't seem like they can't just put their nuke on the station?

Their speed is 1.3m/s when dragging the nuke which doesn't seem like they can't just put their nuke on the station?

Having played nuke ops, getting it off the ship takes forever and moving it through space via jetpack is buggy, if it works at all. You physically can't pull the nuke off the ship half the time into space, and even then it's extremely unwieldy to transport via jetpack.
And babysitting a big heavy object for the whole assault isn't exactly a viable strategy, unless you just camp in the dark in some obscure corner of the station, which isn't fun for anyone.

You don't need to pull the nuke into space, people choose to do it.

And babysitting a big heavy object for the whole assault isn't exactly a viable strategy

This is separate and was an explicit change that was made.

You don't need to pull the nuke into space, people choose to do it.

And babysitting a big heavy object for the whole assault isn't exactly a viable strategy

This is separate and was an explicit change that was made.

 Leaving it on the ship is liable to be stolen as the ship itself can be very easily stolen, unless you post guards - and you need the manpower. That is the problem.
It's heavy enough to discourage an attack but not heavy enough to prevent it being extremely useful to the station crew, so much so that it becomes a game of who can get to the nuke first, of which the station crew always has the advantage. This limits the area that nuke ops can realistically strike because they always have to get to the nuke in the first three or so minutes or they lose  - of which I have seen multiple times, even when ops have been relatively robust and shouldn't arguably have lost

Like of course they're going to lose sometimes but they often lose because the objective (in this case the nuke) is in some unlit room somewhere in maints or on solars outside where it should literally never be.

Like of course they're going to lose a lot, that's fine, but they often lose because the objective (in this case the nuke) is in some unlit room somewhere in maints or on solars outside where it should literally never be.

Having the nuke in some part of maint is fine, solars is definitely not.

Like of course they're going to lose a lot, that's fine, but they often lose because the objective (in this case the nuke) is in some unlit room somewhere in maints or on solars outside where it should literally never be.

Having the nuke in some part of maint is fine, solars is definitely not.

What makes dragging the nuke to a random part of maint fine and solars an immediate no? I don't see how either are fair or fun.

Like of course they're going to lose a lot, that's fine, but they often lose because the objective (in this case the nuke) is in some unlit room somewhere in maints or on solars outside where it should literally never be.

Having the nuke in some part of maint is fine, solars is definitely not.

What makes dragging the nuke to a random part of maint fine and solars an immediate no? I don't see how either are fair or fun.
Half the time nukies just turns into deathmatch and isn't an objective-based gamemode, which I believe is the intention.

Putting the nuke in maint as Nukies has always been a viable strategy. It's on station, unlike solars which is just in space.
Nukies has always been a deathmatch mode.

Like of course they're going to lose a lot, that's fine, but they often lose because the objective (in this case the nuke) is in some unlit room somewhere in maints or on solars outside where it should literally never be.

Having the nuke in some part of maint is fine, solars is definitely not.

What makes dragging the nuke to a random part of maint fine and solars an immediate no? I don't see how either are fair or fun.
Half the time nukies just turns into deathmatch and isn't an objective-based gamemode, which I believe is the intention.

Putting the nuke in maint as Nukies has always been a viable strategy. It's on station, unlike solars which is just in space.
Nukies has always been a deathmatch mode, even back in SS13.

if it's just a deathmatch mode with a side of objective as opposed to an objective mode with a side of deathmatch that's fine then, I just thought the focus was the nuke and not the killing of everyone

Like of course they're going to lose a lot, that's fine, but they often lose because the objective (in this case the nuke) is in some unlit room somewhere in maints or on solars outside where it should literally never be.

Having the nuke in some part of maint is fine, solars is definitely not.

What makes dragging the nuke to a random part of maint fine and solars an immediate no? I don't see how either are fair or fun.
Half the time nukies just turns into deathmatch and isn't an objective-based gamemode, which I believe is the intention.

Putting the nuke in maint as Nukies has always been a viable strategy. It's on station, unlike solars which is just in space.
Nukies has always been a deathmatch mode, even back in SS13.

if it's just a deathmatch mode with a side of objective as opposed to an objective mode with a side of deathmatch that's fine then, I just thought the focus was the nuke and not the killing of everyone

Yeah that's the.. not issue but what happens with nukies. The main objective, especially with wardec, is to get to the station, grab the disk, nuke and extract. But some nukies will take the opportunity to try to aimlessly slaughter instead of mowing down people to get to the disk.
But deathmatch is definitely unavoidable.

Like of course they're going to lose a lot, that's fine, but they often lose because the objective (in this case the nuke) is in some unlit room somewhere in maints or on solars outside where it should literally never be.

Having the nuke in some part of maint is fine, solars is definitely not.

What makes dragging the nuke to a random part of maint fine and solars an immediate no? I don't see how either are fair or fun.
Half the time nukies just turns into deathmatch and isn't an objective-based gamemode, which I believe is the intention.

Putting the nuke in maint as Nukies has always been a viable strategy. It's on station, unlike solars which is just in space.
Nukies has always been a deathmatch mode, even back in SS13.

if it's just a deathmatch mode with a side of objective as opposed to an objective mode with a side of deathmatch that's fine then, I just thought the focus was the nuke and not the killing of everyone

Yeah that's the.. not issue but what happens with nukies. The main objective, especially with wardec, is to get to the station, grab the disk, nuke and extract. But some nukies will take the opportunity to try to aimlessly slaughter instead of mowing down people to get to the disk.
But deathmatch is definitely unavoidable.

Yeah, but when you have the disk, when both nukes are absolutely nowhere to be seen - either because they've been moved to god knows where with 0 way of locating them, or because some goober nicked your shuttle because it is the world's easiest target and shows up on radar, you don't really have any other choice other than to wander around aimlessly shooting everyone you see, as there's nothing to do. We don't even have wardec and this happens most games.
The disk isn't a problem. We have pinpointers. You can't actually put them anywhere after because the nukes end up missing 9/10 rounds.

Like of course they're going to lose a lot, that's fine, but they often lose because the objective (in this case the nuke) is in some unlit room somewhere in maints or on solars outside where it should literally never be.

Having the nuke in some part of maint is fine, solars is definitely not.

What makes dragging the nuke to a random part of maint fine and solars an immediate no? I don't see how either are fair or fun.
Half the time nukies just turns into deathmatch and isn't an objective-based gamemode, which I believe is the intention.

Putting the nuke in maint as Nukies has always been a viable strategy. It's on station, unlike solars which is just in space.
Nukies has always been a deathmatch mode, even back in SS13.

if it's just a deathmatch mode with a side of objective as opposed to an objective mode with a side of deathmatch that's fine then, I just thought the focus was the nuke and not the killing of everyone

Yeah that's the.. not issue but what happens with nukies. The main objective, especially with wardec, is to get to the station, grab the disk, nuke and extract. But some nukies will take the opportunity to try to aimlessly slaughter instead of mowing down people to get to the disk.
But deathmatch is definitely unavoidable.

Yeah, but when you have the disk, when both nukes are absolutely nowhere to be seen - either because they've been moved to god knows where with 0 way of locating them, or because some goober nicked your shuttle because it is the world's easiest target and shows up on radar, you don't really have any other choice other than to wander around aimlessly shooting everyone you see, as there's nothing to do. We don't even have wardec and this happens most games.
The disk isn't a problem. We have pinpointers. You can't actually put them anywhere after because the nukes end up missing 9/10 rounds.

SS13 has locked controls for external shuttles (nukies, pirates) so that should be added in if it's not. But I think that might be a mind/datum related thing because you can even have the ID on SS13 and still not move the ships (you'll also get destroyed by the turrets).


Zero matrices as synthetic outputs

In your AgML-Synthetic.ipynb, I ran the following lines:
loader = agml.data.AgMLDataLoader.helios('tomato_sample')
_ = agml.viz.visualize_image_and_mask(loader[0])

This shows a pair of images as below, where the right seems to be correct with a segmentation result while the left is wrong with a black image.

I can find that loader[0][0] is simply a zero matrix because np.all(loader[0][0]==0) outputs True. I have tried this multiple times, but I always have the issue.

This might be an issue with Helios, since the example notebook generates images on my system. What platform are you running on?

@pranavraja99 @dariojavo, would you have any insight into this issue?

@amogh7joshi, I am running on Ubuntu18

Hi @ctyeong, can you please help us with the following information:

Was Helios correctly installed in your computer?
If so, please share the output of the previous step:

# Generate the data.
generator.generate(name = 'tomato_sample', num_images = 3)
We have tested under Ubuntu 18 and 20, so it should be working. Please help us with that information in order to find out what is happening.

Here is the output from
generator.generate(name = 'tomato_sample2', num_images = 3)
Loading XML file: /home/username/anaconda3/envs/agml/lib/python3.7/site-packages/agml/_helios/Helios/projects/SyntheticImageAnnotation/xml/style_tomato_sample2.xml...done.
Reading XML file: /home/username/anaconda3/envs/agml/lib/python3.7/site-packages/agml/_helios/Helios/projects/SyntheticImageAnnotation/xml/style_tomato_sample2.xml...Building canopy of tomato plants...done.
Ground geometry...done.
Ground consists of 100 total primitives.
done.
/home/username/.agml/synthetic/tomato_sample2/image0Rendering RGB image containing 84.82K primitives...Initializing graphics...done.
writing JPEG image: /home/username/.agml/synthetic/tomato_sample2/image0/view00000/RGB_rendering.jpeg
writing JPEG image: /home/username/.agml/synthetic/tomato_sample2/image0/view00001/RGB_rendering.jpeg
writing JPEG image: /home/username/.agml/synthetic/tomato_sample2/image0/view00002/RGB_rendering.jpeg
done.
Generating labeled image containing 2 label groups...
Initializing graphics...done.
Performing semantic segmentation for view 0... and element:
clusters
leaves
Semantic segmentation ... done.
Performing semantic segmentation for view 1... and element:
clusters
leaves
Semantic segmentation ... done.
Performing semantic segmentation for view 2... and element:
clusters
leaves
Semantic segmentation ... done.
Loading XML file: /home/username/anaconda3/envs/agml/lib/python3.7/site-packages/agml/_helios/Helios/projects/SyntheticImageAnnotation/xml/style_tomato_sample2.xml...done.
Reading XML file: /home/username/anaconda3/envs/agml/lib/python3.7/site-packages/agml/_helios/Helios/projects/SyntheticImageAnnotation/xml/style_tomato_sample2.xml...Building canopy of tomato plants...done.
Ground geometry...done.
Ground consists of 100 total primitives.
done.
/home/username/.agml/synthetic/tomato_sample2/image1Rendering RGB image containing 84.484K primitives...Initializing graphics...done.
writing JPEG image: /home/username/.agml/synthetic/tomato_sample2/image1/view00000/RGB_rendering.jpeg
writing JPEG image: /home/username/.agml/synthetic/tomato_sample2/image1/view00001/RGB_rendering.jpeg
writing JPEG image: /home/username/.agml/synthetic/tomato_sample2/image1/view00002/RGB_rendering.jpeg
done.
Generating labeled image containing 2 label groups...
Initializing graphics...done.
Performing semantic segmentation for view 0... and element:
clusters
leaves
Semantic segmentation ... done.
Performing semantic segmentation for view 1... and element:
clusters
leaves
Semantic segmentation ... done.
Performing semantic segmentation for view 2... and element:
clusters
leaves
Semantic segmentation ... done.
Loading XML file: /home/username/anaconda3/envs/agml/lib/python3.7/site-packages/agml/_helios/Helios/projects/SyntheticImageAnnotation/xml/style_tomato_sample2.xml...done.
Reading XML file: /home/username/anaconda3/envs/agml/lib/python3.7/site-packages/agml/_helios/Helios/projects/SyntheticImageAnnotation/xml/style_tomato_sample2.xml...Building canopy of tomato plants...done.
Ground geometry...done.
Ground consists of 100 total primitives.
done.
/home/username/.agml/synthetic/tomato_sample2/image2Rendering RGB image containing 82.02K primitives...Initializing graphics...done.
writing JPEG image: /home/username/.agml/synthetic/tomato_sample2/image2/view00000/RGB_rendering.jpeg
writing JPEG image: /home/username/.agml/synthetic/tomato_sample2/image2/view00001/RGB_rendering.jpeg
writing JPEG image: /home/username/.agml/synthetic/tomato_sample2/image2/view00002/RGB_rendering.jpeg
done.
Generating labeled image containing 2 label groups...
Initializing graphics...done.
Performing semantic segmentation for view 0... and element:
clusters
leaves
Semantic segmentation ... done.
Performing semantic segmentation for view 1... and element:
clusters
leaves
Semantic segmentation ... done.
Performing semantic segmentation for view 2... and element:
clusters
leaves
Semantic segmentation ... done.
Moving Images: 100%|███████████████████| 9/9 [00:00<00:00, 13282.45it/s]

Seems that images are being generated correctly. Just to verify, for getting the loader you are using tomato_sample2, right? Since you are generating the dataset with that name.
loader = agml.data.AgMLDataLoader.helios('tomato_sample2')

@dariojavo, exactly. Of course, the result won't change with tomato_sample.

Yeah, of course, it should only work with the dataset that you generated. In this case tomato_sample2.
Ok, lets check the images. Can you please confirm if the images on /home/username/.agml/synthetic/tomato_sample2/... (e.g., /image2/view00000/RGB_rendering.jpeg) are not empty?

image0-view00000.jpeg, image0-view00001.jpeg, image0-view00002.jpeg,  image1-view00000.jpeg, image1-view00001.jpeg, image1-view00002.jpeg,  image2-view00000.jpeg, image2-view00001.jpeg, image2-view00002.jpeg.
These all simply look black

Can you try running generator.generate with convert_data = False, and then check whether the output images have been correctly rendered?

Could the issue be related to the file path assuming /home/username?
On Thu, Oct 6, 2022 at 8:58 AM Taeyeong Choi @.***>
wrote:

I got an error below:
FileNotFoundError: The information file at '/home/username/.agml/synthetic/tomato_sample/.metadata/agml_info.json' for the Helios dataset tomato_sample could not be found.
Under ~/.agml.synthetic/tomato_sample/, there are
image0/view00000/RGB_rendering.jpeg,image0/view00001/RGB_rendering.jpeg
... `image2/view00002/RGB_rendering.jpeg. But each one is still a black
image.
—
Reply to this email directly, view it on GitHub
https://github.com/Project-AgML/AgML/issues/30#issuecomment-1270322104,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AG5FGPGB4V74YSOHCGQNNETWB3ZLRANCNFSM6AAAAAAQ5HBFPE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@masonearles I simply posted with username here, which is not my actual username on my end.

@amogh7joshi @dariojavo Has this issue been resolved?

@masonearles @amogh7joshi I have checked and the error is on Helios when compiling in Ubuntu 18. I just reported this issue with Helios team.
Will keep this open until solved it.

@dariojavo Do we have resolution on this issue?

Yes, this has been solved! Tested on Ubuntu 18 and 20.


[INFINITY-1449] CLI code refactoring

Merge after https://github.com/mesosphere/dcos-commons/pull/946 and https://github.com/mesosphere/dcos-commons/pull/951.
This PR refactors the flat directory structure of the CLI into three packages:

commands: containing handlers and methods for each subcommand.
config: containing a handful of constants and global variables that encapsulate configuration
utils: containing helper methods that facilitate HTTP communication, response parsing and integration with the DC/OS CLI.

I also updated the helloworld example to use this new layout. Will probably want to update this again the vendoring work is merged as well.

@ssk2 Please resolve conflicts.

@benclarkwood, @nickbp, rebased, conflicts resolved and most feedback addressed.

retest this please

Not sure what that merge issue is.
@jsrodman any thoughts?

This merge is odd.  Why is anything at the time of the go build trying to do a merge? is build.sh being invoked  recursively?

retest this please

retest this please


Remove pixi-spine dependency. Tested on real project :)

Dont merge it until we understand what to write in gulpfile to expose pixi.js.

I tested pixi-spine build that used "require" => it included pixi.js in it. Now I need to expose pixi.js and use "external" in pixi-spine.
I didnt commit it in pixi-spine yet.

Your bundle should mark pixi as external bundle.external('pixi.js') so it knows :)

Where exactly do I have to insert to this line?

What about resource-loader and async? Are they exposed? Do I have to include them? That way they'll appear in both pixi.js and plugin

You put it in the gulp/util/bundle.js file where the bundler is created.
Resource loader is exposed via PIXI.loaders.Loader, but async is not exposed. That shouldn't be necessary in your plugin though, and if it is we can expose it via PIXI.utils. Now that I think of it we should probably expose ee3 via PIXI.utils as well for plugins to use without duplicating...

Ok, just when I was ready to push changes into pixi-spine, I kind of pressed wrong button and deleted all the changes :( Now I have to redo it.

Ok, pixi-spine works with this commit. Now you can merge it :+1:

Yeah, and atlasSpineLoader was moved to pixi-spine, and pixi-spine has its own PIXI.spine.loaders.Loader that uses it.

Ok, I updated pixi-spine in its repo, now it uses these two exposed classes:
PIXI.loaders.Resource
PIXI.utils.async
Binary file of pixi-spine does not contain that modules and it works with my demo.


ES Metrics

Coverage remained the same at 100.0% when pulling bf9ef4a6aecdac1233ccbb0da00ac07d23244e8e on es-metrics into<PHONE_NUMBER>57ba228eb08cce9994963f75b559f3 on master.


Add link to #documentation stream on Zulip to ways-to-contribute.md document

Description
This file ways-to-contribute.md has the text referring to #documentation stream on Zulip. We could have a link to it, like other streams in the same document have.
Why
This helps newcomers reading the document have direct access to the stream
Acceptance Criteria

[ ] Add the link to #documentation stream from Zulip

@isabelcosta i would like to work on this issue.

@nlok5923 sure :) Will assign it to you!

@isabelcosta please can you help me to find zulip stream link


fix github action prerelease

Codecov Report

Merging #3 (de2a85e) into master (eab03de) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #3   +/-   ##
=======================================
  Coverage   94.73%   94.73%
=======================================
  Files           4        4
  Lines          95       95
=======================================
  Hits           90       90
  Misses          5        5

Merged in 101913a779bc02bdec5f589c3ea15051d4387111.


BotFrameworkAdapter.CreateConversation call for SMS fails to provide Conversation Id

Versions
What package version of the SDK are you using: 4.6.0-preview1
What nodejs version are you using: 11.12
What browser version are you using: N/A
What os are you using: Windows 10 Pro
Describe the bug
Our bot is hosted outside of Azure and interacts with users via SMS. Our bot is registered on Azure and we are using it as a go-between for our SMS provider.
When we attempt to create a conversation with a new user by contacting the SMS service url, the JSON response is in Pascal case. The mappers used in @azure/ms-rest-js assume all content received is in Camel case. The Bot Framework Adapter fails to transfer the correct Conversation Id on line 383: response.id is undefined, but response.Id has a value.
To Reproduce
Steps to reproduce the behavior:

Set up your bot with an SMS handler
Clone this repository: https://github.com/olliecwl/v4bot
Add your MS AppId/Password in .env
Add your mobile and your bot's mobile to the bottom of index.js
Add a breakpoint to line 382
Run your bot. At the breakpoint, you should see that response.Id does have a value.

Expected behavior
The activity passed along to the logic in the BotFrameworkAdapter.createConversation call should contain a conversation object with a defined id value.
Current workaround
Reset the activity's conversation id once the turnContext has been received in your logic function.
Additional context
I understand that the fix for this is probably best generated further upstream. I'm just unsure where. The mappers in ms-rest-js? The code running on sms.botframework.com? Open to suggestions.
[bug]

@dandriscoll can you assign this appropriately. We think this is a limitation of the support in the twillio channel?

I was able to successfully repro this issue. The SDK doesn't appear to have changed in significant ways so I would agree that this is likely a channel issue.

Picking this up to look into on the SDK and Service sides and figure out where to make the fix.

Looking at this from the channel side and hunting for inconsistencies between the formatting in responses vs requests sent from the channel to the bot. The code hasn't changed in over 6 months and this is the first report of the bug so I'm digging a bit deeper to make sure something hasn't changed upstream before deciding where the fix should live.

I've filed a bug against the channel as I feel this behavior is unintentional, but also recognize it has likely always been the implementation. Any changes to the involved code will have a large blast radius that impacts multiple channels, so it's not something we'll do quickly or without careful consideration, but it is now on the radar.
I'm going to close this ticket since it's in the Services repo and we now have a bug in the internal system to track against the specific channel, but if anyone wants to reopen it and transfer to an appropriate repo to pursue one of the alternative fixes Jason aptly illustrated I won't object, the channel bug will move forward regardless.


console02

local repo pushed to remote triggers PR

Configured PR to not automatically merge but do it after review.
Rejecting PR. We distribute code (lessons) across different branches, not main.


Reduce mnist json 'summary' by about 10x

The PR curve for MNIST was including a point on the plot for every row in the eval data. This was then getting posted to the server as json in the artifact json "summary" for the plot. This could cause you to hit a "Request payload too large" from the ingress (Nginx) when running locally against a remote server. This didn't happen when running locally against a local server because there you don't go through the ingress. It also didn't happen when running in the cloud because there the network traffic stays in-cluster and thus also bypasses the ingress. This PR subsamples the points before creating the plot, with the result being that the size of the payload is reduced ~10x.
Here is what the plot looks like now:

Tested and confirmed that we no longer hit "Request payload too large" in this scenario.

Does this fix #997?

Does this fix / work around https://github.com/sematic-ai/sematic/issues/997?

Most likely; it was running this pipeline. I'll close it out.


✨ Add Alpine support

This PR add support of alpine for fish.
I had to do some script refactoring for this. I leave you make the review.
Unfortunately, I could not start on the latest version of fish 3.5.1 because it is buggy in the alpine repo.

So I could not test the version of fish installed.

@guiyomh can you allow pushing for your fork?

HAW-19 Support Alpine in fish feature


Allow optional emiting init(Type)

To do this we should replace the  bool exported with a bitset that allows features as we go, such as defTypeInit.

closed in 07a3acc8bafe19469923ce099bb23085f1dc56b3


[Feature] how to discard the videos for passed scenarios

I am enabling the video recording feature. I don't want to save the video if scenario passed. I need failed scenario's videos need to be saved(I want to save the space while running from cloud).
how can I achieve it?
here is  sample code i used to enable it.
browserContext.set(getBrowser().newContext(new Browser.NewContextOptions().setViewportSize(width, height).setRecordVideoDir(Paths.get("./target/videos/"))                 .setRecordVideoSize(1280, 720)));

You can manually delete the video file after the test has finished:
    try (Playwright playwright = Playwright.create()) {
      Browser browser = playwright.chromium().launch();
      BrowserContext context = browser.newContext(
        new Browser.NewContextOptions().setViewportSize(1280, 720).setRecordVideoDir(Paths.get("./videos/")).setRecordVideoSize(1280, 720));
      boolean passed = true;
      Page page = context.newPage();
      page.navigate("http://playwright.dev");
      page.close();
      if (passed) {
        Files.delete(page.video().path());
      }
      context.close();
    }

Or you can save the videos for failing tests with a nice name (page.video().saveAs(Paths.get("nice_name.webm"))) in a different location and then delete the entire videos dir after the context has been closed.
Will that work for you?

@yury-s At glance, for first solution, I don't think it will work but i will try(if its not deleting other video files i am good as i am running scenarios in parallel).
for second solution, I might need to do some work while generating the report. for failed scenarios  need to attach video as well.
In near future can I expect this feature as some configuration like just setting true or false?
It might be a good feature because in real time people will run 100's of test cases daily and don't want to store all the videos as it space constraints

In near future can I expect this feature as some configuration like just setting true or false?

This is a responsibility of the test runner, Playwright as a library does not know if your test passed or failed and instead provides you full control over the video file after the page is closed. There are no plans to change this functionality, Node.js version of playwright comes with a test runner that is implemented on top of the same APIs, so if the proposed solutions don't work in your case we need to learn why so.

@yury-s
The above solution worked and thanks a lot.


source installation fails to install to prefix_dir with solo

I am using chef-solo to install python to a specific location.
When wrapping the python cookbook, modifying the default prefix_dir is not taking effect unless it's done in solo.json.
The problem arises due to the loading order of the default attributes.
https://github.com/poise/python/blob/master/attributes/default.rb#L39:
default['python']['configure_options'] = %W{--prefix=#{python['prefix_dir']}}

Loads first and creates the configure_options from the prefix_dir that is used for the source configuration
https://github.com/poise/python/blob/master/recipes/source.rb#L23:
 configure_options = node['python']['configure_options'].join(" ")

and https://github.com/poise/python/blob/master/recipes/source.rb#L49:
  (cd Python-#{version} && ./configure #{configure_options})

Is this intentional?
It might be more appropriate to calculate the configure_options directly in source.rb.

This is not a chef-solo problem, it happens in client mode too.
context
# knife cookbook list | grep python
python                1.4.6

# chef-client version
Starting Chef Client, version 12.0.3

# lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 7.8 (wheezy)
Release:	7.8
Codename:	wheezy

# cat attributes/default.rb
default['python']['install_method'] = 'source'
default['python']['version'] = '3.4.2'
default['python']['checksum'] = '44a3c1ef1c7ca3e4fd25242af80ed72da941203cb4ed1a8c1b724d9078965dd8'
default['python']['prefix_dir'] = '/usr'

Running chef-client
[...]
* bash[build-and-install-python] action run
[...]
Chef Client finished, 4/65 resources updated in 96.680297683 seconds

Expected result: python3.4.2 should be installed in /usr/bin.
Actual result (problem): python3.4.2 is being installed in /bin !!!
# ls -1 /usr/bin/python*
/usr/bin/python
/usr/bin/python2
/usr/bin/python2.7

# ls -1 /bin/python*
/bin/python3
/bin/python3.4
/bin/python3.4-config
/bin/python3.4m
/bin/python3.4m-config
/bin/python3-config

The --prefix parameter is passing an empty value. It should be /usr
code "  tar -zxvf Python-3.4.2.tgz\n  (cd Python-3.4.2 && ./configure --prefix=)\n  (cd Python-3.4.2 && make && make install)\n"

debugging the problem with chef-shell
# chef-shell --client
chef > echo node['python']['prefix_dir']
 => "/usr"
chef > echo  node['python']['configure_options'].join(" ")
 => "--prefix="

FIX: adding the following line to attributes/default.rb to overwrite the bogus default
default['python']['configure_options'] = %W(--prefix=#{node['python']['prefix_dir']})

Now chef-shell shows how the array is being created properly
chef > echo  node['python']['configure_options'].join(" ")
 => "--prefix=/usr"

Running chef-client after adding that line fix the issue.

After a clarification from @coderanger I had to test one more time.
There is something going on with the line:
default['python']['configure_options'] = %W{--prefix=#{node['python']['prefix_dir']}}

That line fails to pass the --prefix parameter correctly. I end up with /bin/python3.
If I include that exact line in my cookbook's attributes/default.rb then the --prefix is correct and the python binary is installed in /usr/bin/python3
I try this in a fresh VM, I can reproduce this behavior every time.

Closing this out as this cookbook is now deprecated in favor of https://github.com/poise/poise-python. I'll revisit installation from source in the future.


Reuse context in reconciler

Fixes #67.
Two questions:

I haven't touched requestsForApplicationChange nor requestsForSecretChange as they are called in handler.EnqueueRequestsFromMapFunc(r.requestsForApplicationChange) and handler.EnqueueRequestsFromMapFunc(r.requestsForSecretChange) respectively. Should we?
I'm reusing the global ctx in tests - is there any better approach?

Fixes #67.
Two questions:

I haven't touched requestsForApplicationChange nor requestsForSecretChange as they are called in handler.EnqueueRequestsFromMapFunc(r.requestsForApplicationChange) and handler.EnqueueRequestsFromMapFunc(r.requestsForSecretChange) respectively. Should we?
I'm reusing the global ctx in tests - is there any better approach?

OK So THAT is the answer to my question, the context is initialised there :-)
I think it's ok we can leave that like that for now.
@maruina could prob confirm this.

I think we should change requestsForApplicationChange and requestsForSecretChange as they define they own context (see for example https://github.com/Skyscanner/applicationset-progressive-sync/pull/87/files#diff-a853c97824440aa3801077e1f5661f9087e27091372140f15f89ed5c8d0c5ba6R247)
Regarding the test, I'm not sure about that so I think you can keep the current ctx.

I think we should change requestsForApplicationChange and requestsForSecretChange as they define they own context

But if they don't generate the context, what will?
It seems to be that this is the context that gets propagated to the Reconciler?
Presumably the context needs to be instantiated somewhere?

I think we should change requestsForApplicationChange and requestsForSecretChange as they define they own context

But if they don't generate the context, what will?
It seems to be that this is the context that gets propagated to the Reconciler?
Presumably the context needs to be instantiated somewhere?

You are correct. I was already thinking in a kubebuilder 3.0 scenario.


Fix small typographical error

Description
Extremely small typographical error fix to improve readability of a link.
Related Issue
n/a
Motivation and Context
Readability
Requires Documentation Change
n/a
How Has This Been Tested?
n/a
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] Non-functional change (xml comments/documentation/etc)

Checklist:

[x] My code follows the code style of this project.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes. (Documentation changes, no tests necessary)
[x] All new and existing tests passed.
[x] My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description> (External contribution, fork used, not branch)

Welcome to LEAN @KamuelaFranco !


Mentions of Golang code/data types in Architecture docs could link to Github sources

It's implicit that these are data types/etc. that live in the code, but adding links to source code would make it explicit, and would save the reader who wants to skim some code a context switch.
For example, if we are going to mention a planNode explicitly, we could link to a search of our codebase for planNodes. The same would go for the other mentions of "code things".

I think that in general linking directly to specific pieces of code is more detail than we want in our docs. Github's search is not very good (maybe sourcegraph or something would work better), and linking to a specific file/line is a pain to keep up to date. On the other hand, if we do want to do this I'll point out that this is something sphinx excels at.

This doesn't sound like something we should do. We can re-open this if we hear desire for users to link from our architecture docs to our code.


Update 'Developer workspace' badge image

Using https://www.eclipse.org/che/factory-contribute.svg
See eclipse/che#17758

hey I don't have the push permission somehow ... could someone merge?


Get version dynamically

When we are creating tracer instance, we set version variable like as https://github.com/Trendyol/otel-kafka-konsumer/blob/main/config.go#L14
We need to do here dynamic, we can use go build binary flags etc.

it affets otel.library.version


[Bug]-[1016]:When all the header options are turned off scrollbars in a table dissapear

Is there an existing issue for this?

[X] I have searched the existing issues

Description
When i turn off all the options in header in a table, the scrollbars within the table dissapear
Steps To Reproduce

Add a table
Make it scrollable by resizing horizontally and vertically
Hide the search, pagination, filter and download from the property pane
Observe that the scrollbars dissapear

Public Sample App
No response
Version
Production

@souma-ghosh will the fixed in the recent change we did for scrollbars in table?

@souma-ghosh will the fixed in the recent change we did for scrollbars in table?

No, we need to work on this separately @dilippitchika

@Ravina-Deogadkar  this can be picked up. Please let me know if you are interested
Please don't forget to read the Contribution Guidelines. Would appreciate if you can open a PR within the next 2 days. let us know here

Hi, I would love to work on this issue. Could you assign it to me?

Greetings @thedreader  thanks for showing interest 🎉 , Please go ahead and create a PR. I will assign this to you and @Ravina-Deogadkar. If any of you can contribute to this, it would be great.
Please don't forget to read the Contribution Guidelines. Would appreciate if you can open a PR within the next 2 days. let us know here

Thanks for assigning

Stats

Stat
Values

Reach
1016

Effort (months)
0.5

@keyurparalkar can you check this issue once, since you changed the scrollbar recently

This behaviour should also be present in the column freeze feature. https://github.com/appsmithorg/appsmith/issues/15448

Fixed in column freeze pr


Add timestamps to events

Afaik there is no way to show time of the event while mobile. You can get time of the event by hovering your mouse on event in events viewer and it's only available on PC, no way to get it mobile. I think it's an important feature to add.

Thanks for the feature request @ansarowsky , I think you're right on the feature gap for mobile devices
Did you have something in mind on how you'd like to see this?

In my opinion, a good way to solve this problem would be showing time below the event in event viewer. I also believe that list event viewer will be great to have too, so you can choose between tiles and list.

Another option could be showing events spotify-like, but I'm sure you can do better than me.

I had also been watching the development of https://github.com/blakeblackshear/frigate/pull/2633 and wondering if there's a card equivalent of that possible in future. I think there's probably three feature requests buried in here:
[Easier] Get the time rendered on the event somehow so you can see it on mobile devices.
[Medium] An option to configure the gallery as a list view instead.
[Much harder] A full recording navigation system with timeline.

Easy option implemented. Please follow the dedicated bugs shown above for updates on the other ideas proposed.


cudafeatures2d

All OpenCV functions in CUDA accept cv::cuda::Stream, but I'm not sure if we can make it by utilizing cutorch stream API. Creating separate wrappers for cv::cuda::Stream would be pointless. Will make it synchronous for now

ugh, its annoying that they created another abstraction called cv::cuda::Stream. You can get the current cudaStream_t from the THC API via THCState_getCurrentStream: https://github.com/torch/cutorch/blob/master/lib/THC/THCGeneral.h.in#L110

@soumith
Oops...I incidentally posted this comment! Right after I wrote it, "before submitting" I managed to solve this. Yes, I found it easy to get cutorch's current stream and tell OpenCV to use it. Thanks.

Many functions here won't allow 32-bit float images. That's why we won't support Canny, CLAHE and some other useful stuff.


Anti spoofing How to create simmilar images

The sample is working fine with the sample images, but can you please tell me how to generate new images with the same features as the sample ??

@mla3beh hello! Use my experiment: https://github.com/FaceONNX/FaceONNX/tree/main/netstandard/Experiments/RealSenseFaceID

thank you


How can I tokenize sentence from paragraph using jiebo?

I don't understand Chinese, but I am working on Chinese tokenization. I want to perform sentence segmentation. How can I do that with jieba?

Have you tried the examples in the manual ?

Yes, I checked the examples. I think there is no example of segmenting a paragraph into sentences only? Like the one in nltk, span_tokenize() for sentences.

Yes, I checked the examples. I think there is no example of segmenting a paragraph into sentences only? Like the one in nltk, span_tokenize() for sentences.

I don't think you should jieba for such case.  Jieba is desined to segment sentence into words.
And I think you can easily use punctuation mark(for example: "。"， “！”, "？") to split paragraph into sentences

Yes, thank you @ybkun. I used regex to split paragraph into sentences.
This post helped me.


feat(hmsl):EXPL-95 hmsl fingerprint now handle env file

Codecov Report

Merging #656 (a732255) into main (4e33638) will increase coverage by 0.03%.
The diff coverage is 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main     #656      +/-   ##
==========================================
+ Coverage   93.54%   93.57%   +0.03%
==========================================
  Files         108      108
  Lines        4926     4952      +26
==========================================
+ Hits         4608     4634      +26
  Misses        318      318

Flag
Coverage Δ

unittests
93.57% <100.00%> (+0.03%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed
Coverage Δ

ggshield/cmd/hmsl/check.py
92.68% <100.00%> (+0.18%)
:arrow_up:

ggshield/cmd/hmsl/fingerprint.py
100.00% <100.00%> (ø)

ggshield/hmsl/utils.py
84.26% <100.00%> (+3.44%)
:arrow_up:

Sorry, I had to push force because ggshield would be happy otherwise (secrets were introduced in the history). I fixed the pyright issue and the ggshield one. Thanks for the tips.


FrameAnimation does not created a paused timeline by default

So it doesn't matter whether we wait until fonts/images are loaded because the timeline plays instantly, regardless.

@mm-paulie what was the PR that fixed this? Just found this issue in Ana's project again, wondering when it got fixed

I checked that project with temple 6.2.2 and noticed the issue is still happening.. reopening this issue

It first runs the init function async, then it creates the animation and pauses it by default? Can you show me an example project where this happens?
In main.js
const banner = new Banner(config); //first load fonts, load images etc in the init animation banner.init().then(   () => {     //initializes animation and creates main timeline     banner.setAnimation(new Animation(document.querySelector('.banner'), config));     //plays banner     banner.start()   } )
In Banner.js
`async init() {
this.banner = document.body.querySelector('.banner');
await politeLoadImages(this.banner)
await this.loadFonts(); //need to wait until fonts are loaded. Otherwise we will run fitText on the wrong fonts
const title = document.body.querySelector('.title');
const ctaCopy = document.body.querySelector('.cta_copy');
fitText([title, ctaCopy]);

this.domMainExit = document.body.querySelector('.mainExit');

this.domMainExit.addEventListener('click', this.handleClick);
this.domMainExit.addEventListener('mouseover', this.handleRollOver);
this.domMainExit.addEventListener('mouseout', this.handleRollOut);

}
setAnimation(animation){
this.animation = animation;
//creates new timeline and pauses it
this.animation.getTimeline().paused(true);
// this.animation.getTimeline().eventCallback('onComplete', this.handleAnimationComplete);
}`
So first it loads the images/fonts and when that is done it creates the animation and pauses it by default?


Initial ShooterSubsystem

Not ready yet, just creating PR so I don't forget

Oops

Looks good to me. Next time, please separate out the formatting changes to a different PR to reduce cognitive overload of reviewers.

I've removed those like 5 times now... time to do it again I guess


Possible Unhandled Promise Rejectio on android device

Like #5338, it was closed.
but the warn "Possible Unhandled Promise Rejectio" still alive on android device "Red mi" when I save file.

Make sure that everywhere you have a promise chain, you're finalizing the chain by calling the non-standard .done()
e.g. fetch( someurl ).then( processdata ).catch( processerror).done()
If it turns out that EVERYWHERE you have a promise you have resolved the chain in this manner, then it's possible this is an RN bug, but I think it's more likely this warning is working as intended

@mangogogos I run the original init project, it throw the warn message.problem like #5338  . it's closed, but I got same warn message again.

Same here.
Warning Possible Unhandled Promise Rejection occurs in app running on android device whenever hot reloading happens.
Repro steps:

Run react-native init someproject
Ensure physical android device is plugged in
cd someproject && react-native run-android

then on device

Menu > Dev Settings > Debug server host & port for device
Menu > Enable Hot Reloading
Menu > Reload JS

Save file index.android.js and observe the warning.
Environment:
react-native-cli: 0.2.0
react-native: 0.24.1
Android version: 4.4.4

Have the same warning when hot reload is enabled even though it still updates the view.
Waning:
Possible Unhandled Promise Rejection (id:0):
Network request failed
onerror@http://<IP_ADDRESS>:8081/
index.android.bundle?platform=android&dev=true&hot=true&minfy=false:18405:21
_sendEvent@http://<IP_ADDRESS>:8081/
index.android.bundle?platform=android&dev=true&hot=true&minfy=false:17872:9
setReadyStatet@http://<IP_ADDRESS>:8081/
index.android.bundle?platform=android&dev=true&hot=true&minfy=false:17858:16
_didCompleteResponse@http://<IP_ADDRESS>:8081/
index.android.bundle?platform=android&dev=true&hot=true&minfy=false:17749:19
call@[native code]
@http://<IP_ADDRESS>:8081/
index.android.bundle?platform=android&

Environment:
OS: Arch Linux
react-native-cli: 0.2.0
react-native: 0.25.1
Android SDK Tools 25.1.6
Android SDK Platform-tools: 23.1
Android SDK Build-tools: 23.0.3

Same here.
OS: OSX
Device: Huawei
react-native-cli: 1.0.0
react-native: 0.27.2

me too:
OS: OSX
Device: iphone6
react-native-cli: 1.0.0
react-native: 0.27.2&0.28

Same here.
OS: OSX
Device: Huawei
react-native-cli: 1.0.0
react-native: 0.27.2

And it only happens when setting debug server host & port for device, no warning for adb reverse

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/possible-unhandled-promise-rejectio-on-android-device
Product Pains has been very useful in highlighting the top bugs and feature requests:
https://productpains.com/product/react-native?tab=top
Also, if this issue is a bug, please consider sending a pull request with a fix.

+1


Pin default Envoy and RateLimit images tags

Description:
Currently envoyproxy/envoy-dev:latest and envoyproxy/ratelimit:master are used as default  envoy and ratelimit images.
https://github.com/envoyproxy/gateway/blob/c6696d9c82f1b8c77ccc8e22965d158691cbbd07/api/v1alpha1/shared_types.go#L22
Wouldn't it be better to pin both images to an immutable latest stable tag?
for envoy: envoyproxy/envoy:distroless-v1.29.1-latest
for ratelimit: envoyproxy/ratelimit:9901a9bf
This way EG installation will be consistent.
In addition, in latest EG release(v0.6.0) envoyproxy/envoy:distroless-v1.28-latest is used as default envoy image. A latest stable immutable tag should also be used here.
WDYT?

For the main branch we try and use the latest  bits for upstream dependencies (envoy-proxy, envoy-ratelimit)
Although this may cause some instability due to bugs in the dependencies, the longer soak time before a release outweighs the cons.

For release images we always pin it for stability.

The caveat here is we didnt pin the envoy image to exact patch version for v0.X releases and only pinned it to a minor version (e.g. v1.29.1-latest) to conserve our efforts, yet provide a way to the user to get the latest CVE free envoy image tied to a minor version (by performing a restart). This will change post v1.X releases where we will have to pin to a envoy patch version and will have to release a new EG patch version every time theres a new patch release in Envoy around fixing CVEs

Hope this helps


Portability fixes

ISO C specifies that atoi() is part of stdlib.h.
POSIX specifies that passing 0 to setpriority selects the current process. Avoiding the Linux‐specific gettid syscall allows Tangram to build on OpenBSD.

Any more thoughts? Can this be merged?

@bentley Hi I've checked that setpriority with 0 works as intended on linux to set the tileworker thread priority. Thanks!
Updated PR is here https://github.com/tangrams/tangram-es/pull/1876

This functionality was merged in #1876


Does Bookshelf/Knex support Postgres Enum data type?

As described here: http://www.postgresql.org/docs/9.1/static/datatype-enum.html
When I ask knex to generate an enum (e.g. table.enu('status', ['Open', 'Closed']); it generates this:
"status" text check ("status" in (\'Open\', \'Closed\')). I was expecting something like:
CREATE TYPE status AS ENUM ('Open', 'Closed');
CREATE TABLE cases (
    ...,
    status status
);

See https://github.com/tgriesser/knex/issues/394 for native enum vs constraint discussion

Awesome! Great discussion. Sticking with check constraint.


Introduce new deduplication algorithm

When submitting a pull request, please make sure you have completed the following checklist:

[x] Your code is flake8 compliant
[x] Your code is python 3.5 compliant (specific python >=3.6 syntax is currently not accepted)
[x] If this is a new feature and not a bug fix, you've included the proper documentation in the ReadTheDocs documentation folder. https://github.com/DefectDojo/Documentation/tree/master/docs or provide feature documentation in the PR.
[x] Add the proper label to categorize your PR

By this PR I have introduced a new deduplication algorithm which identifies duplicate findings based on a set of configured attributes.
A finding has an attribute named line which records the code line where the vulnerability is present. When the code gets updated, that vulnerable line can be moved up or down a little. When line is considered in the deduplication algorithm, it fails to identify findings having a slight difference in line as duplicates. So, I have introduced a new attribute named offset which can identify duplicate findings having a difference of line within a range of +/- 100.

The existing dedupe algorithm allows you to specify which fields to consider for deduplication. For static findings the line number can be used, for dynamic findings line numbers should not be used.
Does that not work for you?
Currently it looks like you are creating an entriely new dedupe algorithm with the only difference that it checks the line number for an offset? Also it would break anything that is using the hash_code for deduplication or unique identification of findings. Which we might use more in the future. Coulld you elaborate more, because I might be misunderstanding.

hello all,
I'm not convinced by the arbitrary 100 lines offset; some files will be less than 100 lines and it will be pretty much the same as not looking at the line at all (all vuln of the same type in the file will be duplicate). other big files will sometimes shift by more than 100 lines when introducing big portions of code so it won't find duplicates.
For what parser do you need this?
For me the solution to this line number shift issue was to not include the line number is the deduplication configurations :) . the presence of the line number in the legacy algorithm is one of the things that made it flawed.
The two solutions i've found are implemented in the checkmarx scanners:

use the source tool intelligence to tell what is the correct unique identifier of a vulnerability: this is implemented in the scanner "checkmarx detailled scanner" : the field "unique_id_from_tool" holds an identifieir that makes it possible to identify an unique vulnerability, even if the line number changes. checkmarx can mess it up sometimes, but not too often.
use a parser that aggregates per filename and count the occurences. this is implemented in the "checkmarx scanner" (not detailed). with this parser there is no line number, problem solved. it makes imports much faster too and the db smaller

same solution is there for sonar parser

@piyarathnalakmali with that info in mind, do you still think that this PR is required? thanks


Can't run this app first time

Target of URI doesn't exist: 'package:flutter/material.dart'.
Try creating the file referenced by the URI, or Try using a URI for a file that does exist.

Try to run flutter analyze in the project root or flutter doctor

same question , run flutter analyze :
zhuangwendadeMacBook-Pro:FlutterEbookApp-master nonacosa$ flutter analyze
Because flutter_ebook_app depends on iridium_reader_widget from path which doesn't exist (could not find package iridium_reader_widget at "../iridium/reader_widget"), version solving failed.
Running "flutter pub get" in FlutterEbookApp-master...
pub get failed (66; Because flutter_ebook_app depends on iridium_reader_widget from path which doesn't exist (could not find package iridium_reader_widget at "../iridium/reader_widget"), version solving
failed.)
zhuangwendadeMacBook-Pro:FlutterEbookApp-master nonacosa$

https://codemagic.io/app/5e230defc5faa60315b1df62/build/628c24a623ff14297e053991

same question , run flutter analyze :
zhuangwendadeMacBook-Pro:FlutterEbookApp-master nonacosa$ flutter analyze
Because flutter_ebook_app depends on iridium_reader_widget from path which doesn't exist (could not find package iridium_reader_widget at "../iridium/reader_widget"), version solving failed.
Running "flutter pub get" in FlutterEbookApp-master...
pub get failed (66; Because flutter_ebook_app depends on iridium_reader_widget from path which doesn't exist (could not find package iridium_reader_widget at "../iridium/reader_widget"), version solving
failed.)
zhuangwendadeMacBook-Pro:FlutterEbookApp-master nonacosa$

I solve the issue by going to the pubspec.yaml file on line 40 and change
path: ../iridium/reader_widget
to
path: ../iridium/reader_widget

hope it helps

This is fixed now