PlayerJoinEvent improvements

The ability to change a player's spawn location on join would be a nice bonus to this event.

Why would that be better than event.getPlayer().setLocation(..)?

Traditionally there has been problems with setting the spawn point on join. Maybe it was due to when the event was being called.

If that is the case then we can look at it, but otherwise there is no point for the change. And if that is the case ideally we'd fix this by solving the issue of using event.getPlayer().setLocation(...) rather than modifying the event. So basically this needs some testing.

Tested. Everything works fine. Code:
@Subscribe
public void JoinEvent (PlayerJoinEvent event){
Player player = event.getPlayer();
Location spawnLocation = player.getWorld().getSpawnLocation();
player.setLocation(spawnLocation);}

Excellent.

So you would prefer having to grab the player, grab the location (if required) from the player, and then set the location - versus having a getter/setter in the method directly? So you'd prefer countless plugins to set the player's location on join, rather than having an event to set the location once? Interesting.
I'm confused by the handling of this issue. @Zidane assigned it to a milestone, and @Deamon5550 closed it. Could someone explain why?

It doesn't make a whole lot of sense to offer a method for this. In my opinion, the API shouldn't be bogged down with tons of extra methods simply because there might be a use case for them. If plugins need this functionality, it will only take 1 or 2 extra lines to make it happen.

Reopening as we don't want to continue calling events from setPosition from every plugin changing a player's position when we can set whoever came last after event is called.

I would still argue that creating any such methods which may set any of a player's attributes inside a simple event aka notification is a bad idea with the main reasons being the following two thoughts on design:
Take for instance that you will find other attributes you might want to change directly as well because there would be events which would get dispatched while still processing the outer event. You would probably just add another method as there would be no reason against it if you chose to add it this time.
Another consideration is that an event still is an event. It is not supposed to be something you modify something else with. It's just there in order to notify you of something, possibly passing in some arbitrary context you might need for interpreting the event (in the case the player reference) and possibly making any adjustments to it. In my opinion you should keep it like this in order to not bloat the API.
As for the dispatching of possibly unnecessary PlayerMoveEvents (or similar) you might also introduce a technique of locking event dispatchment while still processing certain kinds of events. Or you might even want to take it one step further into locking down event dispatchment in such a way that only the last event of a type dispatched from inside an event handler which is processing a lockable event is actually dispatched afterwards. This would also increase chronological ordering of your events which is much more natural to me at least. So I would definitely prefer this technique over the one described above.

@Zidane can you explain what you mean by your comment a little more clearly?

Would it be smart to add some form of Positionable interface to deal with this? For use in any event where one might want to alter the position of the event?


Fix embedded ansible spec tests

https://github.com/ManageIQ/manageiq-providers-ansible_tower/pull/10 changed the notification name from Tower to EMS, update the specs for embedded ansible to match.

Rekicked Travis just so it runs on the latest that fixes the other issues.


[BUG] Insanely Laggy UI

Describe the bug
There's a significant performance issue, particularly concerning UI lag during scrolling. The UI experiences significant delays, negatively impacting the overall user experience and rendering the app unusable
Steps to Reproduce:

Open the Gallery app

Attempt to scroll through the Timeline/Albums with a lot of Photos

Recordings:
https://github.com/IacobIonut01/Gallery/assets/126700686/ed8ac5b1-4b36-423e-a7fa-eba5cec4a6b0
Additional Information:
This issue persists with all of my other devices as well, despite them having decent SOC's [Galaxy S6 Edge, OnePlus Nord 2T]
I've also tried older releases as well to see if that fixes the lag but it's the same story
Here is the logcat if that helps;
logcat.txt

Device tested on:
Device: Realme Pad
OS: Android 13 [ArrowOS 13.1]

sorry.

sorry.

No problem!


Trying to add In-Memory module, getting error

Trying to integrate the new in-memory module for testing purposes, but Gradle is unable to find it

The relevant part of our build.gradle.kts:

Any help would be much appreciated!

Update: moving maven { url = uri("https://dl.bintray.com/kodein-framework/Kodein-DB") } from our buildscript repositories block to allprojects seemed to have fixed this issue.


[Bug]: Speaker ID not working anymore

Project Version
Your local version 3.2.6 is the latest version.
Platform and OS Version
Linux x64
Affected Devices
PC
Existing Issues
No response
What happened?
When i write the speaker ID and click out the text box it become empty
Steps to reproduce

...
Expected behavior
select speaker id
Attachments
No response
Screenshots or Videos
https://github.com/user-attachments/assets/ef5a3102-d18f-4582-8f7d-d17c44268b1f
Additional Information
Also tried to press enter after fill the field, nothing works.
Please also remove speaker id from advanced please

speaker id is in conflict with transpose value,  because now it started to work again, but it's showing 0 to 11 to wrong index and is acting like transpose now.

New info
the bug is on batch inference tab, single is working properly

maybe related to this snippet on tabs/inference/inference.py
refresh_button.click(
    fn=change_choices,
    inputs=[model_file],
    outputs=[
        model_file,
        index_file,
        audio,
        sid,
    ],
)

i'm not gradio expert but seems refresh button only refresh sid and not sid_batch


Add required ReadTheDocs configuration

Should fix broken RTD doc builds. Needed because of https://blog.readthedocs.com/migrate-configuration-v2/

Codecov Report
Attention: Patch coverage is 71.42857% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 95.13%. Comparing base (80795ad) to head (0c9ec71).
Report is 24 commits behind head on master.

Files
Patch %
Lines

medallion/common.py
66.66%
2 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #183      +/-   ##
==========================================
- Coverage   95.25%   95.13%   -0.12%
==========================================
  Files          26       24       -2
  Lines        2822     2959     +137
==========================================
+ Hits         2688     2815     +127
- Misses        134      144      +10

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Documentation update - toolkit segments

Context
Following #69, the deployer service has changed. New deployer allows for much easier deployment of multi-contract projects, as well as performs compilation at the deployment activity. We must update all documentation sections where the deployer of the Toolkit is mentioned.
User flow

Developer comes to the documentation at https://docs.massa.net/en/latest/.

Goes to segment "Web3 developers"

All guides are updated and correspond to the latest Toolkit's tools (compiler, deployer)

How to
Update docs and examples with correct commands and code.
Technical details
tbd
QA testing

Tag Ena and Nathan as reviewers
Request a review from a Dev from another team (i.e: core), to follow the given instructions in the Documentation and report of any inconsistencies.

tackle https://github.com/massalabs/massa-docs/issues/80 jointly


Panic in GitHub Actions

#33 747.5 thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-chef-0.1.12/src/skeleton.rs:244:60
#33 747.5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
#33 ERROR: executor failed running [/bin/sh -c cargo chef cook --release --recipe-path recipe.json]: exit code: 101

The project itself is closed source. I think I can share specific relevant bits if you direct me.

Hi!
To debug I'd say that we need:

the version of cargo-chef you are using;
your Cargo.toml files.

Hi!
To debug I'd say that we need:

the version of cargo-chef you are using;
your Cargo.toml files.

We saw the same today here:
https://github.com/paritytech/parity-bridges-common/runs/1732103007?check_suite_focus=true#step:7:1488
cargo-chef version:
Installed package cargo-chef v0.1.12(executablecargo-chef)

We saw the same today here:
https://github.com/paritytech/parity-bridges-common/runs/1732103007?check_suite_focus=true#step:7:1488
cargo-chef version:
Installed package cargo-chef v0.1.12(executablecargo-chef)

Interesting - it points to this line: https://github.com/LukeMathWalker/cargo-chef/blob/e1a1697c7886e5a18940acc6f91cc0f4025f37d7/src/skeleton.rs#L244
I'll try to do some debugging this evening.

Interesting - it points to this line: https://github.com/LukeMathWalker/cargo-chef/blob/e1a1697c7886e5a18940acc6f91cc0f4025f37d7/src/skeleton.rs#L244
I'll try to do some debugging this evening.

Actually, I just released a patched version that should solve the issue (0.1.13) - can you confirm @tomusdrw @mkpankov?

Actually, I just released a patched version that should solve the issue (0.1.13) - can you confirm @tomusdrw @mkpankov?

@LukeMathWalker Our CI passes with v0.1.13, so I think you can close this 🎉

@LukeMathWalker Our CI passes with v0.1.13, so I think you can close this 🎉

Awesome - thanks for confirming @HCastano 😁

Awesome - thanks for confirming @HCastano 😁


tikv-ctl: add region state to raft region command output

What is changed and how it works?

Issue Number: Close #17037

What's Changed:
add region state to `raft region` command output

Sample output from a test cluster(the "state": "Normal", is newly added after this PR):
$ /tikv-ctl --host <IP_ADDRESS>:20180 raft region -r 6356

{
  "region_infos": {
    "6356": {
      "region_id": 6356,
      "region_local_state": {
        "region": {
          "id": 6356,
          "state": "Normal",
          "start_key": "748000000000000AFF0B5F728000000000FF4BF0F00000000000FA",
          "end_key": "748000000000000AFF0B5F728000000000FF529AAB0000000000FA",
          "region_epoch": {
            "conf_ver": 1,
            "version": 223
          },
          "peers": [
            {
              "id": 6357,
              "store_id": 1,
              "role": "Voter"
            }
          ]
        }
      },
      ...
    }
  }
}

Related changes

[ ] PR to update pingcap/docs/pingcap/docs-cn:
[ ] Need to cherry-pick to the release branch

Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Release note

None

/retest

/merge

/run-cherry-picker

/cherry-pick release-8.1


when async the withCredentials is flase

Version
v2.0.0
Reproduction link
https://github.com/nuxt/nuxt.js/issues/new
Steps to reproduce
.
What is expected ?
when async send axios data  the withCredentials is flase
bug in client  it is true
What is actually happening?
when async send axios data  the withCredentials is flase
bug in client  it is true
Additional comments?
when async send axios data  the withCredentials is flase
bug in client  it is true

