Tweak odometer in HUD

Avoid redrawing HUD pixels that  can be written once by the bitmap:

Upper horizontal line of frame.
Dividing line between before last, right digit.

Remove overwritten pixel columns from number bitmaps.

This saves ~52bytes and reduces number of times pixel data is updated per frame (may improve speed).


Buttons don't respect preventDefault in forms and try to force submit

What is affected?
Component
Description
Whenever I click on an MWC button inside a form, the validity checks start going off. Usually this happens because buttons inside a form trigger the submit behavior, which can be stopped by calling preventDefault on the event.
Attaching a click listener to a MWC button to prevent the submission doesn't do anything. On a native <button> however the validity check and submission is stopped
Reproduction
You can see an example here, with an icon button, a filled one and a native button. Just start clicking the buttons without filling any of the inputs to notice the jarring effect.
https://lit.dev/playground/#gist=2245bd0b6209c8d3519ff1505c15bd86
The native one works as expected, respecting the preventDefault, the mwc ones keep on trying to submit the form.
Workaround
No workaround.
Setting type="button" would stop the form submission completely instead of preventing the default behavior as expected.
Is this a regression?
No or unsure. This never worked, or I haven't tried before.
Affected versions
1.0.0
Browser/OS/Node environment
Browser: Chrome 117.0.5938.92
OS: Windows 11 Pro 22H2 22621.2283
Node: v18.16.0
npm: 9.6.7

Issue
The issue is that the md-*-button's formSubmitter helper isn't waiting long enough to detect if the event  has been prevented. It's waiting a microtask but the microtask queue is flushed every time the browser's event loop advances (i.e. every time a different handler executes). Instead the helper needs to wait a task await new Promise(requestAnimationFrame).
Workaround
As a workaround until this is fixed, you can capture the click event and call preventDefault(). This works because the event is prevented before the formSubmitter starts waiting.
If using TypeScript, you can capture the event easily with the eventOptions decorator @eventOptions({capture: true}). Otherwise, you should add the event imperatively with {capture: true}.
https://lit.dev/playground/#gist=77bf6a3dcca4b1ae302d380db9aacfb9

Yes! We have an overall tracking bug for ensuring preventDefault() does what is expected. It's on our public roadmap too :)
If you find additional spots where preventDefault() doesn't work as expected, we'd appreciate issues filed!


primary key and foreign key is same after join

code of query
auto headings = DatasetType::whereEq("name", "2d")->first()
		                ->headings()
		                ->join("heading_names", "heading_names.id", "=", "headings.heading_name_id")
		                .with("name")
		                .orderBy("heading_names.name")
		                .get();

sql:
select * from "headings" inner join "heading_names" on "heading_names"."id" = "headings"."heading_name_id" where "headings"."dataset_type_id" = 1 and "headings"."dataset_type_id" is not null and "headings"."deleted_at" is null

then i write
		for (auto& h: headings) {
			qDebug() << h.getRelation<HeadingName, Orm::One>("name")->name();
			qDebug() << h.getAttribute("heading_name_id");
			qDebug() << h.getAttribute("id");
               }

result is
QVariant(qulonglong, 7)
QVariant(qulonglong, 7)
but when i execute SQL query result is

ids should not be equal.

Also, you are mixing with() with join()? But let's focus on that headings() for now.

headings() returns std::unique_ptr<HasMany<DatasetType, Heading>>

Also, you are mixing with() with join()? But let's focus on that headings() for now.

yeah. A need to sort Heading by name. Names are in other table. Аnd when I iterate through the array I want to see the names

Ok, when headings() method returns HasMany relation then it should be correct. 👍
I need to know how the name relation is defined. I need to investigate this query to see if there is any bug in our code.

class Heading final : public Model< ... > {
...
std::unique_ptr<BelongsTo<Heading, HeadingName>> name() {
			return belongsTo<HeadingName>("heading_name_id", "id", QString::fromUtf8(__func__));
		}
}

class HeadingName final : public Model<HeadingName, Heading> {public SoftDeletes<HeadingName>

		std::unique_ptr<HasMany<HeadingName, Heading>> headings() {
			return hasMany<Heading>("heading_name_id", "id");
		}

I understood from the documentation that the foreign key is specified first, and then the primary key. Maybe i shouldn't write "id" key in relation

I understood from the documentation that the foreign key is specified first, and then the
primary key

That's correct.

Maybe i shouldn't write "id" key in relation

There is nothing wrong if you specify it explicitly.
I test it when I will have a little time, I can't tell right away where the problem is, I need to model an entire case and reproduce it, and it will take some time. I think I have all the info I will need.
When I fastly look at the generated SQL query then it looks correct, it looks exactly how it should look like, but maybe I'm wrong.
Also, I would recommend to skip or and call directly something like this:
auto headings = DB::table("headings")
		                ->leftJoin("heading_names", "heading_names.id", "=", "headings.heading_name_id")
		                .whereIn("headings.id", {1, 2, 3})
		                .orderBy("heading_names.name")
		                .get();

Or use that whereEq("name", "2d"), try to play with these.

Thank you

I looked at your solution and noticed that i wrote columns in join in the wrong order. I changed the order and everything worked. Thanks for the help!


New Filter Semantics

Internal Futhark:
filter :: (a->bool, ..., a->bool, [a]) ->
(int,         ..., int,         [a])
External Futhark:
filter :: (a->bool, ..., a->bool, [a]) ->
([a],         ..., [a],         [a])
Semantics (External Futhark):
input:    n conditions and an array
output:  n + 1 arrays, such that the first one contains only the
original-array elements that succeed under the first condition, ...,
and the last (n+1th) array contains the array elements that failed
under all conditions.

This has turned out to be more complicated, as we need a solution that works well with fusion.

I have done the first part of this (adding a generalised partition to the internal language), and am now working on the external language.

In the external language, I am going to preserve the existing filter semantics, but add a new SOAC - partition - that performs multi-way filtering.


Inconsistent TSQL Data Types between imported DB data model and default TSQL data types offered upon data model creation

Describe the bug
Inconsistent TSQL Data Types between imported DB and default TSQL data types offered upon data model creation
To Reproduce
Steps to reproduce the behavior:

Import SQL Server DB Schema into the Data Model (SQL Server DB Importer)
Create a new Data Model and select predefined set of data types: Transact-SQL / MSSQL DataTypes
Compare Data Types of these 2 data models

Expected behavior
Expect to see the same data types, including description.
Screenshots
Default TSQL Server Data Types offered during data model creation

Imported Data Model using SQL Server Importer

Additional context
UI: 6.6.0
CORE: 4.10
SQL Server Plugin: uk.ac.ox.softeng.maurodatamapper.plugins:mdm-plugin-database-sqlserver:5.1.0

If it was consistent, it would save the end user from manual work to adjust the data types.

SQL Server Importer: The length of the field is imported as a separate property in the Other Properties tab, and that could potentially be automatically added to Description to say, for example: Max length: 5.


No bosses/traps spawning

I have flown around in spectator mode in attempt to see if there were any locations where bosses/"traps" (or mob spawners with chest) are spawning and have not been able to find any. Unless they are incredibly rare, they don't appear to be generating. There have has been no crashing and I am still able to craft any items from the mod.
  Might be BoP that is causing it to fail, either due to how the features work or i may not be adding features late enough.

Does Biomes O' Plenty still break it in 1.16.5


Fix dead links in the title

It looks like this page changed its names, but the contents didn't.

hmm, this link
/copper/linux.html#First%20OpenOCD%20connection

breaks local builds (mdbook serve). But this, without the leading slash, works fine:
linux.html#First%20OpenOCD%20connection

Could you try that way instead?

@japaric I removed all the leading slashes I can find, because it seems the book is rendered "flat". I'm not sure how to serve your jekyll pages locally, (jekyll serve failed at the root), and I am currently trying to figure out how to install mdbook (brew install mdbook failed).

Sorry for submitting a pull request without proper testing :) I was hoping it would be a more minor fix.

Of course mdbook is a cargo crate :D

@japaric Links seem to work correctly using mdbook serve now.

@jamesmunns Thank you!


server: limit the number of (refresh) tokens for each user-client pair

 Issue by yifan-gu
Monday Aug 17, 2015 at 18:19 GMT
Originally opened as https://github.com/coreos-inc/auth/issues/365

For example, google has a limit of 25 for per user https://developers.google.com/identity/protocols/OAuth2#expiration

I think this should be configurable. I'd like to see an implementation where we only allow a single refresh token per client/user/scopes tuple.

@rithujohn191 closed, right?

yes closed by #793


chore/more tolerant webhook urls

URLField has validators that only allow for public URLs. Some of our customers want to define webhooks with URLs like https://webhook-processor/stream or similar. This PR allows for that.
URLFields are just varchar(200) with some django validation so the migrations here are NOOP on the actual DB.

Weird not sure why these test are failing?

Because you still have the migration file from your other branch.

OK this is green now @matthewelwell

Weird not sure why these test are failing?

Because you still have the migration file from your other branch.
django.db.migrations.exceptions.NodeNotFoundError: Migration organisations.0041_alter_organisationwebhook_url dependencies reference nonexistent parent node ('organisations', '0040_organisationsubscriptioninformationcache_chargebee_email')

0040_organisationsubscriptioninformationcache_chargebee_email does not exist in this branch (or the main branch).


Several improvements to mapping

Bunch of improvements for the mapping.
Noticed several issues with ABCD(EFG):

coordinates are double and weren't picked up
modified time was in long and wasn't picked up

Fixed differences with David's mapping.
https://naturalis.atlassian.net/browse/DD-445

Check for modified in metadata
Check for license in unit data
Check more fields for specimen name

Able to retrieve tax info for identification extension:
https://naturalis.atlassian.net/browse/DD-495

When no tax info in core file check extension
When there is an identificationStatus only take ones that have "1" (ignore others)
When no identificationStatus take first identification

Yes so the identificationIndex was tricky. What I didn't wanted to do was recheck the identificationIndex for each property. So approached it a bit like a singleton. The first time something is called that needs in identificationIndex we calculate it and store it in a temporary property (in the original data). The next times we first check the temp property, which is now filled, and use the value from there. Before we commit the orginal data we remove the temp property. Bit trick but it means we don't unnecessary loop over all the elements.

