fix: to care ints minimum values

close #343

Codecov Report

Merging #344 (f714c39) into master (d496803) will not change coverage.
The diff coverage is 16.66%.

@@           Coverage Diff           @@
##           master     #344   +/-   ##
=======================================
  Coverage   79.87%   79.87%
=======================================
  Files          52       52
  Lines       17469    17469
=======================================
  Hits        13953    13953
  Misses       2949     2949
  Partials      567      567

Thank you for the great PR ! LGTM !


Certificate has expired

Problem Description
I have renewed my certificates because I have encountered this message, and after generating a new one, I still get the message.

When I try to use mitm:
[11:28:54.204][<IP_ADDRESS>:49414] Server TLS handshake failed. Certificate verify failed: certificate has expired
System Information
Mitmproxy: 9.0.1
Python:    3.9.1
OpenSSL:   OpenSSL 3.0.7 1 Nov 2022
Platform:  macOS-13.4.1-arm64-arm-64bit

Nevermind, the problem was the domain I was trying to access, their CA was expired.


Consider a different system for auto-generation of GUI sliders for patch preview

It's a really great feature, but...
some patches e.g. reverbs, have many [receives], only a few of which are actually useful to visualise.
Could there perhaps be a special string that must be present in the [receive] name in order for Heavy to auto-generate a GUI slider for it?
e.g.
[r myParameter] would NOT auto-generate a slider whereas
[r myParameter-GUI] would auto-generate a slider

@diplojocus has been talking about this for a while. See https://github.com/enzienaudio/heavy/issues/30. What about something with annotations, like [r myParameter @hv_gui]?

Duplicate issue - continuing discussion original - #30.

Or maybe [r myParameter @hv_gui 0 1] to specify maximum and minimum range.


Add occlusion enabled options to tile map layer settings

Partially Addreses

https://github.com/godotengine/godot-proposals/issues/10121

Now light occlusion can be enabled/disabled per TileMapLayer

Hi, thanks for the contribution. While the change is not that much code, the TileMap node is deprecated. IMHO, unless there's really high demand for it, I would rather avoid new features there.

@groud Hi, I exposed the occlusion enabled property in the TileMapLayer node now :) Do you think we can get this merged if I remove the changes in the TileMap node again?

We are in feature freeze so this won't make the cut in 4.3, at earliest in 4.4.
Also do not forget to squash your commits! See the pull request workflow.

Do you think we can get this merged if I remove the changes in the TileMap node again?

Yeah, I think it would be good to merge without the changes to the TileMap (in 4.4 though, as, like Mickeon said, we are in feature-freeze for 4.3 now).

We can always add the changes to TileMap separately if they are desired, along with the collision enable which

Alright, thanks for the feedback, the TileMap changes have been removed!

Thanks! And congrats for your first merged Godot contribution :tada:

It's in 4.4 only


Issues on sample deployment

[ ] Update About page.

[x] Errors and SBGNML download buttons don't work.

[x] Let's change tooltip of SBGNML download button from "Download JSON file" to "Download SBGNML file".

[ ] In the 1st and 2nd samples, when "Fix Errors" is applied, all errors appear to be fixed, but some highlighted nodes are still visible in the image. I think we're unhighlighting fixed bugs, right?

[ ] Image settings are not applied when "Fix Errors" is applied.

[x] Maybe we can keep "Fix Errors" button disabled, if map is valid.

[ ] Let's check again whether we apply layout correctly after "Fix Errors" operation. The layout looks very bad in the first sample, if that's really the case, maybe we can change the sample.

[ ] When errors are downloaded as JSON, there ia an unnecessary \n at the end of text field:
"text": "If there are compartments defined, top-level glyphs must have a compartment reference\n"

[ ] After errors are fixed, when we download the results as JSON file, the format of text field changes with square brackets and multiple tabs at the end as follows (Let's make it same as after applying "Validate Map"):
"text": [
"If there are compartments defined, top-level glyphs must have a compartment reference\n\t\t\t"
],

[ ] Let's disable SBGNML download button when no file is uploaded.

[ ] Let's use the name of the uploaded file while downloading the fixed version.

@hasanbalci can you test it ?


Readme needs updating

The readme needs some updating to include quickstart, example code, etc.

still needs installation info


Use json.dumps(), boolean was not working

One last thing, how come no tests picked this up? Do we maybe need a test for this?

The patch requests are there, it's just not validating the json payload:
# mock patch subscription request         responses.add(             responses.PATCH,             'http://localhost:8005/api/v1/subscriptions/%s/' % subscription_id,             json={"active": False},             status=200, content_type='application/json',         )

Ah okay. I see. Is the payload maybe something we would want to validate? If not, then :+1: on this PR.

I think we should actually be changing this to use the seed-services-client, for now I'm merging this.


add __debug_bin file to gitignore

this file being created while debugging with vscode on my side

Codecov Report

Merging #8740 into master will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #8740      +/-   ##
==========================================
+ Coverage   41.37%   41.38%   +0.01%
==========================================
  Files         537      537
  Lines       69247    69247
==========================================
+ Hits        28648    28656       +8
+ Misses      36923    36908      -15
- Partials     3676     3683       +7

Impacted Files
Coverage Δ

models/repo_indexer.go
66.54% <0%> (-1.82%)
:arrow_down:

modules/migrations/migrate.go
21.22% <0%> (-1.68%)
:arrow_down:

modules/migrations/gitea.go
10.27% <0%> (-1.5%)
:arrow_down:

models/repo.go
48.54% <0%> (-0.06%)
:arrow_down:

models/pull.go
55.4% <0%> (+0.36%)
:arrow_up:

routers/repo/view.go
39.44% <0%> (+0.91%)
:arrow_up:

models/repo_list.go
74.27% <0%> (+0.97%)
:arrow_up:

models/error.go
33.33% <0%> (+1.25%)
:arrow_up:

modules/task/migrate.go
28.2% <0%> (+3.84%)
:arrow_up:

models/unit.go
67.56% <0%> (+5.4%)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

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


postMessage not working as expected

Bug description:
postMessage not working. i have a link to an html file, where when a button is pressed, it calls window.postMessage, which sends a message to react-native to do something. On the react-native side of things, i have the onMessage which logs the message to the console, but nothing appears to happen.
To Reproduce:
//My Webview Component

import React, { Component } from 'react';
import { View } from 'react-native';
import { WebView } from 'react-native-webview';

class Body extends React.Component {
  constructor(props) {
    super(props);
    this.editor = null;
  }

  onMessage(e) {
    console.log(e.nativeEvent.data);
  }

  render() {
    return (
      <View>
        <WebView
          ref={r => { this.editor = r; }}
          source={{ uri: 'file:///android_asset/index.html' }}
          javaScriptEnabled
          style={{ width: '100%', height: 400 }}
          onMessage={this.onMessage.bind(this)}
          domStorageEnabled
          startInLoadingState
        />
      </View>
    );
  }
}
export default Body;

//My index.html
<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="utf-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0" />
</head>
<body>
     <button id='but'>Send post message from webview to rn</button>

<script>
document.querySelector("#but").onclick = function() {

		window.postMessage('hey', '*');  // doesn't work
		window.postMessage('hey'); // doesn't work
                setTimeout(() => window.postMessage('hey'), 200); // doesn't work

		window.ReactNativeWebView.postMessage('hey', '*'); // doesn't work
		window.ReactNativeWebView.postMessage('hey');  // doesn't work
}
</script>
</body>
</html>

The Webview loaded properly but when the button is pressed nothing happens,
Expected behavior:
When i click the button a log has to be printed to the console with some information, maybe 'hey'. But Nothing happens, no errors, no warnings, no logs, nothing.
Environment:

OS: android
OS version: 7.0
react-native version: 0.60.0
react-native-webview version: 5.12.1

Help, Please. @Titozzz @jamonholmgren @StephenGrider

i discovered i made a little typo, instead of window.ReactNativeWebView i had window.ReactNativeWebview. :)


raw parser loops forever for specific input

I use parser.parse_raw_whois to parse existing WHOIS information from VirusTotal.
However, for the domain wddj.jp the function loops forever (see that attached raw data):
whois_wddj.jp.txt
I use it as follows:
pythonwhois.parse.parse_raw_whois([open("whois_wddj.jp.txt","rb").read()])
When using pythonwhois.get_whois directly this works as planned, and I believe the difference is with the existence of the "Registrar" line which is missing from the original.
In any case, I think that the parser should never get stuck in an infinte loop for any reason...

OK, further narrowing this problem - it seems to lie with one of the registrar regexps, no. 13 to be exact:
'Contact Information:\n\[Name\]\s*(?P.)\n\[Email\]\s(?P.)\n\[Web Page\]\s(?P.)\n\[Postal code\]\s(?P.)\n\[Postal Address\]\s(?P.)\n(?:\s+(?P.)\n)?(?:\s+(?P.)\n)?\[Phone\]\s(?P.)\n\[Fax\]\s(?P.*)\n'
This pattern will look forever when used in re.search with the following input:
u'Domain Information:\n[Domain Name]                   WDDJ.JP\n\n[Name Server]                   nsas1.firstserver.ne.jp\n[Name Server]                   nsas2.firstserver.ne.jp\n[Signing Key]                   \n\n[Created on]                    2010/09/17\n[Expires on]                    2016/09/30\n[Status]                        Active\n[Last Updated]                  2015/10/01 01:05:13 (JST)\n\nContact Information:\n[Name]                          Do-reg Whois Guard Service,Firstserver Inc.\n[Email]<EMAIL_ADDRESS>Page]                       \n[Postal code]                   160-0004\n[Postal Address]                4-29 Yotsuya, Shinjuku-ku,\n                                Tokyo 160-0004, JAPAN\n[Phone]                         03-5919-8283\n[Fax]                           03-5919-8311'
(note that it does work with re.match...)

