optional parameter for generics is being ignored

Bug Report

🔎 Search Terms

generics, optional parameter, default generic type, generic constraint
🕗 Version & Regression Information

This changed between versions 4.1.5 and 4.2.3

⏯ Playground Link

Playground link with relevant code
💻 Code

interface SomeInterface<T> {
    value: T
}

declare function factory<T extends string = string>(optionalParameter?: T): SomeInterface<T>;
declare function echo<K extends {[key: string]: SomeInterface<any>}>(opt: K ): K;

const fallbackToConstraintInsteadOfDefault = echo({ foo: factory() } as const);

🙁 Actual behavior

the return type of echo is not fully of type K, but falls back to the constraint of K.
🙂 Expected behavior

The return type is from the default type of T.
Notes
This behaviour does not occur in 4.1.5
This behaviour does not occur when no constraint for K is given.
This behaviour does not occur when factory gets called with a parameter.
This behaviour does not occur when the return value of factory is first stored in a variable.

Appears to be caused by #39384 and #41475. With those PRs we now produce contextual types for expressions in as const assertions and for that reason we make an inference from SomeInterface<any> (the element type in the constraint of K) to SomeInterface<T> (the return type of the factory() invocation). We do the same thing in both 4.1 and 4.2 if you remove as const. Things work as expected if you change the SomeInterface<any> constraint to SomeInterface<unknown> (since unknown isn't assignable to string we then pick string).

A constraint is altering the type, and weakining it through const? That doesn't seem to be working as intended to me.
Especially since that doesn't always happen but only when the optionalParameter is not given, and therefore the default of T is assigned. In all the other cases it does not happen.
Your idea with unknown is interesting and does indeed work in this very simple scenario. But if I have a slightly more complex interface it will break. Since unknown is not assignable to  string
interface SomeInterface<T> {
    value: (opt: T) => T
}

declare function factory<T extends string = string>(optionalParameter?: T): SomeInterface<T>;

declare function echo<K extends {[key: string]: SomeInterface<unknown>}>(opt: K ): K;

const fallbackToConstraintInsteadOfDefault = echo({ foo: factory() });

https://www.typescriptlang.org/play?jts=4.2.3&ssl=1&ssc=1&pln=12&pc=1#code/JYOwLgpgTgZghgYwgAgMoHsC2ECS5rxIA8AKgHzIDeAUMncgG5wA2ArhAFzIAU6ADmC4kAlMgC8FEtQC+1agBMICZnCgoYrEAjDB0IZITDooAT1LIIAD0gh5AZ2R2wUUAHNxj527K8BukCwACqpw2JBQAPxCwlwY2HjhhBCkZADccorKquqa2v4WCAAW6EQA0hbWELYOlADaANYQJlxOLiCuALqxWLj4sIjJmvUg6ADuIGTSPvyCyOUxc+lyCHpOBizMAEaI9SToAMKrznCgYHhOEHDyAPIwACIQ8KzMYB5KxdyUBujoXIbGJm4omkwnSKxAaxGIGufj0LBwdgAYqAUGICh8vjAfn9EEZTNwAETbABeBOBoOWR2QajArCgIAAaix2B5-viKeC1ooni9zpArrdDhDjqdERttgh6m8iuhPt9ftSILT6Uy2CgQekgA


Add rustfmt support

Type of change

New feature or functionality (change which adds functionality)

For changes visible to end-users

Relevant documentation has been updated

Test plan

Manual testing; please provide instructions so we can reproduce: cd example && bazel run format

Trying to add rustfmt as a formatter. rules_rust already has a toolchain for rustfmt, so I am using that in the example.
However, the runfiles cannot be located since we change directory to the root of the repo before running the formatters. Is there a workaround for this?
Initializing rules_rust in the example folder can be improved, but I want to make it work first.
$ bazel run format
Formatting Rust with rustfmt...
/home/paulsmsm/.cache/bazel/_bazel_paulsmsm/573d3651f449593b84c17a4875272cea/execroot/_main/bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/tools/rustfmt.rustfmt: line 2: external/rules_rust~0.38.0~rust~rustfmt_nightly-2023-12-28__x86_64-unknown-linux-gnu_tools/bin/rustfmt: No such file or directory
FAILED: A formatter tool exited with code 123
Try running 'bazel run @@//tools:format' to fix this.
Error: bazel exited with exit code: 123

When calling bazel run //tools:rustfmt -- $(pwd)/src/hello.rs works as expected.

@alexeagle any workaround for the runfiles issue?

Yeah I think we need to set $RUNFILES_DIR to the original directory before we chdir

Sorry for the delay. Busy times, I won't have time to work on this.


[Snyk] Security upgrade react-router-dom from 5.0.0 to 6.0.0

Snyk has created this PR to fix 1 vulnerabilities in the npm dependencies of this project.
Snyk changed the following file(s):

admin-frontend/package.json
admin-frontend/package-lock.json

Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Regular Expression Denial of Service (ReDoS) SNYK-JS-PATHTOREGEXP-7925106
  67

Release notes

Package name: react-router-dom

6.0.0 - 2021-11-03React Router v6 is here!
Please go read our blog post for more information on all the great stuff in v6 including notes about how to upgrade from React Router v5 and Reach Router.

6.0.0-beta.8 - 2021-10-22Remember last week when we said

We anticipate this will be the last beta release before v6 stable next week.

Yeah, about that … 😅
We found and squashed a few high-priority bugs that needed to be addressed first. But it's coming very soon, we promise! In the mean time, here's what you'll get from our eight-est and greatest beta release:
🐛 Bug Fixes