Sonar fails on duplication, but further abstraction is not possible. These are just one liners pointing to super methods. By keeping them in separate files means we will still have the flexibility to include custom logic to the process.


error on isScreenOff, wakeUp and unlock

I used in Ionic 3.5, returned this errors.
Native: tried calling BackgroundMode.isScreenOff, but the BackgroundMode plugin is not installed.
BackgroundMode plugin: 'ionic cordova plugin add cordova-plugin-background-mode';

Native: tried calling BackgroundMode.wakeUp, but the BackgroundMode plugin is not installed.
BackgroundMode plugin: 'ionic cordova plugin add cordova-plugin-background-mode';

Native: tried calling BackgroundMode.unlock, but the BackgroundMode plugin is not installed.
BackgroundMode plugin: 'ionic cordova plugin add cordova-plugin-background-mode';

Can help me?

On what platform?
I think you have installed version 0.7.2 and those functions haven't yet been included in a version

Good Morning!
Yes, i have installed on Android with Ionic 3.5.3.
<plugin name="cordova-plugin-background-mode" spec="^0.7.2" />
What is the new one?

There is not a new one. But you can grab the head version with this command
cordova plugin add https://github.com/katzer/cordova-plugin-background-mode.git
Note: No Ionic in front here as there are some issues with https

I installed it manually, but it still does not work, as it continues to "install" version 0.7.2.
Analyzing the changelog has the following information:

Version 0.7.3 (not yet released)
Check if screen is off on Android
Wake-up device on Android
Unlock device on Android

Link: https://github.com/katzer/cordova-plugin-background-mode/blob/master/CHANGELOG.md#version-073-not-yet-released
Is it not yet available?

No 0.7.3 is not available yet.
When I installed
cordova plugin add https://github.com/katzer/cordova-plugin-background-mode.git
this was updated in my project.json
"cordova-plugin-background-mode": "git+https://github.com/katzer/cordova-plugin-background-mode.git",
IS your project.json still referring to version 0.7.2?

Yes, reference is always made to version 0.7.2, regardless of the form of installation.

Solved!
I ended up installing Git and running the path through Git CMD:
Cordova plugin add https://github.com/katzer/cordova-plugin-background-mode.git
Thanks a lot for the help!

Hello,
I had the same issue, tried to solve with
cordova plugin add https://github.com/katzer/cordova-plugin-background-mode.git
but after this I had another problem:
android-sdk version check failed
Is there some android version requirement?


ros: 1.13.4-0 in 'kinetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository ros to 1.13.4-0:

upstream repository: https://github.com/ros/ros.git
release repository: https://github.com/ros-gbp/ros-release.git
distro file: kinetic/distribution.yaml
bloom version: 0.5.22
previous version for package: 1.13.1-0

mk

No changes

rosbash

No changes

rosboost_cfg

No changes

rosbuild

No changes

rosclean

No changes

roscreate

No changes

roslang

No changes

roslib

No changes

rosmake

No changes

rosunit
* fix test type handling (#123 <https://github.com/ros/ros/issues/123>)

Waiting for other releases...


[Bug]: Build is failing while pushing to main

Is there an existing issue for this?

[X] There are no existing issues

Priority of this issue

[X] high
[ ] medium
[ ] low

What browsers are you seeing the problem on?
No response
Contact Details
No response
Describe the current behaviour
After pushing from dev to main, the build is failing. The current version of nokogiri is not compatible to the ruby version 2.6.5
Describe the expected behaviour
The build should run successfully to deploy the expected changes
Steps to Reproduce

Push to main branch
Build will failed after 20 - 30 seconds.
Newly added changes are not reflected.

Issue got resolved


"Charge port latch" does not toggle/unlock-lock properly in a scene

V3.8.1 (same issue with previous version).
When the charge port latch entity is used in a scene, even after I set the state to "unlock", when the scene runs, it does not unlock.  It does not seem to toggle properly when a scene is used with entity.
Thanks.

Please enable debug logging on teslajsonpy and show the log during a scene.

Thanks for your reply.  I would be glad to do that.  In the meantime, I noticed that when I am configuring the scene and toggle the entity state (such as between lock and unlock), 1) the entity icon does not change color like others, nor does the scene setup asks me to save the settings after I make the change.  In other words, typically during the scene set up, when HA detects a change, the "save" icon will appear on the lower right.  When I am setting up the port latch state, the configuration does not seem to get recorded, therefore it does not prompt the "save" button.  This is unlike every other entity I have set up in my HA, including other Tesla entities.  Port latch is the only one that behaves this way.  I hope this helps to point you in the right direction.

This is probably an HA problem. I have experienced the same several times with other scenes.


feat(useCssVars): work with Transition + v-if

close #3894

See 6ed23f6 - the bug affects more than just <transition>: it occurs when:

a child component is used at root level
the child component contains slot content that may change
the slot content change depends on state that isn't used by the parent (so parent onUpdated doesn't trigger when the child updates)

Using MutationObserver covers all possible cases.


Virtual enviornment not loading after  python committed to Git Hub

A Python project using a virtual enviornment so committed to  Git Hub
The JSON config file is .GitIgnore
The Project is cloned to another machine  where an identical Venv is created.
AFter committing the  project  to the remote Git hub, the venv is not activated on the original machine when
1 - the vs projecr is opened
The VS Project is opened with the python page open and a new terminal session  started.
Checking the JSON file on both machines shows that the path to Scripts/python is correct on both machines.

@NeilWP We advise against committing actual virtual environments to source control. When virtual environments are created, they use absolute paths to where certain binaries are. This prevents them from being used when to check it out. Even if you create an identical virtual environment. If this is not what you are doing can you share a link to your project so i understand what is going on.
You should be checking in the requirements file and create and create a virtual environment locally.

Hi
As I stated very clearly *I am not submitting the venv or the setting JSON
file  to source control - they are in the  ignore bundle. *
The venvs have been locally built on the two dev machines, and proved to
activate
After the  source code relating to the  application development  (not the
venv) has been committed,  synched across the remote GitHub and the two dev
machines, It is not longer possible  to activate the venv via Visual Code
on either of the  development machines.
Checking the JSON setting on both machines shows that the venv paths to
Scripts/python are  correct for both machines.
Deleting the  Remote Github in Visual Code and  severing the two machines
from source control re-instates the activation of the Venv  on both
machines   in the normal fashion .
It would appear that GitHub is getting in the way of this
Neil
On Wed, 19 Jan 2022 at 18:52, Karthik Nadig @.***>
wrote:

@NeilWP https://github.com/NeilWP We advise against committing actual
virtual environments to source control. When virtual environments are
created, they use absolute paths to where certain binaries are. This
prevents them from being used when to check it out. Even if you create an
identical virtual environment. If this is not what you are doing can you
share a link to your project so i understand what is going on.
You should be checking in the requirements file and create and create a
virtual environment locally.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-python/issues/18318#issuecomment-1016717088,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AP2Q6ORYKJFO2HW73J6FVRDUW324HANCNFSM5MKMXW6Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

A Python project using a virtual enviornment so committed to Git Hub
The JSON config file is .GitIgnore

@NeilWP You said this in your original post, and it was unclear if the python itself was committed. I also suggested that you share a link to your project. Please provide a minimal repro for this, and the steps you take to check out and open the project in VS Code.

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on then we will be happy to re-open this issue to pick up where we left off.

Hi - I moved into a tactical solution of cut and paste rather than waste more time in the project. I sill look at it again later
Many regards
Neil

On 8 Mar 2022, at 20:39, Brett Cannon @.***> wrote:

Closed #18318.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.


Build SQLite 3.28 on newer BinaryBuilder

Reason I started this PR was to fix this warning:
Warning: platform_key() is deprecated, use platform_key_abi() from now on

Which comes from the dated build.jl that the current latest release has. Simply building again on a newer BinaryBuilder will fix that. I come across this in downsteam builders like PROJBuilder that depend on this builder.
But while I was at it I made some more updates, if you prefer I can remove them again:

Update from SQLite 3.24 to 3.28 (changes)
To be more in line with other builders: change name from SQLiteBuilder to SQLite
To be more in line with other builders: change version from the builder version to the SQLite version. The release tag can then be v3.28.0-1 with the last part indicating the build number.
Travis build on julia 1.0, update YAML to how the wizard would print it now

If this is tagged I can make a PR to SQLite.jl to use this build.

Ah just realized I actually need this to be able to use it as a dependency when building with GCC7 instead of the GCC4 used here.
Reason is in the old build.jl a simple haskey is used, whereas nowadays the more sophisticated choose_download is used in build.jl (example).


Migrate to AndroidX, Update dependencies

Update appcompat to AndroidX dependencies

Update Android Gradle plugin to 3.6
Update Kotlin version to 1.3.70
Update Glide to 4.11.0
Update PhotoView to 2.3.0

@WindSekirun Please merge this branch and a release a new version.

@deepakkumardk Release as 2.0.7 (with !30) Sorry to late.


feat(RFC): sync example apps to separate repos

Is your feature request related to a problem? Please describe.
Currently, we have https://t3.new which opens a fresh t3-app in Codesandbox - but it doesn't sync up to new releases.
I'm thinking we could build some apps automatically on each release that would then be subtree'd down to separate repos which could then be forked on CodeSandbox / Stackblitz. It would also make it quite easy to browse how a t3-app looks without needing to run the CLI.
Describe the solution you'd like to see
I think we'd need to have each app in the main monorepo workspace like examples/* and then when we publish new releases, git subtree them down to separate repos so that they are kept up to date.
tRPC does something similar:
Workspace: https://github.com/trpc/trpc/tree/main/examples/next-minimal-starter
Subtree workflow: https://github.com/trpc/trpc/blob/main/.github/workflows/subtree.yml
Repo: https://github.com/trpc/examples-next-minimal-starter
Then, we could update the https://t3.new to accept some query params for what packages you would like to use and it would launch that repo in CodeSandbox/Stackblitz accordingly:

https://t3.new?prisma&next-auth
https://t3.new?prisma&trpc&tailwind
etc...