This bug report is available on Nuxt community (#c8539)

I think I am having an issue with this too. I have project using server session cookie (not jwt) on nuxt with an external API server. My Auth completely stopped working (it's completely broken) after I upgraded nuxt. It is not passing credentials to the server any more. I am not near my computer now but i will check later to see what version was working. I believe it broke when I upgraded

This is my config...
I believe this was working in nuxt v2.3.1 and now it is not working. I'm not 100% certain because I have a lot of nuxt projects, and I was in the middle of upgrading some from nuxt 1.x to nuxt 2.x -- when I go back through my git history for this project, it was set to nuxt-latest....
This is a bit speculative on my part about a possible bug with withCredentials, but I do know my Cookie Login flow used to work on this project and now it is completely broken.
I've tried rolling back to 2.3.1 (deleted node_modules & package-lock) and reset my package.json to point to nuxt 2.3.1, but the builder is showing 2.4.3 -- not sure how to roll the nuxt builder back to 2.3.1 -- it is also possible that I was running 1.44 (or newer)...
    strategies: {
      local: {
        endpoints: {
          login: { url: '/login', method: 'post' },
          logout: { url: '/logout', method: 'post' },
          user: { url: '/user', method: 'get' }
        }
      },
      tokenRequired: false,
      tokenType: false
    }
...

  axios: {
    credentials: true,
    proxy: true,
  },

  proxy: {
    '/api': { target: 'http://localhost:3000/api/v1', pathRewrite: {'^/api/': ''} },
    '/accounts': { target: 'https://accounts.mydomain.com/api/check-access/....' },
  }

@manniL if you want me to open a new issue with better detail, please let me know. I'd love to help to resolve this, and would definitely like to help to "tidy up" the documentation wrt Cookie Login flow (I find that the documentation is not explicit enough on what differences are needed for Cookie Login flow vs JWT login flow.

ok - so I rolled back to nuxt v1.4.4 (and made some small nuxt config changes for the build) and BOOM! my project is running again. I seriously think there's some sort of issue with Cookie Login flow on nuxt 2.x

is this issue reported in the wrong repo? perhaps it should be put in "auth-module" repo? https://github.com/nuxt-community/auth-module/issues @manniL let me know and I can make a new issue over there if you prefer (then we can close this) - I do know that without changing any code, withCredentials works in nuxt 1.4.4 but not in at least 3 versions of nuxt 2.x

You are right! I think it would fit better in the repo of the auth module.
Don't forget that there are huge internal changes between 1.x and 2.x


Feature Request: Retain Export Preferences

Love the update! I think one thing that would be excellent is if you had the option to retain the color, font, and general fps settings in trdrop so you didn't have to re-configure it each time you open the program or add a new file! This would be great especially when you're doing multiple analysis passes.

Yea that's a good idea, I already forgot that this was the plan from the start but I'll look into it for sure.

Yea that's a good idea, I already forgot that this was the plan from the start but I'll look into it for sure.


Update microservices-intro.md

Added some content to cover the bounded context and APIM policies. In my view, these are two important aspects. Thnaks

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

Hi @ckittel - Thanks for your review. In this repository, pull requests should be approved by a member of the content team or the product team.
@doodlemania2 or @EdPrice-MSFT - Could you review the proposed update?
Thanks.

@ktoliver -- just curious what I'm considered here?  @doodlemania2 -- are we not supposed to be part of that group?  Or is it just PMs?

Well that's awkward lol - yes, everyone on PnP should be in the approvers list - @ktoliver can we make sure that list gets an update?

Sorry, making things awkward is sometimes the only thing I'm good at.  Carry on folks. :)

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

Hello,
I don't see changes to https://docs.microsoft.com/en-us/azure/architecture/microservices/ page yet, is there a time interval when changes are being pushed.
Thanks and Regards
Vidya Vrat Agarwal (He/Him). Microsoft MVP+1-215-917-2091
www.MyPassionFor.Net
On Friday, April 9, 2021, 09:00:41 AM MST, Kristine Toliver<EMAIL_ADDRESS>wrote:

Merged #2755 into master.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

There is indeed a delay. I believe this specific change is scheduled to go live within 24 hours, it's in our main publish branch -- just waiting on the next publish to occur.  Thanks for asking/checking.


clashleaders.clash.api.ApiTimeout in GET /clan/swd-lrfdyn-yc9ucprc.xlsx

Error in ClashLeaders
clashleaders.clash.api.ApiTimeout in GET /clan/swd-lrfdyn-yc9ucprc.xlsx
API timed while fetching #YC9UCPRC clan.
View on Bugsnag
Stacktrace
clashleaders/clash/api.py:61 - find_clan_by_tag
clashleaders/model/clan.py:61 - fetch_and_save
clashleaders/views/clan.py:157 - clan_from_days_ago
clashleaders/views/clan.py:58 - clan_detail_xlsx

View full stacktrace
Created automatically via Bugsnag

An error linked to this issue has been marked as fixed in Bugsnag
clashleaders.clash.api.ApiTimeout in GET /clan/warriors-yv08p98l.xlsx

An error linked to this issue has been reopened in Bugsnag
clashleaders.clash.api.ApiTimeout in GET /clan/bisaya-world-808vgpcc.xlsx

An error linked to this issue has been marked as fixed in Bugsnag
clashleaders.clash.api.ApiTimeout in GET /clan/lkwsr-2r0vrvyj.xlsx

An error linked to this issue has been marked as fixed in Bugsnag
clashleaders.clash.api.ApiTimeout in GET /clan/dutchroyale-2029r8vyu.xlsx

An error linked to this issue has been reopened in Bugsnag
clashleaders.clash.api.ApiTimeout in GET /clan/matrix-jcc9jjuq.xlsx

An error linked to this issue has been marked as fixed in Bugsnag
clashleaders.clash.api.ApiTimeout in GET /clan/good-vibes-jql8pjcg.xlsx

An error linked to this issue has been reopened in Bugsnag
clashleaders.clash.api.ApiTimeout in GET /clan/hua-xia-cyvu29g8.xlsx

An error linked to this issue has been marked as fixed in Bugsnag
clashleaders.clash.api.ApiTimeout in GET /clan/hua-xia-cyvu29g8.xlsx

An error linked to this issue has been marked as fixed in Bugsnag
clashleaders.clash.api.ApiTimeout in GET /clan/CYYC89U/refresh.json


Add Setapp

Setapp - The best apps for Mac in one suite: https://setapp.com

Subscribed to it since they were on beta, now I've made the subscription to the annual plan. Setapp is a subscription service of Mac apps.
This service is provided by MacPaw, which is famous for Clean My Mac (as well as Clean My PC) and Gemini. It might worth to mention that they acquired The Unarchiver.
Some noticeable apps that I use continuously are:

Clean My Mac X
iStat Menus
2Do
Paste
Marked
Ulysses
Bartender
Archiver
Numi
IconJar
Image2icon
Sip
Boom 3D
HazeOver
Folx
Noizio

And yes, there are more apps available: https://setapp.com/apps
All apps are full version, no more in-app purchase.
Issue Checklist

[ x ] I have checked for other similar issues
[ x ] I have explained why this change is important
[ x ] I have added necessary documentation (if appropriate)

I'm surprised Setapp is not on the list yet.


Emoji

Emojis are working now

@harshitmittal99 maybe you should see #47.

thanks lalit, I will update the pr.

My suggestion is to use https://github.com/iamcal/js-emoji . and jsDeliver for the emoji images.
If you look into the code of js-emoji, you will see it is setting paths of the images and sheets, so for it  the code would be something like this -
for (var i in emoji.img_sets){
	emoji.img_sets[i].path = 'https://cdn.jsdelivr.net/npm/emoji-datasource-' + i +<EMAIL_ADDRESS>+ i + '/64/';
	emoji.img_sets[i].sheet = 'https://cdn.jsdelivr.net/npm/emoji-datasource-' + i +<EMAIL_ADDRESS>+ i +'/sheets/64.png';
}

Closing in favour of #50.


smithay-client-toolkit fails 1.24.1 Linux builds

The root cause seems to be from stb_truetype, which is depended on by smithay-client-toolkit via andrew via rusttype.

Yes, some of our dependencies have made patch versions upgrades breaking rustc compatibility, however SCTK remains 1.24.1 compatible if these dependencies are forced to their older versions.
We are testing this in our travis script, like so: https://github.com/Smithay/client-toolkit/blob/6538cab77a6bde08d6784f8f1ebe818de38e0045/.travis.yml#L61-L68
This way, SCTK can remain its rustc compatibility without locking itself out of dependencies updates. I guess we could do the same thing for winit?

We could. I'm not sure if that's really in the spirit of guaranteeing 1.24.1 compatibility, though - I read it as "you can download a copy of this library off crates.io and use it with 1.24.1 with no extra steps", which that doesn't really do.

I agree with @Osspial that superficially making the CI pass isn't in the spirit of maintaining compatibility. I've created an issue on stb_truetype that will hopefully lead to an elegant resolution.

For the record before I forget (am on mobile right now), rusttype itself also broke the compatibility with their 0.7.2.
Their only change from 0.7.1 is the update of their dependency ordered-float to 1.0, which does not compile on 1.24.1.
Le 11 novembre 2018 21:53:00 GMT+01:00, Francesca Plebani<EMAIL_ADDRESS>a écrit :

I agree with @Osspial that superficially making the CI pass isn't in
the spirit of maintaining compatibility. I've created an issue on
stb_truetype
that will hopefully lead to an elegant resolution.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tomaka/winit/issues/698#issuecomment-437703819

At this point, I'm leaning towards just increasing the minimum required Rust version. It's been 6 months since we chose 1.24.1. Now Ubuntu 16.04 is up to 1.28.0, and 1.28.0 is just as old as 1.24.1 was when we picked it. It's still unclear to me how important it is to be conservative with the required version, but either way, staying further back increases maintenance costs.

I'm okay with doing that. I'm not aware of many reasons for enforcing a minimum version besides making sure code works on commonly-available distributions of Rust. If commonly-available distributions support a newer version, I don't see the point in sticking with a version that requires a significant amount of work on our end to support.

I also agree. I was on my side pondering the question of bumping the rust version in wayland-rs/sctk to improve the code with more recent rust features, but restrained myself to not break winit's guarantee.

Should changing to 1.28.0 require a bump to 0.19.0? 0.18.0 already doesn't compile out of the box on 1.24.1, so it's sort of already an unlisted breaking change.

Well, in that case it's just a matter of updating the readme and the travis build I'd say.


Resampler fails for pd.Series if the column is not selected

Normally, plotly allows one not to specify (the only) column of a series one is plotting. So the following code works fine:
fig = go.Figure()
ser = pd.Series(index = np.arange(100), data = {'a': np.arange(100)})
fig.add_trace(
go.Scattergl(
    x=ser.index,
    y=ser,
)
fig.show()

However, it fails when combining it with the FigureResampler with the following error:
C:\tools\miniconda3\envs\stat-analysis-3.7\lib\site-packages\plotly_resampler\figure_resampler.py in add_trace(self, trace, max_n_samples, downsampler, limit_to_view, hf_x, hf_y, hf_hovertext, **trace_kwargs)
    531             if pd.isna(hf_y).any():
    532                 not_nan_mask = ~pd.isna(hf_y)
--> 533                 hf_x = hf_x[not_nan_mask]
    534                 hf_y = hf_y[not_nan_mask]
    535                 if isinstance(hf_hovertext, np.ndarray):

IndexError: too many indices for array: array is 1-dimensional, but 2 were indexed

The problem is solved by specifying the column of the series to plot, i.e. y=ser['a']. It took me several minutes to find it though and I guess plotly-resampler was designed to be transparent.
Perhaps, an if instance(pd.Series) could be added to treat this specific case? Or could there be another way for checking if isna that works for such series as well?
In any way, thanks for the great software!

Hi,
Thanks for creating this issue!
While trying to reproduce your error, I discovered the following;
ser = pd.Series(index=np.arange(100), data={'a': np.arange(100)})

creates a pd.Series with all (i.e., 100) nan-values.
Changing this to
ser = pd.Series(index=np.arange(100), data=np.arange(100), name="a")

results in the expected outcome; a series of 100 ints.
Then, your updated snippet looks like this
fig = FigureResampler(go.Figure())
ser = pd.Series(index=np.arange(100), data=np.arange(100), name="a")
ser.iloc[42] = np.nan  # set 1 value to nan
fig.add_trace(
    go.Scattergl(
        x=ser.index,
        y=ser,
    )
)
fig.show_dash()

Which works perfectly fine!
But when I convert ser to a pd.DataFrame (that contains a nan value), then I do get the exact same error. See snippet below.
fig = FigureResampler(go.Figure())
ser = pd.Series(index=np.arange(100), data=np.arange(100), name="a").to_frame()
ser.iloc[42] = np.nan  # set 1 value to nan
fig.add_trace(
    go.Scattergl(
        x=ser.index,
        y=ser,
    )
)
fig.show_dash()

So in conclusion, this error occurs when you pass a pd.DataFrame (with nan values) as your y variable. The code seems to work as intended when a pd.Series (with nan values) is passed as y variable.
When a dataframe without nan values is passed, the behavior is exactly the same as plotly. When the dataframe contains nans, the behavior is differently (i.e., an error is thrown). In my opinion, a resolution for this issue might be implementing a check that raises a more clear error when either x or y are pd.DataFrame.
We are glad to hear that you like our library :)

Hey @jvdd,
Oops, yes, sorry, I have adapted the snippet from my code but had limited time, so I didn't actually launch it. Sorry if it took you more time to reproduce than it could have had. :(
And indeed, you have identified the problem correctly, my bad. I have gone back to the state of code I had and apparently I have left a single column in a data frame, but it was still a data frame. And, as you guessed, that resulted in an error that I have posted. Now I see clearly where I went the wrong way.
So since the problem was clearly on my side, I would say there is nothing to do in plotly-resampler. Unless you would like to add a clearer error, as you say, for this part of code that is outside plotly.
Thanks again for the prompt reply!

I have encountered though another problem related to Gitlab pipelines when using plotly-resampler. I will post it in a separate issue in case it helps anyone.


fix: Allow string values for FlagEvaluationDetails.reason and  FlagResolutionDetails.reason

This PR
Expands the types allowed for reason on FlagEvaluationDetails and FlagResolutionDetails to include both Reason and str types.
Related Issues
Fixes #262
Notes
Related to spec issue: https://github.com/open-feature/spec/issues/236

Hi @keelerm84! Thank you for your contribution. Change LGTM, but I am lost on what the test is supposed to assert.
If it's just a type check then it should be already covered by mypy. Would any of the tests break if you reverted the type change?

That's a good point. I've removed the useless test and will rely on mypy as suggested.


Model Methods

Are there any model methods from round-three that will be transferred over (and probably done coded better) or new methods that will need to be implemented due to the new microservice styled coding we will be doing?

That is for us to find out! Essentially our job is to take the round-three logic (so that's model methods/controller actions) and decide how much of it going to stay in round-three, how much of it is going to move to our microservice but change, and how much of it is going to be copied over to our microservice

Since this is going to be a actually issue then, I can leave this open till we can resolve this.

Closing this issue – this is just part of our process, doesn't need a separate issue for it.


Content block segmented: Align to non-gutter grid line and use CSS grid

The problem
<dds-content-block-segmented> assumes that it's used within a Carbon grid with gutter. However, there are several child contents, for example, card and link list, that should be aligned to non-gutter grid line.
We don't have a cohesive way how to deal with that at this point, that have caused for example the following problems:

Cards are aligned to grid gutter whereas it should be aligned to non-gutter grid line
Link list (horizontally) sticks out of the container element unless its containing element has (horizontal) paddings larger than $carbon--spacing-05 (the padding of Carbon grid gutter).

The solution
Make <dds-content-block-segmented> not depend on a gutter (of Carbon grid) defined in its containing element. Also, use CSS grid for its internal layout to make the internal markup simpler.

#4859 addresses this.

#4859 addresses this.


[Feature] Probability Calculator

Description
@Rakesh9100  I can add probability calculator, in which different probability such as chances of event to occur , chances of event not to occur, chances of one event occur and one event does not occur,etc. can be calculated.
Please assign me this under SWOC.
Screenshots
No response
Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[ ] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[X] I am a SWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

Proceed @NirbhayTiwari15


Add docs validation to Travis

Enact-DCO-1.0-Signed-off-by: Roy Sutton<EMAIL_ADDRESS>Checklist

[x] I have read and understand the contribution guide

[ ] A CHANGELOG entry is included

[ ] At least one test case is included for this feature or bug fix

[x] Documentation was added or is not needed

[ ] This is an API breaking change

Issue Resolved / Feature Added
Need a handy way to check docs are up-to-date when committing
Resolution
Add a validate-docs task to the root and update Travis to run it.
Additional Considerations
Won't pass until @enact/docs-utils is published
Links
PLAT-99867
Comments

Note: replaced with #2878 due to massed up commit logs.


Connect camera manager to main script.

Issue #67

This change is

Coverage decreased (-0.7%) to 84.81% when pulling a375285a75fcf3a7f04b7c0c393010b94afe8432 on camera_manager into bd9fade3ce4aebe090b7b13fde8501cbc89fd6ec on master.

Coverage decreased (-2.0%) to 83.565% when pulling 12ab21a8e727b62035e23cf6784fc3cfdd66a9d3 on camera_manager into bd9fade3ce4aebe090b7b13fde8501cbc89fd6ec on master.

Coverage decreased (-1.1%) to 84.419% when pulling 25fe69143aef2a6e8f91d728fdfcd9bdc6a21a12 on camera_manager into bd9fade3ce4aebe090b7b13fde8501cbc89fd6ec on master.


Endpoint type documentation missing mention of EndpointWithMapper<TRequest, TMapper>

https://fast-endpoints.com/docs/get-started#endpoint-types does not mention EndpointWithMapper<TRequest, TMapper> as a valid option that can be inherited from on an endpoint.
It does seem to get mentioned later in the last section of https://fast-endpoints.com/docs/domain-entity-mapping#mapping-logic-in-a-separate-class that exists and how to use it with the mapper.
Requesting that https://fast-endpoints.com/docs/get-started#endpoint-types be updated to list this missing option for clarity.

that is actually done on purpose. didn't wanna overwhelm beginners on the first page. and it's not really needed until you actually get to the point of using mappers. also IDE intellisense should show all variants in one place when you type in Endpoint... which the user can cycle through to see what they wanna use.


✨(app-frontend) feature to remove a member from a team

Feature Request

Integrate endpoint to remove user
Integrate new design

⚠ Be sure that the design is validated with the team before starting this dev (Johann / Antoine / Anto / JB ?).

⚠The bulk editing use a datagrid, so it can be smart to use more or less the same components that we use for the bulk editing.

Endpoint is ready! Design is validated, we can go for dev!


Unwanted digest cycles

I am using bluebird as my Promise library in the browser and have also included this library (along with angular), but I am getting $rootScope:inprog errors when Promise is being used directly.
I would have thought digests were only triggered when using $q but presumably it has extended the Promise object with this functionality? If so is there any recommended way to disable this?

I think it's because of this: https://github.com/mattlewis92/angular-bluebird-promises/blob/master/src/angular-bluebird-promises.js#L71
To get the old behaviour I think you could do:
.run(($rootScope, Bluebird) => {
  Bluebird.setScheduler(cb => setTimeout(cb));
})

Although when a $q promise resolves it now won't trigger a digest.


Downtime protection

feature: in order to protect for downtime of nodes during replication, replicate until distributed to all configured endpoints

Done.
See feature Downtime protection.


node-red integration / if-then-else

Perhaps its nice if this could have integration with Node-RED for "if-then-else" actions. I haven't used it yet (other than checking if it runs and dragging some stuff around) but it could be a nice addition.
IIUC this app should be able to deal with the whole "if-then-else" handling for making complex plans such as:

If the sun has gone down;
Turn on the lights in the living room
Close the curtains

Or

Motion is detected in the hallway;
And if the alarm is armed (alarm could be a simple nodejs app);
And if the trusted devices (phones) are out of range;
Send out alarms to SMS & PushBullet;
Trigger the ZWave alarm;

I didn't know Node-red, it looks very great and usefull to create workflows.
Did you take a look to the "Zwave" connector in Node-Red  ?

Yes, this is based on OpenZWave but I haven't tested that part yet. At the moment all I have is a ZWave stick and Fibaro Binary Sensor which I haven't yet been able to get to work.


fix: include str ivalue type conversion

Description
Fixes #1756
Type of change
Please delete options that are not relevant and/or add your own.

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
This change requires a documentation update

Checklist:

[ ] My code follows the style guidelines of this project (You can use the linters)
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas and hacks
[ ] I have made corresponding changes to the documentation
[ ] I have added tests to verify my fix or my feature
[ ] New and existing unit tests pass locally with my changes
[ ] I have added the relevant labels to my PR in so that relevant reviewers are notified

Looks good to me, just made a style recommendation, and I've verified that this resolves the error being displayed in #1756. I do see another error now when running that model, however, also during partitioning:
/usr/local/lib/python3.8/dist-packages/torch/jit/_recursive.py:266: UserWarning: 'batch_first' was found in ScriptModule constants, but was not actually set in __init__. Consider removing it.
  warnings.warn("'{}' was found in ScriptModule constants, "
Traceback (most recent call last):
  File "issue_1756.py", line 56, in <module>
    trt_ts_module = torch_tensorrt.compile(
  File "~/TensorRT/py/torch_tensorrt/_compile.py", line 125, in compile
    return torch_tensorrt.ts.compile(
  File "~/TensorRT/py/torch_tensorrt/ts/_compiler.py", line 136, in compile
    compiled_cpp_mod = _C.compile_graph(module._c, _parse_compile_spec(spec))
RuntimeError: Expected Tensor but got Uninitialized

Yes, I also noticed this one, I'm me cc you for that discussion


Vbd read access field from config

@lorc @arminn @firscity ping

Reviewed-by: Andrii Chepurnyi<EMAIL_ADDRESS>

added tag to commit messages

I am okay with the changes, but...

xen-dom-mgmt: minor fixes for vbd and vif

Can we please use imperative mood and descriptive headers?

I am okay with the changes, but...

xen-dom-mgmt: minor fixes for vbd and vif

Can we please use imperative mood and descriptive headers?

changed

Reviewed-by: Volodymyr Babchuk<EMAIL_ADDRESS>
done


Add maximumOn1, and minimumOn1 functions for Foldable1(no default imp…

Resolves #306

Checklist:

HLint

[ ] I've changed the exposed interface (add new reexports, remove reexports, rename reexported things, etc.).

[ ] I've updated hlint.dhall accordingly to my changes (add new rules for the new imports, remove old ones, when they are outdated, etc.).
[ ] I've generated the new .hlint.yaml file (see this instructions).

General

[ ] I've updated the CHANGELOG with the short description of my latest changes.
[x] All new and existing tests pass.
[x] I keep the code style used in the files I've changed (see style-guide for more details).
[ ] I've used the stylish-haskell file.
[x] My change requires the documentation updates.

[x] I've updated the documentation accordingly.

[x] I've added the [ci skip] text to the docs-only related commit's name.

I don't know if it's possible to define a default implementation for maximumOn1 and minimumOn1. I've not added them to the MINIMAL pragma for now. I'll try to provide default implementations if there are any suggestions.

I am sorry, I wasn't paying proper attention. I have changed the typeclass constraint.

Thank you.


[$500] FAB - Menu icon doesn't change color when hovered over "New workspace" in FAB menu

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

Version Number: v1.4.19-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal Team
Slack conversation: @
Action Performed:

Navigate to staging.new.expensify.com
Create new account
Hover over the "New Workspace" option in FAB menu

Expected Result:
"New workspace" logo icon should change to black color in light theme & to white in dark theme when hovered over the option
Actual Result:
"New workspace" logo icon doesn't change color when hovered over the menu
Workaround:
Unknown
Platforms:

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

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

Screenshots/Videos

https://github.com/Expensify/App/assets/115492554/d2df22a0-a94b-4509-8cec-2ac6265e3d98

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01817cdb0a4cd143cf
Upwork Job ID:<PHONE_NUMBER>616701952
Last Price Increase: 2023-12-29

Proposal
Please re-state the problem that we are trying to solve in this issue.
New workspace icon on FAB menu is not changing its color on hover.
What is the root cause of that problem?
It seems like the intension is to keep the icon as such as displayInDefaultIconColor: true is set for this icon. Also the SVG used for this icon has fill color defined in it which prevents the fill from being modified programatically.
What changes do you think we should make in order to solve the problem?
If we infact want to change the icon color on hover displayInDefaultIconColor: true should be removed from the icon for newWorkspace. Also the svg should be modified to remove the fill Color and use currentColor for building icon.
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" id="Layer_1" x="0" y="0" version="1.1" viewBox="0 0 40 40" style="enable-background:new 0 0 40 40" xml:space="preserve"><style type="text/css">.st0{}.st1{fill-rule:evenodd;clip-rule:evenodd;fill:currentColor}.st2{fill:#fed607;stroke-width:2;stroke-linecap:round;stroke-linejoin:round}</style><path d="M20,0L20,0c11,0,20,9,20,20l0,0c0,11-9,20-20,20l0,0C9,40,0,31,0,20l0,0C0,9,9,0,20,0z" class="st0"/><path d="M13,12.8c0-1,0.8-1.8,1.8-1.8h10.5c1,0,1.8,0.8,1.8,1.8v14.5c0,1-0.8,1.8-1.8,1.8H22v-3.2	c0-0.4-0.4-0.8-0.8-0.8h-2.4c-0.4,0-0.8,0.4-0.8,0.8V29h-3.2c-1,0-1.8-0.8-1.8-1.8V12.8z M16.9,13c-0.6,0-1,0.4-1,1s0.4,1,1,1h6.2	c0.6,0,1-0.4,1-1s-0.4-1-1-1H16.9z M15.9,18c0-0.6,0.4-1,1-1h6.2c0.6,0,1,0.4,1,1s-0.4,1-1,1h-6.2C16.3,19,15.9,18.6,15.9,18z M16.9,21c-0.6,0-1,0.4-1,1s0.4,1,1,1h6.2c0.6,0,1-0.4,1-1s-0.4-1-1-1H16.9z" class="st1"/><path d="M28.8,5.8C28.8,5.7,28.7,5.7,28.8,5.8c-0.6-1-2-1-2.6,0l0,0l0,0l-0.9,1.7l-2.1,0.3l0,0l0,0	c-1.1,0.1-1.8,1.5-0.8,2.4l0,0l1.5,1.3l-0.3,1.8v0c-0.1,0.6,0.2,1.1,0.6,1.4c0.4,0.3,1,0.3,1.5,0.1c0,0,0,0,0,0l1.9-0.9l1.9,0.9	c0,0,0,0,0,0c0,0,0,0,0,0c0.5,0.2,1.1,0.2,1.5-0.1c0.4-0.3,0.7-0.8,0.6-1.4v0l-0.3-1.8l1.5-1.3l0,0c1-0.9,0.3-2.3-0.8-2.4l0,0	l-2.1-0.3L28.8,5.8z" class="st2"/></svg>

What alternative solutions did you explore? (Optional)
None (edited)

Proposal
Please re-state the problem that we are trying to solve in this issue.
The "New workspace" menu icon under the FAB menu doesn't change colors when hovered on.
What is the root cause of that problem?
It looks like the icon was intentionally made to not change colors as the displayInDefaultIconColor property is set to true here.
What changes do you think we should make to solve the problem?
Removing the displayInDefaultIconColor property is not enough in this case because the new-workspace icon is more complex than all the other menu icons under the FAB menu, which are transparent and take on the background of their container. My solution is to create a react component version of the icon to maximize the ease of customization.
import React, { useEffect, useState } from 'react';
import useThemePreference from '@hooks/useThemePreference';

const colors = {
    background: '#03d47c0',
    building: '#fff',
    star: '#fed607',
    starStroke: '#03d47c',
}

function NewWorkspaceIcon(props) {
    const themePreference = useThemePreference();
    const [backgroundColor, setBackgroundColor] = useState(colors.background);
    const [buildingColor, setBuildingColor] = useState(colors.building);
    const [starStrokeColor, setStarStrokeColor] = useState(colors.starStroke);

    const resetColors = () => {
        setBackgroundColor(colors.background);
        setBuildingColor(colors.building);
        setStarStrokeColor(colors.starStroke);
    };

    useEffect(() => {
        if (props.hovered === 'true') {
            if (props.fill) {
                setBackgroundColor(props.fill);
                setStarStrokeColor(props.fill);
            }

            if (themePreference === 'dark') setBuildingColor('#000');
        } else resetColors();
    }, [props.hovered]);

    return (
        <svg
            x="0"
            y="0"
            version="1.1"
            viewBox="0 0 40 40"
            enableBackground="new 0 0 40 40"
            xmlSpace="preserve"
            {...props}
        >
            {/* Background */}
            <path
                d="M20,0L20,0c11,0,20,9,20,20l0,0c0,11-9,20-20,20l0,0C9,40,0,31,0,20l0,0C0,9,9,0,20,0z"
                fill={backgroundColor}
            />

            {/* Building */}
            <path
                d="M13,12.8c0-1,0.8-1.8,1.8-1.8h10.5c1,0,1.8,0.8,1.8,1.8v14.5c0,1-0.8,1.8-1.8,1.8H22v-3.2	c0-0.4-0.4-0.8-0.8-0.8h-2.4c-0.4,0-0.8,0.4-0.8,0.8V29h-3.2c-1,0-1.8-0.8-1.8-1.8V12.8z M16.9,13c-0.6,0-1,0.4-1,1s0.4,1,1,1h6.2	c0.6,0,1-0.4,1-1s-0.4-1-1-1H16.9z M15.9,18c0-0.6,0.4-1,1-1h6.2c0.6,0,1,0.4,1,1s-0.4,1-1,1h-6.2C16.3,19,15.9,18.6,15.9,18z M16.9,21c-0.6,0-1,0.4-1,1s0.4,1,1,1h6.2c0.6,0,1-0.4,1-1s-0.4-1-1-1H16.9z"
                fillRule="evenodd"
                clipRule="evenodd"
                fill={buildingColor}
            />

            {/* Star */}
            <path
                d="M28.8,5.8C28.8,5.7,28.7,5.7,28.8,5.8c-0.6-1-2-1-2.6,0l0,0l0,0l-0.9,1.7l-2.1,0.3l0,0l0,0	c-1.1,0.1-1.8,1.5-0.8,2.4l0,0l1.5,1.3l-0.3,1.8v0c-0.1,0.6,0.2,1.1,0.6,1.4c0.4,0.3,1,0.3,1.5,0.1c0,0,0,0,0,0l1.9-0.9l1.9,0.9	c0,0,0,0,0,0c0,0,0,0,0,0c0.5,0.2,1.1,0.2,1.5-0.1c0.4-0.3,0.7-0.8,0.6-1.4v0l-0.3-1.8l1.5-1.3l0,0c1-0.9,0.3-2.3-0.8-2.4l0,0	l-2.1-0.3L28.8,5.8z"
                fill={colors.star}
                stroke={starStrokeColor}
                strokeWidth={2}
                strokeLinecap="round"
                strokeLinejoin="round"
            />
        </svg>
    )
}

export default NewWorkspaceIcon;

All color customization logic is encapsulated in this component ensuring that we don't have to change how the MenuItem component works or the alter svg. This is important to avoid affecting other parts of the platform.
Import the new icon in FloatingActionButtonAndPopover.
import NewWorkspaceIcon from './NewWorkspaceIcon';

Then replace the reference to Expensicons.NewWorkspace with the new icon. The displayInDefaultIconColor property should either be removed or set to false.
The new menu item object should look something like this.
{
    contentFit: 'contain',
    icon: NewWorkspaceIcon,
    iconWidth: 46,
...

Result
https://github.com/Expensify/App/assets/31987492/0dd62fd4-552b-45b3-a138-2e7fc6a04eb1
What alternative solutions did you explore? (Optional)
N/A

the proposal from @aswin-s looks good to me, seems like an issue we experienced before on other icons.
🎀 👀 🎀 C+ Reviewed!

@getusha The color of the building in the icon in dark mode is currently white. @aswin-s's proposal would make it black even when it's not hovered on. Is that desired?

Screenshot from staging

@sofi-a @getusha I simply used the fill style for other icons like request money.  If we want to retain building color as white for both dark and light mode, currentColor in SVG could be set accordingly. It's just an implementation detail.

Just sharing my opinion that we also have the stroke width around the star and that color matches with the background color, isn't @sofi-a's proposal more accurate as we are also doing the same for Lounge Icon here

@Pujan92 Expensicons.LoungeAccess icon is throwing error on UserProfile Page.  I guess it is not used at the moment.

Try removing props.user.hasLoungeAccess  conditional and load the page on a native device.
The MenuItem component passes the icon prop down to ImageSVG component, which uses expo-image library to display the SVG file. It cannot accept a react component as mentioned in @sofi-a 's proposal. That's also the reason why UserProfile page crash if you try to enable the Lounge Access menu item.

I got your point that it will crash at the moment after expo-image changes, to solve we can render conditionally considering whether src is a function or not which won't render in expo image if it is a function.
Maybe the design team can help here about omitting the stroke around the star is fine or not @shawnborton

Current
With selected proposal

@Pujan92 I never had the intension to remove the stroke around the star and I didn't mention anything like that in the proposal. Just that when I made the fix I accidentally dropped the stroke. I've fixed that now in the PR. Thanks for noticing.
This is how it looks now.

Normal State
Hovered State

Part of me thinks we should keep the green BG on this particular item on hover, it feels a bit more special than the other items and almost like we want to specifically promote the green BG here as a new item to discover. What do you think @dannymcclain @dubielzyk-expensify ?

As far as the stroke goes, we want to keep it there, but we can recreate the svg to not actually have a stroke line and just subtract that outline from the building shape. Is that what you need?

As far as the stroke goes, we want to keep it there, but we can recreate the svg to not actually have a stroke line and just subtract that outline from the building shape. Is that what you need?

@shawnborton That's how it is achieved right now.  So we wouldn't be needing another SVG file unless you feel something is missing with the current view. And there is no plan to remove the stroke.

Ah okay, so what exactly is the bug then or what do you need the design team's input on?

Ah okay, so what exactly is the bug then or what do you need the design team's input on?

In the first implementation I accidentally missed the stroke. So @Pujan92 thought it was on purpose and pinged the design team to check whether it is okay to remove the stroke. I've clarified above that it was never the intention and just a mistake. Hope that clears all the confusion.

Got it, sounds good! Let's not remove the stroke.

Part of me thinks we should keep the green BG on this particular item on hover, it feels a bit more special than the other items and almost like we want to specifically promote the green BG here as a new item to discover.

I tend to agree. I don't really see this is as a bug—more of a choice. The "new workspace" icon feels intentionally different from the rest (and it's also the only item with a description, which further makes it feel special), and the row still gets a hover state, so I don't really see the need to change the icon for this one.
BUT if y'all feel really strongly that we do need to change it, I won't stand in the way!

Thanks @Pujan92. I've updated my proposal according to your comment under the compatibility section. With the changes, we should be able to use svg react components in native platforms. @bfitzexpensify @shawnborton @dannymcclain what do you guys think?

So this one isn't actually a bug - can we just close the issue out? cc @MariaHCD @bfitzexpensify

Thanks for the input on the design her!  I agree that this is not a bug.

@MariaHCD Considerable effort was put into the PR to make it work seamlessly against both web and native platforms. The expected outcome on both themes were detailed out in the proposal itself. Still it got assigned and PR was raised 2 weeks ago. Is there a policy regarding how to compensate contributors on issues which gets closed after assigning and PR was raised?

@MariaHCD I think partial compensation makes sense, since there was time spent on the PR before deciding to close this out.

Okay, that's fair. I'd like @bfitzexpensify's input but what partial compensation here do you think is fair in this case, @aswin-s?

@MariaHCD I leave the decision to you. That's why I was checking if there is a process already in place for such scenarios.

Referencing the internal SO and this doc: Considering the effort/time spent on the PR and on testing as well as the C+'s time in reviewing the proposals here and reviewing the PR, I think 25% partial payment to both is fair. Thoughts, @bfitzexpensify?

bump @bfitzexpensify

Referencing the internal SO and this doc: Considering the effort/time spent on the PR and on testing as well as the C+'s time in reviewing the proposals here and reviewing the PR, I think 25% partial payment to both is fair. Thoughts, @bfitzexpensify?

I agree, 25% seems fair. Payments complete.


Android (CI): use API level 29 for the emulator

API 31 somehow breaks the emulator action, the config.ini file doesn't seem to be used anymore, or at least the value for the userdata partition isn't honoured (the CI complaints of no disk space for a 7GB partition when the config.ini file says it should be only 3GB).
Also, enable dispatch for the Android action so it can be more easily tested in the future.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 88.64%. Comparing base (034afd0) to head (7b99cab).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1022      +/-   ##
==========================================
- Coverage   90.19%   88.64%   -1.56%
==========================================
  Files         179       18     -161
  Lines       21468     2465   -19003
  Branches      280      280
==========================================
- Hits        19363     2185   -17178
+ Misses       2102      277    -1825
  Partials        3        3

Flag
Coverage Δ

uitests
?

uitests-ios
?

unittests
88.64% <ø> (-0.64%)
:arrow_down:

unittests-ios
?

unittests-react
88.64% <ø> (ø)

unittests-rust
?

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


ARTEMIS-3420: Target Java 11

https://issues.apache.org/jira/browse/ARTEMIS-3420
I have been extracting and dropping related isolated changes onto main for a while already that have just released with 2.18.0, since they improved various Java 11+ related issues without actually requiring it. These are my remaining changes to actually require and target Java 11, resolve new issues that creates, and clean up some bits that become stale as a result.

Rebased again and updated to account for other subsequent build config changes I made.

Yep figured as much, that is the reason I haven't sent a  comment to the mail thread already ;)

@gemmellr  / @clebertsuconic  with the next Java LTS due this month, with the dropping of java 8, i assume we want to add support of 17, at same time, e.g. we keep support of two current java LTS versions.

You may have seen me actually reference 17ea at various points in JIRAs and emails, as I do personally think it should supported quickly though I'd say its somewhat separate from requiring 11.
That said, I have actually also been ensuring the GHA build works on 17ea with these changes though (and also 2.18.0 with those I extracted before then), I just didnt include it here yet as its wasnt out yet and Temurin inst in the GHA build runner tool cache yet. I planned to add it to the actual build as soon as 17 released though (and hopefully Temurin might actually be in the tool cache by then also).

@gemmellr of course 17 is separate than this PR it was more a question of did you have something in the pipeline...and it sounds like you do. +100.

yayyyy!!!!

:)


Doesn't recognize with webcam. Lags heavily with opencv

I am trying to implement live feed qrcode data matrix decoder similar to pyzbar but it doesn't work. So is there anyway to make it work with it?

did you find a solution for that problem?

I did but it was extremely slow. Didn't continue further.
Its in one of my repos

See #78
You need to add a timeout and optionally a max_count. More thorough explanation is in the other issue.
msg = pylibdmtx.decode(thresh, timeout=100, max_count=1)


docs(stepper): add better documentation and examples

Need lots more examples (currently only one)
Better explanation of interaction between various state flags (editable, completed, etc) - which combo leads to which icon

Can be linked to #10365 ?

I'd like to try this as my first contribution to this project, but I need a few pointers such as what would make the documentation ideal, any things I should know about the stepper which is perhaps not in the current documentation, etc. Thanks!

@raygervais A good first step would be to convert the existing text-only examples to embedded examples: https://material.angular.io/components/stepper/overview
You could also look over the various components that make up the stepper (https://github.com/angular/material2/tree/master/src/cdk/stepper https://github.com/angular/material2/tree/master/src/lib/stepper) and make sure that the docs covers the various @Input() and @Output() options they support.

Yep. Testing the examples is kind of a pain though, you have to clone our docs repo as well https://github.com/mmalerba/material.angular.io and run npm run fetch-local to import the examples from your local copy of the material2 repo. If you have trouble getting that to work just test them out in a StackBlitz and I can verify it in the docs site before approving.

Noted, I have the fetch-local working so far, but when I attempt to view it locally via nom start, it fails to compile. Furthermore what is StackBlitz? 😨

@mmalerba, I've created a WIP PR so you can tell me what else we should have or what needs to be changed. Looking forward to this contribution helping to improve documentation 😄


Editor crashes silently while loading project

Godot version
v4.1.stable.mono.official [970459615]
System information
Godot v4.1.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1070 Ti (NVIDIA; <IP_ADDRESS>79) - AMD Ryzen 7 2700X Eight-Core Processor (16 Threads)
Issue description
When I load my project, I see a blank editor window (sometimes with the Godot logo, sometimes without), the windows progress bar iterates over several scenes that need to be opened. It then stops at my main scene, gets unresponsive and stays there for a while.
Then Godot closes silently. When opened from the console, I see the following error (written very often):
ERROR: Failed method: EditorToaster::_error_handler_impl. Message queue out of memory. Message queue out of memory. Try increasing 'memory/limits/message_queue/max_size_mb' in project settings.    at: push_callablep (core/object/message_queue.cpp:96)
Steps to reproduce
I am not sure to what this relates, but it could a be C# [Tool] script that creates ~1200 voxels in _Ready (I could accept that this is not working, but I don't like the silent crash.). Starting the game works without issues though.
As I did not change this code for a while (and the editor startup was slow but worked), I assume there's something else accumulating. I just know that the editor starts when I disable the creation of the voxels, but tbh, I don't think this is the root cause.
Minimal reproduction project
wasn't able to create a mrp

PS: The editor is also starting when I set my voxel-creating node to operate in a subthread.

Your voxel script likely has many errors (maybe some API changes) that fill up the message queue

It does not throw any errors when I run the game, nor does it show any errors when running in subthread. The error mentioned above is something with TCP, which I suppose is related to the subthreads (as I never touch anything with TCP in my script). But yes, it might be that my script causes some errors, but I would be happy if the editor would show them to me (or atleast they appear in some log)

Without any more details, it will be impossible to investigate this. Please try to create a MRP and upload it.

Closing due to lack of response, if you provide the above required information this can be reopened


look into C++ build throughput

The C++ team put out this blog post with information related to tuning up your build... could be something for us to investigate? https://devblogs.microsoft.com/cppblog/cpp-build-throughput-investigation-and-tune-up/

different, but not really: #3670?


update compose function for more lambda style

update compose function for more lambda style

Much harder to read and maintain having everything in a single line.

Thanks for the PR! I think we want to be a little more explicit in the intent. The version you propose strike me as more elegant but harder to understand to people looking at this code for the first time so I decided not to take this. Nevertheless I appreciate the time you took to contribute!


Issues with z.date() in config.ts

Can the documentation provide more details here?
https://docs.astro.build/en/guides/content-collections/#defining-datatypes-with-zod
    // In frontmatter, dates written without quotes around them are interpreted as Date objects
    publishDate: z.date(),

I tried various "dates written without quotes" in my .md files and they all resulted in Expected type "date", received "string" errors when building. Example:
post-1.md
---
publishDate: 4/27/2023
---

If there's an exact format we need to use, please specify it in the documentation. I eventually resolved it by updating config.ts to this:
    publishDate: z.coerce.date(),

Ah yes, this needs to be something that YAML considers is a date/timestamp, like 2023-04-27. This is because Markdown frontmatter is usually written in YAML. The YAML spec has some more examples of valid timestamps in Example 2.22.

@delucis this is great info. Would it be possible to add this to the documentation as I think it would be helpful for those new to Astro/zod.

The line directly under the one you referenced does show a date string, so I do think that there's a visual example right in that section for what a date in YAML frontmatter should look like.
What I think actually addresses this problem better is something that specifically introduces YAML on the Markdown/MDX page. We really only teach/introduce what the frontmatter is in the tutorial. I do think our markdown-content page could include mention of the top section of a Markdown file being written in YAML and should adhere to that language.
So I'm going to close this issue, but make a task to add some YAML content to our Markdown page. I think something there can helpful for more than just this one specific case. Thanks for pointing this out!


update

Hello @yutiansut! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file QAStrategy/qactabase.py:

Line 29:80: E501 line too long (90 > 79 characters)
Line 29:82: E251 unexpected spaces around keyword / parameter equals
Line 29:84: E251 unexpected spaces around keyword / parameter equals
Line 417:80: E501 line too long (212 > 79 characters)
Line 418:80: E501 line too long (149 > 79 characters)

In the file QAStrategy/qastockbase.py:

Line 36:46: E231 missing whitespace after ','
Line 240:80: E501 line too long (212 > 79 characters)
Line 241:80: E501 line too long (136 > 79 characters)

In the file example/CCI_EXample.py:

Line 45:1: W293 blank line contains whitespace
Line 50:1: W293 blank line contains whitespace
Line 61:80: E501 line too long (84 > 79 characters)
Line 66:1: W293 blank line contains whitespace


[bug] <input type="file" accept="image/*" />, non-image files can still be selected.

Describe the bug
Even if I set accept="image/*" on the input file tag, non-image files can still be selected in tauri, while they are not selected in browser.
I'am in MacOS.
Reproduction
No response
Expected behavior
No response
Platform and versions
@tauri-apps/cli [NPM]: 1.2.3 (outdated, latest: 1.3.0)
@tauri-apps/api [NPM]: 1.2.0 (outdated, latest: 1.3.0)
Tauri [RUST]: 1.2.4,
tauri-build [RUST]: 1.2.1,

Stack trace
No response
Additional context
No response

Can you please add the whole output of tauri info as the template required? Or at least tell us your macOS version please.

while they are not selected in browser.

What kind of browser did you test? Please test it in Safari since that's basically what Tauri's WebView is on macOS.

Has this been fixed? I'm experiencing the same issue.


Added Let's Encrypt ISRG Root X1 and ISRG Root X2 root certificates to the Android system cert trust store

Task/Issue URL: https://app.asana.com/0/72649045549333/1199564873039373/f
Tech Design URL:
CC:
Description:

Bundled ISRG Root X1 and ISRG Root X2 root certificates with the binary APK
Modified network-security-config XML file to add ISRG Root X1/X2 to the system certificate trust store

Steps to test this PR:
On device with API = 24

Install app from develop
Navigate to https://valid-isrgrootx1.letsencrypt.org/
Verify the page does not load
Install app from this PR
Navigate to https://valid-isrgrootx1.letsencrypt.org
Verify the page does load

Internal references:
Software Engineering Expectations
Technical Design Template

@CDRussell I hope both this and the option for devices on API < 24 can be released at once. In case they'd not, what do you think about adding a pixel that might record SSL validation failures under this PR?

@CDRussell I hope both this and the option for devices on API < 24 can be released at once. In case they'd not, what do you think about adding a pixel that might record SSL validation failures under this PR?

I don't think it's worth waiting on getting the solution available for older devices before getting this merged and released. What insights does that pixel offer?


Subtle compatibility issue with serve_arrow

Describe the bug
serde_arrow::from_record_batch expects arrow::record_batch::RecordBatch and arrow::schema::Schema as inputs, while ParquetRecordBatchStream seems to yield arrow_array::record_batch::RecordBatch and similarly ::schema() returns arrow_schema::schema::Schema.
As far as I can tell, the implementation of the types are exactly the same but the compiler considers them different types.
To Reproduce
#[derive(Deserializable)]
struct S {}

let file = File::open(path.as_ref()).await?;
let mut batches = ParquetRecordBatchStreamBuilder::new(file).await?.build()?;
let schema = batches.schema().as_ref();

while let Some(batch) = batches.next().await {
    let batch = batch?;
    from_record_batch::<S>(&batch, schema);
}

error[E0308]: arguments to this function are incorrect
  --> src/sign.rs:28:17
   |
28 |                 from_record_batch::<S>(&batch, schema);
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^ ------  ------ expected struct `Schema`, found struct `arrow_schema::schema::Schema`
   |                                           |
   |                                           expected struct `arrow::record_batch::RecordBatch`, found struct `arrow_array::record_batch::RecordBatch`
   |
   = note: expected reference `&arrow::record_batch::RecordBatch`
              found reference `&arrow_array::record_batch::RecordBatch`
   = note: expected reference `&Schema`
              found reference `&arrow_schema::schema::Schema`

Expected behavior
I would expect the API to return the types exposed by the main arrow namespace rather than arrow_array and arrow_schema. At least it should be possible to convert between them with From.
Because of this, as far as I can tell, it isn't possible (or at least ergonomic) to use serde to deserialise from parquet directly.

Could you run cargo tree | grep arrow for your crate. This sounds like you might have two versions of the crate in your workspace?

Thanks, I didn't consider that. Here you go, is it how you would expect it?
│   ├── arrow v25.0.0
│   │   ├── arrow-array v25.0.0
│   │   │   ├── arrow-buffer v25.0.0
│   │   │   ├── arrow-data v25.0.0
│   │   │   │   ├── arrow-buffer v25.0.0 (*)
│   │   │   │   ├── arrow-schema v25.0.0
│   │   │   ├── arrow-schema v25.0.0
│   │   ├── arrow-buffer v25.0.0 (*)
│   │   ├── arrow-data v25.0.0 (*)
│   │   ├── arrow-schema v25.0.0
├── serde_arrow v0.5.0
│   ├── arrow v16.0.0

Have you managed to replicate the issue? Does this work fine for you?

I restricted parquet = "16.0" since serde_arrow requires that arrow version. It seemed to improve the situation, but I still have this issue.
error[E0308]: mismatched types
  --> src/sign.rs:28:51
   |
28 |                 from_record_batch::<Sign>(&batch, schema);
   |                 -------------------------         ^^^^^^ expected struct `Schema`, found struct `arrow::datatypes::schema::Schema`
   |                 |
   |                 arguments to this function are incorrect
   |
   = note: expected reference `&Schema`
              found reference `&arrow::datatypes::schema::Schema`

│   ├── arrow v16.0.0
├── serde_arrow v0.5.0
│   ├── arrow v16.0.0 (*)

Nevertheless, it shouldn't be necessary to do this adjustment by hand. Can you think of a way to enforce this?

Nevermind, it seems like Schema is a different type implemented by serde_arrow, which does implement From<arrow::datatypes::Schema> as well as fn from_record_batch(record_batch: &RecordBatch) -> Result<Self>, so that's fine.
I'll close this, but I'll open another issue at serde_arrow so that they at least update their dependency to the most recent version.


Bad state: Support for generic type aliases is not yet implemented

Analyzer Feedback from IntelliJ
Version information

IDEA 172.SNAPSHOT
1.23.0-dev.2.0
172.SNAPSHOT, JRE 1.8.0_112-b15x64 Oracle Corporation, OS Windows 10(amd64) v10.0 , screens 1920x1200

Exception
Dart analysis server, SDK version 1.23.0-dev.2.0, server version 1.18.0, error: Analysis failed: C:\dart_projects\dart-lang\sdk\tests\language\mixin_illegal_syntax_test.dart context: exception_20170302_203216_465
Bad state: Support for generic type aliases is not yet implemented
#0      ErrorVerifier.visitGenericTypeAlias (package:analyzer/src/generated/error_verifier.dart:883)
#1      GenericTypeAliasImpl.accept (package:analyzer/src/dart/ast/ast.dart:5849)
#2      NodeListImpl.accept (package:analyzer/src/dart/ast/ast.dart:8046)
#3      CompilationUnitImpl.visitChildren (package:analyzer/src/dart/ast/ast.dart:2523)
#4      RecursiveAstVisitor.visitCompilationUnit (package:analyzer/dart/ast/visitor.dart:707)
#5      ErrorVerifier.visitCompilationUnit (package:analyzer/src/generated/error_verifier.dart:566)
#6      CompilationUnitImpl.accept (package:analyzer/src/dart/ast/ast.dart:2516)
#7      LibraryAnalyzer._computeVerifyErrors (package:analyzer/src/dart/analysis/library_analyzer.dart:279)
#8      LibraryAnalyzer.analyze.<anonymous closure> (package:analyzer/src/dart/analysis/library_analyzer.dart:96)
#9      _HashVMBase&MapMixin&&_LinkedHashMapMixin.forEach (dart:collection-patch/compact_hash.dart:351)
#10     LibraryAnalyzer.analyze (package:analyzer/src/dart/analysis/library_analyzer.dart:95)
#11     AnalysisDriver._computeAnalysisResult.<anonymous closure> (package:analyzer/src/dart/analysis/driver.dart:759)
#12     PerformanceLog.run (package:analyzer/src/dart/analysis/driver.dart:1639)
#13     AnalysisDriver._computeAnalysisResult (package:analyzer/src/dart/analysis/driver.dart:745)
#14     AnalysisDriver._performWork (package:analyzer/src/dart/analysis/driver.dart:1077)
<asynchronous suspension>
#15     AnalysisDriverScheduler._run (package:analyzer/src/dart/analysis/driver.dart:1371)
<asynchronous suspension>
#16     AnalysisDriverScheduler.start (package:analyzer/src/dart/analysis/driver.dart:1297)
#17     AnalysisServer.AnalysisServer (package:analysis_server/src/analysis_server.dart:404)
#18     SocketServer.createAnalysisServer (package:analysis_server/src/socket_server.dart:95)
#19     StdioAnalysisServer.serveStdio (package:analysis_server/src/server/stdio_server.dart:39)
#20     Driver.start.<anonymous closure> (package:analysis_server/src/server/driver.dart:477)
#21     _rootRun (dart:async/zone.dart:1150)
#22     _CustomZone.run (dart:async/zone.dart:1026)
#23     runZoned (dart:async/zone.dart:1503)
#24     Driver._captureExceptions (package:analysis_server/src/server/driver.dart:514)
#25     Driver.start (package:analysis_server/src/server/driver.dart:476)
#26     main (file:///E:/b/build/slave/dart-sdk-windows-dev/build/sdk/pkg/analysis_server/bin/server.dart:12)
#27     _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:259)
#28     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:148)

1488475935950 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\method_override7_test.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIME_ERROR",
1488475935965 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\method_override8_test.dart","errors":[{"severity":"WARNING","type":"STATIC_WARNING","l
1488475935981 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\method_override_test.dart","errors":[{"severity":"WARNING","type":"STATIC_WARNING","lo
1488475935996 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\minify_closure_variable_collision_test.dart","errors":[]}}
1488475936012 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mint_arithmetic_test.dart","errors":[]}}
1488475936028 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mint_compares_test.dart","errors":[]}}
1488475936044 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\missing_const_constructor_test.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIM
1488475936055 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\missing_part_of_tag_part.dart","errors":[]}}
1488475936069 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\missing_part_of_tag_test.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIME_ERRO
1488475936086 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_black_listed_test.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIME_ERROR
1488475936106 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_bound_test.dart","errors":[]}}
1488475936120 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_cyclic_test.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIME_ERROR","loc
1488475936142 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_extends_field_test.dart","errors":[{"severity":"INFO","type":"HINT","location":{
1488475936157 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_extends_is_test.dart","errors":[]}}
1488475936173 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_extends_method_test.dart","errors":[{"severity":"INFO","type":"HINT","location":
1488475936187 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_field_initializer_test.dart","errors":[]}}
1488475936218 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_field_test.dart","errors":[{"severity":"INFO","type":"HINT","location":{"file":"
1488475936234 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_forwarding_constructor1_test.dart","errors":[]}}
1488475936248 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_forwarding_constructor2_test.dart","errors":[]}}
1488475936264 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_forwarding_constructor3_test.dart","errors":[]}}
1488475936283 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_forwarding_constructor4_test.dart","errors":[{"severity":"ERROR","type":"COMPILE
1488475936305 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_generic_test.dart","errors":[]}}
1488475936321 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_getter_regression_test.dart","errors":[]}}
1488475936339 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_illegal_constructor_test.dart","errors":[{"severity":"WARNING","type":"STATIC_WA
1488475936356 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_illegal_cycles_test.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIME_ERR
1488475936369 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_illegal_object_test.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIME_ERR
1488475936384 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_illegal_static_access_test.dart","errors":[{"severity":"WARNING","type":"STATIC_
1488475936403 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_illegal_superclass_test.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIME
1488475936420 <= {"event":"analysis.errors","params":{"file":"C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_illegal_super_use_test.dart","errors":[{"severity":"WARNING","type":"STATIC_TYPE
1488475936533 <= {"event":"server.error","params":{"isFatal":false,"message":"Analysis failed: C:\\dart_projects\\dart-lang\\sdk\\tests\\language\\mixin_illegal_syntax_test.dart context: exception_201

This is as expected at this point. As the error message suggests, support for generic function types and generic type aliases is not yet implemented. See https://github.com/dart-lang/sdk/issues/27969.


customize deletion_policy

TL;DR
https://github.com/hashicorp/terraform-provider-google-beta/pull/4972
# google_sql_database.database will be updated in-place
  ~ resource "google_sql_database" "database" {
      ~ deletion_policy = "ABANDON" -> "DELETE"
        id              = "projects/graphite-test-rileykarson/instances/myinstance/databases/mydb"
        name            = "mydb"
        # (5 unchanged attributes hidden)
    }

The deletion_policy change has 2 implicit steps as follows:

ALTER DATABASE [library-main] SET single WITH NO_WAIT.
ALTER DATABASE [library-main] SET multi_user WITH NO_WAIT.

In our production, there is an exception after the first step and the database access mode wasn't changed back, so all of the services can't connect to the DB anymore.
Could we expose the deletion_policy as a variable in this module? so we can give it a stable value
Terraform Resources
No response
Detailed design
No response
Additional information
No response

This issue has been fixed in https://github.com/terraform-google-modules/terraform-google-sql-db/pull/395

Hello,
I'm also facing this behaviour 👍
It seems solved by https://github.com/terraform-google-modules/terraform-google-sql-db/commit/8ab6e374dd74a8c3f5d6963640f9eb945cd996f5 but not released
Is a released planned soon ?

Yes this seems to have been address by #386 and should be available with v14.0. Keep an eye on this: #380. Closing this now.


update quickstart to v4.1

This pull requests updates the quickstart command to use version 4.1.0.

v4.2 has been released, so I'll go ahead and close this. Thanks though!


Added XTIME fallback for Time coord generation

Change Summary
Added XTIME as fallback for Time coordinate decoding if Times does not exist for some reason.
Related issue number
Closes #169
Checklist

[x] Unit tests for the changes exist
[x] Tests pass on CI
[x] Documentation reflects the changes where applicable

I am happy to review as well @lpilz

Awesome, any time!


Some UI bug on Android

[x] Re-check bug error page in case delete account when wallet have 1 account
[x] Duplicate message(Android Samsung S20 FE 5G)

[x] Add network

Version test: PR #1142 09:15 10/11/2023
Device test: Samsung S20 FE 5G
Validation passed.


[RFC] [WIP] Consolidate OSX signing params

Per discussion in #285, I feel that there are too many OS X signing options, and that it would be better to group them together. This has the added benefit of leaving in room for a potential future Windows signing module to be integrated (#32).
CC: @sethlu

For the moment, I want to get a consensus on what the API/CLI params should look like, so I did the docs first.
@positlabs per https://github.com/electron-userland/electron-packager/issues/285#issuecomment-194389616, I don't know what bundle-identifier is. That doesn't seem like the same as identity?

@malept Do we then feed the osx-sign object into electron-osx-sign? That could work quite nicely when put together.
Also, we could try the same mechanism for modifying the various plists' items in OS X builds?

Do we then feed the osx-sign object into electron-osx-sign?

That was the plan, yes.

Also, we could try the same mechanism for modifying the various plists' items in OS X builds?

That sounds good too, but that should wait until after 6.0.0 is released.

@malept, sorry, I meant identity, not bundle-identifier.
I kind of started working on this. Here is my progress, in case it helps: https://github.com/positlabs/electron-packager/blob/master/mac.js#L162-L166
There is some extra logic for handling identifier. I think ideally we would copy the whole osx-sign object and pass it to electron-osx-sign without modification. Maybe this warrants an update to osx-electron-sign?

On https://github.com/positlabs/electron-packager/blob/master/mac.js#L166, I think we may go with
identity: signOpts.identity || true,

so when signing from CLI, we could simply use --osx-sign to trigger auto discovery of settings? Now we may need --osx-sign.identity instead.

Do you think this would work? I want to use the whole osx-sign object so it can serve as a passthrough to electron-osx-sign
      var signOpts = opts['osx-sign']

      // --osx-sign from CLI or osx-sign: true from API
      if(signOpts === true){
        signOpts = {
          identity: true
        }
      }

      // assign additional options from main opts
      if(typeof signOpts === Object){
        signOpts.app = finalAppPath
        signOpts.platform = opts.platform
      }

I'm not a fan of having parameters be more than one type, but we've already got a precedent with tmpdir. As with tmpdir, there would need to be special handling of the argument in cli.js (because minimist can't handle an argument that's more than one type).

I updated the description of osx-sign in both the CLI and API docs. Let me know if those changes don't accurately reflect the discussion.

Looks good. Should we add docs for binaries and verbose?

...yeah, why not. It's not too much effort. I really want to feature freeze master so 6.0.0 can get out the door.

@positlabs do you mind writing the docs here (or in a branch of this branch)? I won't be able to get to it until tomorrow at the earliest.

Sure, I can do that now

I can't figure out how to grab this branch. Maybe I have to be a contributor? Anyway, here's a snippet from the electron-osx-sign docs.
`binaries` - *Array*

  Path to additional binaries that will be signed along with built-ins of Electron. Default to null.

`verbose` - *Boolean*

  Verbose flag, to display logs. Allowed values: true, false.

This is how I'd do it:
git clone https://github.com/electron-userland/electron-packager
git checkout osx-sign-single-param

I would prefer it if we have an abbreviated version electron-osx-sign docs (don't say what the defaults are, for example) and make it obvious that for more information, you need to look at the other module's docs. I think I already did that in the readme.

Huh, deleting the repo and re-cloning did the trick.
For the sake of brevity, and the fact that these options are documented elsewhere, I think we should only add docs for binaries.

I'm thinking if we need to here distinguish darwin and mas as the signing identities are different for the two if both specified from osx-sign (and I'll have a think on how to put it more naturally if to have these two settings separated).
Also, once we have the params consolidated, I could have these pages on https://github.com/electron-userland/electron-osx-sign/wiki updated.

Here's my interpretation of this current discussion: (Please correct me if any's misunderstood.)

If to codesign an app with electron-packager, then a flag --osx-sign should be expected. (However, we are not taking into account that a mas distribution needs signing before going submitted.)
If to codesign an app with electron-packager, however, with custom identity, then (without an explicit --osx-sign flag) --osx-sign.identity will call codesign with the identity plugged in.
On the verbose flag, I think it could go with --verbose, so opts.verbose; so with a verbose flag given for electron-packager (if it eventually is going to have something like it), the same should apply for electron-osx-sign.

However, we are not taking into account that a mas distribution needs signing before going submitted.

We should address this before this gets merged.
Re: the verbose flag: I think your DEBUG change will be sufficient, I don't think we need to pass that in explicitly.

I have added a few lines here, but I'm unsure of how to merge into this PR.

(However, we are not taking into account that a mas distribution needs signing before going submitted.)

@sethlu I think we can allow mas builds to be unsigned in case the user wants to implement their own solution

@positlabs I'll merge it tomorrow. Looks good so far. Do you want to put your initial implementation in there as well?

Re: the verbose flag: I think your DEBUG change will be sufficient, I don't think we need to pass that in explicitly.

@malept nice. I should be able to have https://github.com/electron-userland/electron-osx-sign/pull/24 merged so DEBUG could be supported in a later release.

@sethlu I think we can allow mas builds to be unsigned in case the user wants to implement their own solution

@positlabs I don' know, because the entitlements specified should be different as well. :confused:

@sethlu is there a reason to sign darwin with entitlements? From what I understand, entitlements are only needed for mas builds, right?
@malept I can start working on implementation. Likely push tomorrow morning

@positlabs It's not required to sign darwin with entitlements. However, as the same script is used for packaging mas and darwin builds, --osx-sign may be acknowledged for mas and darwin if to package for all platforms at a same time.

Oh, I hadn't considered that!
I have some changes here. I tested building my app, and code signing is successful according to spctl.
Would there be any reason to allow the user to override platform or app if those options are included in osx-sign? Should we throw a warning/error if they attempt to? Or should we add logic to allow it? I vote we warn. If they want to really fiddle with the options, they can use electron-osx-sign directly.

Would there be any reason to allow the user to override platform or app if those options are included in osx-sign? Should we throw a warning/error if they attempt to? Or should we add logic to allow it? I vote we warn. If they want to really fiddle with the options, they can use electron-osx-sign directly.

A warning would be sufficient.

So I think what I want to do now is let @positlabs work on their branch (based off of mine), and when they're done, I'll merge that into this branch in a separate PR, then rebase + merge the whole thing into master.
Yep, I know it's pretty convoluted.

@malept, thanks. I'll add that warning.
Back to @sethlu's comment on mas distributions...

(However, we are not taking into account that a mas distribution needs signing before going submitted.)

Should this be handled in a separate PR? I'm not sure how to address it.

I think it's just another warning.

I made a noob mistake and assumed npm install would pull in my local version of electron-packager even though version hadn't changed. My previous test was invalid.
osx-sign is borking on binaries because they are not done copying before it runs. I'm copying a binaries folder with the asar-unpack-dir option. Is there a way we can run this copy op before signing?
I added some warnings, and my code is here https://github.com/positlabs/electron-packager

I assume you mean https://github.com/positlabs/electron-packager/tree/osx-sign-single-param
You may want to run $(npm bin)/standard.

Is there a way we can run this copy op before signing?

I don't see why not, from a conceptual standpoint. Try it and see if any tests fail.

@malet, yep, on that branch.
I've realized that the issue is that the files are actually in the temp build directory, and not the final path.
One solution would be to resolve the binaries paths to the temp dir. This adds more logic, but I'm not sure of any other way.
@sethlu do you have any ideas?

@positlabs On the asar-unpack-dir option, I'd just recommend not to use the asar option so all unpacked binaries that come with one app could be completely signed individually and ready for shipping.
However, as you mentioned that the binaries are packed in asar packages. I can't really tell if those packed executables are permitted to run in a sandbox environment. (I'm not sure if codesign alters the internal structure of executables/binaries, or just stores a hash for testing data integrity.)

Extra Unpacking on Some APIs
Most fs APIs can read a file or get a file’s information from asar archives without unpacking, but for some APIs that rely on passing the real file path to underlying system calls, Electron will extract the needed file into a temporary file and pass the path of the temporary file to the APIs to make them work. This adds a little overhead for those APIs.
From: http://electron.atom.io/docs/v0.36.3/tutorial/application-packaging/#extra-unpacking-on-some-apis

If those executables are unpacked to a temp dir, those binaries unsigned, it could be possible that they work without sandbox. I'll have a check on this now.

I swear I remember needing to sign these binaries for some reason, but maybe not. Using unsigned binaries in asar-unpacked doesn't seem to affect the .pkg or the .app during runtime, but I will try submitting a test build.
I'm using a lib, node-fluent-ffmpeg, which uses child_process.spawn(), which requires the binaries to live in the asar-unpacked dir according to this.
I suppose I could go without asar, but I think this is an issue worth solving. I just submitted a test build with unsigned asar-unpacked binaries, and no errors came up in the upload process. I think that means the code signing was successful.
Is there ever a reason to sign extra binaries?

@positlabs is the binaries signing option the only thing holding up your branch? If so, I'd like to defer that to another PR.

@malept, yeah that's all. It just doesn't work because of temp dir path. I'm not even sure if it's really needed, but @sethlu might know more.
I can add a warning against it, and comment it out of the docs. I agree it shouldn't hold up v6 any more.

I can add a warning against it, and comment it out of the docs. I agree it shouldn't hold up v6 any more.

:+1: Thanks for doing that. I'm going to (probably tomorrow) merge your branch into mine, squash your commits, and do some documentation fixes before merging this PR into master, and finally release v6.0.0.

In addition to documentation tweaks, I had to revert some syntax/API that didn't exist in Node 0.12, and added some testcases.

Just found https://github.com/electron/electron/blob/master/docs/tutorial/application-packaging.md#adding-unpacked-files-in-asar-archive. @positlabs I'll have a check later to see if some binaries present in the asar.unpacked dir will be auto-signed.


look_at gives strange results

Godot version:
3.2
OS/device including version:
win8
Issue description:
i place skidmarks on terrain via the code
var new_skidmark
new_skidmark = skidmark.instance()

# add skidmark
$"../..".add_child(new_skidmark)

# get Raycast Normal + HitPoint
var normal = $RayCast.get_collision_normal()
var point = $RayCast.get_collision_point()

# move skidmark to hitpoint
new_skidmark.translation = point

# hitpoint/hitnormal/velocity vector transform via look_at
# HERES THE PROBLEM since 3.2 !!!!!!!!!!!
new_skidmark.look_at(point - normal, get_linear_velocity() )

# move skidmark away from ground a little
new_skidmark.translate_object_local(Vector3(0,0,0.08))

now the problem/bug since 3.2:
if the ground is totally flat - the skidmarks are NOT rotated correctly along the velocity vector.
if the ground is just a little bit uneven, it works fine.
this look_at code worked in 3.1.2 just fine - in every case.
since 3.2 theres that problem if ground is totally even
look at hit_normal UP-AXIS=velocity_vector should work - and did 3.1.2
Steps to reproduce:

open the attached project
open the scene "look_at_bug"
press F5 and see the car driving and the skidmarks all over the place (rotation-wise)
now rotate the "GROUND" Meshs X-Axis 1 degree   (same scene)
press F5 and see the skidmark-rotation working just fine

Minimal reproduction project:
look_at_bug_1.zip

sorry for the strange format of my code
i used the code tag to insert the code in the issue... it looks totally broken... and i cant edit the issues content... just the title... is that normal?

Press three dots at the top of your post and you should be able to edit it.
The code tag is sometimes finicky in my experience.

The default code tag is for single lines. Use ``` instead, like
```
code
```

Please provide a minimal reproduction project. It is needed for the issue to be solved.

Hello!  :)
okay i attached a mini-project to the mein thread.
thx for helping :)

I think I have related issue, since i also have perfectly perpendicular inputs for look_at, tried to upgrade my project from 3.1 to 3.2.
look_at( (0,0,1) , (1,0,0) )
works the same but if i call it on the same object but with
look_at( (0,-1,0) , (1,0,0) )
the object is flipped in the up axis (1,0,0) which was not the case in the previous version and it breaks a big chunk of my project.
ive seen some changes to look_at to fix its issue with scaling in 3.2, but it might had broken it.

Seems like this is already fixed. Just tested provided minimal reproduction project and:

3.2.stable - bug,
3.2.3.stable - no bug,
3.3.2.stable - no bug.


Adds neighbourhooding to wind direction as a backup

Addresses #495
Adds a new (and default) backup method for most-likely wind direction to sample the local neighbourhood as well as other ensemble members when the derived wind direction comes with low confidence.
Follows PR #592
Testing:

[ ] Ran tests and they passed OK
[ ] Added new tests for the new feature(s)

Incorrect merges. Closing and trying again with Ben's help!


How to calculate variance

I notice that variance is calculated according to equation 7 in the paper, but the code seems not to be consistent with it.
I can not find the term (1-1/t)M_l_t-1

Hi, please check this issue.
Best,
Rick


Failed to build/deploy Kubernetes Spring Cloud LoadBalancer Example

Hi,
I tried to build/deploy the Kubernetes Spring Cloud LoadBalancer Example by running the command below:
mvn clean install fabric8:deploy -Dfabric8.generator.from=fabric8/java-jboss-openjdk8-jdk -Pkubernetes
But it failed on the Greeting Service as below.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Spring Cloud LoadBalancer Example 2.1.0-SNAPSHOT:
[INFO]
[INFO] Spring Cloud LoadBalancer Example .................. SUCCESS [07:44 min]
[INFO] Spring Cloud LoadBalancer :: Name Service .......... SUCCESS [01:54 min]
[INFO] Spring Cloud LoadBalancer :: Greeting Service ...... FAILURE [ 15.995 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  10:14 min
[INFO] Finished at: 2021-07-10T15:21:56+08:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project greeting-service: Could not resolve dependencies for project org.springframework.cloud:greeting-service:jar:2.1.0-SNAPSHOT: The following artifacts could not be resolved: org.springframework.cloud:spring-cloud-starter-kubernetes-fabric8-loadbalancer:jar:2.1.0-SNAPSHOT, org.springframework.cloud:spring-cloud-starter-kubernetes-fabric8:jar:2.1.0-SNAPSHOT: Could not find artifact org.springframework.cloud:spring-cloud-starter-kubernetes-fabric8-loadbalancer:jar:2.1.0-SNAPSHOT in spring-snapshots (https://repo.spring.io/snapshot) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :greeting-service

We branched the repo to begin work on our next release train.  We are still working through some build issues so some artifacts are missing.  It would be better to use the 2.0.x branch for now until we resolve things.


Add openSUSE binary

based on https://github.com/ghostty-org/ghostty/discussions/2720, add section for install binary on openSUSE by package manager.

I apologize but can you rebase on main. Thank you


Client optimisations

https://github.com/protolambda/eth2-impl-design
https://twitter.com/terencechain/status/1184963077575282689
PublicKey caching https://github.com/sigp/serenity-benches#pubkey-cache-builds

I believe all low-hanging fruits are gathered for now


Do not refresh the bitmasks on all operations in IPAM

Currently allocator pulls all the bitmasks from datastore
before processing each public API. This is not needed as
the APIs already selectively pull the interested bitmask
when needed.

Signed-off-by: Alessandro Boch<EMAIL_ADDRESS>

LGTM

LGTM


tslint-loader: disable for node_modules

I'm submitting a ...
[x] bug report
[ ] feature request
[ ] question about the decisions made in the repository

Do you want to request a feature or report a bug?
bug

What is the current behavior?
tslint-loader show warnings for node_modules folder

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via
Install any deps with tslint warnings.

I suggest exlude node_modules for tslint-loader in webpack.dev.js file via
exclude: [/\.(spec|e2e)\.ts$/, helpers.root('node_modules')]

Thanks for the fix! Had a lot of tslint warnings! :)

You can also exclude the node-modules folder in the lint property in the .angular-cli.json file.
Source: https://github.com/angular/angular-cli/wiki/angular-cli
example:
"lint": [
{
"project": "src/tsconfig.app.json",
"exclude": "/node_modules/"
},
{
"project": "src/tsconfig.spec.json",
"exclude": "/node_modules/"
},
{
"project": "e2e/tsconfig.e2e.json",
"exclude": "/node_modules/"
}
],

for any one referenceing this I found that you need to exclude to bee in this format
	"lint": [
		{
			"project": "src/tsconfig.app.json",
			"exclude": "**/node_modules/**/*"
		},
		{
			"project": "src/tsconfig.spec.json",
			"exclude": "**/node_modules/**/*"
		},
		{
			"project": "e2e/tsconfig.e2e.json",
			"exclude": "**/node_modules/**/*"
		}