We fixed a few bugs in useHref that resulted in the incorrect resolved value in cases where a basename is used on the <Router /> component (See #8133 and #8142 for details).
We also fixed a bug in our path ranking algorithm so that splat routes (routes with a * path value) are now correctly ranked ahead of layout routes.

🗒 Docs
We've added lots of goodies to our docs and examples, and there's a lot more yet to come. Take a look and see if you find something that makes your work a little easier! We think the lazy loading and custom query parsing examples are particularly cool! 🤓

6.0.0-beta.7 - 2021-10-15In this release we made a small but significant change to how <Link to=".."> works. This is going to help out a lot if you were trying to use links in a * route.
We have also backed out our blocking/prompt APIs for the stable v6 release. We will revisit this post 6.0 when we have a little more time to get it right.
✨ Features
The major change in this release could also be classified as a bugfix or a breaking change, depending on how you look at it. We essentialy altered the way <Link to=".."> works. See #8086 for the motivation behind this change.
You'll probably want to reread the section in the v5 => v6 migration guide about <Link to> values (it has been updated), but it basically boils down to this: any leading .. segment in a <Link to> value traverses "up" one route and builds upon that route's path instead of just removing one URL segment. This feature really completes the story of relative routes and links.
We could consider this a bugfix, since this is how it was always intended to work in the first place. Without it, you'd have a difficult time linking predictably in * routes because your  would be different depending on the number of segments in the current URL.
The reason this could also be considered a breaking change is that .. now works slightly differently in <Link to> than it would in . When you have  it operates on the URL pathname, removing one segment of the current URL. However, since many routes really only match a single segment of the URL, there is often no difference between <Link to=".."> and .
💔 Breaking Changes

We removed useBlocker(), usePrompt(), and <Prompt> for now. We will revisit these post 6.0 when we have more time to get it right. But we don't want it to block (see what I did there) the release of all the other awesome stuff we've got in v6.

🛠 Roadmap
We anticipate this will be the last beta release before v6 stable next week. Please give it a shot and let us know how it goes!
👍 Upgrading
If you're thinking about upgrading to v6, I published a few notes this past week that may help you:

This note talks about removing <Redirect> elements from any <Switch>es you may have in your v5 app and how you can get better SEO in the process if you're currently relying on client-side redirects.
This note talks about how to refactor your code to avoid "wrapping" <Route> elements, which won't work in v6.

Both of those posts contain steps you can take today in your v5 app without upgrading to v6.
We are also developing a backwards compat lib that should help some of you upgrade from v5 to v6. We'll post more about this when it's ready.
💻 Installing
Development for v6 has switched from dev to the main branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next

6.0.0-beta.6 - 2021-10-07No big enhancements in this release, just squashing bugs and writing lots of tests! Also, we are hard at work on cranking out examples for v6. See the end of this post for an update on our roadmap between here and v6 stable.
🧰 Examples
We have begun creating some examples for v6 that we hope will help developers make effective use of all the new features we have. So far, we have examples for the following:

Basic Example – A basic client-side app for v6 showing how to use nested routes, layouts, links, and the new <Outlet> API
Auth Example – Demonstrates an authentication flow including using the new useNavigate() hook, the <Navigate> element, and location.state
Search Params Example – Demonstrates how to build a simple search form that uses the new useSearchParams() hook
SSR Example – A server-rendered app that uses <StaticRouter> on the server and uses a <BrowserRouter> with ReactDOM.hydrate() on the client

Each example includes a button in the README that allows you to instantly launch a running instance on StackBlitz that you can play with. We hope you enjoy exploring!
🐛  Bugfixes

Make <NavLink> match only whole URL segments instead of pieces. This means that <NavLink to="/home/users"> will still be active at /home/users, but not at /home/users2. See #7523
Makes "layout routes" (routes with no path) never match unless one of their children do. See #8085
Fixes a route matching regression with splat routes that was introduced in beta.5. See #8072 and #8109
Fixes matching a nested splat route. See af7d038
Provide all parent route params to descendant <Routes>. This reverses a decision that we made in beta.5 to remove them. See #8073

💔 Breaking Changes

Splats in route paths (*) match only after a / in the URL. This means that <Route path="files*"> will always match as if it were <Route path="files/*">. The router will issue a warning if your route path ends with * but not /*

🛠 Roadmap
We are very close to a stable release! The last big code changes we need to make are:

Fixing "linking up". Currently a <Link to=".."> operates on the URL pathname. However, this makes it difficult to link to the parent route when you're in a splat route. See #8086. This will be a breaking change.
We are going to remove useBlocker() and <Prompt> in our initial v6 release, with plans to revisit them and possibly add them back at some point in the future. I still need to write up something here that explains our rationale. This will also be a breaking change.
We are going to add some animation primitives (see #8008). The <Routes location> prop will be in v6, but it isn't ideal for animation.

💻 Installing
Development for v6 is chugging along on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next

6.0.0-beta.5 - 2021-09-25This week's release adds some much-needed polish to a few niche features of the router: splat routes (a route that uses a * path) and basenames. It also adds a renderMatches API that completes the story for those of you who may have been using react-router-config in v4 and v5.
🐛  Bugfixes

A * in a child route path matches after a slash following its parent route path. This fixes some situations where the * was overly greedy (see #7972)
Resolution of <Link to="."> and useResolvedPath(".") values are fixed in splat routes. Previously these resolved relative to the parent route's path. They now resolve relative to the path of the route that rendered them.

✨  Enhancements
This release makes it easier to work with apps that have multiple entry points. Using the <Router basename> prop allows React Router to be easily deployed on only a portion of a larger site by using a portion of the URL pathname (the "basename") to transparently prefix all route paths and link navigations.
For example, you can deploy one React Router app at the /inbox URL prefix, and another one at the /admin prefix. These base URLs represent two different entry points into your app, each with its own bundles. The rest of your site, including the root / URL could be rendered by something other than React Router, for example by your server framework of choice.
In the bundle for each entry point, simply initialize React Router with the basename of that entry point.
<Router basename="/inbox">
  // ...
</Router>
Then define your routes and link paths without using the /inbox URL prefix in any of them. The entire app will run relative to that prefix.
Another improvement in this release is the addition of the renderMatches API, which is the complement of matchRoutes. These APIs are both very low-level and should not normally be needed. But they are sometimes nice to use if you are doing your own data loading using the array of matches that you get back from matchRoutes.
matchRoutes and renderMatches are the equivalent of the react-router-config package we shipped in v4 and v5, just built directly into the router instead of in a separate package.
💔 Breaking Changes

<Routes basename> has moved to <Router basename>. This prop is also available on all router variants (<BrowserRouter>, <HashRouter>, etc.).
useLocation().pathname no longer includes the basename, if present.
The basename argument was removed from useRoutes. This reverts the signature to useRoutes(routes, location), same as it was previous to beta.4.
Descendant <Routes> do not get the params from their parents. This helps a set of <Routes> to be more portable by decoupling it from the params of its parents and makes it easier to know which params will be returned from useParams(). If you were relying on this behavior previously, you'll need to pass along the params manually to the elements rendered by the descendant <Routes>. See this comment for an example of how this is to be done and for a potential workaround if you really need the old behavior.
match.pathname in a splat route now includes the portion of the pathname matched by the *. This makes the * param behave much more like other dynamic :id-style params.
Resolution of relative <Link>s in splat routes is changed now because the entire pathname that was matched by that route is now different (see previous bullet). Instead of resolving relative to the portion of the pathname before the *, paths resolve relative to the full pathname that was matched by the route.

💻 Installing
Development for v6 is chugging along on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next

6.0.0-beta.4 - 2021-09-11Last week we released a lot of nice little bug features, but we did get a little carried away and let a little bug slip through with relative path resolution. Our bad! That nasty lil' guy is squashed in this week's beta. 🐛
And there's more! Let's dive in…
🐛 Bugfixes

Path resolution for nested relative routes was broken in the last release and should now be fixed. Nested routes construct their pathname based on the location of their parent, not the current location. This is explained in detail under Relative Routes and Links in our advanced guides, and the issue itself in #8004

✨ Enhancements

We made some enhancements with the Params type which is now generic, so you can add your own types if you know what to expect from functions that return query parameters. (#8019)

// before
let { valid, invalid } = useParams(); // No problems here!
let match = useMatch("profile/:userId");
let userId = match?.params.user; // wrong param, but TS doesn't know that!
// after:
let { valid, invalid } = useParams<"valid" | "key">(); // Property 'invalid' does not exist on type 'Params<"valid" | "key">'
let match = useMatch<"userId">("profile/:userId");
let userId = match?.params.user; // Property 'user' does not exist on type 'Params<"userId">'

Absolute nested path support

There was quite a bit of discussion in #7335 from people who are using constants to define their route paths. In this style, paths are often written as absolute paths from the root / URL. These constants are then able to be used both in <Route path> definitions as well as <Link to> values. It usually looks something like this:
const USERS_PATH = "/users";
const USERS_INDEX_PATH = ${USERS_PATH}/;
const USER_PROFILE_PATH = ${USERS_PATH}/:id;
function UsersRoutes() {
return (
<Routes>
<Route path={USERS_PATH} element={<UsersLayout />}>
<Route path={USERS_INDEX_PATH} element={<UsersIndex />} />
<Route path={USER_PROFILE_PATH} element={<UserProfile />} />
</Route>
</Routes>
);
}
This style of use is now fully supported in v6. This is great for people who write their apps like this, but it technically could cause some breakage if you were using absolute paths (that start with /) in nested routes in previous betas. To fix this, simply remove the / from the beginning of any route paths that are meant to be relative. React Router will throw an error if you are using absolute paths that don't match their parent route paths. Hopefully this should help you find them if you are upgrading.
If you were using <Route path="/"> to indicate an index route, you can now use the new <Route index> prop to accomplish the same thing. The index prop makes it easy to scan a route config to find the index route. It also provides a guarantee that nobody will ever add children to that route.
Here's the same route config as the one above, but rewritten with relative paths and the index prop:
function UsersRoutes() {
  return (
    <Routes>
      <Route path="users" element={<UsersLayout />}>
        <Route index element={<UsersIndex />} />
        <Route path=":id" element={<UserProfile />} />
      </Route>
    </Routes>
  );
}
A lot of our work on React Router is about doing the least surprising thing for our users. Allowing absolute paths in nested routes gets us a little closer to that goal!
💔 Breaking Changes

Removed the ability for nested route paths to begin with a / and not contain the complete path of their parent routes. This was necessary in order to introduce support for absolute paths in nested routes, described in detail above

Removed the createRoutesFromArray utility function. You can now pass your routes directly to useRoutes or matchRoutes without passing it through createRoutesFromArray first

Removed the PartialRouteObject type. If you were importing and using this type before, use RouteObject instead, which has been updated to make all properties optional

The useRoutes API has changed slightly. Instead of passing a basename as the second argument, you should instead pass it as a named property in an object:

// Before
useRoutes([...routes], basename);
// After
useRoutes([...routes], { basename });

The matchPath function now returns match.pattern instead of match.path, which is a little more descriptive about what it actually is

💻 Installing
Development for v6 is chugging along on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next

6.0.0-beta.3 - 2021-09-03Loads of goodies for you this week, as well as a few breaking changes for all of you eager beavers who are brave enough to use beta software in production! 🦫
(seriously, thank you all for helping us tighten up our APIs and fix nasty bugs)
💔 Breaking Changes!

NavLink no longer supports the activeClassName or activeStyle props. Instead, we provide a more powerful API that allows you to pass functions to either the className or style props to conditionally apply values based on the link's active state. While a bit more verbose in some cases, this offers a nicer experience for folks who use utility class-based CSS. (#7194)

// Before
<NavLink className="link" activeClassName="active-link" />
<NavLink style={{ color: "blue" }} activeStyle={{ color: "green" }} />
// After
<NavLink
className={({ isActive }) =>
link ${       isActive         ? "active-link"         : // Couldn't do this before!           "inactive-link"     }
}
/>
<NavLink style={({ isActive }) => ({ color: isActive ? "green" : "blue" })} />

Note: You can always abstract over this feature in a custom NavLink if you prefer the old v5 API.

The useRoutes API has changed slightly. Instead of passing a basename as the second argument, you should instead pass it as a named property in an object:

// Before
useRoutes([...routes], basename);
// After
useRoutes([...routes], { basename });
🐛 Bugfixes

The basename prop on Routes is treated as case-insensitive (#7997)
useNavigate previously used the incorrect pathname when called from parent routes when the URL matches one of its children. This fix also applies to useSearchParams (#7880)

✨ Enhancements

Routes and useRoutes now allow you to override the location, which may be useful when building some modal interfaces and route transition animations. We are working hard to update our docs to include examples for advanced patterns where this might be useful, but in the mean time this also brings Routes closer to feature parity with v5's Switch via the location prop. (#7117)
Provided new hooks useClickHandler and usePressHandler to make customizing Links a bit easier. (#7998)

Please note: with great power comes great responsibility. If you create a custom Link, be sure to render an actual HTML anchor element, otherwise your app will likely be inaccessible without a significant amount of additional work which, I assure you, you don't want to do!

💻 Installing
Development for v6 is chugging along on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next
🙏 Credits
Thanks to @ andrelandgraf, @ dhulme, @ fgatti675, @ hugmanrique, @ MeiKatz, @ chaance and @ mjackson for your contributions!

6.0.0-beta.2 - 2021-08-20🐛 Bugfixes

Fixed a bug that broke paths in nested routes
Adds missing displayName back to <Link /> and <NavLink /> components

✨ Enhancements

The navigate function now prepends hash and search strings by default:
navigate({ search: "?foo=1&bar=2" }); // this works as expected!
navigate({ search: "foo=1&bar=2" }); // this also works!

useParams now returns parameters from nested <Route />s when called in a parent <Route />

💻 Installing
Development for v6 is chugging along on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next
🙏 Credits
Thanks to @ liho98, @ wojtekmaj, @ cravend, @ chaance and @ mjackson for your contributions!
Enjoy!

6.0.0-beta.1 - 2021-08-13

6.0.0-beta.0 - 2020-06-19

6.0.0-alpha.5 - 2020-05-15

6.0.0-alpha.4 - 2020-05-05

6.0.0-alpha.3 - 2020-04-04

6.0.0-alpha.2 - 2020-02-22

6.0.0-alpha.1 - 2020-02-01

6.0.0-alpha.0 - 2020-01-31

5.3.4 - 2022-10-02

5.3.3 - 2022-05-18

5.3.2 - 2022-05-17

5.3.1 - 2022-04-17

5.3.0 - 2021-09-03This release of react-router-dom adds support for passing a function to either the className or style props to conditionally apply values based on the link's active state.
This provides similar functionality as the existing activeClassName and activeStyle props, but is a bit more powerful. For example, you can now easily apply styles exclusively to an inactive NavLink as well. This offers a nicer experience for folks who use utility class-based CSS tools such as Tailwind.
function Comp() {
  return (
    <NavLink
      to="/"
      className={isActive =>
        `px-3 py-2 ${isActive ? 'text-gray-200' : 'text-gray-800'}`
      }
    >
      Home
    </NavLink>
  );
}
Note that as of v6.0.0-beta.3, the activeClassName and activeStyle props are removed completely. Adding support for functional className and style props to both v5 and v6 will give v5 users an easier upgrade path.
Thanks to @ tim-phillips for raising the issue that inspired the change! 🥳

5.2.1 - 2021-08-27This release fixes a bug with <Link> so that, when the to location is the same as the current, the history state entry is replaced instead of pushed to the stack. See #5362 for details. 🥳
Thanks to @ guidobouman for the PR and for everyone else who weighed in for the fix!

5.2.0 - 2020-05-11

5.1.2 - 2019-09-30

5.1.1 - 2019-09-27

5.1.0 - 2019-09-24

5.0.1 - 2019-06-04

5.0.0 - 2019-03-18

    from react-router-dom GitHub release notes

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Regular Expression Denial of Service (ReDoS)

🎉 Snyk hasn't found any issues so far.
✅ code/snyk check is completed. No issues were found. (View Details)


Rename io.druid to org.apache.druid.

Good luck reviewing this one.

@gianm any chance there's a way to get git to recognize these as renames instead of drops and adds?
As it stands, I don't think a merge from master would be tolerable for any outstanding PR as they would all just be klobbered

👍 after test, my browser crashes when loading pages...will have to trust @gianm on this one.

@drcrallen Git actually can figure out that these are renames, but you must change these configs first:
git config --local diff.renameLimit 5000
git config --local merge.renameLimit 5000

By default, git will disable rename detection if the number of files is >400 for diffs or >1000 for merges.

added labels for ReleaseNotes and Compatibility as this one will definitely break all extensions.
+1 after the successful build.

FYI, I put the steps I used here in the top comment. Parts (6) and (7) were just done now, I missed them in the first commit, and they resulted in some of the test failures.

Ah, @himanshug your comment makes me realize we should also update the migration code in MonitorsConfig. I'll do that now.

Added a fix for protobuf tests and re-pushed. The unit tests all pass on my machine, although I haven't tried the integration tests there. Will keep monitoring them in Travis.

ok here we go!

@gianm get's a major line count boost with this one :)

really good at writing import statements


Add maisi controlnet training

Fixes # .
Description
Add training script for MAISI ControlNet.
Checks

[ ] Avoid including large-size files in the PR.
[ ] Clean up long text outputs from code cells in the notebook.
[ ] For security purposes, please check the contents and remove any sensitive info such as user names and private key.
[ ] Ensure (1) hyperlinks and markdown anchors are working (2) use relative paths for tutorial repo files (3) put figure and graphs in the ./figure folder
[ ] Notebook runs automatically ./runner.sh -t <path to .ipynb file>

Hi @guopengf , can we have some doc-string added in the functions? Thanks!

Hi @guopengf , can we have some doc-string added in the functions? Thanks!

Hi @mingxin-zheng, thanks for the comments. I added docstring for util functions.

@KumoLiu I don't have any further comments except the ones above.

Hi @KumoLiu and @mingxin-zheng, thanks for the valuable comments! I addressed them in the latest commit. In addition, I moved utility functions used in the controlnet training script to scripts/utils.py since I found Can's PR has been merged.


Fix gpio samples

samples/basic/disco and samples/drivers/gpio were implemented with the assumption
one single GPIO controller was used for 2 different pins.
This is actually a particular case. Update the code to take into account the general case in which
different gpio controllers might have to be considered.
Additionally, simplify yaml filter for these samples

Codecov Report

Merging #12074 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #12074   +/-   ##
=======================================
  Coverage   48.05%   48.05%
=======================================
  Files         281      281
  Lines       43416    43416
  Branches    10406    10406
=======================================
  Hits        20864    20864
  Misses      18403    18403
  Partials     4149     4149

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 1870d99...6ba1acd. Read the comment docs.


Top_K_Frequent_Elements.cpp

This is my solution for the problem Top K Frequent Elements on Leetcode.

This one already exists. Still fine, I'm merging it


Qbe vendor

Fixes NULL
Description
Compiles QBE during Antimony build process and embeds it into the binary
Changes proposed in this pull request

QBE source is vendored in vendor/
Introduce cargo build script

ToDo

[ ] Proposed feature/fix is sufficiently tested
[ ] Proposed feature/fix is sufficiently documented
[ ] The "Unreleased" section in the changelog has been updated, if applicable

Closed, as this is a bad idea


[FR]:  Improve Ratio Support - Support Unlimited for Ratio or Time

Is your feature request related to a problem? Please elaborate.
currently if either ratio or time is -1 (unlimited) then no ratio is set
Describe the solution you'd like
-1 of ratio or -1 of time should only be unlimited for that specific goal not both
Does your solution involve any of the following?

[X] New config option
[X] New command option

Describe alternatives you've considered
work around by leaving the -1 value out of qbm config
Who will this benefit?
all users who wish to seed for X time regardless of rato
Additional Information
No response

this needs a new config option/command? Also would this be a bug rather than FR?

why would this need a new option or command?
Yes arguably a bug then.
From what I recall - setting -1 for ratio or time results in qbm setting no limit at all.
what should be expected is the limit is set for the non-unlimited attribute.

e.g. if ratio is unlimited, then set and enable time
e.g. if time is unlimited, then set and enable ratio
e.g. if time and ratio are unlimited, then set no ratio.


Adjust default number of threads for JobQueue:

The existing calculation would limit the maximum number of threads that would be created by default to at most 6; this may have been reasonable a few years ago, but given both the load on the network as of today and the increase in the number of CPU cores, the value
should be revisited.
This commit, if merged, changes the default calculation for nodes that are configured as large or huge to allow for up to twelve threads.

Looks good, though I think at some point in the future we should look at just defaulting to hardware_concurrency, or 1.5 * hardware_concurrency, or some such, instead of defaulting to 12 (or 6) when not specified in the config.

I think this merits further investigation, but feel that this approach is conservative enough to merit expedited approval. Thanks for the review.

Incorporated into #3981


Support for streamz.cc

Checklist

[x] I'm reporting a new site support request
[x] I've verified that I'm running youtube-dl version 2020.03.08
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that none of provided URLs violate any copyrights
[x] I've searched the bugtracker for similar site support requests including closed ones

Example URLs

Single video:
https://streamz.cc/y2924c8e964f9dcbbb6043b641815b378
https://streamz.cc/y831c3899c06115aab44d54ad6506ec68
https://streamz.cc/y0d4b33c22a81c6e7625c78b671a814df
https://streamz.cc/y25cf4192016a3a2f501d8f96ba2c0058

Description
Streamz.cc is a streaming provider.

This issue was originally at https://github.com/ytdl-org/youtube-dl/issues/24393 , but that link died. I've added 4 links here. Hopefully one or more will still be working by the time this is checked.

File not found, sorry!


Display status QUICKSTOP more clearly

Currently treated as not in OP which means some tiles are hatched, but generally not very clear what's happening.

Might be covered by #221 but need to review.


feat(CategoryTheory/Galois): definition and characterisation of Galois objects

Defines Galois objects in a Galois category in a fibre functor independent way, also gives an equivalent characterisation in terms of a fibre functor.
To allow for a definition that only depends on C, contrary to what was said earlier, we introduce a GaloisCategory typeclass extending PreGaloisCategory that additionally asserts the existence of a fibre functor.

[x] depends on: #10213

Thanks :tada:
bors merge

retrying
bors merge


Adds UI Elements Branding to UI

This PR depends on Branding Typography PR. Therefore, we should be reviewing only the last commit.
Regarding 2019-R6-CE's source{d}-branded superset UI EPIC, the next step was to move forward with our branding design document objectives: Main UI components and UI Interactive elements.
This PR addresses the two objectives above. Keep in mind that we're not able yet to fully control every single UI element/interactive, that being said this means that you might find some outlier elements on the UI that will be handled as soon as possible, and addressing your review on this PR as well.
We are aware that the outlier elements shouldn't block this PR to be merged. We're making the best possible effort to take care of the outliers, but they're not a blocker.
The UI Elements/Interactive that this PR addresses specifically are on:

SQL Lab (SQL Editor Main Interactive Elements, Secondary and Labels & Results Main, and Secondary Interactive Elements) ("Run Query", "Save Query", "Share Query", "Explore" and all the other interactive elements)
Dashboards (Main Interactive Element - "Actions" :hover & :focus is a known bug)
Dashboard (Main Interactive Element - "Edit Dashboard")
Chart (Main Interactive Elements, and Secondary - "Run Query" & "Save", and Chart's Interactive Elements "Rows" & "Cached" and all the other elements on the Action Bar"

Known issues: Please don't consider branding on UAST Lab Navbar, Run Parser, UI Elements
SQL Lab
Before:

After:

Dashboards
Before:

After:

Dashboard
Before:

After:

Chart
Before:

After:

@ricardobaeta I rebased this PR on top of https://github.com/src-d/sourced-ui/pull/139
Let me know if you're resuming the work over this branch, or if you need assistance to pull-push again over this branch :D

In which state is this PR @ricardobaeta?

@dpordomingo The state of this PR is what is explained in the description. We can merge this and continue to work on it, I believe.


Update MD file on new branch 2017-23-25_15-11-48

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestRef.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


feat(build): make npm run build work on Windows

Even if you might have GnuWin32 installed (and that is not mentioned), not all commands run successfully. E.g. cp ./{package.json,README.md,LICENSE} ./release fails.

LGTM


[HOLD for payment 2023-07-12] [$1000] Update to USD popup is not dismissed dynamically if currency is updated (connect bank account page is updated dynamically on change in currency)

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

Action Performed:

Open the app and login with user A (device 1)
Open the app in another device or incognito and login with user A (device 2)
Open settings-> workspaces->any specific workspace (select same on both) on both the devices
If in settings, currency is USD, change to any other currency using either of the device
Click on bank account in device 1 to trigger 'Update to USD' popup
From device 2, change currency to USD and observe that popup is not dismissed in device 1
Open bank account in device 1, click connect manually, fill in step 1 details (eg details: routing: 210021002, acc no: 1234) and click continue
From device 2, again change currency to any other except USD and observe in device 1 that it dynamically updates the screen to display the message

Expected Result:
App should dynamically dismiss popup 'Update to USD' if currency is updated to USD like it updates connect bank account pages dynamically
Actual Result:
App does not dynamically dismiss 'Update to USD' if currency is updated to USD
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

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

Version Number: 1.3.30-5
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/1f4bb0a6-2843-4725-a7a5-f5d174009c34
https://github.com/Expensify/App/assets/93399543/1eb8a275-45d1-4a3a-8dcd-8b0355d5a88b
Expensify/Expensify Issue URL:
Issue reported by: @dhanashree-sawant
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1687426441178099
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01a8436d652229e8bc
Upwork Job ID:<PHONE_NUMBER>658876416
Last Price Increase: 2023-06-26

Proposal
Please re-state the problem that we are trying to solve in this issue.
Update to USD popup is not dismissed dynamically if currency is updated (connect bank account page is updated dynamically on change in currency)
What is the root cause of that problem?
Currently, we don't watch the change for the policy.outputCurrency and not closing the CurrencyModal if the currency gets updated to USD in some other tab.
What changes do you think we should make in order to solve the problem?
We can create a useEffect hook where we can add policy.outputCurrency in the dependency and inside that we can validate if the CurrencyModal is opened and the new currenct is the USD then just close the opened CurrencyModal.
useEffect(() => {
        if(!isCurrencyModalOpen || policy.outputCurrency !== CONST.CURRENCY.USD) {
            return;
        }
        setIsCurrencyModalOpen(false);
    }, [policy.outputCurrency, isCurrencyModalOpen])

Proposal
Please re-state the problem that we are trying to solve in this issue.
Problem: The problem in this issue is that the "Update to USD" popup in the WorkspaceInitialPage component is not being dismissed automatically when the currency is updated to USD.
What is the root cause of that problem?
Root Cause: The root cause of this problem is that the isCurrencyModalOpen state is not being updated when the currency is changed to USD. As a ### result, the popup remains visible even after the currency has been successfully updated.
What changes do you think we should make in order to solve the problem?
Solution: To solve the problem, the following changes can be made:
Locate the confirmCurrencyChangeAndHideModal function in the code.
After successfully updating the workspace currency to USD, update the isCurrencyModalOpen state.
Ensure that the state update occurs within the callback function of setIsCurrencyModalOpen.
By updating the state, the component will re-render and the popup will be hidden.
What alternative solutions did you explore? (Optional)
Event-based approach to trigger an event whenever the currency is updated. This event can be listened to by the components that need to react to the currency change. When the event is triggered, the components can update their state and dismiss the popup if necessary.
Or Using a global state management library or pattern (such as Redux or Context API) to manage the currency state

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link:

Sorry, I should not have added the eng label until we choose a PR, removing @amyevans from this!

Thank you all for the proposals!
I'm inclined to control the value isCurrencyModalOpen to display the confirm modal instead of adding a condition. So @Pujan92 proposal looks good to me.
🎀 👀 🎀 C+ reviewed!

@Pujan92 Proposal looks good!

@mollfpr @Li357 PR is ready for review!

@mollfpr do we need a regression test for this?

[@mollfpr] The PR that introduced the bug has been identified. Link to the PR:
[@mollfpr] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:

I don't think this is a bug. Instead, it's an improvement where we can hide the modal if the policy currency is updated to USD.

[@mollfpr] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:

The regression step should be enough.

[@mollfpr] Determine if we should create a regression test for this bug.
[@mollfpr] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Login with two different devices
In device A, Goto Settings -> Workspace -> Select any workspace(where default currency is not USD) -> Bank Account
From other device B update the default currency to the USD for the same workspace
Verify device A's open update currency modal gets closed.
👍 or 👎

No regressions - ready for payment

Paid with 50% bonus (PR created June 29th and merged 30th)
Payment based on hiring here - https://github.com/Expensify/App/issues/21570#issuecomment-1611895388
Closed just on Upwork
Created regression test  https://github.com/Expensify/Expensify/issues/299830
Closing this GH


ZFULL Elif Karaarslan Leaks Video On Social Media X Twitter[2B75K]

Describe the bug
1 minute ago Elif Karaarslan, ZFULL Elif Karaarslan Leaks Video On Social Media X Twitter[2B75K]

Elif Karaarslan's latest video has taken social media by storm, captivating viewers and sparking widespread discussions. This young digital creator has garnered significant attention for her engaging content, particularly with her recent Spiderman-themed video that has gone viral. Fans are eagerly searching for where to watch the full video, turning to platforms like Instagram, X (formerly Twitter), and Discord for access.
As the buzz around Elif Karaarslan grows, fans are actively sharing their reactions online. The viral success of her video highlights the powerful role of social media in propelling creators into the spotlight. With her unique style and creativity, Elif has quickly become a notable figure in the digital landscape, leaving many eager to learn about her future projects and content.
Affected component/components
NOW VIDEO
How to reproduce

Codesandbox/StackBlitz link
code website
Logs
jhs wbsa

System Info
browser webs

Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues

cvbvcbvcb


Make SyncRuntime represent the execution lifetime

Motivation

In order to have application services to live longer than a single query, the SyncRuntime needs to be longer lived. However, SyncRuntime contains cyclic Arc references inside, which means that if it is dropped without clearing its internal loaded_applications field, it will leak memory. Therefore, there needs to be a safe way to let SyncRuntime to be used by other modules in a way that it can be dropped safely.
Proposal

Rename SyncRuntime into SyncRuntimeHandle, and create a new SyncRuntime wrapper type over the SyncRuntimeHandle. The new wrapper type represents the execution lifetime, and when it is dropped, it will clear the loaded_applications so that the internal SyncRuntimeHandle can be safely dropped without causing a memory leak.
Test Plan

A few unit tests were added to check if there aren't memory leaks.
Release Plan

This is an internal refactor, so nothing is needed.
Links

reviewer checklist

Should these references have been weak references instead?

Should these references have been weak references instead?

I think that would be possible, but then I think we should implement ContractRuntime and ServiceRuntime for something like Weak<SyncRuntime> instead. That's because the applications receive an impl {Contract,Service}Runtime, and they are the ones that hold the cyclic dependency. The disadvantage is the need to pay for an atomic check to see if the reference is valid on every system API call. What do you think?

Should these references have been weak references instead?

I think that would be possible, but then I think we'd have to implement ContractRuntime and ServiceRuntime for something like Weak<SyncRuntime> instead. That's because the applications receive an impl {Contract,Service}Runtime, and they are the ones that hold the cyclic dependency. The disadvantage is the need to pay for an atomic check to see if the reference is valid on every system API call. What do you think?

It looks like LoadedApplication::instance could have type Weak<Mutex<Instance>> so that loaded_applications doesn't retain the instances. Then, prepare_for_call would have to upgrade the Weak pointer into an Arc (and same on the service side with the other occurrence of application.instance in the file runtime.rs)


Adding CUDA SDK Toolkit ?

Hi,
Using  dizcza/docker-hashcat (latest tag), and starting hashcat -b, it outputs :
* Device #1: CUDA SDK Toolkit installation NOT detected.
             CUDA SDK Toolkit installation required for proper device support and utilization
             Falling back to OpenCL Runtime

While it's just a warning, it seems to have bad effects on performance/stability.
Could you kindly add CUDA SDK Toolkit installation  to the docker file?
Thanks!

Yeap. I was thinking of adding CUDA support. But I don't have a GPU anymore to test it.
Would you be willing to test the docker build? This will probably require changing the dockerfile once I push a draft - the way I think it should work - and building it manually if the installation fails.

Ok for testing! Let me know which docker I should load.
BTW CUDA is quicker than OpenCL according to the last version of hashcat.

Actually, this might be easier than I thought. I just replaced manual OpenCL driver installation instructions with
FROM nvidia/cuda:10.2-runtime-ubuntu18.04
as you can find in the "cuda" branch. Check it out and give me the feedback whether it works or not:
dizcza/docker-hashcat:cuda

Using dizcza/docker-hashcat:cuda :
$ hashcat -I
hashcat (v6.0.0-3-g53fb4050) starting...

clGetPlatformIDs(): CL_PLATFORM_NOT_FOUND_KHR

ATTENTION! No OpenCL-compatible or CUDA-compatible platform found.
You are probably missing the OpenCL or CUDA runtime installation.
* NVIDIA GPUs require this runtime and/or driver (both):
  "NVIDIA Driver" (440.64 or later)
  "CUDA Toolkit" (9.0 or later)

$ nvidia-smi
Fri Jun 19 18:05:31 2020
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 440.64.00    Driver Version: 440.64.00    CUDA Version: 10.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 108...  On   | 00000000:08:00.0 Off |                  N/A |
| 23%   56C    P8    10W / 125W |      1MiB / 11178MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

Damn. Nvidia team cannot even ship a proper docker image for their products - the same situation happened with their opencl docker image, as you mentioned in your one-year-old last issue.
Please do the steps described in this post. After you remove all cuda-related drivers, the official website proposes the next installation steps:
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/cuda-ubuntu1804.pin
sudo mv cuda-ubuntu1804.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget http://developer.download.nvidia.com/compute/cuda/11.0.1/local_installers/cuda-repo-ubuntu1804-11-0-local_11.0.1-450.36.06-1_amd64.deb
sudo dpkg -i cuda-repo-ubuntu1804-11-0-local_11.0.1-450.36.06-1_amd64.deb
sudo apt-key add /var/cuda-repo-ubuntu1804-11-0-local/7fa2af80.pub
sudo apt-get update
sudo apt-get -y install cuda

which you can easily find by following https://developer.nvidia.com/cuda-downloads.

I think your should load nvidia/cuda:10.2-devel-ubuntu18.04 instead of nvidia/cuda:10.2-runtime-ubuntu18.04
runtime docker does NOT include CUDA-toolkit, while devel does.
devel: Builds on the runtime and includes headers, development tools for building CUDA images
Then simply download hashcat:
$ hashcat -I
hashcat (v6.0.0-3-g53fb4050) starting...

clGetPlatformIDs(): CL_PLATFORM_NOT_FOUND_KHR

CUDA Info:
==========

CUDA.Version.: 11.0

Backend Device ID #1
  Name...........: GeForce GTX 1080 Ti
  Processor(s)...: 28
  Clock..........: 1582
  Memory.Total...: 11178 MB
  Memory.Free....: 11039 MB

$ hashcat -b -m 2500 -w 4
hashcat (v6.0.0-3-g53fb4050) starting in benchmark mode...

clGetPlatformIDs(): CL_PLATFORM_NOT_FOUND_KHR

CUDA API (CUDA 11.0)
====================
* Device #1: GeForce GTX 1080 Ti, 11039/11178 MB, 28MCU

Benchmark relevant options:
===========================
* --workload-profile=4
Hashmode: 2500 - WPA-EAPOL-PBKDF2 (Iterations: 4095)
Speed.#1.........:   639.5 kH/s (357.10ms) @ Accel:64 Loops:512 Thr:1024 Vec:1

Issue:
We notice the error CL_PLATFORM_NOT_FOUND_KHR. Maybe because OpenCL is not properly installed? clinfo returns 0 device, so it confirms OpenCL platforms is not installed.
I don't really know if OpenCL is mandatory when CUDA is here.

Side note , using dizcza/docker-hashcat:latest (=> using OpenCL only, no CUDA), performance on WPA (mode 2500) are lower:
$ hashcat -b -w4 -m2500
hashcat (v6.0.0) starting in benchmark mode...

* Device #1: CUDA SDK Toolkit installation NOT detected.
             CUDA SDK Toolkit installation required for proper device support and utilization
             Falling back to OpenCL Runtime

OpenCL API (OpenCL 1.2 CUDA 10.0.206) - Platform #1 [NVIDIA Corporation]
========================================================================
* Device #1: GeForce GTX 1080 Ti, 11008/11178 MB (2794 MB allocatable), 28MCU

Benchmark relevant options:
===========================
* --workload-profile=4

Hashmode: 2500 - WPA-EAPOL-PBKDF2 (Iterations: 4095)

Speed.#1.........:   578.0 kH/s (395.67ms) @ Accel:64 Loops:512 Thr:1024 Vec:1

Roughly +10% with CUDA.

Cool, thank you! Then I'll switch to devel, as you suggest.

I don't really know if OpenCL is mandatory when CUDA is here.

According to the description opencl is not mandatory if cuda is installed. Moreover, I get the impression that having cuda only is recommended if your device supports it because hashcat priorities cuda (if it's available) over opencl and thus installing opencl-related software will only contaminate your system unless you use them elsewhere.

runtime docker does NOT include CUDA-toolkit, while devel does

Hm, this is strange. Did I misinterpret their nvidia docker description...

runtime: Builds on the base and includes the CUDA math libraries, and NCCL. A runtime image that also includes cuDNN is available.
devel: Builds on the runtime and includes headers, development tools for building CUDA images.

I guess the warning "clGetPlatformIDs(): CL_PLATFORM_NOT_FOUND_KHR" tells not only that ocl-icd-libopencl1 (requires by clinfo) is missing system-wide but also that hashcat does not see anything in /etc/OpenCL/vendors/ folder. I think this warning can be ignored.

Here is what I did:

nvidia/cuda:10.2-devel-ubuntu18.04 for the cuda tag.
latest = cuda + opencl, meaning that apart from nvidia/cuda:10.2-devel-ubuntu18.04 I kept opencl-related installation.

I'd be nice if you try :latest tag (update it beforehand) and give me the feedback if it works for you. It should also get rid of the warning you see with cuda-only backend.

Something strange has changed here, I've been unable to load the :latest tag with Vast.ai sessions, :pocl loads correctly and I can drop in to an attached shell, but neither :latest nor :cuda seem to start and run correctly.

Thank you for letting me know.
Do you have Nvidia GPU, @msoose ?
If yes, it'd be helpful if you test the alternative installation steps as I described here.
For now, I'll revert the changes to :latest and keep :cuda untouched until the issue is resolved.

Using cuda tag (from nvidia/cuda:10.2-devel-ubuntu18.04) : works awesome!
And weird thing : it has nvidia version 450 + CUDA 11.0 - not consistent with the name.. don't know why!
$ nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 450.36.06    Driver Version: 450.36.06    CUDA Version: 11.0     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+=============

$ hashcat -I
hashcat (v6.0.0-4-g5628317d) starting...

clGetPlatformIDs(): CL_PLATFORM_NOT_FOUND_KHR

CUDA Info:
==========

CUDA.Version.: 11.0

Backend Device ID #1
  Name...........: GeForce GTX 1080 Ti
  Processor(s)...: 28
  Clock..........: 1632
  Memory.Total...: 11178 MB
  Memory.Free....: 11039 MB

$ hashcat -b -m2500 -w4
...
Hashmode: 2500 - WPA-EAPOL-PBKDF2 (Iterations: 4095)
Speed.#1.........:   651.1 kH/s (351.21ms) @ Accel:64 Loops:512 Thr:1024 Vec:1

As expected, CUDA 11.0 speed for this mode is +13% :)
@msoose : don't need OpenCL anymore, and this the cuda tag works ok on Vastai as well.

@adrastee Great, thanks for the update, just confirmed :cuda tag does work correctly on Vast instances. Excellent.

Could then anyone test :opencl-cuda tag? I put OpenCL + CUDA back again in a separate branch:
docker pull dizcza/docker-hashcat:opencl-cuda
What's the output of hashcat -I?

@dizcza :opencl-cuda also works.
hashcat -I with some snipping out of unwanted information:

CUDA Info:
==========

CUDA.Version.: 10.2

OpenCL Info:
============

OpenCL Platform ID #1
  Vendor..: NVIDIA Corporation
  Name....: NVIDIA CUDA
  Version.: OpenCL 1.2 CUDA 10.2.131
    Version........: OpenCL 1.2 CUDA
    OpenCL.Version.: OpenCL C 1.2
    Driver.Version.: 440.59

All right, thank you. I reverted the changes so that latest = cuda + opencl again. I hope that the previous fail was a mere coincidence.
Talking about speed, you might squeeze an extra few percent out of your gpu capabilities if you run the computation not in a docker container. That very much depends on what you're doing on top of this image. If you're into dockering and use it primarily for wpa hashes, take a look at a repo of mine: https://github.com/dizcza/hashcat-wpa-server.
Feel free to post here cuda-related issues, if you encounter any.

Hi again,
Using dizcza/docker-hashcat:cuda on latest 3090 GPUs, I got the error hashcat nvrtcCompileProgram(): NVRTC_ERROR_INVALID_OPTION
It works great with docker image nvidia/cuda:11.1-devel-ubuntu18.04
Maybe you can FROM this one?
Best.

Hi again,
Using dizcza/docker-hashcat:cuda on latest 3090 GPUs, I got the error hashcat nvrtcCompileProgram(): NVRTC_ERROR_INVALID_OPTION
It works great with docker image nvidia/cuda:11.1-devel-ubuntu18.04
Maybe you can FROM this one?
Best.

Thanks for the heads-up!
I've pushed CUDA 11.1 devel into the cuda branch and left 10.2 in the master.
I'll keep cuda branch as experimental and master with CUDA latest_major_version-1.
Feel welcome to post here next time the 11.1 doesn't work to bump up the version again, as I'm not using it anyway and cannot capture outdated software errors.

Thanks for the heads-up!
I've pushed CUDA 11.1 devel into the cuda branch and left 10.2 in the master.
I'll keep cuda branch as experimental and master with CUDA latest_major_version-1.
Feel welcome to post here next time the 11.1 doesn't work to bump up the version again, as I'm not using it anyway and cannot capture outdated software errors.

I am getting an error:
nvrtcCompileProgram(): NVRTC_ERROR_INVALID_OPTION
nvrtc: error: invalid value for --gpu-architecture (-arch)

Device #1: Kernel /usr/local/share/hashcat/OpenCL/shared.cl build failed.

Device #1: Kernel /usr/local/share/hashcat/OpenCL/shared.cl build failed.

This happened on many hosts that I have tried the container on.
I will try dizcza/docker-hashcat:nvidia-full next

I am wondering if this was a driver issue? It was running on a remote RTX 3060 when the issue happened, and when I used :cuda on a 2x RTX 3080 remote host it was able to start the benchmark successfully. Tonight I can do a direct A/B, I didn’t have time last night. Is there a configuration you think I should look at?

Ah, so it's the opposite: your card is one of the newest.
Let's settle it down.
It should be a CUDA incompatibility issue (not Nvidia driver).
nvidia-full tag is obsolete, outdated, and is about to be removed. It was built at the time when HashCat had no CUDA support whatsoever.
Which tag triggers the error you described - latest or cuda? Try running both. If cuda runs and latest fails, CUDA 11 must be used. If latest runs and cuda fails, CUDA 10 must be used.
If none of the tags works, you can change the base image, the CUDA version, at the first line of the Dockerfile. The valid cuda images can be found on nvidia hub docker.

@dizcza Would you consider building an arm64 version of the image? I'm trying to run this on an Nvidia Jetson Nano

@lawndoc well yes, if you test it - I don't have any arm64 hardware to test.
Let me have a look.

I should be able to test it, but I might need a bit to figure out how to upgrade the cuda version on the jetson. I tried building locally and when I run I get an error that says it's not detecting 11.8 (though I did install it). I am using an older version of Jetpack that might not work nicely with newer cuda versions, so I'm going to start with reflashing Jetson OS and starting with the newest Jetpack.


corrects word usage

@kyleburnsdev : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Typo fix looks good; thanks.


Updating Git from msysgit to Git 2.21.x

I noticed in #189 that there's an issue updating past git 1.9.5. Has anyone attempted to update to 2.x (or 2.21.x)?

How can i update Git 2.25.1 for my git server. If i use version 1.95 but client use lastet version may be it run normally?

Apparently it needs some work on Bonobo to be able to update all the parts which connect with Git, but I don't think you'll have any difficulty with the current version and client compatibility.  I haven't seen anything, anyway.

I have create a new bonobo git server with git version 2.25.2. Let me test sometime. Thanks for respond


CV #453 refactored build and push scripts for vpp binaries

Coverage increased (+0.06%) to 77.209% when pulling 51abc8f68973c5b7382cfc762bdd653b17be5754 on amarcine:master into 6461e4386b8dd362adb85009a6ca896701b7068a on contiv:master.


fix(dialog): broader types for options list

Adding broader types for optionsList.

@benbrown Sorry I know I opened this PR before but after using it a bit more I found more use cases.

Just Note here that after testing different edge cases - I purposely left out boolean type. Slack will fail with a validation error if you use a boolean type inside of the value (default value)

@benbrown
Sorry for the delay on this. I just updated the branch. Do you mind merging this in? 😄


Secondary variants break consumable configuration with no artifacts

Current Behavior
Adding a secondary variant to a consumable configuration with no artifacts makes the main variant not resolvable.
Expected Behavior
Adding a secondary variant to a consumable configuration with no artifacts does not exclude the main variant from resolution.
Context (optional)
In some cases, artifacts are added to the consumable configurations based on some user configuration. That's the case for KGP. We have a consumable configuration with the output of the cinterop tool. This configuration is created for Kotlin/Native targets and contains artifacts only if a user declares cinterop definitions.
Steps to Reproduce
https://github.com/ALikhachev/gradle-reproducers/tree/main/secondary-variants-bug
Gradle version
8.8
Build scan URL (optional)
No response
Your Environment (optional)
No response

This issue is confirmed and work on a fix is in progress.


db:seed --files=f.js not working

When I run ./ace db:seed --files=prod.js runs all seeds in /database/seeds/, but need only prod.js

Fixed same in this commit. You can install from github or wait till weekend when I will release it

Closing since fixed and will release soon


[Fixes #15106] Document how to properly handle modals with dynamic height

Fixes #15106 — Document how to properly handle modals with dynamic content height
X-Ref: #15881 — Fix backdrop not readjusting when height changes

Works for me.

See my comment here for clarification: https://github.com/twbs/bootstrap/pull/15881#issuecomment-75883495

But documenting it is a good idea, just need to change the text to reflect the new behavior.

Updated verbiage based on @hnrch02's comments.


INTL0002 should ignore generated code.

Fixes #40

This is great, but can we get one more unit test where the GeneratedCodeAttribute is on the class rather than the property?

Thanks for pointing that out.
Updated the tests.

Great job. Thanks for the contribution.


Empty duplicate branch entries in config

I have Git 2.3.3 and a Git repo. I have to migrate to another server for push and pull. I do:
git remote remove origin; git remote add origin new_repo; git push; git branch --set-upstream-to=origin/master
Now I get in my .git/config:
[core]
...
[branch "master"]
[remote "origin"]
    url = new_repo
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master

The case is the first line [branch "master"] is left from the old upstream. It's empty (when I remove the old origin, its' contents are removed), but it's still in the config file and that's not necessary.
My suggestion that Git should either:

When removing an entry from the config file it should remove the config section, if it's empty
When appending to a config file, it should search for a matching section, it should append to it, not leaving it blank and writing a duplicate one.

Hey, this is the issue tracker for the git-scm.com website, not Git itself. If this issue is still relevant and you still want to discuss it, you should reach out to the community.


Add [ODFC] On Demand Fuel Cells from Kerbal Stuff

This pull request was automatically generated by Kerbal Stuff on behalf of Orum, to add [ODFC] On Demand Fuel Cells to CKAN.
Please direct questions about this pull request to Orum.

Closing in favour of hand-written one


Flexible Pricing: Allow courseware object to be assigned to Flexible Pricing Request Forms

As an administrator, I'd like to be able to explicitly set what courseware object a Flexible Pricing form applies to.
Learners request Flexible Pricing through a custom form page that can be configured through the Wagtail CMS system. Each Flexible Pricing request needs to be tied to the courseware object that it's for (either a course or a program), and this is done currently through the page hierarchy: the form itself is created as a child page for a course, and the code determines what the parent page is and grabs its course when a learner submits a request.
We'd like to replace that functionality with a dropdown in the form itself that allows the form to be explicitly linked to a courseware object. The parent page code works well for requesting flexible pricing for standalone courses but (at least for now) programs won't have a marketing page so there won't be a way in the CMS to do the same for programs. So, the easiest thing to do is to just have a dropdown in the editor in the CMS that allows the admin or whoever to select the course or program that requests should be for.
There is some prior art for this in the CoursePage model in the cms app - course pages have a dropdown for the course they belong to. We should do something similar here but it should also incorporate available programs. (My suggestion would be to have this be a single dropdown with the courses and programs separated into groups but there's a few ways this can be done.) Additionally, cms.models.FlexiblePricingRequestForm doesn't have a FK to a courseware object at all - there's a class method in there to work it out based on ownership - so one will need to be added; this should ideally be a generic relationship, which we do in a number of other spots (like in flexiblepricing.models.FlexiblePrice).
Acceptance Criteria:

[ ] The Flexible Pricing Request Form form in Wagtail should have a dropdown to choose a specific program or course that requests should be tied to.
[ ] Flexible Pricing Request Forms should only be tied to either a course or a program. (A relation will need to be added for this.)
[ ] Existing Flexible Price requests should be ignored. (Flexible Pricing isn't live yet so data that does exist on RC or in local instances can just be cleared for this.)

Which form is this? Are you saying we need a program version of, for example, https://rc.mitxonline.mit.edu/cms/pages/22/edit/ ?

Yes and no - yes, it's that form, but no not a totally separate version of it. We should be able to just add a dropdown to select what courseware object it belongs to rather than have that be determined by where it is in the CMS's page hierarchy.

I just saw in standup notes that @jkachel is about to work on this one, so, unassigned myself.


How to get started with manipulator control.

I have been using Mujoco for some weeks now. I found that dm_control has a simple Ik function and the mjcf module and I want to try those.
I created an environment where I can control a robot joint using keyboard and the passive viewer for convenience.
Is there a way to achieve a similar setup using the dm_control bindings?
I figured out that you need to define an environment in order to launch the viewer? Is there a simpler way?
If not, can you point me to the direction in which I should follow to be able to control a manipulator and use the ik function?
For reference, here is my code in mujoco, I basically want to achieve the same thing with dm_control:
import mujoco
import numpy as np
from math import pi
from mujoco import viewer

# Load model and initialize data
xml = "universal_robots_ur5e/scene.xml"  # Change to your model's path
model = mujoco.MjModel.from_xml_path(xml)
data = mujoco.MjData(model)
init_q = [-pi/2, 0.0, 0.0, 0.0, 0.0, 0.0]
data.qpos = init_q
mujoco.mj_forward(model, data)

# Define variables
goal = np.array([0.1, 0.1, 0.3])
step_size = 0.5
tol = 0.001
damping = 0.15

# Marker setup
marker_id = 0  # Assuming the first mocap is the marker
data.mocap_pos[marker_id] = goal  # Initialize marker position
mujoco.mj_forward(model, data)
paused = False

def key_callback(keycode):
    print(f"Char: {chr(keycode)} - keycode: {keycode}")
    increment = 0.025
    print(f"Current goal: {goal}")
    if chr(keycode) == ' ':
      paused = not paused
    elif keycode == 265:
        # x up
        print(f"{goal[0]}->{goal[0] + increment}")
        goal[0] = goal[0] + increment
    elif keycode == 264:
        # x down
        goal[0] = goal[0] - increment
    elif keycode == 263:
        # y up
        goal[1] = goal[1] + increment
    elif keycode == 262:
        # y down
        goal[1] = goal[1] - increment
    elif keycode == 266:
        # z up page up
        goal[2] = goal[2] + increment
    elif keycode == 267:
        # z down pagedown
        goal[2] = goal[2] - increment
    print(f"New goal = {goal}")
    data.mocap_pos[marker_id] = goal
    mujoco.mj_forward(model, data)

# Function to calculate inverse kinematics (IK)
def calculate_ik(goal, step_size, tol, damping):
    jacp = np.zeros((3, model.nv))
    error = np.subtract(goal, data.body("link_6").xpos)

    while np.linalg.norm(error) >= tol:
        mujoco.mj_jac(model, data, jacp, np.zeros((3, model.nv)), goal, data.body("link_6").id)
        I = np.identity(model.nv)
        j_inv = np.linalg.pinv(jacp.T @ jacp + damping * I) @ jacp.T
        delta_q = j_inv @ error

        # Update joint positions
        data.qpos += step_size * delta_q
        mujoco.mj_step(model, data)
        error = np.subtract(goal, data.body("link_6").xpos)

def check_joint_limits(q):
    """Check if the joints is under or above its limits"""
    for i in range(len(q)):
        q[i] = max(model.jnt_range[i][0], min(q[i], model.jnt_range[i][1]))

jacp = np.zeros((3, model.nv)) #translation jacobian
jacr = np.zeros((3, model.nv)) #rotational jacobian
step_size = 1
tol = 1e-14
alpha = 0.5
damping = 0.15

#Get error.
end_effector_id = model.body('wrist_3_link').id #"End-effector we wish to control.
current_pose = data.body(end_effector_id).xpos #Current pose
error = np.subtract(goal, current_pose) #Init Error

# Initialize viewer
with mujoco.viewer.launch_passive(model, data, key_callback=key_callback) as viewer:

    # Main rendering and simulation loop
    try:
        while viewer.is_running():
            with viewer.lock():
                viewer.opt.flags[mujoco.mjtVisFlag.mjVIS_JOINT] = True
                viewer.opt.flags[mujoco.mjtFrame.mjFRAME_GEOM] = True

            if (np.linalg.norm(error) >= tol):
                mujoco.mj_jac(model, data, jacp, jacr, goal, end_effector_id)
                #Calculate delta of joint q
                n = jacp.shape[1]
                I = np.identity(n)
                product = jacp.T @ jacp + damping * I

                if np.isclose(np.linalg.det(product), 0):
                    j_inv = np.linalg.pinv(product) @ jacp.T
                else:
                    j_inv = np.linalg.inv(product) @ jacp.T

                delta_q = j_inv @ error

                #Compute next step
                q = data.qpos.copy()
                q += step_size * delta_q

                #Check limits
                check_joint_limits(data.qpos)
                # print(error)
                #Set control signal
                data.ctrl = q
                print(q)
                mujoco.mj_forward(model, data)
                #Step the simulation.
                mujoco.mj_step(model, data)
                # error = np.subtract(goal, data.body(end_effector_id).xpos)
            error = np.subtract(goal, data.body(end_effector_id).xpos)
            viewer.sync()
    finally:
        viewer.close()

EDIT (29/11/2024):
I found this repo from @kevinzakka  that does what I aimed but better than the code above using mujoco API. Still I would like to achieve similar things using dm_control bidings, is this possible?

Why do you want to use dm_control rather than native MuJoCo?

@yuvaltassa
Thanks for the response. Indeed I was thinking about this after I created this issue.
The biggest plus for my use case is the MJCF module that allows to create dynamic scenes. I did not experiment with manipualtors yet, but I want to create obstacles in random positions, for example, that would be useful.

@yuvaltassa Thank you very much!
I was not aware that native mujoco had this feature! I will check it soon!


setOptOut clears dispatecher each time the method is invoked

Hi,
each time setOptOut method is invoked the dispatcher queue is cleared.
    /**
     * Use this to disable this Tracker, e.g. if the user opted out of tracking.
     * The Tracker will persist the choice and remain disable on next instance creation.<p>
     *
     * @param optOut true to disable reporting
     */
    public void setOptOut(boolean optOut) {
        mOptOut = optOut;
        getPreferences().edit().putBoolean(PREF_KEY_TRACKER_OPTOUT, optOut).apply();
        mDispatcher.clear();
    }

When app has switch that enable / disable event tracking we can loose events history. Example scenario:

App collected many events during last 1 minute.
Uses goes to settings.
User disables tracking. setOptOut is invoked. Dispatcher is cleared.
User enables tracking. setOptOut is invoked. Dispatcher is cleared.
User disables tracking. setOptOut is invoked. Dispatcher is cleared.
User enables tracking. setOptOut is invoked. Dispatcher is cleared.
No events to dispatch.

In that case user still allows tracking but we lost all collected events.
I think it should work this way:

App collected many events during last 1 minute.
Uses goes to settings.
User disables tracking. setOptOut is invoked. Events collecting is disabled. Next event will not be collected.
User enables tracking. setOptOut is invoked.  Events collecting is enabled. Next event will be collected.
User disables tracking. setOptOut is invoked.  Events collecting is disabled. Next event will not be collected.
User enables tracking. setOptOut is invoked.  Events collecting is enabled. Next event will be collected.
All collected events when user allowed to be tracked are dispatched.

I think this is the way iOS SDK works at the moment.

It's a bigger question.
When the user disable tracking, does this mean from now on, or all past and from now on.
And what's past ? Just local, non-sent, or even the ones on backend ?
I can't answer it, I just have the power to merge pull requests.


Added instrument_type attribute

There is now an instrument_type global attribute reflecting the instrument type from definitions.py
If there are multiple instruments in the file, they are separated by a "/" (i.e., GCMD/GCMS-Medusa")

Looks good to me


Improve files ignore for git and Docker

Ignoring files that won't be used on git is a safety measure for contributions.
For Docker this helps on the build time, as every time a docker image gets built, it requires the context. Filetring out files prevents this and uninteded secret exposure.
Motivation

Specifications

Designs

Solution

Review

Reviewer Checklist

[ ] Code implements Specs and Designs
[ ] Tests for Expected Behaviour
[ ] Tests for Errors

Follow Up Work

@gustavovalverde is this a duplicate of PR #3399?

@teor2345 I was going to do most things in this single PR, but I decided not to. I forgot to close this one.


add provider targeted images

This should now be supported by the introduction of docker bake. Some features of this PR might however still be missing. Closing for now.


add a PaintBrush type

I'm reminded by #523 of something we'd talked about a little while ago, and might as well have an issue for. There is currently a PaintBrush type in piet, which is a way of representing disparate different things that act like colors; the idea is that we can treat colors or gradients equivalently for the sake of our API.
@futurepaul brought up a good point, which is that it would be nice if we could treat env/theme keys as colors, where appropriate, so that you could write,
let my_widget = TextBox::raw().padding(5.0).background(theme::BACKGROUND_LIGHT);

And then have your color be determined by the value of that key at runtime.
I think we can do this, and I think it's pretty simple. I propose that we add a type to druid, also called PaintBrush, which should look like this:
pub enum PaintBrush {
    Concrete(piet::PaintBrush),
    Key(Key<Color>),
    // other variants possible
}

And then we should be able to take one of these types, pass it an Env, and get something we can actually paint, like:
impl PaintBrush {
    fn resolve(&self, env: &Env) -> piet::PaintBrush { ... }
}

The idea is that a method like Container::background would take as its argument impl Into<PaintBrush>, and so you could then pass it either an actual color/gradient or a key that could be resolved to a color/gradient at runtime.
This isn't too tricky, but it does require some understanding of the type system and of how Env works, but not much more than that.

I have this working for Key<Color>, having a lifetime issue with Key<LinearGradient>

push a branch and we can take a look?

With #592 merged, is this still relevant? KeyOrValue is ubiquitous in the codebase now.


added custom directory (#1)

Hi, with this PR I am submitting possible fix for #4 I opened. You need to check this code first though, since I'm not quite familiar on js and developing github actions.

I'll check this out later. Thank you for your report and patience. 😄

I've been successful with the new feature. You can check it out at zgosalvez/github-actions-flutter-workflows#22.
Please test it yourself then let me know if it also works for you. Simply change the YAML file to uses: zgosalvez/github-actions-report-lcov@test-pr-5

I've been successful with the new feature. You can check it out at zgosalvez/github-actions-flutter-workflows#22.
Please test it yourself then let me know if it also works for you. Simply change the YAML file to uses: zgosalvez/github-actions-report-lcov@test-pr-5

Hi. thanks for the update. I've been successful with the new feature as well.


Configure jvmToolchain for Android and Kotlin projects

There was only a single Kotlin JVM project, so I did not create a dedicated convention plugin for that.
But this can be done if needed.
References #571

Hey @borisf, would you mind checking this out?


Show information of all dependencies

It would be nice to have an option to recursively query information of all dependent crates.
Imagine I want to ship a binary, and would like to include the license / copyright of all crates that the binary uses. Ideally, I should be able to just do cargo info --license --all and that should output it to the screen.
Another user would be crates.io itself. Lot's of crates say they have the Apache license, but then rely on dependencies with licenses that I bet nobody has checked, or that might change between releases.
I would like crates.io to tell me that a package has the Apache license, and that all its dependencies have so as well, so that I know that by using it I wouldn't be pulling in any crate with an incompatible license.
This would make it much easier to use Rust / cargo in companies that ship software.

I've started on something to this effect. I tailor-made it to my present use-case, but it might be reusable or extendible beyond that. In case it is of interest: https://github.com/maghoff/cargo-license-hound

I couldn't get cargo-license-hound to work on my mac, so I wrote this, which just uses cargo metadata and github to get the actual license text and print it.
https://bochs.info/p/nhgj9h

We offer cargo metadata to get a certain form of dependency information.  We lack the more particulars of platform/build-target/feature combinations but have issues on those.
cargo info is being tracked in #948.  Doing all of the licensing work for you is unlikely to happen though.
Some existing tools that resolve the licensing workflows

https://github.com/EmbarkStudios/cargo-deny can help with license verification
https://github.com/EmbarkStudios/cargo-about can help with generating notices

As this issue seems to be focused on the querying of dependencies and that is offered, I'm going to go ahead and close this.  If there is interest in resolving specific use cases (generating notices, license verification), I'd recommend creating dedicated issues.


Swapped RUNE for ETH, RUNE decrimented but never received ETH

Prerequisites

[ ] Using yarn
[ ] Using node 12.x
[ ] Using the latest release or an up-to-date master branch
[ ] Link to stacktrace in a Gist (for bugs)

Expected Behavior
 Transaction should complete correctly for swapped Coins

Current Behavior
  I swapped 448 RUNE for 1.97463114 ETH.  The 448 RUNE were deducted from my Wallet.  But, the 1.97463114 were never credited to my Wallet.

Possible Solution
 Unknown

Steps to Reproduce (for bugs)

Context
 I am unable to swap my ETH because I haven't yet received it.
 N/A
 N/A
Your Environment

Node version :
Version or Branch used :
Operating System and version : ASGARDEX App, Version 0.2.1
Link to your project :

@BoWilly If possible, could you share your wallet addresses for RUNE + ETH, pls?

ETH: 0x3670f12cf805e8b05c13e2fd22f3a0632706d7c1
RUNE: thor1jqr29uqn9sjmmeue56kwmtnmjgqfa2n4ry4jw8
Transaction: 3FE97CC9EA2A7BF01D345B3B9968804C328C1EB1150CF9AE9D1FF7CE645A5362

Transaction ID In (RUNE): 3FE97CC9EA2A7BF01D345B3B9968804C328C1EB1150CF9AE9D1FF7CE645A5362
Transaction IF Out (ETH): 69079E5AB7BDF2D86E0B04E8432D4093736744E5F1946CE1813C13D6941947F3
The RUNE was deducted, but the ETH was not credited to my wallet.

@BoWilly Thanks for providing more data, I'm going to reach out to the team to get more information what might happened here ^

@BoWilly Your outgoing swap tx was successful https://etherscan.io/tx/0x69079e5ab7bdf2d86e0b04e8432d4093736744e5f1946ce1813c13d6941947f3 and it's in already in your wallet. To see outgoing amount of ETH at Etherscan, check https://etherscan.io/address/0x3670f12cf805e8b05c13e2fd22f3a0632706d7c1#internaltx
There is currently a bug in a depending library (xchain-js) used by ASGARDEX desktop, which does not return internal txs (a outgoing swap tx is such internal tx). That's why this tx is not visible in tx history of ASGARDEX desktop (similar to #1350).

History for ETH balances will be fixed by https://github.com/thorchain/asgardex-electron/issues/1465
Closing this issue here for now... If you have still issues / questions, feel free to re-open it again or create another issue. Thx!

@BoWilly
"The RUNE was deducted, but the ETH was not credited to my wallet."
Same happened to me but with BTC, not quite sure what is going on ... are we waiting for the ETH people to fix the bug ?
Did you see your ETH yet ?

I still can't see the ETH in my wallet yet.
Here is a comment on another thread: Currently xchain-ethereum does not support internal txs for balances, it needs to fixed there first to bring it into ASGDX.
But, I'm not sure how long it will take to resolve or who is working on this issue.
Combined thread:
https://github.com/thorchain/asgardex-electron/issues/1465#

OK ty. Just hodl on then :)

My issue has now been resolved and I can see the ETH in my wallet. - #1462
Thanks for the help!

Just got in to find mine there too, hooray for the fixers :)


Fix personinfo autoupdate

Made a couple changes:
Resolves #128, #141, #127.

Made a home panel
Made side panel default to home panel when displayed person no longer exists
Fixed some bugs regarding edit command
Made UI cosmetic changes

LGTM from Chao Yung and Shi Jun.


Support multiple HTTP inputs

Required for all non-trivial PRs

[x] Rebased/mergable
[x] Tests pass
[x] CHANGELOG.md updated
[x] Sign CLA (if not already signed)

Adds support for multiple HTTP listeners. This is the last issue to completely fix https://github.com/influxdata/influxdb/issues/2785.

Looks like AppVeyor failed on an influx_stress test.

LGTM 👍

This is looks like a breaking change to the config file.  Are there any other inputs that are limited to only one?
It would be nice to not have the config break.  Can we keep the existing HTTP config option and add it to the slice for backwards compatibility?

@jwilder I'm planning to open another PR to do exactly that for all the listeners but haven't finished yet.

@gunnaraasen What happens when you use an old config that still uses [http] and not [[http]]?

This needs to be updated to support [http] and log a deprecation warning similar to how we handled [collectd] and [opentsdb].  See: https://github.com/influxdata/influxdb/blob/master/cmd/influxd/run/config.go#L133

What's the rationale behind this change? Unlike the other configuration changes, I don't see much value to multiple HTTP listeners. There are some downsides though with the naming behind the environment variable overrides and the configuration file change. If someone needs multiple HTTP listeners, what can we do better that Nginx can't do? Otherwise, I think we should just advise people to install a proper web server without risking the breaking change.

I agree w/ @jsternberg.  I don't see the benefit of supporting this.

Mainly, the benefit would be the ability to set up an unauthenticated localhost listener for administrative access. It would also make this service consistent with the Graphite, OpenTSDB, UDP, and CollectD services.
I'm going to close this since it's a large change not necessary for 1.0.


"Auto-generate" import templates

Add SemTK functionality to greatly improve the speed at which ingestion templates can be generated.

given a nodegroup with returns, generate a "round-trip" ingestion template.   As if the query had been run, returned data, and the columns were mapped to the data properties that created them.

begin iterating on an import mapping wizard that would perform functions  such as "for each class with only one data property mapped, look up the class using that property and set mode to CREATE_IF_MISSING"

consider common transforms (null to "") and  wizard to apply to all, etc.

I built a jar-with-dependencies and hosted it in this
box folder
so that Dan could use it as he modified the ontology.  Others may also try it if needed.
Again, it is kept in a private location until we get word on the disclosure.

I built a jar-with-dependencies and hosted it in this
box folder
so that Dan could use it as he modified the ontology.  Others may also try it if needed.
Again, it is kept in a private location until we get word on the disclosure.


[BUG]: Media Sync API key

Describe the bug
Trying to set up media syncing and don't know what the some-api-token is.  I've tried the Sonarr or Radarr API key, but it returns a HTTP request failed, which makes sense because I would assume it would be looking for a Midarr API key.
To Reproduce
Steps to reproduce the behavior:

Create webhook in Sonarr or Radarr
Copy webhook URL into the URL of the webhook setup.
Don't know what to put in for the some-api-token.

Expected behavior
I would expect something in the Midarr web interface or the docker logs displaying my API key, or documentation pointing me to where I can find it.  If it is available and I didn't find it, I apologize, but I did a search through the repo
Desktop (please complete the following information):

OS: Running it in docker on Synology
Browser: Edge
Midarr Version 4.10

ghcr.io/midarrlabs/midarr-server:v4.1.2
Hi, thank you for opening this issue. Yes sorry about that, you're correct. There was no display of the api token in Midarr itself. The only way to access it was through the database.
I've pushed a new release that adds an API Token field to the Settings page. Please use the new image above 😄

Great, thanks! I did pull the new image and recreated the container.  I did get an Internal Server error the first time, but destroyed the container and recreated it and then I was able to login and view the API field in the settings.
The field in the settings is editable.  If you change the key, does that actually change the API key, or will editing it screw something up?

No worries! The field is editable but any changes to the api token won’t persist.
I’ll make some improvements over the next few releases so it’s not editable as well.


Use newer version of SDL for better Wayland support

There has been a bunch of work in SDL lately to improve Wayland support (including fixing scroll speed on trackpads, preventing the screensaver from starting when playing with a gamepad, fixing window resize support, fixing key repeat going wild after Alt+Tabbing, fixing mouse pointer hiding on Plasma, and adding keyboard grab which Moonlight uses for system key capture). These haven't made it into an official SDL release but should come out in 2.0.16 in a few months (not that it really matters for our purposes).
Being stuck with Ubuntu 20.04's version of SDL means that we're have much less mature Wayland support, which is problematic on distros using Wayland by default (most distros these days). It also means that the system key capture feature in Moonlight will not work with the Snap (due to the missing Wayland keyboard grab support in SDL), which will probably confuse users.
I've been bundling a new SDL version in the Moonlight Flatpak for a while. If you could do something similar, that would bring better parity with the Flatpak.
I'd recommend sticking with a SDL commit that I've tested Moonlight with like dfa64eadd38a6a8125290dcf121f1bc285e98dad for the stable snaps, but you could use SDL master for edge if you want.

Done! Edge snaps now use SDL:main and ffmpeg:master. Stable ones, otoh, point to SDL:dfa64eadd38a6a8125290dcf121f1bc285e98dad and ffmpeg:n4.3.1.
Thanks!


WIP: Sphericart integration

This PR aims at integrating SpheriCart https://github.com/lab-cosmo/sphericart to p4ml. Todo list that I come up with but feel free to update edit. This also fixes a bug that the current real solid harmonics returns NaN when an (approximately) zero vector is given or does not evaluate.

[x] p4ml interface for real solid harmonics in SpheriCart
[ ] normalization of real solid harmonics in SpheriCart which compatible with current p4ml

If we want to retire the old backend entirely (though this sounds to me too ambitious):

[ ] make sure all the laplacian/derivative/pullback/pushforward of previous solid/spherical harmonics can be called exactly the same as before
[ ] check the normalization is correct for each basis, or provide an option normlization = :p4ml which recovers the previous normalization
[ ] and possibly evaluate the complex spherical harmonics via a transformation? This sounds something to be done in SpheriCart
[ ] update documentation, and maybe tag a minor version?

CC @zhanglw0521 @TSGut

If we want to retire the old interface entirely

What do you mean by "the old interface"? The interface should remain the same only the backend - i.e. the code that generates the basis will be sphericart?

I think all your points are very doable and should be doen.

If we want to retire the old interface entirely

What do you mean by "the old interface"? The interface should remain the same only the backend - i.e. the code that generates the basis will be sphericart?

Sorry that was a typo - yes I mean backend.

Something like this should give a correct scaling up to a sign. This comes from the Condon-Shortley Sign Convention. Is there a better way to fix this other than modifying the sign at the end of the output directly?

function generate_Flms(L::Integer; normalisation = :p4ml, T = Float64)
   Flm = OffsetMatrix(zeros(L+1, L+1), (-1, -1))
   for l = 0:L
      Flm[l, 0] = sqrt(2)
      for m = 1:l
         Flm[l, m] = Flm[l, m-1] / sqrt((l+m) * (l+1-m))
      end
   end
   return Flm
end

Are you saying that you need to rescale the Ylm output vector by a sign after the computation, and this cannot be done at the stage of precomputing the Flms?

Are you saying that you need to rescale the Ylm output vector by a sign after the computation, and this cannot be done at the stage of precomputing the Flms?

Yes exactly.

this is unfortunate. But do we really care about the sign convention?

@DexuanZhou  -- what do you think? Can you also ask Huajie? (i can't find his github name right now)

@DexuanZhou -- what do you think? Can you also ask Huajie? (i can't find his github name right now)

Sorry I just saw this message. In our current simulation of Schrodinger equations, I think the sign convention is not a problem, we will be happy as long as it is a complete basis.
But I am not sure whether this could become an issue in future project. For example, when we consider some symmetry of the system and evaluate the Clebsch-Gordan coefficients?

Using it as a single basis function, I agree with Huajie that the sign convention shouldn't matter much. The only potential issue arises when we compare with chemical basis functions, where they might express one-body basis as f = a_1f_1+a_2f_2+a_3f_3. In such cases, we need to be very careful to ensure that the coefficients align properly; for instance, adjusting coefficients to -a1, a2, and a3 as needed.

That sound to me like we should try to recover the correct signs. I'll discuss with Jerry.

... on the other hand we can just fix the signs in the clebsch-gordans ...

this PR seems to have gone stale. What shall we do?

I remember there is a normalization to be fixed before merging, but for some reason (which I don't remember) this can only be done on Sphercart end.

So exactly what is needed at the Sphericart end?

I remember we didn't arrive at a conclusion but we decide to make a issue on that end to discuss it (which I forgot to). I just skim over the code again, it make sense to me just to scale the output in P4ML?

Let's discuss at our next meeting what we should do.

Please double-check whether #84 makes this PR obsolete and if you agree, then please close it.


Mapping DateTime to a specific TimeZone on the fly

We have a multitenant app where tenants have different time zones stored in their app settings.
For example a CustomerDb object has NextPayingDate which is UTC stored in the database, so whenever we pick the Customer with the NextPayingDate (UTC) from EntityFramework we have to map it to the Settings where the specific time zone is located.
Therefore it comes the need if I can do something similar to AutoMapper with IValueConverter on the fly, whenever there is a map between Dates it uses the Tenant specific TimeZone. Is it possible to do the same with Mapperly?
Example
public async Task<CustomerDto> GetCustomerWithTimeZone(Guid customerId)
{
	var customerSettings = await dbContext.Settings.FirstOrDefaultAsync(x => x.CustomerId == customerId);

	var customerWithTimeZone = await dbContext
		.Customers
		.Where(x => x.Id == customerId)
		.AutoMap<CustomerDto>(customerSettings) // here it maps all DateTime fields to TimeZone specific thanks to IValueConverter on AutoMapper
		.FirstOrDefaultAsync();

	return customerWithTimeZone;
}

public class CustomerDto
{
	public Guid Id { get; set; }
	public DateTime NextPayingDate { get; set; } // with correct TimeZone here set up in AutoMapper
	// other date time properties are also mapped to specific TimeZone
}

public class Customer
{
	public Guid Id { get; set; }
	public DateTime NextPayingDate {get;set;}
}

public class Settings
{
	public Guid Id { get; set; }
	public Guid CustomerId { get; set; }
	public string TimeZone { get; set; }
}

This sounds like business logic which should actually not happen in an object mapper.
You should be able to implement this either by using user-implemented mapping method for the conversion from DateTime to DateTime or before-/after-map.

Thank you, will take a look for a custom implementation


[fix][doc] fix typo in ConsumerConfigurationData and ServiceConfiguration.

fix typo in ConsumerConfigurationData and ServiceConfiguration.

Motivation

Modifications
threashold --> threshold
aconsumer --> a consumer
createdif --> created if

Verifying this change

[ ] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

[ ] Dependencies (add or upgrade a dependency)
[ ] The public API
[ ] The schema
[ ] The default values of configurations
[ ] The threading model
[ ] The binary protocol
[ ] The REST endpoints
[ ] The admin CLI options
[ ] The metrics
[ ] Anything that affects deployment

Documentation

[x] doc
[ ] doc-required
[ ] doc-not-needed
[ ] doc-complete

Matching PR in forked repository
PR in forked repository:
https://github.com/SeasonPanPan/pulsar/pull/1

@SeasonPanPan please fill in this part in your PR description.

Feel free to ping me to merge if all tests pass.

@SeasonPanPan please fill in this part in your PR description.
Feel free to ping me to merge if all tests pass.

Done

@Anonymitaet I checked the CI error, it was not code reason, maybe it was the env problem.

@SeasonPanPan I've tried re-running the failed tests several times but they still failed. Have you tried pulling the latest master and then merging?

@Anonymitaet I've pushed a new PR for https://github.com/apache/pulsar/pull/19906


--list-devices and binary version mismatch

--list-devices in more recent versions of sshnpd will respond with the noports_core version instead of the sshnpd binary version (as it did previously). We should:

Include the noports_core version in the usage info for all the binaries (since the noports_core version is what actually determines the capabilities of a particular device)
Consider including the sshnpd binary version in the --list-devices output

@gkc can I leave this issue to you to look at more closely, since I know you've recently implemented similar capabilities for the SRDs?

Fixed by #659


 I'm going to switch to types generated from the swagger file (https://raw.githubusercontent.com/vegaprotocol/documentation/main/specs/v0.62.1/blockexplorer.openapi.json) - I'll make a ticket for that ⌛
Originally posted by @edd in https://github.com/vegaprotocol/frontend-monorepo/pull/2152#discussion_r1026545673
Tasks

[ ] Add a project level script to run https://www.npmjs.com/package/openapi-typescript and use the generated types to replace the hand written ones

i have a lib for this which is extremely nice to use: https://orval.dev/
check it out, if you like it. it uses react-query, so the generated result's semantics will be super similar to the hooks generated by the graphql codegen, it allows you to be able to just use endpoint specific hooks for requests, all typed.