Describe alternate solutions
Technically, we wouldn't need both example workspaces and separate repos - but I'm unsure how to do one without the other? We could only do workspace and launch Stackblitz from the example/* directory - although then they wouldn't have lockfiles which would cause long installation times 🤔
Open to suggestions on the implementation.
Additional information
I think we can switch to Stackblitz since the swc issue seems to be fixed there now.

For this we would first have to create different repos for all the individual repositories and then we can git subtree them down right?
Have we created them yet or is it yet to be created?

For this we would first have to create different repos for all the individual repositories and then we can git subtree them down right? Have we created them yet or is it yet to be created?

Nope - haven't created them yet but that can be done

I can pick this but repos should be created as i won't have the access to that!

I can pick this but repos should be created as i won't have the access to that!

Lets try first with just having them in the monorepo and see if we need separate repos for them later?

Hey y'all,
Are you(@harshsinghatz ) taking care of this? I would love to try to work on this too

this is from half a year ago, so feel free to pick it up.

Hey @juliusmarminge ,
Is this kind of what you were expecting? examples . I don't know if I should add more examples or not.Should I host it somewhere?

Hey @juliusmarminge  ,
I created a repo with some examples, Do we want people to have access to the code? I was thinking of making an app that could push people to something like stackblitz so people can have access to the code? Let me know what you think
https://github.com/mqshaikh8/t3_examples

The initial plan was probably to have them generated inside the repo and then we could do stackblitz links like https://stackblitz.com/github/t3-oss/create-t3-app/tree/main/examples/with-drizzle-trpc-tailwind or something

I just wanted to kind of generate a a sample, I am going to fork the repo and create those examples there.

Hi @juliusmarminge,
I created a pull request with the examples. Let me know if there is something I should change. (sorry if the pr is weird, This is my first open source pr)
#1573

Hi @juliusmarminge,
I created a pull request with the examples. It lets people pick the different combinations and view them on stackblitz.
#1576

Can I close this? I am not sure what the process is @juliusmarminge


terminate called after throwing an instance of 'YAML::BadFile'

Hello,excuse me.
when I run into this step: ./build/test_distance_map_planner_2d ../data/corridor.yaml
it occurs error: terminate called after throwing an instance of 'YAML::BadFile'
what():  yaml-cpp: error at line 0, column 0: bad file
how can I solve it? please

I guess you need to change the command a bit as:
./build/test_distance_map_planner_2d ./data/corridor.yaml (single dot for /data/corridor.yaml)
or go to the build/ folder and run:
./test_distance_map_planner_2d ../data/corridor.yaml

I guess you need to change the command a bit as:
./build/test_distance_map_planner_2d ./data/corridor.yaml (single dot for /data/corridor.yaml)
or go to the build/ folder and run:
./test_distance_map_planner_2d ../data/corridor.yaml

Thank you very much!!!


Authentication error since yesterday

Hi
Since yesterday 10h, I have authentication error....nothing has changed on my side so I am wondering if sonoff has changed something on server side??

I restarted the flows and all went good...


Release 3.22.1

Improvements

feat: Change manifest.json requirements for Safe Apps (#3684)
Refactor: tidy up Safe creation (#3660)

Bug fixes

Fix: safeTxGasEstimation race condition (#3683)
fix: clear pending status when transaction reverts (#3691)
fix: virtualize collectibles list (#3700)
fix: only disconnect WC when a peerId exists (#3686)

Chores

Chore: remove storybook (#3707)
chore: bump Safe React Components version (#3678)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

67 of 153 (43.79%)  changed or added relevant lines in 19 files are covered.
2 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.3%) to 35.145%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/routes/safe/components/Apps/components/AppFrame.tsx
0
1
0.0%

src/routes/safe/components/Transactions/helpers/TxModalWrapper/index.tsx
1
2
50.0%

src/logic/collectibles/store/selectors/index.ts
0
2
0.0%

src/logic/wallets/walletConnect/utils.ts
0
2
0.0%

src/routes/opening/index.tsx
3
5
60.0%

src/routes/safe/components/Balances/Collectibles/components/Item.tsx
0
2
0.0%

src/routes/safe/components/Transactions/helpers/TxParametersDetail/index.tsx
2
4
50.0%

src/logic/safe/transactions/gas.ts
0
3
0.0%

src/logic/collectibles/sources/Gnosis.ts
0
4
0.0%

src/routes/safe/components/Apps/utils.ts
12
16
75.0%

Files with Coverage Reduction
New Missed Lines
%

src/logic/safe/store/actions/createTransaction.ts
1
48.03%

src/routes/safe/components/Balances/Collectibles/index.tsx
1
0%

Totals

Change from base Build<PHONE_NUMBER>:
0.3%

Covered Lines:
3403

Relevant Lines:
8757

💛  - Coveralls

Only found a small issue with an icon that looks bad in the error notification that doesn't happen in prod
To see it try to create a safe but change the gas limit from the 523k estimated by default to 80k

The rest looks fine. I didn't had issues using other wallets and signing tx in a few other networks.

Fixed, thanks Franco!


add the ability for a user to iterate through transactions

What problem does your feature solve?
Horizon will cease to serve txmeta sometime in Q2 (see discord discussion) due to data storage size concerns of Soroban transactions. The ecosystem needs an alternative to this, and we want that alternative to be the RPC.
What would you like to see?
Allow a user of the RPC to iterate through transactions within it's transaction window, and those transactions should serve all appropriate txmeta related to that transaction.
What alternatives are there?

Note that the use of the word "stream" here does not necessary dictate the implementation/behavior. Actual streaming/pubsub through something like a websocket/SSE is an option (as Horizon implements it), but a restful endpoint for transactions that supports pagination could also be sufficient.

@janewang do you have an opinion on the "how" here? That is, websocket/pubsub vs polling/pagination

I suggest streaming pub/sub as Horizon currently implements it.

I suggest streaming pub/sub as Horizon currently implements it.

Hello @janewang , @jake commented on same aspect of streaming as an RPC futurescope feature in Stellar RPC Product Specification , I posted a follow on reply with more potential on that, can paraphrase here also:

streaming protocols are great for clients in distributed systems that need to handle 'infinite' data and promotes event driven architecture with decoupled micro-services which can derive their own custom data models from the root source-of-truth stream.

horizon's streaming is based on HTTP SSE, server-sent-events, its one-way, single client request to a single ongoing server push over the same http connection, this could fit for RPC streaming.

SSE has some limitations on streaming ability, it's one-way, and somewhat lossy since any connection disruption will result in client being disconnected and having to restart a new http connection at which point may have missed messages in the interim unless the endpoint has more logic for cursors and client code maintains that cursor.

A level up from SSE is websockets, which allows two-way messaging, not suggesting to use that directly in RPC though, rather an option to consider in general for providing more robust streaming from RPC to clients, is to offload the websocket responsibility to an external mq broker instead which can implement its protocol over websockets, such as MQTT, then RPC doesn't need to provide any streaming infrastructure, instead it could just be configured as an mq client and pub/sub to the broker such as MQTT, and client apps pub/sub with the broker using that client sdk, like MQTT.js, this way the client system is responsible for provisioning the mq broker instance, and the broker manages websocket loads. Clients can leverage some nice MQTT protocol features like subscription topic filtering, to build streams that filter down to only specific messages like maybe by contract id. Rpc getEvents already has the notion of topic filters in place and they were kinda modeled after the MQTT pattern. Clients can leverage the mq protocol for messaging QoS and persistent sessions to achieve advanced messaging delivery semantics, such as exactly-once delivery for clients, which is much more robust than polling, SSE, or websockets.

As suggested in the spec, websocket is where we are planning to go eventually. We do need tx metas changes to be out by protocol 21 as there are quite a bit dependencies from the ecosystem on this and Horizon will turn off the tx meta flag in protocol 21. If there are not no objections to the timeline, I'm supportive of a websocket implementation.

Should we rename this issue to add the ability for a user to iterate through transactions? Iterating through txs (not only meta) is an important feature and I assume we'll be using the existing transaction resource (which includes metas). Is there a need to separate?
On API design, I think that we should definitely have a regular json-rpc method (getTransactions?) to iterate over transactions (I assume it's shape will be similar to whatever we currently use for events).
Do we really need a streaming API on top of that? Updates happen only every ~5s after ledger closes, you can potentially just poll the above method.
Turning on websockets should theoretically be easy as JSON-RPC is transport agnostic (and seems like our library has a relevant ws module). Though not sure what the lift is of adding streaming on top of that.

I'm not committed to this opinion but I'll offer it up in contrast to facilitate discussion:
Are we sure we want to commit to websockets when we don't have a compelling reason to have bidirectional communication? They are more demanding relative to SSEs and come with their own add'l complexities: e.g. defining a schema on top of it and the lossy/reconnect issue still being there. It also opens a permanent connection and I'm not sure how that works with load balancing because they're stateful. They also will be mostly idle and only do something every ~5s (ledger close). So it feels like overkill relative to SSEs.
I do like the idea of only providing streaming data in the form of an MQ: as you said it's very robust and keeps things simpler on our end as well. However, I'm worried it might be too demanding for downstreams to get started quickly? But honestly there's libraries for everything these days (like @sreuland pointed out with mqtt.js!) But it would be annoying to maintain multiple ways to stream stuff so going for robustness could be the right answer.

yes, SSE is lighter weight and proven in action with horizon. For plain websockets with no other protocol on top, it's subject to the same potential lossy-ness due to connection interruption as SSE, and to @Shaptic's point, RPC requirements don't call for two-way communication, server sends requests to clients. Websockets probably only makes sense if we think it's worthwhile to make the extra leap to with an MQ protocol on top of websockets like MQTT to gain reliable message delivery on streaming events, tx-meta, transactions
sse/websockets can both be challenging to deploy under higher client volumes, since each client holds a long running http connection on the server(and through any load balancers), usually entails non-trivial scaling architecture on the back-end servers. The idea with isolating the streaming under an external MQ is the broker deployment deals with this scaling and provides its reliable messaging protocol on top. It doesn't conflate streaming requirements into rpc server deployment. If rpc hosts a streaming service then we will likely need to include more advanced RPC deployment requirements/contingencies based on  expected number of clients, not related to pure rpc runtime requirements.

🤔 A meta streaming API for RPC is somewhat at odds with the goals RPC has specified in the specification: The RPC has a small window of data access, 7 days only. Applications that stream data, rather than selecting narrow segments of data, probably won't tolerate gaps in data. If those applications won't tolerate gaps in data, and RPC can't fill gaps in streamed data, then integrating it as the way to stream meta could be challenging. I'm sure streaming meta would still be useful, but it may set folks up to fail. How would they fill gaps?
What are the use cases for how streaming meta will be used in RPC?
I think folks building applications that need to stream meta, probably need to depend on something where they can fill gaps. Maybe this is something the RPC could do in the future, efficiently, but it isn't in the goals at the moment.

The existing getTransaction endpoint already returns meta, which is great, so applications can already extract meta for transactions they've submitted. And many of the folks chatting here seemed to indicate they're getting meta for specific transactions, not streaming meta of all time.

Allow a user of the RPC to iterate through transactions within it's transaction window

It does seem like getTransactions that @tomerweller suggests above, with maybe with a ledger number as input, would allow a developer to iterate over transactions within a transaction window.
Transactions are announced in this burstable fashion. Maybe the stream shouldn't be oriented around transactions or meta at all, and instead be a stream of ledgers. The goal being to subscribe and be notified or new ledgers. Then if you want to follow transactions, you watch the stream of ledgers to be notified when a new one is released, and when a new ledger is announced, you go and retrieve the transactions for that ledger. Possibly you might request multiple pages of transactions for a single ledger concurrently rather than serially and disconnecting the stream from the data is helpful in doing that.

For implementing websocket in the RPC, it is a potential feature for future development. At present, there is no requirement to implement it now, and I believe more thorough assessment on the RPC websocket methods is required to fully scope this piece of functionality on the product side and an evaluation of engineering design is likely required from eng.
In the immediate term in light of the upcoming sunset of tx metas in Horizon, our primary focus for Q1 is to provide alternative solution and facilitate the transition away from using tx metas in Horizon.

getTransactions: Return all transactions available on the RPC with an optional filter which returns a filtered array of transactions

once that's added to rpc, we could include mention for js-stellar-sdk to abstract the long polling of cursor based pages of getTransactions into a more standard programmatic streaming interface like subscription class and callback handler.
With the js sdk subscription abstraction, it could also enable ability to update RPC to an actual streaming protocol like SSE if we see the value later and js sdk could update it's abstraction to that format but not introduce breaking change upwards on client since they continue using the subscription/callback interface.

I think folks building applications that need to stream meta, probably need to depend on something where they can fill gaps.

there's a new component LedgerExporter coming up as part of composable data initiative, it's currently under development, it's purpose is to serialize tx-meta based on ledger range(or unbounded) and export to pluggable destinations, could be file stores, MQ broker, etc. Wondering if this may be an alternative further out to consider for recommendation to apps to use in a complementary way with RPC when they want ranges of meta beyond the RPC's window.

For getTransactions, could we add the ability to filter similar to how we filter in getEvents.
Btw, as a quick follow on, I opened a ticket in stellar-docs for documenting this endpoint: https://github.com/stellar/stellar-docs/issues/357

Closing in favor of https://github.com/stellar/soroban-rpc/issues/110


unable to populate textfield with information [v1.34.1]

Describe the bug.
while attempting to populate textfields using inputText command, the text field is not getting populated with the complete text that was specified in the test. i.e i tried to login using email address and password on my application , the email address was not completely typed out despite all attempts, i went as far as using the shortest email address i had access to but even that did not work.
To Reproduce

Start the simulator
Input text into a textfield i.e enter email address into email field
Run maestro test  login.yaml
The Flow fails at type email address

Expected behavior
the entire text in this case , the email address that was specified in the test should be completely populated in the text field. no numbers or letters should be omitted
Screenshots

Environment information (please complete the following information):

Maestro version [v1.34.1]
Platform: [Android 11.0, Chrome]
Framework: [Flutter]
Device model and OS version: [e.g. Nexus 6P]
emulator
Host [Mac M1]

Additional context
this issue is applicable to all input attempts

Hey, thanks for creating this issue! Unfortunately, it's not reproducible to us.
Please provide [a minimal, reproducible example] that clearly explains how to reproduce the problem with the detailed, step-by-step instructions (that can be easily run by me or other maintainers).


Is disque suitable with multiple consumers

Hi all, thanks for what you are doing!
I would like to know if I can use disque in scenarios where a single message (job) must be consumed by multiple consumers (usually the sender doesn.t know how many consumers needs that message)
For example the "event" that a new order is issued must be forwarded to the warehouse service and to the invoice service for correct management.
Can I use disque is this use case?
Thx

No, you would need to submit the job to a different queue for each service. It would be nice for disque to support this more natively like NSQ or Kafka. Maybe addjob could support more than one queue.

Thx. That means that I could create a queue for every consumer and write a sort of router/dispatcher that receive the first job (sent by the producer) and resend it to every registered queue.

Correct.


Image Classification example with Java

has the sap image classifier service been taken down? I can no longer find the api. What would be a similar api I could use?

Hi @kawaiipooptato,
Apparently the service has been renamed to Inference Service for Customizable Image Classification
Therefore the URL is now:

https://sandbox.api.sap.com/ml/imageclassification/classification

instead of:

https://sandbox.api.sap.com/ml/imageclassifier/inference_sync

I'll update the tutorial with the change

Hi @kawaiipooptato
Any feedback on this?
Thanks

Yup I actually noticed that as well. I tried it and it worked really well. Thanks for the tutorial!

Fixed in af4c7b8.


Default test files are generating repeating text / hallucinating

I used the default settings on the Kaggle notebook.
https://huggingface.co/datasets/sanchit-gandhi/whisper-jax-test-files

Looks like a hallucination (known issue of the Whisper model) - worth trying with timestamps

We could implement a logits processor that stops repetition of repeated tokens (similar to what we have in PyTorch: https://github.com/huggingface/transformers/blob/04ab5605fbb4ef207b10bf2772d88c53fc242e83/src/transformers/generation/logits_process.py#L474)
This might be quite difficult to do in a JAX compiled way though without returning the value of each token generated

See this issue can be improved by reducing the --compression_ratio_threshold from default 2.4. https://github.com/openai/whisper/discussions/192
How can I modify this with this library?


Can't connect

Seeing this error:

Host '<IP_ADDRESS>' is not allowed to connect to this MariaDB server

What user are you using to connect?
If you using one that you've added yourself check that you have given it access from the correct IP's


New Design

This incorporates a number of features from the Tailwind starter and ditches the existing styled-jsx CSS in favour of Tailwind. The aim is to create a functional, good looking starter that will serve as an introduction to Tina for new users.

@spbyrne updated the screenshot in the README based on the one you shared.

What's supposed to happen when you try to access https://tina-cloud-starter-orcin.vercel.app/admin ?


[SPARK-8913][ML] Simplify LogisticRegression suite to use Vector Vector comparision

Cleanup tests from SPARK 8700.

Merged build triggered.

Merged build started.

Test build #36981 has started for   PR 7335 at commit e5e2c5f.

Test build #36981 has finished for   PR 7335 at commit e5e2c5f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

cc @dbtsai here is the PR I meant to make when I did the other cleanup (sorry about that).

Merged into master. Thanks.


Adds ability to set class name as part of parlour dsl.

Need to add the ability to set the class name instead of job name.

:+1:


Action Deprecation Warning

Every time my test runs in GHA I get this output:
(node:2203) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `node --trace-deprecation ...` to show where the warning was created)

Don't know how serious a deprecation / security issue it is, but it would be nice not to see it.

Great, thanks!


Fail to build libmarpa using CMake

Currently, I build libmarpa in the directory build.
Some information:

libmarpa: latest git master branch
CMake 3.15.4
MSVC 10.9.24

Output:
λ cmake ..\cmake
-- Building for: Visual Studio 16 2019
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.18363.
-- The C compiler identification is MSVC 19.24.28314.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Looking for inline
-- Looking for inline - found
-- Checking if NULL == 0
-- Checking if NULL == 0 - yes
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for inttypes.h
-- Looking for inttypes.h - found
-- Configuring done
CMake Error at CMakeLists.txt:91 (ADD_LIBRARY):
  Cannot find source file:

    marpa.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx

CMake Error at CMakeLists.txt:91 (ADD_LIBRARY):
  No SOURCES given to target: marpa

CMake Error at CMakeLists.txt:92 (ADD_LIBRARY):
  No SOURCES given to target: marpa_s

CMake Generate step failed.  Build files cannot be regenerated correctly.

https://colabti.org/irclogger/irclogger_log/marpa?date=2019-12-29#l1
I alerted our IRC channel to this issue.  I don't run any MS OS, and the Microsoft build comes from other volunteers.
A lot of people are offline due to the holidays, so I will wait until next week and alert the IRC channel again then.

Thanks for your rapid reply. I'll wait for the patches.
BTW, thanks for this great project.

I'll go back to the IRC channel on this in the coming week.
The complaint is about a missing marpa.c file.  Is it really missing?  Or is there a naming issue?
The Microsoft support has always been on the basis that those who want it maintain it and I just do upstream stuff -- Microsoft support only exists because someone long ago took the trouble to make sure my C code compiled on Microsoft.  My perception is that some of the original volunteers have lost interest, but we will find out.
If the worst happens, and a Marpa-Microsoft community does not come forward, as a desperate last measure, I will take this on, but I will only do sanity checks under Linux.  If, as is quite probable, no issue appears that I can deal with under Linux, then I will close this issue without a fix, and the documentation will be updated to reflect lack of Microsoft support.  Right now I'm working on a paper on Marpa, and I'd tackle this issue after I finish it.
Hoping for the best on this, jeffrey.

Thanks very much.

I'd hoped to finish a paper I was working on and then move on to this, but the paper is taking longer than expected, so I've moved this to the front of the queue.

I can do a cmake build successfully under Linux with the following commands:
cd libmarpa_repo
make clean
make dists
cd ..
mkdir build
cd build
cmake ../libmarpa_repo/cm_dist
cmake --build .
@tan-wei I don't know if this helps you at all.  I don't have access to any Microsoft environment and, if this doesn't point the way to a solution to your problem, my next step will be to go to the IRC channel and see if anyone is interested in supporting these environments.  (In the past, people have used Windows, and been willing to do some volunteer work, but I'm not sure if anyone is using Windows now.)

Thanks for your reply. But I still have some questions before try the commands under Linux, since I must install a Linux machine.
The error messages from CMake complain that source code file marpa.c is missing, I can't find in the repo, either. I find the commands you give me inculdes make dists. Does it mean that marpa.c is generated by make dists? If yes, I think it's clear for me why I fail to compile it.
Thanks!

Yes, marpa.c is a created file, and will not exist unless make dists is run.  (I used "literate programming" and marpa.c is produced by Don Knuth's Cweb.) If you have not been running make dists, that would certainly explain the problem.  Perhaps now you'll be able to get it working under Windows.

Thanks, quite clear for me.
Let me try it on Linux first. After a successfully try, I will close this issue.


[CGP-337] [StdLib] Removed duplicate names

This finally removes duplicate names from the stdlib in a very simple way: we just rename each term. Some terms already do not have duplicates, but we rename them as well, because it's too easy to make a mistake and decide that a term has no duplicates while it actually has them.
Holed data types can't be renamed that easily, but

they do not contain duplicate names as far as I see
we will remove HoledType anyway, so I don't bother dealing with them right now

Type checking of generated terms is turned on finally and everything type checks correctly.
We need a testing machinery that checks Plutus Core entities for not having duplicate names, but I'll add that later, here I just want to fix a critical bug.
I also removed getBuiltinEnumCountNat. It doesn't really belong to the stdlib. I think, I'll return it later in the form of an "interesting generator", but for now I'm just removing this noise.

I do wish we could track this information on the type level somehow, so the stdlib could produce non-renamed terms and it would just be up to the consumer to rename them before the typechecker will accept them.

I usually like ideas like this, but not in this case. The thing is that whatever we return, it has to contain indices and run in the Quote monad. It's really just simpler to always return terms/types without duplicate names, because it does not complicate the API and the user doesn't have to think whether Uniques are unique or not. Unique Uniques are appropriate in all cases, even when we don't need them.

If going to merge, please squash.


Improve usability of SQL init scripts with multiple file support

Context
Issue originally raised on stackoverflow as a question.
It would be useful to be able to initialize a database with multiple startup scripts. In most projects that I've worked on, there are multiple onboarding scripts (database, schema, data, test-data etc). As such, when provisioning a new database using testcontainers for an integration test, it'd be helpful to be able to execute all of these scripts on startup without needing to merge them into a single script.
Suggestion
An additional API in JdbcDatabaseContainer
/**
  * Execute each script in the order of which they're provided
  */