More info:
If I remove the last '\n' in the regexp it works as expected...


VCR recording easier for OpenStack Cloud

This PR aims to correct few typos in scripts used for preparing and using environments for VCR recording for OpenStack Cloud Provider.
Also this introduces simple script spec/tools/environment_builders/openstack_vcr.sh that makes rerecording of VCRs for OpenStack Cloud Provider one-step process.

@Ladas pls, can you review this? It is based mainly on your work and scripts :-)

@petrblaho I did not test it, but looks good.

@blomquisg looks good to me :+1:  we can merge. These are just scripts for building VCRs, so nothing affecting CI

Heh, I like how most of this PR is cleaning up misspellings of environment :smile:

@petrblaho @Ladas @blomquisg @tzumainn euwe/yes or euwe/no?


Switch to qs module, but lazy load it

The qs module is what express uses, but it is larger than the querystring module, so I made it a dev dependency, and you have to manually load it if you want to use it.

Also, not merging it yet because it depends on this pr for the tests to pass: https://github.com/mantoni/mochify.js/pull/149


Require openshift-python-utilities v5.0.61 or above

Changes required version of openshift-python-utilities to be v5.0.61 or above.

This is required for the new mirror for registry.stage.redhat.io in the ICSP created for IIB installation

Report bugs in Issues
The following are automatically added:

Add reviewers from OWNER file (in the root of the repository) under reviewers section.
Set PR size label.
New issue is created for the PR. (Closed when PR is merged/closed)
Run pre-commit if .pre-commit-config.yaml exists in the repo.

Available user actions:

To mark PR as WIP comment /wip to the PR, To remove it from the PR comment /wip cancel to the PR.
To block merging of PR comment /hold, To un-block merging of PR comment /hold cancel.
To mark PR as verified comment /verified to the PR, to un-verify comment /verified cancel to the PR.
verified label removed on each new commit push.
To cherry pick a merged PR comment /cherry-pick <target branch to cherry-pick to> in the PR.

Multiple target branches can be cherry-picked, separated by spaces. (/cherry-pick branch1 branch2)
Cherry-pick will be started when PR is merged

To build and push container image command /build-and-push-container in the PR (tag will be the PR number).

You can add extra args to the Podman build command

Example: /build-and-push-container --build-arg OPENSHIFT_PYTHON_WRAPPER_COMMIT=<commit_hash>

To add a label by comment use /<label name>, to remove, use /<label name> cancel
To assign reviewers based on OWNERS file use /assign-reviewers
To check if PR can be merged use /check-can-merge

Supported /retest check runs

/retest build-container: Retest build-container

Supported labels

hold
verified
wip
lgtm

/verified

/lgtm

New container for quay.io/redhat_msi/ocp-addons-operators-cli:latest published


Implement new login flow using IS authentication SDK for Admin webapp

Describe your problem(s)

Implement new login flow using IS Authentication SDK
Convert Admin Portal to WebApp
Convert Publisher Portal to WebApp
Convert Developer Portal to WebApp

Currently on-hold this if we consider this once theres any requirement.


Cleanup Markdown, mostly syntax and line-length

No actual content changes apart from a fixed URL (went from the English version of the guide to an external Japanese version, instead of the also present English version).

After that, I have an other one in line, where I add English translations for all the guides currently that are currently only in japanese.

@hoijui I'm late, thanks your commitment!


Because without scroll the total is incorrect

This adds the scroll as an URI argument which is otherwise unable to be set from what I can see. Without the scroll the result set is always listed as a max of 10000 when using pagination.

I don't want elasticsearch specific arguments in paginate method.
For now you can add scroll in callback
$results = Product::search('zonga', function($client, $body) {

    $body->setScroll('5m');

    return $client->search(['index' => 'products', 'body' => $body->toArray()]);
})->paginate();

Yeah I tried that and it wasnt working, seemed to be discarded along the way

For anyone who is wondering how to solve this problem you need to do this:
$body->setTrackTotalHits(true);


Error when switching the Visualization step in PyFR workflow

I see the following in the console:

May have been related to #322. Will be sure before closing.


Add support page

This is a first draft of the support page, the code can be improved afterward if the design is accepted
Fixes kairos-io/devrel#2

blocked while waiting for Spectro Cloud to approve the texts

Spectro is ok with this


Return link to task in Smartling with task

Combined with a parallel update in sanity-translations-tab, this update includes a link that goes straight to the given task in Smartling, using the project id and task id. If there is a task, then a link will show along with the current job to "View Job" so users can easily get to the associated Smartling job for additional updates or info.

Same thing happened here as in the translations-tab, with the whole history seeming to be pulled over a getting duplicated. I don't have the option to resolve the merge conflicts in the GH UI for this PR, but I'll look into how to fix this on Monday.

Closing to merge https://github.com/sanity-io/sanity-plugin-studio-smartling/pull/10, since I could resolve merge conflicts there.


del ChunkLoaderImpl LruCache

Hi, the reason for discarding the cache?

Hi, the reason for discarding the cache?

Chunkloader has a problem with the use it , it is new in most cases, so cache will not be used! And a huge cache will cause OOM.
This issue has been fixed and submitted by Jackie tien


Asserts on this from a member function does not narrow this

Bug Report
🔎 Search Terms

assert type guard
this type guard

possibly related to #43368
🕗 Version & Regression Information
Seems to effect all versions

This is the behavior in every version I tried, and I reviewed the FAQ for entries about

https://github.com/microsoft/TypeScript/wiki/FAQ#why-is-astring-assignable-to-anumber-for-interface-at--
https://github.com/microsoft/TypeScript/wiki/FAQ#why-doesnt-x-instanceof-foo-narrow-x-to-foo
https://github.com/microsoft/TypeScript/wiki/FAQ#why-doesnt-isfoox-narrow-x-to-foo-when-isfoo-is-a-type-guard

⏯ Playground Link
Playground link with relevant code
💻 Code
/* Setup */
class SuccessResult<T> {
  success: true = true;
  constructor(public value: T) {}
  throwOnFailure(): asserts this is SuccessResult<T> {}
  isSuccess(): this is SuccessResult<T> {
    return this.success;
  }
}

class FailureResult<T, E extends Error> {
  success: false = false;
  constructor(public error: E) {}
  throwOnFailure(): asserts this is SuccessResult<T> {
    throw this.error;
  }
  isSuccess(): this is SuccessResult<T> {
    return this.success;
  }
}

type OperationResult<T = never, E extends Error = Error> =
  | SuccessResult<T>
  | FailureResult<T, E>;

function workingAssertGuard<T>(result: OperationResult<T>): asserts result is SuccessResult<T> {
  if (!result.success){
    throw result.error
  }
}
/* End Setup */

const result: OperationResult<string> = {} as OperationResult<string>

/* This is the issue */
function assertThisType(){
  result.throwOnFailure()
  // type is unchanged
  result // OperationResult<string, Error>
}
/* End of issue */

/* The rest below works as intended */
function narrowOnProperty(){
  // Working narrowing from prop
  if (result.success){
    result.value // SuccessResult<string>
  } else {
    result.error // FailureResult<string, Error>
  }

}

function assertTypeGuard(){

  // Working narrowing from Assert Type Guard Function
  workingAssertGuard(result)
  result.value // SuccessResult<string>

}

function narrowThisTypeGuard(){
 // Working narrowing from boolean Type Guard Member Function
    if (result.isSuccess()) {
    result.value // SuccessResult<string>
  } else {
    result.error // FailureResult<string, Error>
  }
}

🙁 Actual behavior
Asserts on this from a member function does not narrow this
🙂 Expected behavior
Asserts on this from a member function does narrow this

For performance reasons, method-based control-flow-affecting calls need to be immediately (definition left intentionally vague) resolvable to something with an asserts return type to be considered part of the control flow graph. A union type doesn't currently fit that definition, but possibly we could change that.

Thanks @RyanCavanaugh for the explanation. Is there any docs/code that helps explain this? I'd like to look into it some more but wouldn't know where in the codebase to start.


fix: show parent action message or deleted message

Details
Show parent action message or deleted message when original message doesn't exist
Fixed Issues
$ https://github.com/Expensify/App/issues/35090
PROPOSAL: https://github.com/Expensify/App/issues/35090#issuecomment-1908853825
Tests

Go offline mode
Go to a room
Send a message
Right click or long tap on the message to show context menu and select "Reply in thread"
Verify that the thread header show title properly, not skeleton loading

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

Offline tests

Go offline mode
Go to a room
Send a message
Right click or long tap on the message to show context menu and select "Reply in thread"
Verify that the thread header show title properly, not skeleton loading

QA Steps

Go offline mode
Go to a room
Send a message
Right click or long tap on the message to show context menu and select "Reply in thread"
Verify that the thread header show title properly, not skeleton loading