public SELF withInitScript(String... initScriptPaths) {
    // ...
}

An additional consideration for this API might be the result of 2127

Please reopen this issue. It should be possible to execute multiple init scripts.
My use-case: first script contains definitions of tables (DDL) and another script that is full of testdata.

@bjmi unless somebody wants to work on a PR to support it, keeping an issue open makes little sense. Would you like to work on such PR?
Also, have you considered using Flyway or Spring Boot's built-in support for data/schema SQL files?

can be achieved by using inheritance in OracleContainer class:
`public class MyOracleContainer extends OracleContainer {
private List<String> listInitScriptPaths;

public MyOracleContainer(String dockerImageName) {
	super(dockerImageName);
}

public MyOracleContainer withInitScripts(List<String> listInitScriptPaths) {
    this.listInitScriptPaths = listInitScriptPaths;
    return this;
}

@Override
public void runInitScriptIfRequired() {
	super.runInitScriptIfRequired();
	if (listInitScriptPaths != null) {
		for (String initScriptPath : listInitScriptPaths) {
			ScriptUtils.runInitScript(getDatabaseDelegate(), initScriptPath);
		}
	}
}

}`

I end up using ScriptUtils.runInitScript(databaseDelegate, initScriptPath) directly where needed and don't use JdbcDatabaseContainer.withInitScript(String) at all.
E.g.
@BeforeEach
private void setup() {
    ScriptUtils.runInitScript(new JdbcDatabaseDelegate(CONTAINER, ""), "sql-files/Unittest-ddl.sql");
    ScriptUtils.runInitScript(new JdbcDatabaseDelegate(CONTAINER, ""), "sql-files/Unittest-data.sql");
}

The solution by @bjmi still works.

Hopefully it will help others. If you are using Spring and testcontainers, below worked for me in Spring Boot 3.2.1
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/datasource/init/DataSourceInitializer.html can be used to use multiple sql files.
import org.springframework.boot.SpringApplication;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.boot.testcontainers.service.connection.ServiceConnection;
import org.springframework.context.annotation.Bean;
import org.springframework.core.io.ClassPathResource;
import org.springframework.jdbc.datasource.init.DataSourceInitializer;
import org.springframework.jdbc.datasource.init.ResourceDatabasePopulator;
import org.testcontainers.containers.MSSQLServerContainer;
import org.testcontainers.utility.DockerImageName;

import javax.sql.DataSource;

@TestConfiguration(proxyBeanMethods = false)
public class TestDemoApplication {

    @Bean
    @ServiceConnection
    MSSQLServerContainer<?> sqlServerContainer() {
        return new MSSQLServerContainer<>(DockerImageName.parse("mcr.microsoft.com/mssql/server:latest"));
    }

    @Bean
    public DataSourceInitializer initializer(DataSource dataSource) {

        DataSourceInitializer dataSourceInitializer = new DataSourceInitializer();
        dataSourceInitializer.setDataSource(dataSource);
        // schema.sql and data.sql should be in resources folder under sql folder
        dataSourceInitializer.setDatabasePopulator(new ResourceDatabasePopulator(
                new ClassPathResource("sql/schema.sql")
                , new ClassPathResource("sql/data.sql")));

        return dataSourceInitializer;
    }

    public static void main(String[] args) {
        SpringApplication.from(DemoApplication::main).with(TestDemoApplication.class).run(args);
    }

}

The PR opened 3 months ago: https://github.com/testcontainers/testcontainers-java/pull/7680
Code owner review required, please take a look.


502 server error

Been getting 502 error this week for declutter.1j.nz

Been on the process of moving my vps from Digital Ocean to Vultr. Declutter is currently a casualty that I haven’t fixed yet.
There’s also some other issues making it difficult for me that I need to solve.


Vulkan apps default to my "secondary" GPU, performance issue

Hi!
Not sure if this is the right place. I was redirected here after contacting Feral Interactive support (and subsequently KhronosGroup/Vulkan-LoaderAndValidationLayers/ and mesa developers). I'll just copy/paste what I wrote to them. I think it will explain the issue perfectly well.

Hi Feral!
This isn't really a support request. It's more of a suggestion for improving performance on multi-GPU systems.
I'm on Debian Sid with kernel 4.15 and Mesa 17.3.9 and noticed that Vulkan games, including Rise of the Tomb Raider runs on my secondary GPU.
By switching over to my primary GPU in the Feral launcher, I've increased my benchmark score from 60fps to 73fps (1080p high) and the game runs noticeably smoother. This is something I have to do every time I launch the game because the setting resets between play sessions.
It's a bit weird that the primary GPU is in the bottom of the list. I wonder if this is a RADV issue since it happens in all Vulkan applications, including non Feral apps.

Debian Sid
Kernel 4.15
Mesa 17.3.9
Ryzen 1700X
Asus PRIME X370-PRO
32GiB DDR4-2400 cl14
Sapphire Nitro R9 Fury (two of them)

KhronosGroup/Vulkan-LoaderAndValidationLayers
bugs.freedesktop.org

AFAIK Vulkan spec (or the loader interface doc) does not prescribe any particualar order in the vkEnumeratePhysicalDevices list.
But I do struggle to find a good examples (for all the platforms) of how to choose a good default physical device.
It is not exposed through the API which one is the one currently connected to primary monitor (which would be a reasonable default to choose). Also some OS are somewhat too eager to connect all GPUs to all display ports, which can lead to some performance issues (and you cannot choose by simply querying the presentation support).
A) Should someone who knows what he is doing make such code samples available?
B) Considering this may be nontrivial, would it make sense to add new API to Vulkan querying this stuff (connected monitors, as well as "primary" on platforms having that concept)?
C) Should loader just be nice (outside spec guarantee) and order it for now on platforms where this is feasible?

This seems like a thorny problem. Do we have data on how this app behaves on other platforms?
Would be good to get some feedback from Feral on what might help solve this problem. @Brisse89 do you have contacts you can ping to chime in on this issue?

@nsubtil Well, not really. I noticed a Feral dev subscribed to the mesa bug report though.
To make the problem even more thorny, I believe this app doesn't use the Vulkan API on any other platform.

Hey, Feral dev here.
The problem from our perspective is that in this case we get 2 devices which are pretty much identical. We check for presentation support when picking a device, but here both support presentation, just it is slower from one of them (the one which the display is not connected to). We don't have any information to determine which is "best".
The linked Mesa bug report has some comments from Bas (RADV developer) about the issues here. In the case of having two devices from different vendors (e.g. Intel iGPU + AMD discrete) we can generally assume that the discrete GPU is the better choice (regardless of which the display is connected to), and default to that (which I believe we already do).
For the case of multiple identical devices, it'd be useful to have some API mechanism to identify which device is preferable, for example by letting us know whether, given a physical device and X/Wayland/whatever connection, the display that'd be presented to is connected directly to the device. It'd be preferable if this could be done without a surface (similar to vkGetPhysicalDeviceXcbPresentationSupportKHR), since we do our device enumeration/selection long before we create the main game window and surface.
I'm not sure how feasible that is - also problematic if it's possible to have something like multiple displays connected to different GPUs, but combined into a single desktop.
Side note - the issue in the original post of not remembering the chosen device between runs of the game is our bug and will be fixed soon.

@aejsmith thanks for the feedback.
It sounds like you'd need some sort of display + GPU topology enumeration API to deal with this problem? Does the Windows version of the app in question handle this situation better? Or is this just not an interesting case to solve?

This is a somewhat straight forward API if we can use a VkSurface as the input, but if you just provide a desktop handle (Like an X display connection + screen number), you're likely to just get back a list of all the devices.  For some optimus-like setups (e.g., laptop with external GPU, internal display on integrated GPU, external display on external GPU), which GPU is closest to the display depends on which part of the desktop the window is on, whether a compositor is running, which GPU that compositor is running on, etc.).  If you're running Xinerama, you get similar issues.  If we have a window/VkSurface, we can probably do a reasonably good job of telling you which GPU(s) it spans at its current coordinates + size.
Caveats remain even with the per-window API though: We still need to decide whether you want proximity to the display itself or the desktop compositor though, and keep in mind that nearest isn't always optimal either.  If you're doing optimus/switchable graphics, the user most often wants the least-close GPU to be used.
It would also be good to know what factors led to a design where Vulkan device selection precedes window creation.  It's likely having a window before device selection is going to be vital to making these more complicated topologies work optimally once we get the APIs worked out, so if there's something making that difficult, we should try to address that as well.