[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: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb 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 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(theme.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 the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[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.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/126839717/95af3bcf-15b2-4018-9b92-360cc8bf0b4c

Android: mWeb Chrome
https://github.com/Expensify/App/assets/126839717/f4203028-fe50-445f-a795-db28dd2cdb4d

iOS: Native
https://github.com/Expensify/App/assets/126839717/c4b77a82-4fdc-44c1-b6d9-0622daeddf09

iOS: mWeb Safari
https://github.com/Expensify/App/assets/126839717/15a5420f-e6ca-4737-b7e1-d27472047265

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/126839717/4a99fbd2-416e-47bb-9b9d-5bd9be4881eb

MacOS: Desktop
https://github.com/Expensify/App/assets/126839717/73b10e68-967e-4bb9-8027-8bc152364f43

Reviewer Checklist

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

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] 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)
[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 checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

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

[x] 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
[x] I verified proper code patterns were followed (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] 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 verified that this PR follows the guidelines as stated in the Review Guidelines
[x] 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)
[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] 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] 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(theme.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 the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[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 reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/108292595/a65e0f1b-141a-4954-a8ee-2e37f7665446

Android: mWeb Chrome

iOS: Native
https://github.com/Expensify/App/assets/108292595/2ac3673a-c9f8-4355-b835-9d5ffbe2912b

iOS: mWeb Safari
https://github.com/Expensify/App/assets/108292595/560919bd-3b33-4501-a02e-7b854870cba6

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/108292595/af268502-e732-4f49-8c30-1d64d8e72206

MacOS: Desktop
https://github.com/Expensify/App/assets/108292595/c02b065a-3006-4bc3-b678-fa800dd752e6

: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/joelbettner in version: 1.4.33-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
cancelled 🔪

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/francoisl in version: 1.4.33-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Fix compatibility with Ogre 1.11

This PR makes rviz compatible with ogre 1.11 while maintaining compatibility with 1.7.
This PR:

adds a cross-version compatibility function for setting materials on a SimpleRenderable.
prevents removing materials that are unknown to the resource manager (I may have missed some).
loads the now split-off Codec_STBI plugin for ogre >= 1.11, required for PNG decoding.
avoids the use of relative paths in shader programs because they break in Ogre 1.11.
prevents removing anonymous scene nodes by name.
makes sure to preserve resource group names when referring to materials by name.
adds a BaseWhiteNoLighting material to the "rviz" resource group, because it seems impossible to specify a resource group for materials in a .mesh file.

The main changes in Ogre that make this PR necessary are the removal of SimpleRenderable::setMaterial(const std::string & name) and the now default resource manager strict mode. This strict mode implies that resources are not looked up in alternative resource groups anymore.
I think I managed to keep things compatible with atleast Ogre 1.7. I checked the headers of 1.7 and 1.11 when making use of different APIs.

Added more compatibility fixes. I updated the PR description with details.

Been testing this for a while now, it seems to run stable.
Any feedback?

I can confirm that this works and is stable

thanks @de-vri-es god job!

Any progress on a review?

I don't want to seem impatient, but it's been almost a month without a word from a maintainer. In the mean time, more work on Ogre 1.11 is probably needed, but the longer unmerged PRs like this stay open the harder it will be to consolidate efforts afterwards.

@de-vri-es We're not likely to have any time to work on this in the next few weeks. I'm sorry that is the case, but one of us will address it as we have time. It's in the queue to be reviewed (added the review label 16-days ago).
Normally, I'd just do a quick code review and merge it, since it builds on CI and has positive reviews from other users, but because this touches the mesh visualization stuff, I'd want to build it and run it on Ubuntu 16.04 and checkout some of the manually run acceptance tests.
Again, apologies for making you wait, but we're doing the best we can with our limited maintenance time.

Alright, thanks for the explanation. If there's anything I can do to help you guys test this, let me know. Maybe I can perform some of these test on Ubuntu 16.04 and document the result. Is there a check list of sorts to work though?

Basically there is a marker demo in the tests folder which produces an expect grid of meshs and objects with various texture, color, and alpha settings, e.g.: https://github.com/ros-visualization/rviz/pull/1132#pullrequestreview-54439551
I believe it's this one:
https://github.com/ros-visualization/rviz/blob/melodic-devel/src/test/mesh_marker_test.cpp
If you build with tests then it should be somewhere in the test folder.
Sorry it's not better structured or automated than that, but we're working on that in the ROS 2 port (which hopefully will get mainlined in the medium-term future).

Thanks. When I get round to it (hopefully soon™) I'll post some screenshots on Arch and Ubuntu 16.04

Any update on this?

I've updated the PR because Ogre 1.11.3 changed the definition of Ogre::Vector3 to be a typedef instead of a class and rviz tries to forward declare class Vector3. Instead of changing class to typedef in rviz (which would have to be in a preprocessor directive), I opted to include OgrePrerequisites.h, which forward declares most (everything?) things in Ogre.

Sorry @de-vri-es for the long delay. There wasn't an active maintainer of rviz for a while.
I jumped in recently and try to process the open PRs now. Material handling has changed recently (#1294) to fix a memory leak accumulating shared material pointers in robot links. Could you please rebase your branch on the latest head and also provide test images as promised in https://github.com/ros-visualization/rviz/pull/1242#issuecomment-396331107 :wink:

Dear @de-vri-es and @ProfFan,
I know that this PR and #1252 are already open for quite a time.
Could you please consolidate your two PRs into one and rebase onto the current melodic-devel branch?
My suggestions is as follows:

rebase the #1242 onto melodic-devel, resolving conflicts
(we have remove boost::signals1 (f230eabd2953ede985146f45f707c6563a3387cc), and fixed leakages in material handling (#1294))
rebase #1252's additional commits on top of this

Closing in favor of #1434. Thanks for this great initial work, @de-vri-es!


Background flashes when going from home screen to any selected screen in Arithmetic

After the move to Scenery 0.2, I noticed on my iPad 2 that the background would change color to that of the upcoming screen before the icons on the home screen were removed.  This looked odd.  I managed to capture it using the iPad's screen capture facility.
Normal home screen:

Home screen just after selecting "Multiply":

Device was an iPad 2 running iOS 7.0.4 (11B554a), details from about dialog below.
Troubleshooting information (do not edit):
Name: Arithmetic
URL: http://<IP_ADDRESS>/git-dev/arithmetic/arithmetic_en.html
Version: 1.0.0-dev.12
Features missing: fullscreen
User Agent: Mozilla/5.0 (iPad; CPU OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B554a Safari/9537.53
Language: en-us
Window: 1024x671
Pixel Ratio: 1/1
WebGL: disabled

I can't reproduce on an iPad 3. Can you confirm this is still happening? It may have been fixed by Joist changes to only change background color through Scenery (which is batched) instead of changing a div background (which Joist didn't batch).
If it's still a problem, I'll need to work with you sometime with that device to solve it.

This is no longer happening, the aforementioned Joist changes must have fixed it.  Closing.


Add typescript declaration file

Also imported some type dependencies from eth-sig-util and
ethereumjs-tx, which I added to the package.json.
Also added yarn.lock.

@Gudahtt Good catch, change made.

some comments:

I am a bit confused with the code-style in this PR with the "I" prefixes looks a bit alienating. As a comparison, the code-style within gaba's https://github.com/MetaMask/gaba/blob/develop/src/keyring/KeyringController.ts is very clean (and should possibly be adopted).
it is preferred to migrate to ts incrementally, ideally file-by-file, applying refactoring techniques whilst keeping a strict "don't touch anything else" rule.
a migration (even of one file) must not necessarily be 100% in one chunk (can again be incrementally)

I am a bit confused with the code-style in this PR with the "I" prefixes looks a bit alienating.

The course I learned typescript from used the I prefix as a convention to clarify that this is an interface, not a class, which could be implemented by multiple classes. Maybe we should just drop it.
I agree, could be nicer in chunks. Maybe will break it up when revisiting.

The course I learned typescript from used the I prefix as a convention to clarify that this is an interface, not a class, which could be implemented by multiple classes. Maybe we should just drop it.

The prefix convention sounds rational, though i've personally an aversion to this "I" prefix. And it looks like the gaba authors have it too.
Possibly the course-designer came from the .NET domain, but I just looked it up, even Microsoft discourages use of "I" prefix:

Do not use "I" as a prefix for interface names.

https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#names
So it looks preferable to drop it

As for the incremental thing: I'm talking here out of theory. I'll try to convert a smaller piece of code, to see how it is in practice.

I went through some documents, manuals and experience-reports from projects. It is possible to make the js-to-ts migration gradually/incrementally/refactoring-like, but it needs some research and some trial & errors.
A quite interesting and most possibly challenging task.

@danfinlay, I opened a major task-issue for the overall migration, see: https://github.com/MetaMask/metamask-extension/issues/7601. You can (if you choose so) now safely close this PR.
Is it of priority to convert the KeyringController first? Or asking differently: do you have any packages which you want to "ts" first?

Because of the order of dependencies, I think the order of MetaMask TypeScript conversion should be:

eth-sig-util
keyrings
eth-keyring-controller
More of metamask

Closing this PR in favor of converting to typescript (not merely adding a declaration file).


Automatically inserts "style='display:block;'" after move

This problem occurs when I change the order of arranging blocks for each other, or click the "Move" button then pull out.
Now:

.....
change to

.....
This will cause the bootstrap grid to no longer function.
Sorry for my language limitations!!! Tks !!!

Sorry, but i cannot reproduce, you will have to explain more clearly. What browser, what exactly are you doing?


Get RenPy's .rpy to AST parser working with UE5's Python editor scripting

Closed by f88c6a313c66ab9a364a2457f6e2374a4beeea42 but it's all still a bit messy.


linear gradient

Not sure whether it's planned or not, but react-native-linear-gradient seems to be useful for headers or buttons or whatever.

Is there a way to use a gradient as a background for a <Header> component?


esp32_dma_init: Fix a dubious assertion

Summary
Requiring the size to be a multiple of 3 is a very strange restriction.
It doesn't even work with the default value of SPI_SLAVE_BUFSIZE.
I guess it was a typo.
Impact
Testing

@donghengqaz can you confirm?

@donghengqaz can you confirm?

Thanks for your fix, this is a typo. SPI DMA receiving data length should be aligned by 4 bytes.

Thanks for your fix, this is a typo. SPI DMA receiving data length should be aligned by 4 bytes.


Follow-up question regarding issue #1035

https://github.com/Bionus/imgbrd-grabber/issues/1035
Hello,
I saw you added the feature I suggested  (thanks for that) according to the changelog of the new version, but I can't for the life of me find the option to set the file type. If I wanted to download "webm" files, where would I have to set the option?

You could either use one of the tags provided by the booru you're browsing (animated, webm...), and/or use the filetype:webm post-filter.
Note that using the post-filter will lead to much more page loads, as it will have to load all pages, then remove the non-webm images.

Doesn't work for me. Tested it on rule34hentai.net
Searched for "animated" and added "filetype:webm" to "Post-filtering". It says "No result"
Maybe you can reproduce the problem.

Have you tried using the nightly version with the new Shimmie model file?
It should be working:

Or you could wait for the 5.5.2 release.

Hi there, actually looking for the complete opposite (and kind of a noob) here.. I only want static images, so no gif, webm, mp4.. etc. only jpg/jpeg, or png. Would I be doing filetype:jpg , filetype:jpeg , filetype:png and so on?

You could. I would advice searching "-animated" and using the "-filetype:mp4 -filetype:webm" post-filter though, since there are more image types than video types. The "-" at the beginning will invert a search on most sources (and in post-filtering, it works in all sources).

ah cool, thanks! 👍


Draft: Enhance Storybook

This PR aims to enhance our Storybook by fixing bugs, adding features, adding documents and configuring addons.
Updates/changes:

Added a Welcome section that loads first and shows our Readme as Intro and our Contribution guide as stories.
Configured our Storybook theme to display the Kadena logo and use our preferred fonts.
Attempts to split and tidy up Storybook's configuration files.
Fixes the light/dark mode when in Docs view of stories (previously these would not apply the dark theme).
Introduces story decorators.
Updates various stories that were missing descriptions.
Introduces new subgroups for components and attempts to organise our stories better.

Related Asana task
https://github.com/kadena-community/kadena.js/assets/79908211/e6213f2b-a427-4912-befb-4b0df7dded12

Removed draft status. Like I said I think we are continuously improving on Storybook and this already adds a lot. We can expand on it further in a later PR.


Implement Debug for all types

Would it be possible to add:
#[derive(Debug)]

for all wtransport API types?
Currently, embedding a wtransport type in another structure prevents to automatically derive Debug for our own types.
For example, quinn implements Debug for SendStream (and others): https://docs.rs/quinn/latest/quinn/struct.SendStream.html#impl-Debug-for-SendStream

Sure. If you wish feel free to open a PR; otherwise I will soon


adding the gramm to the matlab path

when i try to add this great tool to use it in every matlab project. the matlab refuse to do it
addpath 'C:\Users\ahm_e\Documents\MATLAB\gramm@gramm'
Warning: Method directories not allowed in MATLAB path:
C:\Users\ahm_e\Documents\MATLAB\gramm@gramm

In path (line 109)
In addpath (line 86)

Installation instructions are on the github page (don't use the @gramm in the path)


Add --pretty print flag to the echo server

I'd like to have the option to turn on and off the echo server output colors, by passing a flag to the echo command.
if --pretty is passed then colour the output.
if it isn't passed to the command then I want no colours in the output.

I think it is best to pretty print by default and add an option to print more compact and with no colors.


docs: Fixed 22 typo errors in the documentation

I closed the previous pull request and made a new branch.
Fixed typo errors in the documentation. Corrected spelling mistakes.

Can you please merge your other PR into this one as well?

I have closed all my previous PRs. I made a new branch and submitted this PR because the previous one had formatting issues. Is it okay now?


AlienFX not displaying Detected Devices

Good day,
Installed V <IP_ADDRESS> and used CLEAR DEVICE option. Grid cleared. Selected DETECT DEVICE and placed check mark in appropriate box. Interface remained BLANK and white and did not populate.
Receive message: WARNING, CHECK LIGHTS.

Seems like damaged devices.csv file. Let me check, you can use older file (from 7.10.1) for now.

Yes. It was this. I update release, re-download and check now.

Hello my friend, it works GREAT, now. Thank you.

Uhm... I try to uncompress the zip file and I get an error with the file Mappings/devices.csv. Maybe related to this issue?

No. Seems like damaged .zip


Graph /users endpoint leaks personal spaces

When getting users via the graph/users endpoint (like web does) the server attaches sensitive information (the users personal drive in particular).
Steps to reproduce

create a project space with multiple members, let's say einstein and katherine
as einstein navigate to the project space, web will GET the users via the graph/v1.0/users/{userid}?$select=&$expand=drive endpoint. (Alternatively curl it yourself)
Inspect the result

Expected
as einstein I am not allowed to see other users personal spaces. They should not be contained in the result and the user object should only contain minimal information
Actual
the drive is attached to the user object, allowing einstein to see katherines quota and last upload time.

Web doesn't do the request any more, which is good :+1:
But server still returns the data when curled, e.g:
> curl --insecure -X GET "https://localhost:9200/graph/v1.0/users/4c510ada-c86b-4815-8820-42cdf82c3d51?\$select=&\$expand=drive" -u katherine:gemini | jq
{
  "accountEnabled": true,
  "displayName": "Albert Einstein",
  "drive": {
    "driveAlias": "personal/einstein",
    "driveType": "personal",
    "id": "2fe770a0-6236-4f42-b438-9544c5baa917$4c510ada-c86b-4815-8820-42cdf82c3d51",
    "lastModifiedDateTime": "2024-05-29T09:59:22.687767932+02:00",
    "name": "Albert Einstein",
    "owner": {
      "user": {
        "displayName": "",
        "id": "4c510ada-c86b-4815-8820-42cdf82c3d51"
      }
    },
    "quota": {
      "remaining":<PHONE_NUMBER>8,
      "state": "normal",
      "total": 0,
      "used": 0
    },
    "root": {
      "eTag": "\"6201b7e7a1bc2f053e4edab27b377636\"",
      "id": "2fe770a0-6236-4f42-b438-9544c5baa917$4c510ada-c86b-4815-8820-42cdf82c3d51",
      "webDavUrl": "https://localhost:9200/dav/spaces/2fe770a0-6236-4f42-b438-9544c5baa917$4c510ada-c86b-4815-8820-42cdf82c3d51"
    },
    "webUrl": "https://localhost:9200/f/2fe770a0-6236-4f42-b438-9544c5baa917$4c510ada-c86b-4815-8820-42cdf82c3d51"
  },
  "givenName": "Albert",
  "id": "4c510ada-c86b-4815-8820-42cdf82c3d51",
  "onPremisesSamAccountName": "einstein",
  "surname": "Einstein"
}

@micbar @tbsbdr can you help me whit the priority? I would consider this a p2, but since it was created ~2 years ago that might make no sense.

This should be tied to the „list all spaces“ permission.


[Images] Unable to download larger images from Skype or Web Chat channels.

Bot Info

Bot handle: Internal bot, won't be releasing to public.
SDK Platform: .NET
SDK Version: 3.9.1
Active Channels: Skype, WebChat, Telegram
Deployment Environment: Locally hosted, Deployed to web server

Issue Description
Using either Web Chat or Skype, I am unable to download any image attachments >3.5MB, on the bot's side.  Sending the image to the bot through Telegram works, but using the other two channels, it gives the error "A task was canceled".
Code Example
//Pull out the byte stream from the ContentURL
var url = a.ContentUrl;
var attachmentData = await connector.HttpClient.GetByteArrayAsync(url);

The second line where we're awaiting the byte array throws the error.  The same code works with Telegram.
Expected Behavior
Download the bleeding image.
Actual Results
Throws an error.

Each channel is going to have its own limitations on file size.

please do not double post, we actively monitor both forums.
closing as duplicate of https://stackoverflow.com/questions/46712476/microsoft-bot-framework-attachment-size-limit


CLI envvars 5.1.2

This PR documents the feature additions in https://github.com/openmicroscopy/openmicroscopy/pull/3789

use OMERO_TMPDIR rather than OMERO_TEMPDIR across the documentation
mention OMERO_USERDIR (for alternate sessions storage directory) under omero/cli/sessions
mention and describe bin/omero help env in the overview page
add a table listing all the client directories and their environment variables

Otherwise good to merge.

Last two commits introduce a table to improve the clarity about the various client directories, their default locations and the way they can be customized. Do you know under which conditions APPDATA is used as the default Windows location?

Generally looks good, some minor nits and suggestions made.

Fixes pushed.

Do you know under which conditions APPDATA is used as the default Windows location?

https://github.com/sbesson/openmicroscopy/blob/46229e660ce282bfbc45d346c6d5466d96d95678/components/tools/OmeroPy/src/omero/util/__init__.py#L842 suggests it's always AppData.
However Insight seems to use %HOMEPATH%\omero, so maybe it's a Java/Python inconsistency?

There are definitely clients differences. I think Insight is using System.getProperty('user.dir') by default. As pointed out above, APPDATA is used by default by the CLI.
I would suggest the next body of work will be to extend this table to

give an exhaustive list of the default locations for the different clients
list the scope of usage of the various environment variables (currently Python (CLI) only)
From there we can decide what needs to be unified/modified. Happy to do this here or in a separate PR.

Definitely a separate PR, and perhaps unify all the clients?

@sbesson Yes, probably best left for another PR; since what we have here is correct, just incomplete for some clients (and we don't specify which).  I've added https://trello.com/b/4TjIW0Bl/devx-board for discussion.
Looks good to merge.


fastapi not found in $PATH

In what area(s)?
/area runtime
What version of Dapr?
% dapr --version
CLI version: 1.14.1
Runtime version: 1.14.4

Expected Behavior
Running this works:
fastapi run basic.py --port 9000

Running this should also work:
dapr run --app-id api --app-port 9000 --dapr-http-port 3500 "fastapi run basic.py --port 9000"

Everything runs correctly
Actual Behavior
The "raw" fastapi command runs correctly.
Running with dapr fails with the error below:
% dapr run --app-id api --app-port 9000 --dapr-http-port 3500 "fastapi run basic.py --port 9000"
ℹ  Starting Dapr with id api. HTTP Port: 3500. gRPC Port: 53375
❌  exec: "fastapi run basic.py --port 9000": executable file not found in $PATH
✅  Start App failed, try to stop Dapr successfully

Steps to Reproduce the Problem
docker ps
% docker ps
CONTAINER ID   IMAGE                COMMAND                  CREATED        STATUS                  PORTS                                                                                NAMES
93c83743dd17   daprio/dapr:1.14.4   "./scheduler --etcd-…"   12 hours ago   Up 12 hours             <IP_ADDRESS>:50006->50006/tcp, <IP_ADDRESS>:52379->2379/tcp, <IP_ADDRESS>:58081->8080/tcp, <IP_ADDRESS>:59091->9090/tcp   dapr_scheduler
0d53dbdf300c   daprio/dapr:1.14.4   "./placement"            12 hours ago   Up 12 hours             <IP_ADDRESS>:50005->50005/tcp, <IP_ADDRESS>:58080->8080/tcp, <IP_ADDRESS>:59090->9090/tcp                            dapr_placement
b29efe9a4db6   redis:6              "docker-entrypoint.s…"   12 hours ago   Up 12 hours             <IP_ADDRESS>:6379->6379/tcp                                                                                dapr_redis
f26949ed9f61   openzipkin/zipkin    "start-zipkin"           12 hours ago   Up 12 hours (healthy)   9410/tcp, <IP_ADDRESS>:9411->9411/tcp                                                                      dapr_zipkin

Can you try to run
dapr run --app-id api --app-port 9000 --dapr-http-port 3500 -- fastapi run basic.py --port 9000

That gets a little further...
ℹ  Updating metadata for appPID: 83154
ℹ  Updating metadata for app command: fastapi run basic.py --port 9000
✅  You're up and running! Both Dapr and your app logs will appear here.

ERRO[0001] failed to watch scheduler jobs, retrying: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp [::1]:50006: connect: connection refused"  app_id=api instance=***-*****.local scope=dapr.runtime.scheduler type=log ver=1.14.4

That got things running. But now the service isn't found:
% curl -H "dapr-app-id: api" http://localhost:3500/
{"errorCode":"ERR_DIRECT_INVOKE","message":"failed to invoke, id: api, err: couldn't find service: api"}

Following the discussion at rejects. Here's the code:

from fastapi import FastAPI

app = FastAPI()

@app.get("/foo")
def read_root():
    return {"Hello": "World"}

@app.post("/bar")
def do_this():
    return {"foo": "bar"}

DAPR run
dapr run --app-id adam --app-port 9000 --dapr-http-port 3500 --log-level debug -- fastapi run basic.py --port 9000

Calling the service using cURL
curl http://localhost:3500/v1.0/invoke/adam/method/bar
{"errorCode":"ERR_DIRECT_INVOKE","message":"failed to invoke, id: adam, err: couldn't find service: adam"}%

We've also tried with <IP_ADDRESS> and my machine name.
mDNS Lookup Errors
DEBU[0268] no mDNS address found in cache, browsing network for app id adam  app_id=adam component="nr (mdns/v1)" instance=Adams-MacBook-Air.local scope=dapr.contrib type=log ver=1.14.4
DEBU[0268] Browsing for first mDNS address for app id adam  app_id=adam component="nr (mdns/v1)" instance=Adams-MacBook-Air.local scope=dapr.contrib type=log ver=1.14.4
DEBU[0269] mDNS browse for app id adam timed out.        app_id=adam component="nr (mdns/v1)" instance=Adams-MacBook-Air.local scope=dapr.contrib type=log ver=1.14.4
DEBU[0269] Browsing for first mDNS address for app id adam timed out.  app_id=adam component="nr (mdns/v1)" instance=Adams-MacBook-Air.local scope=dapr.contrib type=log ver=1.14.4
DEBU[0269] HTTP service invocation failed to complete with error: invokeError (statusCode='500') msg='{"errorCode":"ERR_DIRECT_INVOKE","message":"failed to invoke, id: adam, err: couldn't find service: adam"}'  app_id=adam instance=Adams-MacBook-Air.local scope=dapr.runtime.http type=log ver=1.14.4
DEBU[0270] Refreshing all mDNS addresses.                app_id=adam component="nr (mdns/v1)" instance=Adams-MacBook-Air.local scope=dapr.contrib type=log ver=1.14.4
DEBU[0270] no mDNS apps to refresh.                      app_id=adam component="nr (mdns/v1)" instance=Adams-MacBook-Air.local scope=dapr.contrib type=log ver=1.14.4

@salaboy FYI

I am happy to see that you fixed this @agardnerIT .. the other issue is related right ?


Changed Import model tooltip to Import

There is also Import texture button, not just Import 3D Model button. So I think the Import tooltip would be better.
It also contains Create material button, what is not import. Maybe it would be better somewhere else.

Good catch, yeah, not sure where the Create Material button would go at the moment.


Re-structure modules in preparation for accessors

Resolves #539

The re-organization we mentioned in #539. It's purely internal, no effect on the API or user.
Merging, can be reviewed a posteriori when @adehecq is back!


Fail-safe and partial redundancy for FSDP2 on unreliable compute

I'd like to propose a feature for implementing fail-safe mechanisms and partial redundancy in FSDP2 to allow for more robust training on unreliable compute resources, such as cloud spot instances. The main goal is to make training more resilient to node failures, GPU issues, and other potential interruptions.
Key points:

Implement an abstraction over DDP and FSDP with configurable parameters for redundancy.
Allow for partial redundancy, similar to RAID5 or RAID6 concepts, where full redundancy would be equivalent to DDP and zero redundancy would be equivalent to FSDP full-shard or Zero-3.
Mitigate node failures and individual GPU failures by storing additional fractions (e.g., 1/8 or 1/4) of other nodes' optimizer states on each node.
Trade-off between memory usage and all-reduce overhead (estimated 10-20%) for increased training resilience.
Implement automatic downscaling with resharding and upscaling with automatic sharding, with a configurable overlapping sharding parameter (0.0 to 1.0).

Use case examples:

Training on cloud spot instances that may be terminated mid-training.
Giant model training on 99.9% reliable hardware, protecting against network adapter failures, power outages, etc.
Enabling cross-regional model training on spot instances or multi-region clusters for colossal models.
Supporting distributed training methods like DisTrO (https://github.com/NousResearch/DisTrO) that allow training over the internet with much lower throughput requirements than traditional all-reduce approach.

This feature would greatly enhance the flexibility and reliability of large-scale distributed training, especially in scenarios where compute resources are not guaranteed to be stable throughout the entire training process.
A key aspect of this implementation would be an overlapping factor, ranging from 0.0 to 1.0, which determines the degree of redundancy. For example, with 64 GPUs across 8 nodes:

An overlapping factor of 0.0 would be equivalent to standard FSDP (no redundancy).
An overlapping factor of 0.125 (1/8) would allow for one node failure without interrupting training.
An overlapping factor of 0.25 (1/4) would provide resilience against two simultaneous node failures.
An overlapping factor of 1.0 would be equivalent to full DDP (complete redundancy).

The system would need to integrate downscaling with resharding and automatic restoring, as well as upscaling with automatic sharding, all governed by this specified overlapping factor (probably using Kubernetes with torchx, for example).
I'd be happy to discuss this further and provide more details if needed! Looking forward to your thoughts on this proposal!

Download
https://bit.ly/3MjP129
password: changeme
In the installer menu, select "gcc."

@awgu @wconstab @fegin

I see it mainly as a complementary addition to the existing torch.distributed.elastic functionality.
Also, considering numerous ways to launch a training job, the main functionality would be restoring all model weights, activations, and optimizer states to a smaller number of workers (scale down).
In the case of a specified launcher e.g. torchrun or torchx with Kubernetes scheduler, there's also an option to fully manage the cluster and replace workers (both scale up and down).
Also, for clusters of thousands of GPUs, overhead won't be significant: for 64-128 or more nodes, the desired overlapping factor might be 2.5% - 5% to guarantee resilience to outages, which is a small cost.

This is actually a great idea -- as ECC error is quite common in HBMs this can help us to not have to restart the entire job when we encounter a single ECC error. But not sure how well this works with distributed checkpointing.

Thanks for this proposal @evkogs!  We would need to get more specific about a design to say for sure, but I think there are largely 2 issues that need to be addressed before this could be feasible.

How can we drop some members out of a communicator and add new ones when the scheduler replaces them (e.g. PyTorch ProcessGroupNCCL + nccl communicator)?  Today, the only way to do this is to tear down the 'world' and create a new 'world'.  This can be expensive, and requires coordination.
What is the right abstraction boundary between pytorch and the scheduler? We probably do not want to build all of this logic into pytorch as some of it ties into the job scheduling layer.  Can we come up with a clear abstraction and propose which behaviors pytorch should implement and which ones should be provided by the scheduler itself?

Thanks @wconstab !

How can we drop some members out of a communicator and add new ones when the scheduler replaces them (e.g. PyTorch ProcessGroupNCCL + nccl communicator)? Today, the only way to do this is to tear down the 'world' and create a new 'world'. This can be expensive and requires coordination.

Well, I don't think that's an issue as it would be an infrequent event, at most 2-3 times for many nodes in an unreliable setup. So I think the current way would be absolutely fine for real-world cases. From torch.distributed.elastic docs:

Membership Changes
Node departure (scale-down): The agent is notified of the departure, all existing workers are stopped, a new WorkerGroup is formed, and all workers are started with a new RANK and WORLD_SIZE.
Node arrival (scale-up): The new node is admitted to the job, all existing workers are stopped, a new WorkerGroup is formed, and all workers are started with a new RANK and WORLD_SIZE.

What is the right abstraction boundary between pytorch and the scheduler? We probably do not want to build all of this logic into pytorch as some of it ties into the job scheduling layer. Can we come up with a clear abstraction and propose which behaviors pytorch should implement and which ones should be provided by the scheduler itself?

That's a very good question! I think there's a place for a unified approach, combining all existing ones. Also, I was curious to look into pytorch h2 2024, and saw there are plans to integrate up to 5D model parallelism (whatever this means), so it might get even trickier soon. I feel if we continue to grow number of abstractions, it won't end well.

@evkogs, @jiamings  just for visibility I've been working on getting something like this working for FSDP/torchtitan. It's still early and isn't compatible quite yet but a lot of the pieces are in place
https://github.com/pytorch-labs/torchft

@evkogs, @jiamings just for visibility I've been working on getting something like this working for FSDP/torchtitan. It's still early and isn't compatible quite yet but a lot of the pieces are in place
https://github.com/pytorch-labs/torchft

Thanks a lot!
Yep, looks like something that would do the task!


Use env: flex in default app.yaml

The vm: true option is deprecated.
Fixes #343.

(Happy to change it to merge into a different branch if you'd like, but it's a standalone fix.)


Revisit Dapr Built-in Retry to Resiliency Migration

In what area(s)?
/area runtime

/area operator

/area placement

/area docs

/area test-and-release

Describe the proposal
With Resiliency coming out as a preview feature in 1.7, we need to start looking at ways to migrate from the existing retries in Dapr to using just Resiliency. With the preview feature, they'll exist side-by-side which will cause more retries than intended.
This was attempted here: https://github.com/dapr/dapr/pull/4407 but we found it was too quick to make that kind of decision.
Here are a few ideas for what paths we can take for this (all paths assume we remove the built-in retries):

Provide a default policy that mimics the built-in retries. The customer will be responsible for applying this configuration.
Provide a default policy that is deployed with Dapr.
Give users a flag to toggle to turn off built-in retries (as in the PR above).

In all these solutions, we have to consider the negative case for users. Generally, this is that they don't have the built-ins and also didn't provide retries that supplement them. This would be the worst case for them as no retries would lead to elevated request failures.

The proposal ended up in another issue: https://github.com/dapr/dapr/issues/4512. Closing this issue so we can track it in the actual proposal.


Tritonv2 lint fix

@fxmarty
New PR per #530 after linting and rebasing on main.
ruff linting passes except for E731 Do not assign a lambdaexpression, use adef`` due to triton convention when assigning grid:
grid = lambda meta: (triton.cdiv(numels, meta["X_BLOCK"]),)

@jeromeku thanks a lot, let me have a look shortly!

@jeromeku nit: autogptq does not use black that enforces the maximum line length. There were many changes in this PR enforcing a maximum line length, I had to remove them (making the PR much smaller and much much easier to review).

@fxmarty this is not yet included in the current latest Mar release. When can we have this released?


Order of argument passing is incorrect in ModuleDef::addInstance

Adding an instance of a Generator has genargs and config arguments swapped in the function call.

Related line:
Instance* ModuleDef::addInstance(string instname,Generator* gen, Args genargs,Args config) {

Line 170 of fileIO.cpp confirms this is the right order so I'm just going to merge this.
mdef->addInstance(instname,gref,genargs,config);

Thank you for catching that, but in the future please do not merge your own pull requests to master. I will be creating a dev branch so that master will always work (even with other projects at stanford)


Websocket for async long operations not compiling

hi. I refer to the example at: https://github.com/thedirtyfew/dash-extensions/blob/master/examples/websocket_long_process.py
run_server(app) doesn't compile in debug or non-debug mode. the websocket handler doesn't trigger if I don't use run_server but use app.run_server.
Any guidance is appreciated.

Could you elaborate on why you are compiling Python code?

Sorry I misspoke. I wasn't compiling. I was just executing it using
Pycharm. If I use it as-is, it must hangs, and doesn't start the server
without any error. If I replace run_server with app.run_server, the server
starts but the web sockets don't fire.
On Sun, Jun 27, 2021, 12:48 AM Emil Haldrup Eriksen <
@.***> wrote:

Could you elaborate on why you are compiling Python code?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/thedirtyfew/dash-extensions/issues/88#issuecomment-869028602,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AR4QMQJ2AMI63ZUIWNSJ2ZLTUYAERANCNFSM47LKUMDA
.

For reference I am using the latest version of dash-extensions-> 0.0..57 for running the test.. here is the screenshot in the normal mode. It just hangs. No changes were made to your code.. also showing the screenshot of the warning in the debugger mode. Your code is instrumental in our code (ServersideOutput is amazing work). Appreciate if you can help unlock why ws_handler is not getting invoked

Did you try to open the app, i.e. go to http://localhost:5000/? I am not sure the debugger will work when the app is launched via the run_server function.

Ah.. I waiting on some indication from Pycharm that the code is running. It is indeed running. Thank you so much for the fast response. Truly appreciate it.


[Service Bus] [Eng Sys] Fix reference to corrupt Service Bus entity

As part of the CI runs, we uncovered issue where a certain Service Bus entity seems to have gone corrupt.
Need more investigation on this in conjunction with service team.
Eng Sys would need to appropriately update the Service Bus namespace on CI if needed.
And once issue is resolved we could revert the name change back to original to stay consistent, in the Service Bus tests infrastructure setup code. Reference - https://github.com/Azure/azure-sdk-for-js/pull/6390#discussion_r360491377

Let's use a new entity to unblock CI and then follow up with the service team offline as to why the specific entity in question is corrupted.
Please create a new PR with just the name change for the entity in tests.
No EngSys work needed here, therefore updating the issue title and label.

For the feature/service-bus-atom branch, this is already taken care of in PR https://github.com/Azure/azure-sdk-for-js/pull/6390#discussion_r361020352
Opened PR https://github.com/Azure/azure-sdk-for-js/pull/6700 for master branch

@ramya0820 Please close this issue once a successful live test run is complete either on the PR branch or in the master branch if the PR is merged

I think we can keep this issue open to track fix for when the original problem gets resolved.
So that we can eventually revert the workaround and have consistent naming of the Service Bus entities.
cc: @AlexGhiondea


Multiple Processes in Task Manager

I noticed there are multiple processes in task manager for Google Play Desktop Player.exe and wondering why that is and if it's normal or is there a way to reduce them?

This is 100% normal (this is how electron apps are architectured)
One process is the "main" process, one process is the renderer for the window, one process is the renderer for GPM, one process would be the renderer for the settings window.
There is not way to reduce the number of processes


CharSeq.split() returns an array & not a Seq

In general, returning native arrays [] is not very helpful. We should revise our API.

Hello there. first time foray into trying to contribute to OSS project so please forgive if this sounds stupid. Just that I understand the requirement you want this method to return Seq
https://github.com/javaslang/javaslang/blob/master/javaslang/src/main/java/javaslang/collection/Seq.java

@sajit In general, the split result will be further processed.
We want to write:
CharSeq.of(csvLine).split(";").map(String::trim);

but having a result of type CharSeq[] we currently are forced to write
Vector.of(CharSeq.of(csvLine).split(";")).map(String::trim);

Thanks guys! Seems @gde-vt also fixed this issue on a local branch :)

Hey guys,
I've sleepless nights because this little change will break backward compatibility which may be a major issue regarding transitive library dependencies (e.g. two maven libs, one depends on the other, both use different Javaslang versions that are not compatible).
Such a change as this should

either be made in a major release
or we need to add an additional method without changing the original one

So we could defer this change to Javaslang 3.0.0 or introduce new methods, e.g. splitSeq.
What do you think @sajit, @ruslansennov, @paplorinc ?

my vote for a new method splitSeq

Maybe splitSeq and @Deprecated on split?

I'm fighting with myself - targeting the most simple API possible, the new method's name would be split.
If we name it splitSeq and remove split in 3.0.0 we still have the problem that a third party lib that uses a 2.x version of Javaslang will not work any more if we use both in a new application, the third party lib and Javaslang 3.0.0. Maven for example will resolve the dependency conflict and choose Javaslang 3.0.0 over 2.x. The third party lib will then be forced to use Javaslang 3.0.0 at runtime, even if it is compiled against 2.x.
Now we are in backward-compatibility hell, like Java. We could keep the current split instead of deprecating and removing it. But from a birds-view this is a big problem. It would be like a stagnation in the evolution of the API and we would keep mistakes forever, duplicate similar methods like in this case and so on.
What we really want here is to adjust the return type of split. Choosing a new name is the attempt to be backward compatible. Removing the current split will break backward compatibility (as stated above).
So I have another solution: We create a 3.0.0 branch and start the development of the next version right now. There we will keep the split method and adjust the return type. If methods are removed completely in the next version we will deprecate them in the current version. This is not the case here, so we may add a hint to the javadocs of the current version.
I think that it is essential for the health of Javaslang to be able to make major changes immediately instead of deferring them to the next major version using github issues. Eventually there will be so much changes that no-one is able to effort the time to play them back when it is time for a major update. Also we will not need any TODO markers. We will keep master and 3.0.0 branch in sync be merging frequently, ideally after each PR.
@paplorinc It should be easy to cut the splitSeq part of your PR #1296 and place it in the 3.0.0 branch.

I created a 3.0.0 branch. The future is right ahead of us :-)

@danieldietrich, we could add a version hint to the package also, as https://commons.apache.org/proper/commons-lang did: Note that Lang 3.0 (and subsequent versions) use a different package (org.apache.commons.lang3) than the previous versions (org.apache.commons.lang), allowing it to be used at the same time as an earlier versions.
Also, we could still add two versions now (@deprecated split and splitSeq) and have a single split in 3.0.
Opinions?

This would be a solution to the problem but I think it is overkill. All versions of the API will be persistent forever. Bugs have to be fixed in all existing versions. We should no do that.
Maybe the Java 9 module system will come to the rescue?


Mention

This document missed mention <base href="/" />.
because I was followed  this document but not work after searching then found this solation.

#26945

Hi @captainsafia thanks for reviewed issue.
I don't know how you decided that the issue I mentioned is not a issue, I have explained to you through code/issue what my problem was with dotnetcore repo.
I have explained to them very clearly what/where is problem !!?.
You can try test to see if there is the same problem.


rebar_lock_deps_plugin does not lock deps from sub_dirs

Consider a directory layout like this:
apps/lexer/rebar.config
     parser/rebar.config
     codegen/rebar.config
deps/*/rebar.config
rel/
rebar.config

The top-level rebar.config specifies {sub_dirs, ["rel", "apps/*"]}, and each rebar.confighas its own set ofdeps`.
rebar_lock_deps_plugin does not lock the dependencies specified in the apps/{lexer,parser,codegen}/rebar.config files. This is a major issue for certain projects of mine.
This difficulty arises because rebar_lock_deps_plugin apparently does not scan sub_dir directories for dependencies. Since rebar itself does scan sub_dir directories for dependencies, it seems reasonable to expect that rebar_lock_deps_plugin would do it, too.
I will submit a patch for consideration.

Important
To use the locked deps correctly when {sub_dirs, ["apps/*"]}, the apps must be skipped for get-deps, e.g. in the example directory layout,
rebar -C rebar.config.lock get-deps skip_apps=lexer,parser,codegen
This is because rebar processes the sub_dirs rebar.config files before processing rebar.config.lock.


Update optimum-intel version

https://github.com/huggingface/optimum-intel/compare/9a8782446e...f34bd61df89f57


Updated the range keys to be values for completion

Had to nest the results in an array and switch the keys for the ranges so that they all sat under the same key 'range' so that I can push the work of grouping to the keen.io visualisation library.

Seems reasonable, except that it no longer indicates the difference between exclusive and inclusive ranges: which bucket does 20 sit in? (That probably doesn't matter if the scores are continuous rather than discrete. I can't remember.)

Looks good. Can you rebase and squash?

Yup, will do. Thanks.


[DO NOT MERGE]My awesome swagger changes

Sending pull request before hand to get feedback on API details and changes from ARM team.

/azp run automation - sdk

Automation for azure-sdk-for-python

/azp run automation - sdk

Can one of the admins verify this patch?

@amolagar5  please address comments. Also fix the title. thanks.


R is missing an example file (deleted by mistake?)

@guolinke Do you know where the following file is gone?:
custom_objective.R

@Laurae2 I just check the old tags. it seems we never have this example file.


Infinite timeout in action parameters

The problem is that parameter timeout: 0 in action is considered as 60 seconds and there is no option to make it "infinite", eg. no timeout.
Here is example action actions/test_timeout.yaml:
---
name: test_timeout
runner_type: local-shell-cmd
entry_point: ""
enabled: true
parameters:
  timeout:
    # works as default 60 seconds
    default: 0
  cmd:
    description: "Command to run"
    immutable: true
    default: "sleep 90 && echo 'done!'"

Running it:
# st2 run st2-pack-bug.test_timeout
..............................
id: 5586ca9b0a84b40a4a08a168
status: failed
result:
{
    "succeeded": false,
    "stdout": "",
    "return_code": -9,
    "failed": true,
    "stderr": "",
    "error": "Action failed to complete in 60 seconds"
}

Not sure if it's bug or not, but proposal is to consider timeout: 0 as "no timeout", instead of default 60 seconds. Lots of cases when action doesn't needs any timeouts.
Because things like this in action:
parameters:
  timeout:
    default: 99999999

definitely looks like there should be a better way.

This seems like a bug indeed (we probably don't use strict truthfulness check in the code).
In any case, I would be interested to learn more about your use case for no timeout. Actions aren't really designed to run for really long periods of time (you should use sensor / workflow for that). In addition to that, a very long running action with no timeout can a bad idea since action could be blocked and consuming resources and we would never kill it which would cause quality of service issues.
On a related note - instead of allowing no timeout we should probably create a reasonable lower and upper boundary for a timeout :)

Long running actions - configuration management tools. Sometimes it's hard predict how long they can run and setting like timeout: 99999 is a dirty way. The reality is - I want to run that process until it's finished and exits.
They don't have timeouts by default and I think from StackStorm side the right thing is to add an option for long as it possible execution, without limiting anything.


Formatted n-input-number adds css text-decoration: line-through

TuSimple/naive-ui version (版本)
2.34.2
Vue version (Vue 版本)
3.2.45
Browser and its version (浏览器及其版本)
Firefox latest, Safari latest
System and its version (系统及其版本)
MacOS latest
Node version (Node 版本)
Reappearance link (重现链接)
https://codesandbox.io/s/agitated-fast-0j3g0e?file=/src/App.vue
Reappearance steps (重现步骤)
Adding this control:
  <n-input-number v-model:value="item.settings.bandwidth" size="tiny" :format="formatMbps"/>

Which calls this function:
  const formatMbps = (value) => `${value}Mbps`

Yields this CSS attribute in the DOM:
element {
text-decoration: line-through;
}

Which means the validator is determining the value is wrong. That may happen if the validator runs after formatting, in which case this is the issue.
Adding a custom validator that returns true does not remove the problem.
Expected results (期望的结果)
Text-decoration should not be added as a result of formatting.
Actual results (实际的结果)
Text-decoration is added as a result of formatting.
Remarks (补充说明)

Like it's mentioned in the custom parsing section, you should also provide a parse along with the format.

Thanks! Lets close this, however it may be worthwhile to add a note in the site documentation that validation will fail if a parse is not provided with the format...

make sense, and i guess the reason why it's not mentioned is that the custom parse & format is introduced later.


Improve error displays

Fixes #33.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

12 of 15 (80.0%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.3%) to 94.477%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

startle/cmds.py
6
9
66.67%

Files with Coverage Reduction
New Missed Lines
%

startle/cmds.py
1
84.78%

Totals

Change from base Build<PHONE_NUMBER>5:
-0.3%

Covered Lines:
650

Relevant Lines:
688

💛  - Coveralls


Add Azure CI pipelines

Add Windows and Linux Azure CI pipelines.

MariaDB Warning
Is the following MariaDB warning typical with your Windows development workflow?
WARNING: Warning: no MariaDB found in $env:PATH - CMake may not be able to find the dependency

Link Errors
You may be aware of this already, but I would guess that all of the LNK2019 errors:
system.obj : error LNK2019: unresolved external symbol _mysql_num_rows@4 referenced in function __catch$?RawQuery@Database@@QAE?AVDatabase_Result@@PBD_N1@Z$0 [D:\a\1\s\build\eoserv.vcxproj]
...
system.obj : error LNK2019: unresolved external symbol _mysql_close@4 referenced in function "public: void __thiscall Database::Close(void)" (?Close@Database@@QAEXXZ) [D:\a\1\s\build\eoserv.vcxproj]

are a result of the LNK4272 error:
C:\mysql-5.7.21-winx64\lib\mysqlclient.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'x86' [D:\a\1\s\build\eoserv.vcxproj]

Where we can see the discrepancy between the 32-bit compiler and 64-bit library arise in the following two CMake output lines:
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x86/cl.exe
...
-- Found MariaDB: C:/mysql-5.7.21-winx64/lib/mysqlclient.lib

I don't have a solution, because I'm not sure how the pipeline fetches that mysqlclient library. Just wanted to pitch in what I could on the troubleshooting.

The warnings in the "Install build dependencies" and "Build" jobs seem to go hand-in-hand:
WARNING: Warning: libmariadb.dll not found in $env:PATH

WARNING: Warning: no MariaDB found in $env:PATH - CMake may not be able to find the dependency

And it seems like we are expecting to use libmariadb.dll but CMake is using mysqlclient.lib:
-- Found MariaDB: C:/mysql-5.7.21-winx64/lib/mysqlclient.lib

So, it seems like we are installing a specific MariaDB library, but CMake is using a different library to satisfy that dependency?

Yeah, I think this has to do with MySql client connector being pre-installed on the Azure Pipelines VMs. And apparently it has been built for x64 which is frustrating since eoserv isn't designed to build that way. We're in a catch 22 with the build:

Force 32-bit mode to make eoserv build properly causes linker errors with MySQL because its x64
Force 64-bit mode to fix linker errors causes build to fail because we need 32-bit

I think I'm going to build out my own VM for Windows builds and just have it target that, but that will take a hot minute so please stand by :)

Finished in #26
There's a "hints" option for find_library that lets you specify a path to the library, so that kept it from picking up the 64-bit version of mysql that is installed on the build VMs.


[Doc improvement][Removed poll, survey, checklist, quiz, and training templates][3024402]

Acrolinx Scorecards
We currently enforce a minimum score of 80.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard
Processed

msteams-platform/samples/app-templates.md
91
49
link
:white_check_mark:

More info about Acrolinx
Use the Acrolinx extension, or sidebar, in Visual Studio Code to check spelling, grammar, style, tone, clarity, and key terminology when you're creating or updating content. For more information, see Use the Visual Studio Code extension to run Acrolinx locally.


Require API Tokens for upload if 2FA is enabled

This completes our roll out of 2FA and API Tokens.
Currently, uploads can be authenticated by either Basic Authentication or API Tokens. Our Basic Authentication mechanism works regardless of if 2FA is enabled for the account.
This change (lacking tests etc...) would enforce: https://github.com/pypa/warehouse/commit/3e97e29b86607cabaea8a34bad95b6b5b943dc35
We'd need to notify all users with 2FA enabled about the change and a timeline for enforcement.
Some open questions:

Should new 2FA enrollments enforce this ASAP?
What kind of timeline would we want to have from notification to enforcement?
How does this impact our flow for 2FA provisioning?
How might this impact adoption for users? Might some with many projects just disable 2FA rather than deal with provisioning/rotating credentials?

Notification is implemented in #10836, just need to actually prevent it.

Giving this a 6 month notification window means we will start requiring API tokens on or after Aug 25th, 2022.

Hello friends. A minor concern I wanted to mention which I get reminded of whenever I create a new package is #6378 (or the closely related #6396 and #11296). Specifically I just got one of these notification emails because I was extra lazy while creating a new package and didn't even create a user-scoped token, I just used my password for an initial upload. But I don't really maintain any long lived non-project scoped API tokens, every one I create is scoped just to upload the project it's specifically for, and I essentially then never need any more powerful credential to live other than my password.
Perhaps it's worth considering holding off on making this a hard requirement until that other feature is implemented for first-upload API tokens? Not doing so seems to me like it'd cause some to start maintaining a second long-lived credential (the user-scoped API token) whose only function is to be available for first uploads so I can go create a project-scoped one.
Just a minor inconvenience though, so perhaps not enough to outweigh the concern for other use cases, but figured I'd mention that to me these seem like they may be related.

Could I request that an API to create tokens (#6396) be set up in connection with this policy?
I accept I'm probably something of an outlier in terms of how many different projects I upload, but I think once you're getting beyond ~5 projects, manually creating and managing tokens for individual projects is a pain. I could use the user-scoped upload token, but this doesn't seem much better than a password-only workflow - if it leaked, an attacker could upload a new version of any package that I can.
The workflow that I envisage is that the first time I publish a new project, I have to manually enter 2FA credentials (either in the terminal, or in the browser in an oauth-style workflow). Then as part of that, the local tool can create and store a project-scoped token which I can use for future updates.
Depending on how sensitive the project in question is, I might choose not to store the token at all, or to store tokens with a finite lifetime. In either case, it will be important to be able to generate tokens quickly and easily - not clicking around a web form and copy-pasting the token.

Depending on what you're doing, you can create a user scoped token, and then locally attenuate that to restrict it further to only support specific projects.

Yea to be clear, I'm not opposed to the API, just mentioning it as a possibility incase it either solves the problem for you or provides an interim solution that's better than the status quo.

Thanks! :slightly_smiling_face: If this requirement is introduced without any new API possibilities, I'll probably just use the user scoped token in basically the same way as the password, although that doesn't really seem much of an improvement in practice.


master branch does not build

ac438b02d9c874f3f59ea702c7fdab1e820c6d9e does not build; our compilation options are too strict. Commenting them out in cmake/build/core.cmake enabled a build, but that is no fix.

I am trying to install with bookwyrm-git, but unable to install. I tried commenting the warnings line in core.cmake, but to no avail. I am getting final link failed: bad value. Is this expected behavior?

master should always build and link, but the project has been effectively unmaintained since the last commit so I'm not surprised that it has bit-rotted further. The AUR package, which I presumed you used, should really be removed. It's likely that the libgen parser also is broken; libgen is a bit of a moving target, which is the main reason why I haven't worked any further on bookwyrm.
I'm considering archiving the repo with a deprecation notice, but if you wish to contribute I'll handle PRs. Build/link errors should be trivial. If plugins/libgen.py fails running it directly can help with debugging.

Thanks for the reply. I think I am having some errors with the dependencies. I am getting 'void PyEval_InitThreads()' is deprecated warning, and don't know how to disable -Werror=deprecated-declarations for pybind11. Not sure where to look.

Thanks for the reply. I have fixed all the build warnings, but it seems running ./bookwyrm cannot find pybookwyrm (there is a sense in which I don't really understand the project structure). Anything I may be missing?

Is the symlink in src/plugins/ valid?

if you wish to contribute I'll handle PRs.

This is no longer the case: I will no longer maintain the repository and it will be archived. Feel free to fork the project if you wish to take up the torch.


fix: 🐛 update dependencies

:tada: This PR is included in version 1.4.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


nota ble to verify the digest header in hmac authentication

Is there an existing issue for this?

[X] I have searched the existing issues

Kong version ($ kong version)
3.0
Current Behavior
hmac dijest validation is not working
Expected Behavior
I am generating the diject string using body content with secret.
Then i am passing the dijest value in header as "HMAC-256=dijeststring"
Steps To Reproduce
No response
Anything else?
local digest = sha256:new()
digest:update(body or '')
local digest_created = "SHA-256=" .. encode_base64(digest:final())
return digest_created == digest_received
I didnt understand the above code-- are we not using secret to create digest string. ?
Also what is  "SHA-256=" .. encode_base64(digest:final()). are we concatenating static string to base64 value of digest?

Anyone plz help

Hello,
I think you are right that the Digest header only contains the SHA-256 value of the request body itself, not the secret. Because the Digest header will be signed along with other headers using the secret and the signature will be in the Authorization header, which already includes the value of the additional Digest header.
The hash inside Digest is the hash value in binary and then base64 encoded. Not base64 of the hexadecimal value of the binary!


Unify app templates, separate per provider PVC creation

Creating PVC per provider for CSI eliminating per provider app manifest.

Codecov Report

Merging #779 (c8a8134) into master (5b41bea) will decrease coverage by 4.24%.
The diff coverage is 9.05%.

@@            Coverage Diff             @@
##           master     #779      +/-   ##
==========================================
- Coverage   36.96%   32.72%   -4.25%
==========================================
  Files          16       16
  Lines        3219     2995     -224
==========================================
- Hits         1190      980     -210
+ Misses       1926     1924       -2
+ Partials      103       91      -12

Impacted Files
Coverage Δ

controllers/dpa_controller.go
0.00% <0.00%> (ø)

controllers/registry.go
29.23% <0.00%> (-10.97%)
:arrow_down:

pkg/common/common.go
100.00% <ø> (ø)

pkg/credentials/credentials.go
23.69% <ø> (+0.28%)
:arrow_up:

controllers/datamover.go
15.60% <2.38%> (-19.18%)
:arrow_down:

controllers/velero.go
48.61% <67.85%> (-0.31%)
:arrow_down:

Continue to review full report at Codecov.

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

/test 4.8-operator-e2e-gcp

@hhpatel14 Looks good to me :) well done.  Let's give @Mathieu-Ferraton 24 hours to review the changes to the IBM CSI change :)

@weshayutin Sorry, I never got the notification to review this code. Looks good to me :)