If you're doing optimus/switchable graphics, the user most often wants the least-close GPU to be used.

That actually sounds like the simple case. At least it is solved for pre-Vulkan API. There are app profiles, or maybe rules (3D -> DGPU, 2D -> IGPU).
Besides in case both are reported, one would be flagged as INTEGRATED and the other as DISCRETE.

Perhaps this is something that can be helped with a tweak to the RADV driver. The driver could be modified such that it sorts its physical devices so the best choice is first. In this case the device with a monitor attached is better than the one not, all other things being equal. I imagine it would be a simple change and won’t require any new Vulkan API.

Does the Windows version of the app in question handle this situation better? Or is this just not an interesting case to solve?

The Windows version of the app is D3D11/12 - I'm not sure how things are handled there.

This is a somewhat straight forward API if we can use a VkSurface as the input, but if you just provide a desktop handle (Like an X display connection + screen number), you're likely to just get back a list of all the devices. For some optimus-like setups (e.g., laptop with external GPU, internal display on integrated GPU, external display on external GPU), which GPU is closest to the display depends on which part of the desktop the window is on, whether a compositor is running, which GPU that compositor is running on, etc.). If you're running Xinerama, you get similar issues. If we have a window/VkSurface, we can probably do a reasonably good job of telling you which GPU(s) it spans at its current coordinates + size.
Caveats remain even with the per-window API though: We still need to decide whether you want proximity to the display itself or the desktop compositor though, and keep in mind that nearest isn't always optimal either. If you're doing optimus/switchable graphics, the user most often wants the least-close GPU to be used.
It would also be good to know what factors led to a design where Vulkan device selection precedes window creation. It's likely having a window before device selection is going to be vital to making these more complicated topologies work optimally once we get the APIs worked out, so if there's something making that difficult, we should try to address that as well.

The reason we have device selection before window creation is that we have a separate launcher that allows users to choose display settings (including which display they wish the game to run on), and also choose the device to use.
I suppose we could make some hidden dummy windows and VkSurfaces as part of our device enumeration - given that we're giving a choice of which display to use, we could create windows on each display and determine which device is best for each. I think having an API to determine which GPUs a surface currently spans would be reasonable for doing that.
The integrated+discrete situation is easy to solve already - for that, we'd always just default to the discrete using the device type already available, even if it's further away from the display. Really the problem is just the case where there are two discretes which are difficult to differentiate.

Perhaps this is something that can be helped with a tweak to the RADV driver. The driver could be modified such that it sorts its physical devices so the best choice is first. In this case the device with a monitor attached is better than the one not, all other things being equal. I imagine it would be a simple change and won’t require any new Vulkan API.

From the comments on the Mesa bug report it doesn't sound like that'd be easy - it sounds like there's a similar problem that an X connection and possibly a window is needed to reliably determine the "best" device.

dxvk defaults to first non integrated GPU to work around this particular problem in some way. But really isn't it up to the application to decide what GPU to use (or even multiple)? It's rather a question of sane defaults.

As I've already said, we already deal with the integrated + discrete case. The point of this thread is that there isn't an easy way to differentiate identical discrete GPUs.

Thanks for all the feedback. I forwarded this info to the Vulkan WG for consideration.

Hi!
Do you guys have any progress with this? Even a way to select the GPU by the user (in this case by me)?
I have a pc with the following:
Ryzen 7 2700x, 32GB DDR4 RAM 2 RX VEGA64 on primary on secondary, a screen is connected to the primary (and its watercooled), the secondary is an aircooled headless GPU for windows Crossfire gaming. Where its working fine, but in linux sometimes games launch on the primary, but render on the secondary gpu, then they send back the frame to the primary to send it to the screen. Its introducing two problem: latency and the air cooled card is.. air cooled, blower fan type card, so its damn loud (this part is on the way to be solved, but its still latency problem too).
On DXVK the solution is could work, if i wouldnt have two electronically identical card, thus with the same device name and PCI IDs. With vulkaninfo i see the gpus get some "gpu id" 0 and 1, and in lspci they are presented in different location (0b and 0e). It might could be a good idea to either use the location info or the gpu id if i could select it, but have no idea how. Any idea or help about this?
(Im a linux and developer noob, sorry for jumping here like this, just recently migrated to linux and not completly yet... Just learning all there is to learn!)

can you add filter string for chose videocard? like it done in dxvk "DXVK_FILTER_DEVICE_NAME=PITCAIRN"

Still no solution on windows?

I don't generally game on this system, but I load the epic games store from time to time if there's a promotion that I want to grab when I'm not at home.... so I noticed recently that it's refused to start siting "unsupported graphics card", and looking at the log, it's getting "unsupported feature in vulkan", so when I checked I saw this:-
james@morpheous:~$ vulkaninfo | grep "^GPU id"
GPU id : 0 (llvmpipe (LLVM 12.0.0, 256 bits)):
WARNING: lavapipe is not a conformant vulkan implementation, testing use only.
GPU id : 1 (AMD RADV RAVEN (ACO)):
james@morpheous:~$ vkcube
WARNING: lavapipe is not a conformant vulkan implementation, testing use only.
james@morpheous:~$
It seems to suggest that it's picking llvmpipe software rendering over the actual GPU.... could this be related to the issue described above, is there a way to force it to use the hardware, or am I reading this wrong perhaps?

@netlore Yes and no. If an app picks a VK_PHYSICAL_DEVICE_TYPE_CPU device, then frankly it is its own fault.
What I feel is problematic there though is that a non-conformant implementation is listed there at all without any guarding mechanism.

@netlore Yes and no. If an app picks a VK_PHYSICAL_DEVICE_TYPE_CPU device, then frankly it is mostly its own fault.
What I feel is problematic there though is that a non-conformant implementation is listed there at all without any guarding mechanism.

You could try @aejsmith vkdevicechooser. Mesa have an option in it for this, MESA_VK_ device_selection, but its still a no-go for me, while vkdevicechooser is working reliably since ive found it in 2018.

Got same problem with vulkan games on my Setup...
NVIDIA GeForce GTX 1060 3GB (Discrete GPU) with Vulkan 1.2.168 <- PCI X1     - Radeon RX 5500 XT (Discrete GPU) with Vulkan 1.2.170 <- This are Main gpu on X16 Slot     - Radeon RX550/550 Series (Discrete GPU) with Vulkan 1.2.170 <- PCI X1     - Radeon RX550/550 Series (Discrete GPU) with Vulkan 1.2.170 <- PCI X1     - Radeon RX550/550 Series (Discrete GPU) with Vulkan 1.2.170 <- PCI X1
Every game with vulkan simply ingnore main GPU and uses another GPU...  obviously resulting in a mediocre frame rate.


New lint rule: all constructors in React components should accept props

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:
Write code for a React class component that has a constructor which does not accept props or call the super constructor with those props.
Expected Result:
Linter should complain.
Actual Result:
Linter does not complain.
View all open jobs on GitHub

These examples should not cause the linter to complain:
import React from 'react';

class MyComponent extends React.Component {
    constructor(props) {
        super(props);
        this.state = {
            foo: 'bar'.
        };
    }

    render() {
        return <Text>this.state.foo</Text>;
    }
}

class MyNonReactClass {
    constructor() {
        this.someInstanceVar = 0;
    }

    printInstanceVar() {
        console.log(this.someInstanceVar);
    }
}

This example should cause the linter to complain:
import React from 'react';

class MyComponent extends React.Component {
    constructor() {
        // Missing super(props);
        this.state = {
            foo: 'bar'.
        };
    }

    render() {
        return <Text>this.state.foo</Text>;
    }
}

Just curious, but why are we doing this? I'm not following..
Does something bad happen if you do not call super(props) and don't need to access this.props or this.state?
Let's also make sure that any non-react class constructors are not subject to this rule.

Just curious, but why are we doing this?

I actually just created this issue because it was one of the lint rules specified in this doc

Does something bad happen if you do not call super(props) and don't need to access this.props or this.state?

Not that I know of.

This should not cause the linter to complain either yes?

I would think that example would be fine

Ah thanks for the context. Not sure if it is a big problem, but I have definitely been confused once or twice when trying to access this inside a component constructor when I forgot to call super(props) (though I thought maybe React will warn very obviously in the JS console if you do this).

I guess I'd like to just clarify which exact cases are problems for us...
In your examples @roryabraham it sounds like setting an instance variable would be fine without a call to super(), but setting state would not be. But I don't quite understand why. @Justicea83 do you know?

This should not cause the linter to complain either yes?
class RandomClass {
    constructor(whatever) {
        // ...
    }
    // ....
}

Yeah you're right, am factoring that in now


introduce memory trace

Suspicious memory increase has been a big challenge for TiKV. This PR
introduces a way to analyze what is exhausting the memory easily.

/cc @gregwebs, you may be interested as it can help implementing QoS.
/cc @breeswish This can be integrated into existing trace system too.

It would be great to see an example of related work: some other project where a similar approach was taken.

The RFC is inspired by the chromium project, and we use a simplified model that only use a global singleton allocator.
The related work can be checked from https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/.

A POC has been implemented as tikv/tikv#9019, a leak case has been found by the POC as tikv/tikv#10037.


Cannot mute live feeds on camera load

Checklist:

Please try updating to the latest available version.
Please try clearing your browser cache.

[REQUIRED] Card diagnostic information:
{
  "ha_version": "2024.10.2",
  "card_version": "5.2.0",
  "browser": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 Edg/<IP_ADDRESS>",
  "date": "2024-10-22T11:37:16.320Z",
  "frigate_version": {},
  "lang": "en",
  "timezone": "America/Detroit",
  "git": {
    "build_version": "5.2.0-HEAD+g69249b6",
    "build_date": "Fri, 23 Jun 2023 15:26:26 GMT",
    "commit_date": "Thu, 22 Jun 2023 09:21:26 -0600"
  },
  "config": {
    "type": "custom:frigate-card",
    "cameras": [
      {
        "camera_entity": "camera.front_porch_webrtc",
        "webrtc_card": {
          "entity": "camera.front_porch_webrtc"
        },
        "live_provider": "webrtc-card"
      },
      {
        "camera_entity": "camera.doorbell_webrtc",
        "webrtc_card": {
          "entity": "camera.doorbell_webrtc"
        },
        "live_provider": "webrtc-card"
      },
      {
        "camera_entity": "camera.circle_drive_webrtc",
        "webrtc_card": {
          "entity": "camera.circle_drive_webrtc"
        },
        "live_provider": "webrtc-card"
      },
      {
        "camera_entity": "camera.driveway_webrtc",
        "webrtc_card": {
          "entity": "camera.driveway_webrtc"
        },
        "live_provider": "webrtc-card"
      }
    ],
    "live": {
      "auto_mute": "all"
    }
  }
}

type: custom:frigate-card
cameras:
  - camera_entity: camera.front_porch_webrtc
    webrtc_card:
      entity: camera.front_porch_webrtc
    live_provider: webrtc-card
  - camera_entity: camera.doorbell_webrtc
    webrtc_card:
      entity: camera.doorbell_webrtc
    live_provider: webrtc-card
  - camera_entity: camera.circle_drive_webrtc
    webrtc_card:
      entity: camera.circle_drive_webrtc
    live_provider: webrtc-card
  - camera_entity: camera.driveway_webrtc
    webrtc_card:
      entity: camera.driveway_webrtc
    live_provider: webrtc-card
live:
  auto_mute: all

[REQUIRED] Description of problem:
Within the UI for this card, there's an option for Automatically Mute Live Cameras to be "All Opportunities" which puts this setting as "all" in the YAML.  Shouldn't this option automatically set the live camera feeds to a muted state?  If not, how do you accomplish this?  I do not want the audio on unless I tap the unmute button for any of the camera feeds.

What's interesting is the configuration documentation for live auto_mute does not even show the "all" option available or provide any instruction that's clear to accomplish this goal.

[OPTIONAL] Last working release (if known):
[OPTIONAL] Javascript errors shown in the web inspector:

[OPTIONAL] Additional information:

Same here!

Please try the latest beta release and let me know if the issue persists: https://github.com/dermotduffy/frigate-hass-card/releases/tag/v6.0.0-beta.8

Shouldn't this option automatically set the live camera feeds to a muted state?

It should! This may have been fixed already, give the beta release a shot.

Shouldn't this option automatically set the live camera feeds to a muted state?

It should! This may have been fixed already, give the beta release a shot.

I’ve upgraded to the beta, but haven’t been able to fully test due to network connectivity (cellular issues at the moment).  But the all option is no longer in it and breaks the current config.  What’s the recommend setting to have them muted by default?

UPDATE - it looks like the "all" option is no longer available with the beta. And I've now tried all three options available (individually and all together), but none of those configurations start the live camera feeds in a muted state.

OK -- that sounds like a bug. What you are trying to do should definitely be possible (in fact should be the default). Can you hold down your Frigate button again and paste your diagnostics with the new beta version. I will attempt to reproduce.

UPDATE - it looks like the "all" option is no longer available with the beta. And I've now tried all three options available (individually and all together), but none of those configurations start the live camera feeds in a muted state.

OK -- that sounds like a bug. What you are trying to do should definitely be possible (in fact should be the default). Can you hold down your Frigate button again and paste your diagnostics with the new beta version. I will attempt to reproduce.

Here you go.  PLMK what else I can provide to help or test.  Thanks! @dermotduffy
card_version: 6.0.0-beta.8
browser: >-
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 Edg/<IP_ADDRESS>
date: 2024-10-23T16:23:02.730Z
lang: en
timezone: America/Detroit
git:
hash: a869109
build_date: Mon, 14 Oct 2024 00:01:23 GMT
commit_date: Sun, 13 Oct 2024 16:50:47 -0700
ha_version: 2024.10.2
config:
type: custom:frigate-card
cameras:
- camera_entity: camera.garage_webrtc
live_provider: webrtc-card
webrtc_card:
entity: camera.garage_webrtc
live:
auto_mute:
- microphone

UPDATE - it looks like the "all" option is no longer available with the beta. And I've now tried all three options available (individually and all together), but none of those configurations start the live camera feeds in a muted state.

OK -- that sounds like a bug. What you are trying to do should definitely be possible (in fact should be the default). Can you hold down your Frigate button again and paste your diagnostics with the new beta version. I will attempt to reproduce.

Here you go. PLMK what else I can provide to help or test. Thanks! @dermotduffy
card_version: 6.0.0-beta.8
browser: >-
  Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML,
  like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 Edg/<IP_ADDRESS>
date: 2024-10-23T16:23:02.730Z
lang: en
timezone: America/Detroit
git:
  hash: a869109
  build_date: Mon, 14 Oct 2024 00:01:23 GMT
  commit_date: Sun, 13 Oct 2024 16:50:47 -0700
ha_version: 2024.10.2
config:
  type: custom:frigate-card
  cameras:
    - camera_entity: camera.garage_webrtc
      live_provider: webrtc-card
      webrtc_card:
        entity: camera.garage_webrtc
  live:
    auto_mute:
      - microphone

@dermotduffy is there anything I can do in the meantime to force a mute by default?

same issue here, is this resolved ?

v5.4.0

The go2rtc option does not work well on mobile.
The webrtc card works nicely but i can not mute it :(

v5.4.0

That doesn't seem to be a defined release... at least it isn't visible to me, or in HACS.

downloaded from hacs

That's a different repo / fork:

This one is:

not sure how that happened.
Downlaoded from hacs, just removed and re-downloaded but still same issue on latest beta.

I believe this is now fixed. The issue was very simple, webrtc-card starts unmuted, frigate-card always starts (and assumes things start) muted. This should be in the next build. In this case though, you should be able to manually tell webrtc-card to start muted by passing parameters through to it like this:
type: custom:frigate-card
cameras:
  - camera_entity: camera.back_yard
    live_provider: webrtc-card
    webrtc_card:
      muted: true                      <-- This parameter gets passed through


Undeclared dependencies

Hey, thanks for this new package. Looks cool!
I hit an early snag trying to load the library after pip install; I don't think you've declared any of the dependencies. See the Requires field below.
$ pip3 show torch_choice                                                    ─╯
WARNING: Skipping /usr/local/lib/python3.11/site-packages/six-1.16.0-py3.11.egg-info due to invalid metadata entry 'name'
Name: torch-choice
Version: 1.0.2
Summary: A Pytorch Backend Library for Choice Modelling
Home-page:
Author: Tianyu Du
Author-email<EMAIL_ADDRESS>License: MIT
Location: /usr/local/lib/python3.11/site-packages
Requires:
Required-by:

This is easy enough to resolve manually using your requirements.txt file on the repo but it's not something you'd want every user to be doing.

Hi Grant, thank you so much for the suggestion! We have updated the setup.py file accordingly to include this information. Now we have
Name: torch-choice
Version: 1.0.2
Summary: A Pytorch Backend Library for Choice Modelling
Home-page: https://gsbdbi.github.io/torch-choice/
Author: Tianyu Du, Ayush Kanodia, and Susan Athey
Author-email<EMAIL_ADDRESS>License: MIT
Location: /Users/tianyudu/miniforge3/envs/dev/lib/python3.9/site-packages/torch_choice-1.0.2-py3.9.egg
Requires: numpy, pandas, pytorch-lightning, scikit-learn, tabulate, termcolor, torch
Required-by:

The change will be reflected in v 1.0.3. Thank you!


Increase coverage of the clone and sanitize methods

Right now clone is 45% and sanitize around 65%

sanitize will be removed in future release https://github.com/TinkoffCreditSystems/utils.js/issues/3


Clarification needed between setting up from Jar or from source

This section: https://github.com/ihmcrobotics/ihmc-open-robotics-software-tutorials/wiki/Setting-Up-Your-Workspace, helps the user to setup a workspace to work with IHMC software stack directly from source, i.e. import the IHMC software directly in the workspace alongside the user's code.
The tutorials on the other hand show how to set up a workspace depending on the IHMC software stack via Jar dependencies, i.e. the IHMC software is not imported directly in the workspace, instead, Jars are added as dependencies to the user's code.
The distinction between these 2 modes isn't quite clear in the Wiki. However, the difference can be quite important, especially since depending on the IHMC software from source complexify the setup and increase computational load when compiling.
We may want to re-think the structure, because maybe it is working against us to clarify that. Maybe we'd want in the structure to have the 2 setup side-by-side which would help making it clear that they are different.
Let's talk about it at some point

Oh well, I just discovered that you moved the tutorial setup next to the other one. Alright, so I guess it is mostly a wording issue then :)


west build.pristine=auto by default is dangerous

If a user accidentally runs cmake -DBOARD=<board> path/to/sample at the root of a repository, several files will be created.
The user of course has the responsibility cleanup this mess.
However, in case the user calls west build after such a mistake, west will destroy the users complete repository.
And this must not happen.
To reproduce: (WARNING This procedure will wipe your repo.)
$ west init -m https://github.com/nrfconnect/sdk-nrf
$ west update
$ cd nrf
$ cmake -GNinja -DBOARD=nrf52840dk_nrf52840 samples/bluetooth/peripheral_bms/
# Failed, user doesn't clean up

# 2 months later, now using west
$ west build -b nrf52840dk_nrf52840 samples/bluetooth/peripheral_lbs/
-- west build: making build dir /tmp/ncs/nrf pristine   # <--- west doing a pristine at my toplevel, not in a build folder :-(
-- west build: generating a build system
CMake Error: The source directory "/tmp/ncs/nrf/samples/bluetooth/peripheral_lbs" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
FATAL ERROR: command exited with status 1: /usr/bin/cmake -DWEST_PYTHON=/usr/bin/python3 -B/tmp/ncs/nrf -S/tmp/ncs/nrf/samples/bluetooth/peripheral_lbs -GNinja -DBOARD=nrf52840dk_nrf52840
# Wow, did this really happen to me !#$@#%#^%$%

$ ls
# Nothing

$ git status
fatal: not a git repository (or any of the parent directories): .git

and the repo is gone, and ALL local work has been lost.

West build just runs pristine.cmake. It has a little bit of extra checking to try to avoid running pristine.cmake in anything that isn't a valid zephyr build directory, but I think this is a build system "bug" if it is even a bug at all, and should likely be handled there.

West build just runs pristine.cmake. It has a little bit of extra checking to try to avoid running pristine.cmake in anything that isn't a valid zephyr build directory, but I think this is a build system "bug" if it is even a bug at all, and should likely be handled there.

Fixed the title 😉

Fixed the title 😉

from pristine.cmake:
# NB: This could be dangerous to execute, it is assuming the user is
# checking that the build is out-of-source with code like this:

from pristine.cmake:
# NB: This could be dangerous to execute, it is assuming the user is
# checking that the build is out-of-source with code like this:

West build just runs pristine.cmake.

This is exactly the problem.
west unconditionally tries to outsmart the user and do a pristine build as its default behavior.
Even in a fresh workspace.
A user doing ninja pristine in the repo root is asking for trouble, but a user doing west build should not experience this.
So the problem is that west build tries to outsmart the user.
Changed title back, as it is west build that decided to run pristine in the first place

West build just runs pristine.cmake.

This is exactly the problem.
west unconditionally tries to outsmart the user and do a pristine build as its default behavior.
Even in a fresh workspace.
A user doing ninja pristine in the repo root is asking for trouble, but a user doing west build should not experience this.
So the problem is that west build tries to outsmart the user.
Changed title back, as it is west build that decided to run pristine in the first place

from pristine.cmake:
# NB: This could be dangerous to execute, it is assuming the user is
# checking that the build is out-of-source with code like this:

The problem here is not the pristine, that is documented.
The problem is west build automatically doing it, even when it should not.
Suggestion, west build should never call pristine, if folder is having .git or .west.

from pristine.cmake:
# NB: This could be dangerous to execute, it is assuming the user is
# checking that the build is out-of-source with code like this:

The problem here is not the pristine, that is documented.
The problem is west build automatically doing it, even when it should not.
Suggestion, west build should never call pristine, if folder is having .git or .west.

This is exactly the problem.
west unconditionally tries to outsmart the user and do a pristine build as its default behavior.
Even in a fresh workspace.

If that's the problem, then I see no choice but to revert https://github.com/zephyrproject-rtos/zephyr/pull/31364.

Suggestion, west build should never call pristine, if folder is having .git or .west.

Sorry, but NAK.
I refuse to make west get into a guessing game about what it should and should not run pristine on. We can turn off build.pristine=auto by default, forcing users to specifically ask for it, but if we start this guessing game we will be playing whack-a-mole forever.

This is exactly the problem.
west unconditionally tries to outsmart the user and do a pristine build as its default behavior.
Even in a fresh workspace.

If that's the problem, then I see no choice but to revert https://github.com/zephyrproject-rtos/zephyr/pull/31364.

Suggestion, west build should never call pristine, if folder is having .git or .west.

Sorry, but NAK.
I refuse to make west get into a guessing game about what it should and should not run pristine on. We can turn off build.pristine=auto by default, forcing users to specifically ask for it, but if we start this guessing game we will be playing whack-a-mole forever.

Suggestion, west build should never call pristine, if folder is having .git or .west.

Sorry, but NAK.
I refuse to make west get into an even bigger guessing game about what it should and should not run pristine on. We can turn off build.pristine=auto by default, forcing users to specifically ask for it, but if we start this guessing game we will be playing whack-a-mole forever.

IMO there is a huge difference between removing some folder with data, and then removing a complete git repository with local branches, reflog history, and so on (you removed .git so there is NO returning back).
Or even worse, removing the whole west workspace with several repos.
Therefore I believe it can be justified to check for existence of .git or .west.

Suggestion, west build should never call pristine, if folder is having .git or .west.

Sorry, but NAK.
I refuse to make west get into an even bigger guessing game about what it should and should not run pristine on. We can turn off build.pristine=auto by default, forcing users to specifically ask for it, but if we start this guessing game we will be playing whack-a-mole forever.

IMO there is a huge difference between removing some folder with data, and then removing a complete git repository with local branches, reflog history, and so on (you removed .git so there is NO returning back).
Or even worse, removing the whole west workspace with several repos.
Therefore I believe it can be justified to check for existence of .git or .west.

Maybe you misunderstood me. Nobody thinks that deleting a project repository, .west, or the workspace topdir is a good thing. That's not what I'm saying.
What I am saying is that if we refuse to pristine using code that works 99% of the time, we still have a 1% chance of deleting some file, like /path/to/file, that someone really wants, just because they incorrectly created a zephyr build directory in in a parent directory, like /path.
Then we'll chase that 1% and get something that works 99.9% of the time. And so on. No thanks.

Maybe you misunderstood me. Nobody thinks that deleting a project repository, .west, or the workspace topdir is a good thing. That's not what I'm saying.
What I am saying is that if we refuse to pristine using code that works 99% of the time, we still have a 1% chance of deleting some file, like /path/to/file, that someone really wants, just because they incorrectly created a zephyr build directory in in a parent directory, like /path.
Then we'll chase that 1% and get something that works 99.9% of the time. And so on. No thanks.

What I am saying is that if we refuse to pristine using code that works 99% of the time, we still have a 1% chance of deleting some file, like /path/to/file, that someone really wants, just because they incorrectly created a zephyr build directory in in a parent directory, like /path.

I strongly disagree there.
We know that Zephyr build system will never create a .git or .west folder, and we know that it is hazardous to remove those directoriesm as there is no coming back.
If a user creates a important-file.keep, and don't put it under version control, then that file could still risk being deleted by other means, like git clean. If the file is important, then it should be under version control.
But removing .git means that even files under version control gets removed, so I see a big difference in doing something we know is wrong in 100%  of the cases, and we decide not to prevent it, and then your use-case of whether we should handle a case we cannot know about.

What I am saying is that if we refuse to pristine using code that works 99% of the time, we still have a 1% chance of deleting some file, like /path/to/file, that someone really wants, just because they incorrectly created a zephyr build directory in in a parent directory, like /path.

I strongly disagree there.
We know that Zephyr build system will never create a .git or .west folder, and we know that it is hazardous to remove those directoriesm as there is no coming back.
If a user creates a important-file.keep, and don't put it under version control, then that file could still risk being deleted by other means, like git clean. If the file is important, then it should be under version control.
But removing .git means that even files under version control gets removed, so I see a big difference in doing something we know is wrong in 100%  of the cases, and we decide not to prevent it, and then your use-case of whether we should handle a case we cannot know about.

I think #31364 addresses the issue in west build, and I've adjusted the title yet again to reflect what I think west is responsible for here.

This is a bug PR, and the title should reflect the bug.
The fact that build.pristine=auto is dangerous is not in itself a bug, just like rm -rf / is not a bug.
But if mkdir / would do a rm -rf / in it's default setup, then that would be a bug.
It is a bug that west build in it's default configuration may remove a users .git folder, and the title should reflect the nature of the bug, to allow people to notice it. The fact it happens because west build defaults to pristine=auto is an implementation detailt, and that people can configure a different behavior is a workaround. pristine=auto is not in itself an error, as long as that option is an opt-in, and the fact that this option is dangerous should be highlighted in the docs.
So, as a bug title:

west build might destroy your repository, as it is defaulting doing pristine.

is correct as it do describe the outcome of the bug, and that it happens in its default setup.

I think #31364 addresses the issue in west build, and I've adjusted the title yet again to reflect what I think west is responsible for here.

This is a bug PR, and the title should reflect the bug.
The fact that build.pristine=auto is dangerous is not in itself a bug, just like rm -rf / is not a bug.
But if mkdir / would do a rm -rf / in it's default setup, then that would be a bug.
It is a bug that west build in it's default configuration may remove a users .git folder, and the title should reflect the nature of the bug, to allow people to notice it. The fact it happens because west build defaults to pristine=auto is an implementation detailt, and that people can configure a different behavior is a workaround. pristine=auto is not in itself an error, as long as that option is an opt-in, and the fact that this option is dangerous should be highlighted in the docs.
So, as a bug title:

west build might destroy your repository, as it is defaulting doing pristine.

is correct as it do describe the outcome of the bug, and that it happens in its default setup.


Proposal: Make the side nav toggleable on FaaS UI

Expected Behaviour

When the screen is smaller than a certain width (probably 960px?), the side nav should be hidden and toggleable.
Current Behaviour

When the screen is smaller than a certain width (probably 960px?), the side nav is hidden but not toggleable. Therefore, people who don't know this behavior get lost in how to create function, find functions, etc.
Possible Solution

Add a toggleable icon on the top left (perhaps?).  And let people see the side nav even though the screen width small.
Steps to Reproduce (for bugs)

Open the gateway UI
Make the browser window width small.
(Tested it on Chrome and Firefox but all the browsers should have the same problem)

Context

If the side nav gets hidden, it's pretty much impossible to do anything with the UI.
Your Environment

Operating System and version (e.g. Linux, Windows, MacOS):
MacOS

Link to your project or a code example to reproduce issue:
Screenshot

I'll take a look at this this week if there's no problem on that.

Please do

@alexellis how about something like this? Just added a few lines for a toggle button and added a svg in assets/img/icons/menu.svg from the material design icons.

I'll create a PR if it's ok or edit it more if there is more to do.
The bootstrap.js is getting cumbersome so maybe we should componetize it in some point.

@kenfdev looks good 👍

Derek add label: enhancement

Very nice 💯

Derek add label: priority/middle


[289] fixed response status code for /user/profilePicture endpoint from 500 to 200

Pull request related to issue #289
Preconditions
Moved to Swagger http://localhost:8060/swagger-ui.html#/
Sign-in as Admin
Steps to reproduce

Click on User controller.
Click on PATCH /user/profilePicture.
Click on 'Try out'.
Enter valid params.

Changes:

Updated SecurityConfig to permit access to /error endpoint.
Fixed UserController updateUserProfilePicture() method to resolve NullPointerException (500 Internal Server Error raises).
Added spring-security-test and spring-boot-starter-test dependencies to test UserController with enabled SpringSecurity.
Added additional tests cases for UserController to test secured /user/deleteProfilePicture endpoint.

NOTES: Annotation @AuthenticationPrincipal returns username (String) as email of authenticated user.

Results:

Without authentication

With authenticated ADMIN role

NOTES: Swagger returns response status code 400 with authenticated ADMIN role as it's impossible to load image via Swagger to test endpoint.

It also gives 200 If you signed-in as USER. You can add it as a separate bug to the board and solve it


Revert "show message if tab doesn't reload after install"

Reverts gyazo/gyazo-chrome-extension#62

I will revert because it occurs error