broken redirect for medaka model

Description of the bug
when using the medaka path of the of the viralrecon pipeline an error is occuring. Seems the redirection for the file is broken (at least with curl the -L option has to be activated, to download the file). See attached log file
Command used and terminal output
nextflow run nf-core/viralrecon -qs 4 -revision 2.4.1 -profile docker --input results/benchmarking/nf-core-viralrecon/nanopore/sample-sheets/1_ont/sample_sheet.csv --sequencing_summary data/RAW/ONT_batch1/sequencing_summary.txt --fastq_dir resources/benchmarking/data/nf-core-viralrecon/1_ont/fastq_pass --fast5_dir resources/benchmarking/data/nf-core-viralrecon/1_ont/fast5_pass --platform nanopore --genome 'MN908947.3' --primer_set_version 3 --artic_minion_caller medaka --artic_minion_medaka_model r941_min_fast_g303 --outdir results/benchmarking/nf-core-viralrecon/nanopore/medaka/1_ont  > logs/nf-core-nf_core_viralrecon_nanopore/medaka/1_ont.log 2>&1

Relevant files
1_ont.log
System information
Nextflow version: 21.10.6
Hardware: Server
Executor: local via shell and Snakemake
Container engine: Docker/Conda
OS: Ubuntu 20.04.2 LTS
Version of nf-core/viralrecon: 2.4.1

Hi @alethomas ! Thanks for reporting! This appears to be an issue with the medaka tool attempting to auto-download the model for r941_min_fast_g303 from the ONT servers because it may not come shipped with the particular version used by the artic tool. Unfortunately, I don't have any better suggestions other than trying to download the file manually and providing via --artic_minion_medaka_model  /path/to/medaka/model.
There are some docs here for getting a list of models via the medaka tool. Once installed you should be able to run something like:
$ medaka tools download_models --models r941_min_fast_g303
[13:07:50 - ResolveModels] Model r941_min_fast_g303 is stored at: /home/<TRUNCATED>/python3.8/site-packages/medaka/data/r941_min_fast_g303_model.hdf5

Will close this for now as there doesn't seem to be fix I can add to the pipeline for this.


Work for only 1 year

Hi, I have installed pod in my project I have noticed that it work's for only one year which mean 12 month's  for example: it present month is Dec ,2018. it is moving forward scroll for Nov 2019 only only a 12 months working. please resolve this issue asap

@ShaikBaji1911 Hi, you can init VACalendar view with any dates http://prntscr.com/lw0hlt

Hello, Can you please update the pod with this piece of code so that there would be no problem we can use for any month any year  without no restriction to one year please. that's it everything wok's fine

@Vodolazkyi  Hi, Can you please update the pod with this piece of code so that there would be no problem we can use for any month any year without no restriction to one year please. that's it everything wok's fine please make the change it is very useful Thank's in Advance please reply asap @Vodolazkyi

@ShaikBaji1911 Just when you are doing let calendar = VACalendar(calendar: defaultCalendar) in your view controller
replace this line with  let calendar = VACalendar(startDate: startDate, endDate: endDate, selectedDate: endDate, calendar: defaultCalendar)
full code below
    let dateFormatter = DateFormatter()
    dateFormatter.dateFormat = "dd-mm-yyyy"

    guard let startDate = dateFormatter.date(from: "01-01-2000") else {
        fatalError()
    }
    guard let endDate = dateFormatter.date(from: "01-01-2050") else {
        fatalError()
    }

    // let calendar = VACalendar(calendar: defaultCalendar)

    let calendar = VACalendar(startDate: startDate, endDate: endDate, selectedDate: endDate, calendar: defaultCalendar)
    calendarView = VACalendarView(frame: .zero, calendar: calendar)
    calendarView.showDaysOut = true
    calendarView.selectionStyle = .single
    calendarView.monthDelegate = monthHeaderView
    calendarView.dayViewAppearanceDelegate = self
    calendarView.monthViewAppearanceDelegate = self
    calendarView.calendarDelegate = self
    calendarView.scrollDirection = .horizontal

great thank's  @SwarajMeetIOSDeveloper  I have fixed this issue at that same time. :) cheers !!


[Typo] "Theme does not exists"

When a theme is selected and then removed, a Box_Exception shows up to tell the user that the theme does not exist. There is a typo here, because it says "Theme :theme does not exists" instead of "Theme :theme does not exist"

Opened a PR to fix.

No need to create a bug report if you can fix it with a PR :)


Nested scroll containers

I'm trying to get this control working with something I'm pretty sure is not supported - multiple containing scroll frames.  As in the fiddle, this is one horizontal and one vertical.
It's very close to working as-is - the scroll event seems fine when returning multiple items from scrollContainer, it attaches to both and scrolls vertically as expected.  The actual header element, however, is cut off horizontally at the width of the outer container and does not clip to the direct parent, in this case the inner scroll area - this is most apparent when scrolling horizontally using the inner scroll area.  In fact, it does not even seem to clip to the outer on the left, though this is a bit hard to see in the fiddle.
Can you suggest how to get this working?  Or is it not something the control can (or will) support?
https://jsfiddle.net/dr0c8ao4/

This is not supported.. but I can get it working :)
This is actually how the responsiveContainer option works. The x and y scrolling are driven by different containers.
try this:
https://jsfiddle.net/dr0c8ao4/1/

I lied, its too good to be true, it wont work so well when there is a scrollbar on the window. But, you might be able to hack it into submission. I started doing it and made some progress, but I should stop and do real work now:
https://jsfiddle.net/dr0c8ao4/2/

Thanks for the advice, I've managed to get the top aligning correctly, though only by modifying floatthead to account for nested containers when calculating tableOffset inside calculateFloatContainerPosFn.  This removed the need to manually trigger the resize event.
Unfortunately, the headers still float past the bottom of the table's containing element - this is unaffected by my modification, you can see this in your second fiddle by adding a load of br elements after it.
Further, when integrated with my actual app the columns do not correctly align with the real table header when scrolling horizontally - there is a large padding getting added to either side of the floating header.  I've been unable to work out exactly what's causing this so can't provide a minimal example, though it's clearly something to do with the element styles since the padding is exactly the same size as the table's x-offset relative to its direct parent.  It's fine at the initial horizontal scroll offset, but the floating header does not extend left to match the new bounds of the real header when scrolling.
If you have any suggestions on where to look to tackle these further two issues, I'd appreciate it, but it looks like I won't be able to use this control for my app as refactoring the existing layout to get it to cooperate would be a huge amount of effort, and I only have limited time to work on it.

I would suggest looking at responsive scrolling. When it's active it uses window for y and container for x.
That's the best I can do. Good luck

Why do you have such a strange layout?

It's an existing form solution, as part of a larger application, that is broken down into sections, some of which may contain tabular data.  The sections individually scroll horizontally if there is too much content to fit on-screen, but the form as a whole scrolls vertically.  The location of the form container is also dynamic wrt the page.
Thanks for the help anyway!


fix InitFromSeed concurrency bug

This PR fixes https://github.com/NebulousLabs/Sia-UI/issues/583 and https://github.com/NebulousLabs/Sia-UI/issues/581, the wallet was not holding a lock during the duration of the InitFromSeed call, causing users to unlock their wallets while the seed sweeper was still running, resulting in an incorrect seed progress value.

In general don't we suffer from a situation where multiple concurrent calls that affect the scanner don't properly exclude eachother? And aren't these types of calls the things you wouldn't want to stack up? For example, if I call init-force multiple times, I think right now what would happen is one would block until the other finished, and then when the other finished the one would start, which could result in the wallet hanging for days if the user got frustrated and tried the same action multiple times after seeing no results.
We should probably have a separate trylock in the wallet that results in certain actions returning an error if the trylock indicates that they are already being performed elsewhere. The Sia/sync package already has a trylock implementation.

Agreed re: separate lock. It should be easy enough to add a "Already unlocking" codepath or similar. But this PR should at least fix the main issue in the meantime.


how to access "reversed"

We are updating our repos and noticed that the "reversed" Timeline property is no longer available in the latest update.
Is there a recommended way to play an animation in reverse?
Example of usage:
var clockcheck: ClockcheckTimeline!
clockcheck = ClockcheckTimeline(view: clockbegin, duration: 0.5)
clockcheck.reversed.reset()
clockcheck.reversed.play()

Thank you!

Hey, apologies for the delay.
The reversed property hasn't been taken out of the repo...
You can see it here: https://github.com/createwithflow/FlowCommoniOS/blob/4ae4d5e6221865180853ae052595f85305149303/Sources/FlowCommoniOSFiles/Timeline.swift#L151
The best way to play an animation in reverse is to store the reversed timeline like so:
let reversed = timeline.reversed()
Then, you can call:
reversed.play()

You should check out our iOS Custom Button export, it has a great approach for handling exactly the scenario you're working on.

Closing as there hasn't been any activity here in a while.
Feel free to reopen if this isn't resolved.


Missing Uplinks

Skylab has been noticing immense packet loss. They have a potential 5000 device deployment stuck due to this. They’re seeing 30-40% loss in uplinks. There's a probability that there's an overflow of data not getting forwarded to the console. Sensors that were working prior to the LHS update are no longer working. They have observed that the data was reaching the hotspot but is being dropped on the way to the LNS. They're also not seeing join attempts or accepts. The current gateways they are using are LongAP and Kerlink. Devices have also been rebooted/power cycled.

Let's see if the new miner update has had a positive impact on their situation like we've seen with other users: https://engineering.helium.com/2022/07/14/miner-hotspot-release.html

I'm still seeing this on some devices, others behave as expected. Don't know if it could be related but thought I'd post just in case it points towards something.
My devices with missing uplinks are the same devices that have the LinkADRReq/LinkADRAns Looping issue
https://github.com/helium/router/issues/791
On a device that behaves as expected I see the following

This device successfully transmits almost all of it's uplinks, you can see 1 missed uplink at the start of this, every other one was received

Contrast this with the device that has issues

Received uplinks, this sensor missed 15 uplinks over the same period


updates to compile on Jammy with rolling

Signed-off-by: Marco A. Gutierrez<EMAIL_ADDRESS>Bug fix
Fixed bug
rmf_traffic does not compile on Ubuntu Jammy.
Fix applied
Several updates regarding the use of std::optional and the lack of some includes.
This PR also adds rolling to the github workflow since it's the target release of the master branch.

I'm concerned about the changes to fcl that this PR adds.
@mxgrey looking at the Jammy version of fcl: https://packages.ubuntu.com/search?keywords=libfcl&searchon=names&suite=jammy&section=all do you think that packaged version is usable by us now?

Closing due to a hang on Build and test Expected — Waiting for status to be reported , will reopen a new one to se if it fixes the issue.


Mus don't record when the mouse hover an iFrame

Hello, first of all: Thank you for this library, really useful!
I want to point an issue when using an iframe, the mus.record() don't record the mouse when we hover an iframe.

To handle this, I simply added an absolute div on top of the iframe.


Error in compiling "psi_demo" file

I want to use the underlying SDK of psi and pir. At present, the compilation environment is installed in the official image.
When compiling and executing "psi_demo", an error is reported and there is no clue.
The specific implementation process is as follows:
cd spu
bazel build //libspu/psi/demo:psi_demo

Error reporting segment：

Could you please clarify the docker image and version?

secretflow/secretflow-anolis8:0.7.18b3
There is no compilation environment in this image. I have installed some related programs.

pls use secretflow/spu-ci:latest
Thx

Okay, I'll try.
Thx


Delete ovs bridge when forwarder stop

Description

Cleanup the bridge used to connect NSM endpoints.
Issue link

Related issue: networkservicemesh/sdk-ovs#276
How Has This Been Tested?

[ ] Added unit testing to cover
[x] Tested manually
[ ] Tested by integration testing
[ ] Have not tested

Reproduction steps described in the issue
Types of changes

[x] Bug fix
[ ] New functionality
[ ] Documentation
[ ] Refactoring
[ ] CI

networkservicemesh/cmd-forwarder-ovs#305.merged, closing this PR


Light is too bright when exported to Android with GLES2

Godot version:
3.2 beta3
OS/device including version:
Huawei Y6 (MYA-L11), android 6.0
Issue description:
Since beta 3 when exporting to Android with GLES2 directional light is too bright compared to when I run on windows. Not sure about other light sources, spot and omni light.

Scene is the same, I didn't change anything.
Steps to reproduce:
See the project I made for this issue. Compare the android export (apk not included).
Minimal reproduction project:
Made one just for this case.
simplemarsscene.zip

I made 1 more test, reconverting back to GLES3.0 and the strange thing is that now is too bright even there (PC and Android, the same).. Anyhow, I remember the previous versions where not doing that.
I'll wait till another beta or RC to see if it's only a matter of playing around with the parameters, I guess somehow they could have changed due to some GLES2 update(?).

You forgot to check "Is sRGB"

You forgot to check "Is sRGB". That will fix your issue in GLES3.
Ill see if I can reproduce the android issue later tonight.

I'm quite sure I haven't touched that, and it was looking ok with beta 2... I'll try that anyhow.

I can reproduce the issue on GLES2/android on beta3. It appears it is an issue with vertex-lit materials.
In GLES3 you are specifying sRGB colors and then rendering them as linear colors, so you need to set "Is sRGB" to true. When you have it properly set on all six of your materials then the sphere renders fine in GLES3, both on desktop and on mobile.

Here is what it looks like in GLES2/Android beta2

Ive figured out the root cause. It looks like on android the main scene shader isn't properly using the radiance mip-maps. So the specular is always way too crisp. In your test scene it looks like it is simply too bright.
I have started debugging it and it looks like mip-maps are being generated on android, they just arent being used properly.

@clayjohn not sure; but maybe this issue/comment is realted to the problem: https://github.com/godotengine/godot/issues/33633#issuecomment-554537340 there I noticed that on android (quest) the second mip-level was black

Here is what it looks like in GLES2/Android beta2

That's weird, this is how it looks on my mobile:

It is still too reflective, but that's because it has specular to 0.5.

@NeoSpark314 I definitely think it is related. Im noticing the black second mip level too. Now that I realized I can use render doc on Android I'll be able to really dig into it.

I don't know how useful this information is but, as I was trying to put the same rendering quality on desktop as mobile I realized that changing the shading parameters made it superbright as on mobile.
This is with the default settings:

And this with same as on mobile:

Can you try fiddling with the parameters on desktop to see which one exactly makes the difference?

Can you try fiddling with the parameters on desktop to see which one exactly makes the difference?

It's only when all of them are changed that you see it back to normal, uncheck only one and you'll see it too bright.
As an example, by just checking force vertex shading:

I spent a few hours on this issue before the holidays but ran out of time to fix it. I couldn't find any obvious reasons for it to happen. But indeed is connected to blinn shading and vertex shading. Unfortunately we will have to revisit after 3.2 is released.

That's really unfortunate. Somehow a regression that's going to stay for a final release.
Hopefully a 3.2.1 will be out soon after.. 😔

@Toshiwoz You could decrease the lights' intensity when vertex shading is enabled as a workaround. Attach this script to every light:
func _ready():
    if ProjectSettings.get_setting("rendering/quality/shading/force_vertex_shading"):
        energy *= 0.5

I get a similar issue but on desktop Windows 10 GTX 1650 Super. It looks normal with secularity disabled. It appears to happen only for light calculations interacting with secularity. Is almost as if roughness defaults to 0 for Vertex Shading. Ambient in the distance appears to look normal if not hit by a light source.
Force Vertex Shader (ON)

Force Vertex Shader (ON)  with specular_disabled

without Force Vertex Shader (OFF)

Should I make a new issue? I cannot find a related issue other than this one.

Fixed by #51410.


frontend improvement: connect wallet component

Description: Create a “Connect Wallet” button with a dropdown that matches the design in figma
This is the current look on production

This is how it should look like as it is on figma

Figma link; https://www.figma.com/design/6fQvKQWmxnt0XLUSjBjecj/MANCALA-Game-UI?node-id=1372-11495&m=dev

•	The connected wallet icon reveals where the "Braavos" wallet logo is displayed.
    •	Clicking anywhere on the button should open a modal showing options to connect a wallet.
•	The dropdown menu should only appear when the (^) icon is clicked.
•	Wallet disconnection can only be done using the button found within the dropdown.
•	Note: The profile page has not been created yet.

Hi @Israelrex9 , Please can I be assigned this issue? I’m a Full-Stack Blockchain Developer and I believe I can solve this issue. Please give me the opportunity.

@Israelrex9

I believe should use the wallet provider logo for this and not Starknet icon. I like the other part of the suggestion.

@Israelrex9 i would love to work on this issue

Updated the description, everyone.
✨ When applying for a task, please include a brief description of your experience and an estimated time frame for completion.

Hi @Israelrex9 my name is Joy and I am a frontend developer proficient with React, next js, shadcn, tailwind css. I'll have this task ready before close of business today.

As a UI/UX Designer, I have extensive experience in creating user-centered designs that enhance user experiences and meet business objectives. My expertise includes User Research, wire-framing and prototyping, Visual Design, Interaction Design and collaboration.
As a Full-Stack Blockchain Developer, I possess a robust skill set in both front-end and back-end development, My experience includes html, css, react, JavaScript Cairo ,TypeScript, rust and small knowledge on GO.
I’d have my PR ready in less than 24 hours once I’m assigned.

•	The connected wallet icon reveals where the "Braavos" wallet logo is displayed.
•	Clicking anywhere on the button should open a modal showing options to connect a wallet.
•	The dropdown menu should only appear when the (^) icon is clicked.
•	Wallet disconnection can only be done using the button found within the dropdown.
•	Note: The profile page has not been created yet.

@Israelrex9 can you also include a screenshot of the drop down? This will be helpful for the developer to complete the task

Hello @Israelrex9 im waiting to be assigned by you please🙏🏾

Hello i'd like to be assigned this

Hi @Israelrex9 ,
I'm Ugo, a fullstack developer with a strong track record in OD hack projects (JavaScript, React, Node.js, Next.js, Three.js). I've been actively involved since Edition 2, contributing to various initiatives, and I'm excited to be part of Edition 5!
My extensive experience using OnlyDust (as reflected in my profile: https://app.onlydust.com/)) has given me a deep understanding of the platform. I'm eager to leverage this knowledge and my fullstack skills to tackle new challenges within this edition.
In particular, I'm interested in the dropdown button component development.  My experience with similar UI components and familiarity with the Figma design make me confident in delivering a pixel-perfect representation. I estimate the completion timeframe to be 1-2 days, depending on the specific requirements. I will proactively communicate any unforeseen delays.
I'm highly motivated and ready to contribute effectively. I'd happily take on this task if it's still available. Please let me know if you have any questions or require further information about my skills and experience.
Thanks.

Hi @Israelrex9 I am a frontend developer with 6 years experience building applications and I would love to work on this issue
Here is my onlydust profile: https://app.onlydust.com/u/Ayoazeez26
Here is my github profile: https://github.com/Ayoazeez26
I would take 2 working days to deliver this task unfailingly

I would like to try this. This sounds interesting

ChatGPT
Certainly! Here's the text in English:
I'm excited to tackle my first issue here, leveraging substantial experience in frontend development. I intend to approach this challenge progressively and efficiently.
The process I'll follow will be structured to meet the project's specific requirements. Based on the provided details:
I will implement functionality so that clicking anywhere on the button opens a clear modal with options to connect a wallet.
I'll ensure the dropdown menu appears only when clicking the (^) icon, ensuring an intuitive and organized user experience.
For wallet disconnection, I'll enable this action exclusively through the button within the dropdown, adhering to specified guidelines.
It's worth noting that the profile page hasn't been created yet, and I'll factor this into future implementation considerations. I'm eager to contribute my technical skills and deliver a robust, well-integrated solution for this issue.
I'm ready to get started and committed to delivering high-quality results!

@od-hunter I just assigned the task to you

@okhaimie-dev thank you

here ser: https://t.me/+0UKU3P3Eh_s2NTRh
feel free to ask questions there

@od-hunter we'll be working with you on this as I'm also working on refactoring. Will say hi on TG. Trying to minimize conflicts.
First step, ensure separation of concerns. I also have some inputs on that, we'll discuss that soon

@od-hunter are you still working on this, or should I reassign it to someone else

Hey @okhaimie-dev , yes I’m still working on it, I’ll send a PR before the end of today🙏🏾

@okhaimie-dev please review🙏🏾


[BUG] i cant leave the game

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.
[X] I have thoroughly looked through the available Wiki articles and could not find a solution to my problem.
[X] I am using the latest version of Bloxstrap.
[X] I did not answer truthfully to all the above checkboxes.

What problem did you encounter?

the escape menu is stuck on the 2015 one and will not let me leave roblox.
Bloxstrap Log
No response

I'm tired of these 10k duplicate posts man.
Add this fflag
{
"FFlagFixReportButtonCutOff": "False"
}
if it doesn't work, use the 2023 menu.

I'm tired of these 10k duplicate posts man. Add this fflag { "FFlagFixReportButtonCutOff": "False" } if it doesn't work, use the 2023 menu.

thank you it worked. also 10k duplicate posts? i saw no one put a similar post

Yeah because you're too lazy to search first. And also if you looked up, there was literally a post.


add custom imgui styles again

its very nice. imgui styles are very good you can set the style of imgui and the styles are very stylish and stuff like that

I assigned mfed as a joke, simply, no.

I don't see why we couldn't but I'm not willing to spend time to make this how I'd want (saving/loading like reshade)


fix: allow missing MIME type in data URI

this is a belt-and-braces thing as I'm pretty sure Vite will always add a MIME type (hence no test), but just in case we end up copying this regex somewhere else it makes sense to fix it. Means that things like data:,Hello%2C%20World%21 will match.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[x] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

[x] Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

I'm pretty sure Vite will always add a MIME type (hence no test)

You could potentially refactor it into a utility method and just have a vitest unit test for it

You could potentially refactor it into a utility method

that would be premature


rename DEFAULT_MAX_REDIRECYIONS to DEFAULT_MAX_ATTEMPTS

Find that maxRedirection has been rename to maxAttempts in JedisCluster.
Should we also rename DEFAULT_MAX_REDIRECYIONS  to DEFAULT_MAX_ATTEMPTS.

LGTM. @marcosnils WDYT?

@wantedlzx Sorry I didn't aware this patch is against 2.8. We don't treat such kind of PR unless it is only applied to such version. Could you make this patch against master?

hi, @HeartSaVioR
Thanks for review this patch, I have made a patch against to master (#1595)


ASA-5820

Using the latest API's in place of deprecated ones.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


ROKMETRO Updates

Description
This PR contains changes, fixes, and improvements from the ROKMETRO team. These changes were introduced and used by a variety of other applications. The goal of this PR is to align the Illinois app and the rest of our apps on a single branch of the plugin.
We understand that there are a lot of changes here and some of them are quite significant, so all feedback is very welcome. Please let us know if you have any suggestions, concerns or thoughts about the changes we made here.
Thank you!
Depends on: https://github.com/rokwire/core-building-block/issues/674

The changes in Auth2 are mostly related to this issue
@roberlander2 has made a PR to get all of these changes merged into develop on the Core BB soon: https://github.com/rokwire/core-building-block/pull/707

Hi @shurwit,
It is better in the future to use the "classic" way and have standalone PRs for each separate feature that you want to integrate in app-flutter-plugin. This huge PR contains an ocean of changes containing too many different features. It is hard to observe and analyze and obviously it will get merged mostly as it is without a necessary analysis why we do something, are there alternative ways, and so on.
I have some questions on your updates in the plugin:
1. What is the exact purpose of Service.initServiceFallback?
Service.initService API returns error only in case it fails to initialize. If there is cached data it is loaded and the initialization is assumed to be successful. Particularly initService could fail only on the first application launch when there is no cached data yet, and calling initServiceFallback after such failure makes no sense.
When any service returns a fatal error on its initialization the only sensible action to tame (in my opinion) is to present the relevant UI to the user, explaining what happened and giving an option to retry again the service initialization. This is what Illinois app does.
2. What is the purpose to make NotificationsListener.onNotification asynchronous (i.e. to return a Future)?
As far as I can see, maybe this was some experiment that was abandoned? The only sensible reason for this that I can think of is to make Notification.notify API also asynchronous and to await a given notification to get processed. This completely contradicts the philosophy and intent of NotificationService, and if you really need to perform some asynchronous processing at a given point, NotificationService is not a suitable tool for handling this.
3. Assets service
I retired the Assets service after moving all statically embedded assets in the Illinois app to our Content BB service. I see it resurrected in rokmetro-updates branch, not used by anyone particularly. FlexContent widget in develop branch refers to Content service and it is not actually used and kept only for "historical" reasons. So I would guess this was some technical mistake when you merged develop to rokmetro-updates branch. Am I right?
4. App Styles
Something that is not good (and I know it does not come from your updates) is linking app style classes methods with the expected styles.json content. While we can afford this at app level since styles depend on the app we cannot do this on the plugin level as we have no idea what style definitions would the host app have. To make things worse we added some UI classes in the plugin that refer to particular style entries. In my opinion this was a mistake, we should not place UI stuff in this component. Anyway, we should think of some resolution or at least minimizing the inconsistency that we appear to have.
I started integration of the changes coming from "rokmetro-updates" branch of app-flutter-plugin in Illinois app. I created "rokmetro-updates" branch in Illinois app repo for this. While some of the issues are clear and easy to fix there are other issues that I am not quite sure how to resolve. For example, I am not sure how to handle the changes in the Auth2 APIs. I am also making minor updates in "rokmetro-updates" branch of app-flutter-plugin but if you feel that something is wrong please let me know for this.
Thank you!

Hi @mihail-varbanov, thanks for looking at this and for providing your feedback!

It is better in the future to use the "classic" way and have standalone PRs for each separate feature that you want to integrate in app-flutter-plugin. This huge PR contains an ocean of changes containing too many different features. It is hard to observe and analyze and obviously it will get merged mostly as it is without a necessary analysis why we do something, are there alternative ways, and so on.

Yes I definitely agree with this. This was the result of us working on independent projects with time pressure so neither you nor we had the bandwidth to review and merge these changes independently. With that being said I do think we can and should keep these more organized along the way to make the review process more manageable once we get to that point. I also hope to keep the plugin more aligned going forward in general to avoid these types of divergences whenever possible. Let me know if you have any other thoughts on how we should organize the process for continued alignment and contributions to the plugin going forward.

I have some questions on your updates in the plugin:

What is the exact purpose of Service.initServiceFallback? Service.initService API returns error only in case it fails to initialize. If there is cached data it is loaded and the initialization is assumed to be successful. Particularly initService could fail only on the first application launch when there is no cached data yet, and calling initServiceFallback after such failure makes no sense.

When any service returns a fatal error on its initialization the only sensible action to tame (in my opinion) is to present the relevant UI to the user, explaining what happened and giving an option to retry again the service initialization. This is what Illinois app does.

I am certainly not sure that the fallback initialization system we have here is an ideal solution but let me try to describe the situation that led to these changes. For the Vogue app they did not want to display an initialization error to the user if one occurred. Rather they just wanted to land on the login page and display an error if the user attempts to login. I am checking to see if the services initialized successfully or not at that point. If they did not I attempt to reinitialize before attempting to login and display an error to the user if the initialization fails again.
All of this being said, the fallback initialization is intended to allow services to be initialized even if one of its dependencies could not be initialized. As an example it is possible to initialize the Styles service regardless of what happens to any other dependencies (ie. even if Configs fail to initialize). This is important because regardless of how we handle the error (displaying the initialization error and retry panel that you mentioned, showing the login page like we do for Vogue), we need to ensure that the correct styles are loaded in order to display the page appropriately. We have default style references included in the plugin that do need to be overridden by some form of Style service initialization for everything to look and work as expected.
Hopefully this helps you understand the intention of this system. At the time I felt that this was the way to support the expected functionality with the least impact or risk to existing functionality, but I am very open to suggestions as I do feel that it is probably more complicated than it should be.

What is the purpose to make NotificationsListener.onNotification asynchronous (i.e. to return a Future)? As far as I can see, maybe this was some experiment that was abandoned? The only sensible reason for this that I can think of is to make Notification.notify API also asynchronous and to await a given notification to get processed. This completely contradicts the philosophy and intent of NotificationService, and if you really need to perform some asynchronous processing at a given point, NotificationService is not a suitable tool for handling this.

The intention here is to optimize performance around notifications. In general, the notification service is used to communicate between various services and UI components that do not have direct references to each other. Usually, this is used when one service performs an action that requires various other services to perform related actions or requires the UI to be updated (possibly in multiple places). I cannot think of many situations where the actions triggered by the notification need to be performed one by one or in any specific order. Even if they did need to be performed in a certain order, the notification service does not support this since the order is arbitrarily determined by when each notification listener was registered.
This change was made because we noticed significant performance deterioration when many services or UI components are listening for the same notification. It does not make sense to me that we would wait for each one to complete before moving on to the next since as I described above there cannot really be any logical relation between each service/UI component onNotification function.
Let me know if you think I am missing something, but I can say that this significantly improved the performance of the app where many listeners were added to the same notification since each listener was previously being called only after all actions were completed by the previous one.

Assets service I retired the Assets service after moving all statically embedded assets in the Illinois app to our Content BB service. I see it resurrected in rokmetro-updates branch, not used by anyone particularly. FlexContent widget in develop branch refers to Content service and it is not actually used and kept only for "historical" reasons. So I would guess this was some technical mistake when you merged develop to rokmetro-updates branch. Am I right?

We did intentionally bring this back at one point but I can no longer find the reason that we needed it. I have removed it as I agree that this should be retired as you intended.

App Styles Something that is not good (and I know it does not come from your updates) is linking app style classes methods with the expected styles.json content. While we can afford this at app level since styles depend on the app we cannot do this on the plugin level as we have no idea what style definitions would the host app have. To make things worse we added some UI classes in the plugin that refer to particular style entries. In my opinion this was a mistake, we should not place UI stuff in this component. Anyway, we should think of some resolution or at least minimizing the inconsistency that we appear to have.

I understand your concerns about the style references within the plugin, although I don't know that it is actually broken as you described. Since the style definitions in the plugin can and should be overridden by the app itself, these changes should be reflected within the UI components in the plugin. My introduction of the code generation tool (tools/gen_styles.dart) for the styles was also intended to help with this, as it will automatically merge in the styles.json definitions within the plugin into the app styles.json. This ensures that we do not forget about or overlook any of the definitions in the plugin when creating a new app. Are you seeing anything specific that is actually broken or not working as expected due to the style references?
I personally feel that it is important that we have a strategy that allows us to define reusable UI components in the plugin that we can use across various apps if we want to. This dramatically reduces code duplication and speeds up development times. I know this is something that we discussed before and I don't believe we ever really settled the debate, but my feeling is that the goal of the plugin is to make reusable components like these available. Any input you have on how we can approach this in a way that is maintainable would definitely be appreciated, but my team has been using this system across a couple of apps now and so far it has worked pretty well for us.

Plugin assets (styles.json & timezone.tzf) I do not think the right location of these items is in the plugin. The reason is that they could vary for different applications but we want to keep a single plugin codebase for all host apps.

These are both intended to be defaults that can be overridden by the app itself. All of the apps that we have built so far have used the same base definitions for both of these assets so I feel that not including them just creates more unnecessary work. For styles.json specifically, please see my note above about the code generation tool merging these styles above. This was added so that we can guarantee that the necessary style references are available so we can enable the creation of widgets that depend on these overridable styles.

I started integration of the changes coming from "rokmetro-updates" branch of app-flutter-plugin in Illinois app. I created "rokmetro-updates" branch in Illinois app repo for this. While some of the issues are clear and easy to fix there are other issues that I am not quite sure how to resolve. For example, I am not sure how to handle the changes in the Auth2 APIs. I am also making minor updates in "rokmetro-updates" branch of app-flutter-plugin but if you feel that something is wrong please let me know for this.

Thanks for working on this! Yes, the Auth2 changes are not quite ready to be incorporated. As I mentioned above @roberlander2 is working on wrapping up a PR on the Core BB for @petyos to review. This is also a fairly substantial change so it will take some time to review. We will need to merge that PR and deploy to dev before we are able to test the Auth2 changes in the Illinois environment.
Thanks again for all of your comments here! I know this is not an ideal workflow and I appreciate your willingness to work through this with us. My main goal with this PR is to help get us aligned so we can work more collaboratively going forward rather than further diverging on separate branches like this. Hopefully some of these changes will be helpful in the Illinois app too, but at the very least it will let us start fresh and begin contributing the plugin in a more sustainable way going forward.

Hi @shurwit,
Thank you for your feedback!
0. Use the "classic" way …
I see we are on the same page and we will try to avoid situations like this in the future (as far as it is possible :grin:).
1. Service.initServiceFallback
I understand the case. BTW, the Illinois app had a similar problem when displaying the error panel with the "Try Again" button. Styles and Localization were not available and as long as I remember I did not use these in this panel.
I do not like the initServiceFallback resolution because it appears to me like a patch. I think the source of the problem is somewhere else, it is in the not-precise service dependency definition. Styles, FlexUI or Localization do not really depend on Config service, as they state, because they can get initialized without the app config being available. They need Config service only for checking if there are some overrides from the Net, but this does not break their initialization.
I think the right resolution is to tune and adjust the dependency of the services, their initialization process, and the use cases when we throw the fatal initialization errors. My belief is that once this get tuned and adjusted Vogue can present its login UI in case of fatal initialization error, and re-attempt Services initialization again on the next login attempt from the user. My suggestion is, if you do not mind, I to try to implement this for the Vogue app in a separate branches (in Vogue and the plugin), and if my resolution is fine for the Vogue app (you will judge that) to incorporate this update in the "rokmetro-updates" branch. Does this sound good to you?
2. NotificationsListener.onNotification
I see, it makes sense. I had mistakenly assumed that the purpose of this was to await notification processing by all listeners (for some reason). It is true that we do not always care not to perform lengthy processing in notification handlers, that could lead to performance issues. Applying the FutureOr magic appears to be a quite clever solution.
3. Assets service
Good, thanks.
4&5. App Styles / Plugin Assets
Today I ran the "gen_styles.dart" tool for the first time and saw what its idea was. Yesterday I was assuming that it will build gen/styles.dart inside the plugin, not in the application. Building gen/styles.dart in the application level makes many of my concerns meaningless.
While talking about "gen_styles.dart" tool, could you make a few minor improvements/fixes there:

Do not modify the input "assets/styles.json" file;

Define some naming convention for ignoring style entries that match a given pattern. For example, to ignore entries in styles.dart that start with "". By ignoring I mean not to try creating the corresponding class entry in gen/styles.dart output. The idea is to leave an ability to place comments in the source styles.json file. If you open Illinois's styles.json you will see a few entries starting with "" that are supposed to be comment lines for human's usage. "gen_styles.dart" tool currently creates the relevant class entries for them in gen/styles.dart that causes Flutter build errors. It is not a big deal to fix them manually after the tool but it is better if they just get omitted.

Now I am switching back to Style definitions in the plugin. Generally yesterday I did not like the idea of having AppColors.fillColorPrimary definition in the plugin. The reason for this is that we cannot assume that all apps that host this plugin will have the same or similar styles definitions and structure like the Illinois's app. As far as I understand the only reason to have them in the plugin is to serve the UI components that reside in the plugin, e.g. RoundedButton, RibbonButton and so on. Is that so?
I would like to take a stand on the subject about "having a strategy that allows us to define reusable UI components in the plugin". I have two notes:

I have been working with/for JP for more than 20 years and I have done this exercise many times. My personal experience shows that "defining reusable UI components in the plugin that we can use across various apps" is a lost fight and it usually requires more effort than benefits it brings. The reason for this is that usually the different apps have so different UI requirements that it becomes a nightmare to try to keep it as a shared and reusable component.

Something else. How many times did you use RoundedButton or SurveyWidget in the Vogue app? I think the philosophy of the good reusable component is to support only the intersection of the features that the different apps use, and each app to implement locally the features which only it uses. The opposite strategy, adding everything to the plugin that someone could eventually use in the future, just increases its size and the complexity of the plugin maintenance.

Right now I'm just sharing with you my thoughts on this matter. I know you have a different opinion. I find this discussion useless at the moment because we are trying to predict what will happen in the future, i.e. what the other apps that will host this plugin would expect from it. In Bulgaria we have a saying "to put the cart before the horse". I mean we are trying to design a plugin that will serve some unknown client apps. The order must be the opposite: first see what clients exactly will use this plugin, find the intersection of their needs, and implement it in this shared and reusable component. So, what I am trying to say is that for now we can keep what we have in the plugin, and think on the possible solutions when other client app appear and the current model in the plugin does not apply well for them.

Integration of "rokmetro-updates" in Illinois app
I see, and thank you for helping us with this integration! At the moment I prepared what I was able to in the app branch. I left the Login UI unchanged, with the build errors, because I am not sure how this should get handled in the app.

I agree with you that if we are going to share the same source codebase we should work more collaboratively together than we used to do. I see your efforts in this direction and I am grateful to you about this.

Hi @mihail-varbanov, thanks again this is all very helpful!

Service.initServiceFallback I understand the case. BTW, the Illinois app had a similar problem when displaying the error panel with the "Try Again" button. Styles and Localization were not available and as long as I remember I did not use these in this panel.

I do not like the initServiceFallback resolution because it appears to me like a patch. I think the source of the problem is somewhere else, it is in the not-precise service dependency definition. Styles, FlexUI or Localization do not really depend on Config service, as they state, because they can get initialized without the app config being available. They need Config service only for checking if there are some overrides from the Net, but this does not break their initialization.
I think the right resolution is to tune and adjust the dependency of the services, their initialization process, and the use cases when we throw the fatal initialization errors. My belief is that once this get tuned and adjusted Vogue can present its login UI in case of fatal initialization error, and re-attempt Services initialization again on the next login attempt from the user. My suggestion is, if you do not mind, I to try to implement this for the Vogue app in a separate branches (in Vogue and the plugin), and if my resolution is fine for the Vogue app (you will judge that) to incorporate this update in the "rokmetro-updates" branch. Does this sound good to you?

I see exactly what you mean and agree that what you described here sounds like a better solution. I will leave it to you to take a pass at this dependency optimization as you suggested and I will test it out when you are done. Let me know if you have any questions about our use case along the way. Thanks for you help with this!

NotificationsListener.onNotification I see, it makes sense. I had mistakenly assumed that the purpose of this was to await notification processing by all listeners (for some reason). It is true that we do not always care not to perform lengthy processing in notification handlers, that could lead to performance issues. Applying the FutureOr magic appears to be a quite clever solution.

I'm glad this makes sense to you now! I'm not sure we even need the FutureOr vs. just switching to Future completely because I wasn't sure if there was a reason that it was built synchronously in the first place that I was overlooking and I did not want to force an update in the Illinois app across all notification listeners.
That being said, if you do not see a reason that these should ever be synchronous I would suggest that we just go ahead and make all notification handler calls asynchronous. Let me know what you think about this. Thanks!

4&5. App Styles / Plugin Assets Today I ran the "gen_styles.dart" tool for the first time and saw what its idea was. Yesterday I was assuming that it will build gen/styles.dart inside the plugin, not in the application. Building gen/styles.dart in the application level makes many of my concerns meaningless.
While talking about "gen_styles.dart" tool, could you make a few minor improvements/fixes there:

Do not modify the input "assets/styles.json" file;
Define some naming convention for ignoring style entries that match a given pattern. For example, to ignore entries in styles.dart that start with "". By ignoring I mean not to try creating the corresponding class entry in gen/styles.dart output. The idea is to leave an ability to place comments in the source styles.json file. If you open Illinois's styles.json you will see a few entries starting with "" that are supposed to be comment lines for human's usage. "gen_styles.dart" tool currently creates the relevant class entries for them in gen/styles.dart that causes Flutter build errors. It is not a big deal to fix them manually after the tool but it is better if they just get omitted.

Thanks for the suggestions above! I'm also very glad that the style generation tool makes sense to you and that you also feel it alleviates some concerns about the use of styles in the plugin.

The reason for the modification is to handle the merging that I mentioned between the styles in plugin and the app itself. If you see a way to avoid unnecessary modifications that I am overlooking please let me know but I don't think it would be possible to do a merge like this and maintain the existing formatting.
I like this suggestion, I will go ahead and make this change.

Now I am switching back to Style definitions in the plugin. Generally yesterday I did not like the idea of having AppColors.fillColorPrimary definition in the plugin. The reason for this is that we cannot assume that all apps that host this plugin will have the same or similar styles definitions and structure like the Illinois's app. As far as I understand the only reason to have them in the plugin is to serve the UI components that reside in the plugin, e.g. RoundedButton, RibbonButton and so on. Is that so?
I would like to take a stand on the subject about "having a strategy that allows us to define reusable UI components in the plugin". I have two notes:

I have been working with/for JP for more than 20 years and I have done this exercise many times. My personal experience shows that "defining reusable UI components in the plugin that we can use across various apps" is a lost fight and it usually requires more effort than benefits it brings. The reason for this is that usually the different apps have so different UI requirements that it becomes a nightmare to try to keep it as a shared and reusable component.
Something else. How many times did you use RoundedButton or SurveyWidget in the Vogue app? I think the philosophy of the good reusable component is to support only the intersection of the features that the different apps use, and each app to implement locally the features which only it uses. The opposite strategy, adding everything to the plugin that someone could eventually use in the future, just increases its size and the complexity of the plugin maintenance.

Right now I'm just sharing with you my thoughts on this matter. I know you have a different opinion. I find this discussion useless at the moment because we are trying to predict what will happen in the future, i.e. what the other apps that will host this plugin would expect from it. In Bulgaria we have a saying "to put the cart before the horse". I mean we are trying to design a plugin that will serve some unknown client apps. The order must be the opposite: first see what clients exactly will use this plugin, find the intersection of their needs, and implement it in this shared and reusable component. So, what I am trying to say is that for now we can keep what we have in the plugin, and think on the possible solutions when other client app appear and the current model in the plugin does not apply well for them.

I do agree that there will be cases where the UI components need to be styled quite differently between applications. This will be the case whenever we are working with a customer that has strong pre-existing design and branding guidelines and wants us to build an experience that matches (ie. Vogue). On the other hand, we also have done and will continue to do projects where the customer defers to us on design considerations for the most part and just wants to provide us with some colors, fonts, and possibly icons (safer community, chronic illness app, memory app... etc.). In these cases, having standard reusable components makes everything much easier to implement, and as you can see the style system aligns well with our needs.
All of that being said, I see your point about over-planning and trying to predict what will come (interestingly the exact phrase "putting the cart before the horse" is a saying in English as well). I think for the moment you are right we do not need to make any changes. I just wanted to come to some conclusion with you about the correct approach so that we are aligned as we go forward.
Based on what you are saying it sounds like you are open to the idea of adding in more reusable UI components as we begin to see the need for them, which is what I was hoping to clarify. If this is the case, I would suggest that as we move forward and begin developing new applications we begin making PRs to add components that we feel are reusable (eg. if we want to use an existing component in the Illinois app or some other app that is not yet in the plugin, or if we create a component that we feel is fundamental and want to be able to easily access in future apps). We can then discuss on a case-by-case basis each one when you review the PR and decide if it makes sense or not. Does this sound ok to you?

Integration of "rokmetro-updates" in Illinois app I see, and thank you for helping us with this integration! At the moment I prepared what I was able to in the app branch. I left the Login UI unchanged, with the build errors, because I am not sure how this should get handled in the app.

Ok sounds good. I would suggest that our team can work on your Illinois app branch and help resolve the remaining build errors to prepare for the changes to the Core BB. We can test it out once @petyos has had a chance to review and merge @roberlander2's PR (which is available here for tracking purposes: https://github.com/rokwire/core-building-block/pull/707).

I agree with you that if we are going to share the same source codebase we should work more collaboratively together than we used to do. I see your efforts in this direction and I am grateful to you about this.

Thanks for the acknowledgement and for all the feedback again! I feel like we are now fairly aligned on these issues and have a clear path forward!

Hi @mihail-varbanov, just wanted to give you a quick update on your styles generation comments. I believe I have hopefully addressed both of your comments in the last couple of commits.

You recommended not editing the styles.json source file when running the generation. My best guess as to why you said that is because we do not want to overwrite the formatting in this file (ie. ordering of entries, blank spaces). I do want to maintain the merging functionality to add missing entires from the plugin for visibility to avoid the confusion you mentioned around plugin references to the styles. I found a way to preserve both the ordering and blank spaces in the styles.json and I hope this addresses your concerns.
I added support for '_' prefixed comments within the style sections.

Please try it out now and see what you think. If there are any remaining concerns let me know. Thanks!

Hi @shurwit,
Thanks for your comments. Here are my replies and comments on them.
1. Service.initServiceFallback
OK, thanks. I will start the work on this. I will ask you for some assistance/clarification if I need it in Vogue, and will let you know when I get ready.
2. NotificationsListener.onNotification

I'm glad this makes sense to you now! I'm not sure we even need the FutureOr vs. just switching to Future completely because I wasn't sure if there was a reason that it was built synchronously in the first place that I was overlooking and I did not want to force an update in the Illinois app across all notification listeners.
That being said, if you do not see a reason that these should ever be synchronous I would suggest that we just go ahead and make all notification handler calls asynchronous. Let me know what you think about this. Thanks!

Nowhere in the source code does it wait for any notification to be processed, i.e. there is not a problem with the notification handlers being asynchronous (returning Future). However I think you will get exactly the same result as the current when they are actually FutureOr. The reason is that when Dart calls a function that is FutureOr it always does not "await" for its execution even if the function is actually synchronous and returning void (take a look here). When I see that some function returns Future I am expecting there to be performed some asynchronous processing, that is not exactly the case of NotificationListener's onNotification handlers. So to summarize, what I am trying to say is that I do not expect problems from changing onNotification to return Future instead of FutureOr, I just find it a little unnatural and maybe confusing for someone aside. However if you are strongly convinced that this will be for the better we can do it.
4&5. App Styles / Plugin Assets

The reason for the modification is to handle the merging that I mentioned between the styles in plugin and the app itself. If you see a way to avoid unnecessary modifications that I am overlooking please let me know but I don't think it would be possible to do a merge like this and maintain the existing formatting.

I did not know that you are trying to merge plugin and app's styles.json. I do not think that this is a good idea and the right way to go, I mean to override the app's source code or resources (gen directory content is something else). If you take a look at Styles service you will see that it reads and merges the "default" (assets/styles.json) and "app" (app/assets/styles.json) style definitions, but this happens programmatically and does not modify any source data. This is the way that I designed to build apps that are very similar to Illinois, customizing just some colors, fonts, strings, etc. In my opinion this is the right way to go, if we need to merge plugin and app resources at all, please see bellow.
In general, I think there should not be any resource definitions in the plugin. I would rather go towards removing them from the plugin and working on opening the plugin widgets to be easily customized (fonts, colors, etc.) by the host app, without making explicit references any entries from styles.json. Let me say it again, the Illinois app codebase is theoretically prepared (but never used) to support multiple build targets that can build apps that are similar to the Illinois app.

just wanted to give you a quick update on your styles generation comments…

Thanks for the quick update. When I try to run the latest script version I get this error:
FormatException: Unexpected character (at line 1061, character 1)
"_blank_assets/styles.json#1060": "",
^
asset was not loaded

This did not used to happen before.

Based on what you are saying it sounds like you are open to the idea of adding in more reusable UI components as we begin to see the need for them, which is what I was hoping to clarify. If this is the case, I would suggest that as we move forward and begin developing new applications we begin making PRs to add components that we feel are reusable (eg. if we want to use an existing component in the Illinois app or some other app that is not yet in the plugin, or if we create a component that we feel is fundamental and want to be able to easily access in future apps). We can then discuss on a case-by-case basis each one when you review the PR and decide if it makes sense or not. Does this sound ok to you?

I am sorry but this does not sound quite good to me. I think that adding a reusable UI in the plugin should happen only when more than a single host app needs it. Until this happens, the potentially reusable UI should reside in the plugin host app only. When another host app appears that needs the same UI, we can design the right model of the UI component that will go down to the plugin, analyzing the different requirements that come from the different apps. This is "to put the cart after the horse" for me.
In general, I think that the plugin should contain the intersection of the reused UI across the host apps, not the union of everything used in these apps. I think that we should try to keep the plugin as small and simple as possible, not trying to grow it without а good and clear reason.
6. Integration of "rokmetro-updates" in Illinois app

Ok sounds good. I would suggest that our team can work on your Illinois app branch and help resolve the remaining build errors to prepare for the changes to the Core BB. …

Thanks, this is exactly what I was trying to suggest.

Hi @mihail-varbanov, thanks!

Service.initServiceFallback

OK, thanks. I will start the work on this. I will ask you for some assistance/clarification if I need it in Vogue, and will let you know when I get ready.

Sounds good to me!

NotificationsListener.onNotification

I'm glad this makes sense to you now! I'm not sure we even need the FutureOr vs. just switching to Future completely because I wasn't sure if there was a reason that it was built synchronously in the first place that I was overlooking and I did not want to force an update in the Illinois app across all notification listeners.
That being said, if you do not see a reason that these should ever be synchronous I would suggest that we just go ahead and make all notification handler calls asynchronous. Let me know what you think about this. Thanks!

Nowhere in the source code does it wait for any notification to be processed, i.e. there is not a problem with the notification handlers being asynchronous (returning Future). However I think you will get exactly the same result as the current when they are actually FutureOr. The reason is that when Dart calls a function that is FutureOr it always does not "await" for its execution even if the function is actually synchronous and returning void (take a look here). When I see that some function returns Future I am expecting there to be performed some asynchronous processing, that is not exactly the case of NotificationListener's onNotification handlers. So to summarize, what I am trying to say is that I do not expect problems from changing onNotification to return Future instead of FutureOr, I just find it a little unnatural and maybe confusing for someone aside. However if you are strongly convinced that this will be for the better we can do it.

Thank you for bringing this to my attention. I spent some time looking into this and I actually think that I was mistaken about this entire thing and that the change we made here probably did not improve the situation at all. I had a fundamental misunderstanding of how the async functions work in Dart. Because Dart runs everything in a single isolate/event loop (https://dart.dev/language/concurrency) it seems like the code executed within an async function actually is performed synchronously unless it is waiting on some form of I/O stream. To test this out I wrote a minimal example that compares the execution and performance between the async and synchronous onNotification implementation:
import 'dart:async';

void main() async {
  List<NotificationsListener> listeners = [
    FutureExample(), Example(),
  ];

  for (NotificationsListener listener in listeners) {
    print(listener);
    DateTime time = DateTime.now();
    for (int i = 0; i < 3; i++) {
      listener.onNotification('call$i', i);
    }
    print(DateTime.now().difference(time));
  }
}

class Example with NotificationsListener {
  void onNotification(String name, dynamic param) {
    int val = 0;
    for (int i = 0; i < 200000; i++) {
      for (int j = 0; j < i; j++) {
        val = i*j;
      }
    }
    print('sync: $name: $val');
  }
}

class FutureExample with NotificationsListener {
  Future<void> onNotification(String name, dynamic param) async {
    int val = 0;
    for (int i = 0; i < 200000; i++) {
      for (int j = 0; j < i; j++) {
        val = i*j;
      }
    }
    print('async: $name: $val');
  }
}

abstract mixin class NotificationsListener {
  FutureOr<void> onNotification(String name, dynamic param);
}

I tried running this and I found that even with the async function, the code is executed synchronously and sequentially just like the synchronous function. I actually found that it took longer to run the async functions, most likely due to additional overhead to set them up. See an example of the results below:
Instance of 'FutureExample'
async: call0:<PHONE_NUMBER>2
async: call1:<PHONE_NUMBER>2
async: call2:<PHONE_NUMBER>2
0:00:16.271095
Instance of 'Example'
sync: call0:<PHONE_NUMBER>2
sync: call1:<PHONE_NUMBER>2
sync: call2:<PHONE_NUMBER>2
0:00:14.966502

I think I mistakenly thought that this change had an impact on the performance we saw in the app when in fact the improvement was due to some other changes that we were making along side this one. Let me know what you think, but based on the results here I actually feel that it is best to revert this change completely to the current state on develop at this point. I am glad that I learned more about how the async functions operate in Dart from this, but I apologize for the unnecessary work looking into it.

4&5. App Styles / Plugin Assets

The reason for the modification is to handle the merging that I mentioned between the styles in plugin and the app itself. If you see a way to avoid unnecessary modifications that I am overlooking please let me know but I don't think it would be possible to do a merge like this and maintain the existing formatting.

I did not know that you are trying to merge plugin and app's styles.json. I do not think that this is a good idea and the right way to go, I mean to override the app's source code or resources (gen directory content is something else). If you take a look at Styles service you will see that it reads and merges the "default" (assets/styles.json) and "app" (app/assets/styles.json) style definitions, but this happens programmatically and does not modify any source data. This is the way that I designed to build apps that are very similar to Illinois, customizing just some colors, fonts, strings, etc. In my opinion this is the right way to go, if we need to merge plugin and app resources at all, please see bellow.
In general, I think there should not be any resource definitions in the plugin. I would rather go towards removing them from the plugin and working on opening the plugin widgets to be easily customized (fonts, colors, etc.) by the host app, without making explicit references any entries from styles.json. Let me say it again, the Illinois app codebase is theoretically prepared (but never used) to support multiple build targets that can build apps that are similar to the Illinois app.

just wanted to give you a quick update on your styles generation comments…

Thanks for the quick update. When I try to run the latest script version I get this error:
FormatException: Unexpected character (at line 1061, character 1)
"_blank_assets/styles.json#1060": "",
^
asset was not loaded

This did not used to happen before.

I think there are tradeoffs here and I see both sides of the argument. I think it will be a little tricky to communicate like this to address this. I spoke to @pmarkhennessy earlier today about this and I believe he would like to discuss with you on a call to make sure we all understand each other's perspective well.
As for the error you mentioned, thanks for catching that. I pushed some updates that hopefully resolve a couple of issues including that one.

Based on what you are saying it sounds like you are open to the idea of adding in more reusable UI components as we begin to see the need for them, which is what I was hoping to clarify. If this is the case, I would suggest that as we move forward and begin developing new applications we begin making PRs to add components that we feel are reusable (eg. if we want to use an existing component in the Illinois app or some other app that is not yet in the plugin, or if we create a component that we feel is fundamental and want to be able to easily access in future apps). We can then discuss on a case-by-case basis each one when you review the PR and decide if it makes sense or not. Does this sound ok to you?

I am sorry but this does not sound quite good to me. I think that adding a reusable UI in the plugin should happen only when more than a single host app needs it. Until this happens, the potentially reusable UI should reside in the plugin host app only. When another host app appears that needs the same UI, we can design the right model of the UI component that will go down to the plugin, analyzing the different requirements that come from the different apps. This is "to put the cart after the horse" for me.
In general, I think that the plugin should contain the intersection of the reused UI across the host apps, not the union of everything used in these apps. I think that we should try to keep the plugin as small and simple as possible, not trying to grow it without а good and clear reason.

I think if I am understanding you correctly you are taking issue with my statement that I would like to add components to the plugin "if we create a component that we feel is fundamental and want to be able to easily access in future apps" but not the part about adding components when "we want to use an existing component in the Illinois app or some other app that is not yet in the plugin." If this is indeed what you mean then I am happy to move ahead with this approach as I agree that we would not want to clutter the plugin with unnecessary UI and it should not be too hard to move the components in the future if they ever are needed in multiple apps. If you feel I misunderstood your point here please let me know. Thanks!

Integration of "rokmetro-updates" in Illinois app

Ok sounds good. I would suggest that our team can work on your Illinois app branch and help resolve the remaining build errors to prepare for the changes to the Core BB. …

Thanks, this is exactly what I was trying to suggest.

Great, we'll get started on this soon.

Hi @shurwit, thank you!
1. Service.initServiceFallback
I created two PR with the suggested workaround: https://github.com/rokwire/app-flutter-plugin/pull/439 and https://github.com/rokmetro/vogue-app/pull/713
2. NotificationsListener.onNotification
I was wrong too. I knew that everything is executed on the main thread/isolate. However I was expecting that when using FutureOr as a return type the onNotification handlers will get invoked after NotificationService.notify call finishes, and this helps you somehow to improve the performance. Today I played with this and found that this is true only if we wait for async calls in onNotification handlers (something that we normally do not do), and also that there is absolutely no difference if onNotification return type is void or FutureOr. I think it is safe and better to return it to void as it was initially.
4&5. App Styles / Plugin Assets

I think there are tradeoffs here and I see both sides of the argument. I think it will be a little tricky to communicate like this to address this. I spoke to @pmarkhennessy earlier today about this and I believe he would like to discuss with you on a call to make sure we all understand each other's perspective well.

I am looking forward to this conversation.

I think if I am understanding you correctly you are taking issue with my statement that I would like to add components to the plugin "if we create a component that we feel is fundamental and want to be able to easily access in future apps" but not the part about adding components when "we want to use an existing component in the Illinois app or some other app that is not yet in the plugin." If this is indeed what you mean then I am happy to move ahead with this approach as I agree that we would not want to clutter the plugin with unnecessary UI and it should not be too hard to move the components in the future if they ever are needed in multiple apps. If you feel I misunderstood your point here please let me know. Thanks!

This is exactly what I had in mind. It is great that we are on the same page.


Fat extension descriptions

We have an ExtensionDescription which is basically a subset of an extension's package.json. However, when parsing and worst send setting up the extension host we use everything that's in the file. That can be a lot more data then we want and might affect start up performance because we need everything to be send over to the extension host

Hey guys, this breaks the latest beta of the C# extension and I'm certain it will break the shipping version of the C/C++ extension. In those extensions, we've added more information to the manifest, which we use in the extension to download platform-specific dependencies at runtime.

cc @eamodio

Maybe extensions can have some way of expressing a whitelist of properties they do want provided?

Possibly, but that requires extensions to update. Personally, I'd prefer avoiding a breaking change.

Oh, 💩... Didn't even think of that. @sandy081 Sorry for the mess, but I think we need to revert this...

Sure.. will revert

@jrieken I reverted this for now.
I see we expose the packageJSON as an API, and this will be broken if we do not send all data.
What is the use case of exposing this? If it is just let extensions to access their package.json, Isn't it possible for them to get it by calling require(package.json) instead of us providing it?

@sandy081: That would still break shipping extensions. Are there measurements indicating that this change is worth the headache?

@DustinCampbell Ofcourse removing any API will break the extensions. I am trying to understand why we had this API.
I do not have any measurements, but reducing data to sent is always faster. I agree that this should not impact in any breakages. I will revisit this with better and non-breaking approach, if there is major performance impact.

Could changes be made to understand who uses this? If it's a limited number of extensions and this change results in a meaningful performance improvement, it'd be good to understand the impact.

We should measure but I am not expecting this to be very expensive. My initial complained was a bit anal as before we would load and discover all extension descriptions inside the extension host. Now we do it outside and have to send that as initial payload. Let's measure first how much that costs...


use new geobase docker images

expecting everything will fails so need to fix issues as we progress

closing this PR as this needs more work.


Mixin Crash

Minecraft v1.16.5
Forge v36.1.24
More Waterlogging v1.5
Statement v4.0.1
After installing I seem to be getting a mixin crash, although I'm unsure which other mod it is conflicting with.
Crash Report

Not my fault, one of the mods installed has a conflicting mixin/js coremod

If you find it, post it here so that others know.

This crash only happens when More Waterlogging is added to my modpack. If I remove it, the modpack works perfectly.

It's because more waterlogging or statement has a mixin that conflicts with another one, but that doesn't mean that more waterlogging is to blame.
There is nothing I can do on my end until the conflicting mod is at least identified.

Ok, yeah, looks like the crash is triggered by Statement and that there is alse an incompatibility with FerriteCore.
Virtuoel/Statement#5

Closing as resolved since it doesn't involve this mod


better title/descriptions of metrics

@mathias, when you write these, can you please let me know which google doc they're in -- going to use it as the data feed for the app's "what is this", instead of hard-coding it.

sure thing. so you were thinking the descriptions would be hidden and then show upon hovering over key words?

More or less. You'll see in the UI once I build it -- it's a pretty common model of a question mark or similar that gives a tooltip on tap or hover.
On Thu, Sep 10, 2015 at 10:31 AM, Mathias Gibson<EMAIL_ADDRESS>wrote:

sure thing. so you were thinking the descriptions would be hidden and then show upon hovering over key words?
Reply to this email directly or view it on GitHub:
https://github.com/codeforamerica/mdc-feedback/issues/258#issuecomment-139319295

For the violations types, from the County:
"Open - when the SR is first open, the case starts out in Open.
Locked - once the department has received the SR, it changes to Locked.  This can take minutes to hours to happen depending on the department actually.  Code Compliance is usually pretty quick.  These are also still active cases.
Lien/Closed - if they were found in violation and went through the warning, citation, remediation and did not pay, it is changed to Lien status.  A lien is filed against the property and is now with the Lien Unit.
Closed - usually means all is handled.  Could be Not in Violation, Issue Corrected by Owner, Issue Resolved, etc.  No further action needed.
We don’t have an Unresolved option, so, these are what we use.  I have attached some examples for you."

@phiden here's a doc to store these as we go: https://docs.google.com/spreadsheets/d/170neJyhcBkg3sgABsqKk1B6WJa51r6oo6PEMAlwOBB8/edit#gid=0


Installer: log process

Codecov Report

Merging #1530 (6a6766f) into main (76ffb8a) will decrease coverage by 0.17%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main    #1530      +/-   ##
==========================================
- Coverage   46.96%   46.79%   -0.17%
==========================================
  Files          47       47
  Lines        6778     6781       +3
==========================================
- Hits         3183     3173      -10
- Misses       3595     3608      +13

Impacted Files
Coverage Δ

lnbits/extension_manager.py
46.68% <0.00%> (-0.41%)
:arrow_down:

lnbits/db.py
76.51% <0.00%> (-6.05%)
:arrow_down:

lnbits/commands.py
57.89% <0.00%> (-1.76%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Implement type inference for AllGatherOp

To quote the spec, "type(result) = type(operand) except dim(result, all_gather_dim) = dim(operand, all_gather_dim) * dim(process_groups, 1)". However, at the moment we cannot compute "dim(process_groups, 1)" because it depends on num_replicas and num_partitions. We'll need to resolve this.

Sorry - I haven't provided a rationale for why I unassigned this ticket.
dim(process_groups, 1) is something that we cannot compute at the moment. It needs num_replicas and num_partitions, and that's not something that is reflected in the StableHLO dialect right now. #425 is planning to fix this by adding this information to the StableHLO opset (and the dialect).
In the meanwhile, while this work is blocked on another ticket, I've unassigned this ticket.


📚 Doc/contributing.md

Description:
This pull request introduces a new CONTRIBUTING.md file to the repository. This file aims to provide clear and comprehensive guidelines for contributing to the project, ensuring that new contributors have a well-defined path to follow.
Changes:

Added a CONTRIBUTING.md file to the root directory of the repository.
The file outlines the steps and best practices for contributing to the project.

File Contents:
The CONTRIBUTING.md file includes:

Introduction: Brief overview of the project's contribution process.
How to Contribute: Steps for submitting contributions, including for bug reports, feature requests, and code contributions.
Code of Conduct: Expected behavior and guidelines for all contributors to foster a positive community.
Development Setup: Instructions for setting up a development environment.
Testing: Guidelines for writing and running tests.
Submitting Pull Requests: Best practices for creating and submitting pull requests, including how to write a good pull request description and commit messages.

Purpose:
Adding this file serves several purposes:

Guidance: Provides new contributors with clear instructions on how to get involved.
Consistency: Ensures that contributions follow the project's standards and practices.
Efficiency: Streamlines the contribution process, making it easier for maintainers to review and merge contributions.
Quality Assurance: Helps maintain high-quality contributions by setting clear expectations and providing helpful resources.

Thank you for reviewing this addition. Your feedback and suggestions are welcome!

Closes #12

fix conflict here


Add organization or facility-specific patient registration link capability to the backend

Related Issue or Background Info

Resolves #1349

Changes Proposed

Adds a migration for a new patient_registration_link table
Adds PatientRegistrationLink model and associated repository
Adds some tests

Additional Information

For the purpose of easily ensuring uniqueness, this seemed to make sense as its own table rather than an additional field on both the org and facility tables
Added a constraint to this new table using an sql field in the migration file to make sure that each row has either an org ID or facility ID but not both or neither. (I didn't test this constraint; is there a good way to test?).

Checklist for Author and Reviewer
UI

[NA] Any changes to the UI/UX have been approved by design
[NA] Any new or edited error messages have been approved by design

Testing

[X] Includes a summary of what a code reviewer should verify

Changes are Backwards Compatible

[X] Database changes are submitted as a separate PR (this is the PR)
[NA] GraphQL schema changes are backward compatible with older version of the front-end

Security

[NA] Changes with security implications have been approved by a security engineer (changes to  authentication, encryption, handling of PII, etc.)
[NA] Any dependencies introduced have been vetted and discussed

Cloud

[NA] DevOps team has been notified if PR requires ops support

@nullflux I initially misread the ticket and now I'm wondering if this is the right approach. The ticket specifies that you might have an organization registration link that looks like register/org-slug or you might have a facility registration link that looks liek register/org-slug/facility-slug.
The way I coded this ticket was that it would look more like register/org-or-facility-slug. Is this reasonable or should I look at reworking this ticket to have separate org an facility slugs?


only in .match/.find make .embeddings raise error if it contains None element

decided to drop this feature


GzipEnabled = false has no effect on .NET Core 1.x

In Src/Support/Google.Apis.Core/Http/HttpClientFactory.cs we set HttpClientHandler.AutomaticDecompression if GzipEnabled is true, but if GzipEnabled is false, we don't take any action.
On .NET Core 1.x, the default behavior of HttpClientHandler is to perform decompression. Here's an example:
Project file:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp1.0;netcoreapp1.1;netcoreapp2.0;net46;net47</TargetFrameworks>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="System.Net.Http" Version="4.3.3" />
    <PackageReference Include="System.Net.NameResolution" Version="4.3.0" />
  </ItemGroup>
</Project>

Program.cs:
using System;
using System.Net.Http;

class Program
{
    static void Main(string[] args)
    {
        var handler = new HttpClientHandler();
        Console.WriteLine(handler.AutomaticDecompression);
    }
}

Results:
$ dotnet run -f netcoreapp1.0
GZip, Deflate
$ dotnet run -f netcoreapp1.1
GZip, Deflate
$ dotnet run -f netcoreapp2.0
None
$ dotnet run -f net46
None
$ dotnet run -f net47
None

This tallies with a .NET Core compatibility analyzer issue that noted the behavior changing between Core 1.x and 2.0.
If GzipEnabled is false, we should explicitly set AutomaticDecompression to DecompressionMethods.None.

The AutomaticDecompression documentation has more details:

For the .NET Framework 4.x System.Net.Http binary in the Global Assembly Cache (GAC), the default value is None.

When the System.Net.Http NuGet package v4.1.0 to v4.3.2 is used, the default is GZip and Deflate.

After NuGet package v4.3.2, the default value of None is used.


fix(skip): Abort build

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add new graphql qeury

This PR is for a feature that is only used in rio projects.

Added graphql queries for triage and outliers.
Added graphql queries for semi-supervised model.
Added agent_id for filtering agent id to EventListWithTriageFilterInput.
Added new fields to the sampling policy's enum Interval.

Codecov Report
Attention: 626 lines in your changes are missing coverage. Please review.

Comparison is base (2e85115) 47.08% compared to head (595767a) 44.45%.

Files
Patch %
Lines

src/graphql/outlier.rs
0.00%
283 Missing :warning:

src/graphql/event.rs
2.19%
223 Missing :warning:

src/graphql/semi_model.rs
3.80%
101 Missing :warning:

src/graphql/triage/policy.rs
5.88%
16 Missing :warning:

src/graphql.rs
0.00%
3 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##              rio     #112      +/-   ##
==========================================
- Coverage   47.08%   44.45%   -2.63%
==========================================
  Files          65       66       +1
  Lines       10432    11069     +637
==========================================
+ Hits         4912     4921       +9
- Misses       5520     6148     +628

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


Please tell me if there is an interface card with support for two-way audio ???

Please tell me if there is an interface card with support for two-way audio ???

I saw someone make one, but I don't have a link to it. Look it up on GitHub.

@TokarevSergey  , have you found it?

@TokarevSergey , вы нашли его?

No, I didn't.
I am using web torrent links.

Web torrent links?

Ссылки на веб-торренты?

https://github.com/AlexxIT/go2rtc#module-webtorrent

Ссылки на веб-торренты?

You can open the page in any browser with two-way audio.


[@ionic/core 4.0.1] Spinner follows an out of bounds track

Bug Report
Ionic version:
[x] 4.0.1
Current behavior:
The spinner that appears in the loader (among other places, including the spinner tag itself) follows a path which is not correct. See the gif hosted on Imgur below for exactly what is happening. This occurs on only one of the devices we've tested
https://i.imgur.com/BRU7VaY.gif - Recorded from the Chrome Dev Tools screencasting tool, but occurs on the device itself
Expected behavior:
The spinner should follow a concise circular pattern, rather than the stretched variation shown in the gif
Steps to reproduce:

Install Ionic Core on a barebones Cordova project
Include some form of the <ion-spinner></ion-spinner> tag on a working page. The test repo uses the LoadingController to demonstrate other components are working as intended.
Load the app onto a phone (may or may not show incorrectly)

Related code:
I realize now that I originally named the repo wrong. The actual issue is the Spinner, not the Loading container
https://github.com/wcmhc/IonLoadingOffCenter
Other information:
Device: Physical Blu Pure XR running Android 6.0
Ionic info:
We are running a Cordova stack without the Ionic CLI due to specific requirements. We use @ionic/core from NPM, currently installed is v4.0.1

I recognize this behaviour when building my Ionic4 app for Electron. In the browser and on iOS and Android the spinner works fine, but in Electron it also follows this path outside the loading square. Maybe this information is helpful when trying to find why this happens.

I recognized the same behaviour on older Android WebViews e.g. 61.

One of our QA testers reported the same issue with the following emulator. I successfully reproduced locally
Build: OSM1.180201.007
Build fingerprint: 'google/sdk_gphone_x86/generic_x86:8.1.0/OSM1.180201.007/4586646:user/release-keys'
Release Name: Android Oreo 8.1
Bootloader: unknown
Radio: (unknown)
Network: Android
Kernel: Linux version 3.18.91+<EMAIL_ADDRESS>(gcc version 4.9 20140827 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jan 9 20:32:02 UTC 2018

Name: Nexus_5X_API_27
CPU/ABI: x86
Target: google_apis_playstore [Google Play] (API level 27)
Skin: nexus_5x
AvdId: Nexus_5X_API_27
avd.ini.displayname: Nexus 5X API 27


Fix last seen v2

Description
creating a new PR instead of requesting permissions to push to https://github.com/RedHatInsights/insights-results-smart-proxy/pull/872/files
fixes last_checked_at functionality for v2/report endpoint, but keeps the functionality in v1
Fixes # (issue)
Type of change
Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)

Testing steps
make before_commit + locally
Checklist

[x] make before_commit passes
[ ] updated documentation wherever necessary
[ ] added or modified tests if necessary
[ ] updated schemas and validators in insights-data-schemas in case of input/output change

Codecov Report

Merging #879 (502d6b8) into master (e4d4d9d) will increase coverage by 0.28%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #879      +/-   ##
==========================================
+ Coverage   59.90%   60.18%   +0.28%
==========================================
  Files          22       22
  Lines        3030     3029       -1
==========================================
+ Hits         1815     1823       +8
+ Misses       1009      998      -11
- Partials      206      208       +2

Impacted Files
Coverage Δ

server/server.go
59.15% <50.00%> (+1.16%)
:arrow_up:

Continue to review full report at Codecov.

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


Add option to specify priorityClassName to the helm charts

Add option to specify priorityClassName to the helm charts
https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/

Please sign the DCO.
git rebase main --signoff

Also ensure to bump the chart version and generate the docs to make it succeed.


Module import bug

Describe the bug
When using the OL package, in some circumstances (used as a module), importing the RBush package results in an error.
Error messages in browser
Uncaught SyntaxError: import not found: default Executor.js:5:7

and
Uncaught SyntaxError: import not found: default RBush.js:4:7

Bad codes
https://github.com/openlayers/openlayers/blob/82328fe2c1d336bae3744526e18ffa4726be9fbf/src/ol/render/canvas/Executor.js#L5
and
https://github.com/openlayers/openlayers/blob/139b048197f705ccd26919813a6728496423b4be/src/ol/structs/RBush.js#L4
Correctly
The following changes will correct the error.
In the Executor.js:
import RBush from 'rbush';

and in the RBush.js:
import RBush_ from 'rbush';

Thanks @ahocevar!


Replace deprecated mem::uninitialized()

Follow up to #173. If we vendor the parts of MaybeUninit we need for the places where we use it, then we can get rid of all mem::uninitialized and still support Rust older than 1.36.
Because my impression is that there is no way parking_lot will make it into std while using methods std has deprecated and explicitly stated no one should use.
I was not able to make the vendored version #[repr(transparent)].

bors r+

As I wrote, #[repr(transparent)] does not work on unions. But we could add #[repr(C)], that works. Do you think it's worth it? I'm not aware how Rust lays out unions without explicit repr specified.

Considering pre-1.36 compilers aren't being updated anymore, I think it's safe to rely on undocumented behavior (struct layout for single-field structs) for those.

Looks like travis tries to use the branch staging.tmp while in reality it's just called staging

bors retry


Spotter search in Coder

Coder should allow the user to search for packages, classes, and methods.
Something like this:

Selecting a class in coder spotter already works, but spawns browser behind as well due to spotterActDefault on class, cannot be easily shortcut.
Also, selecting anything other than a class does nothing yet, needs to support package and method.

Currently looks like this:


Add Java 9 to Travis

Following the changes made by @jackyq2015 to adapt the script for Java 9 I have tried to enable Java 9 in Travis. It looks like one tests fails with this Java version, due to a different behavior in date parsing. I'm just submitting this PR so that people are aware of the issue. It should of course only be merged once we find a fix for that, and we should not claim that OR runs with Java 9 before that.

we need to fix those failed test cases.


Badge always showing in Slack service

Expected Behavior

If there is no unread message in slack, icon shouldn't show a badge.
Current Behavior

Slack service shows a badge even though when I enter there are no unread messages.
Screenshots (if appropriate):

Context

It's annoying
Your Environment

Franz Version used: 5.0.0-beta.10
Operating System and version: macOS High Sierra 10.13

Duplicate of meetfranz/recipe-slack#1
This repository is only for the Franz client. Please report issues in the dedicated recipe repository.
www.github.com/meetfranz/recipe-slack


feat: check pre-requisites on OSSM plugin init

Checks that the authorino and SMCP CRDs are installed on the cluster before proceeding with plugin installation
Checks that the SMCP referenced in the plugin spec exists and is ready before proceeding
Adds rudimentary testing for the relevant functions that do the heavy lifting in these checks

Creating tests was a bit difficult for the SMCP specifically - please let me know if you see any ways that that process of simulating an SMCP install can be improved.

Also, I added the latest SMCP entire CRD - let me know if I should add a truncated one instead.

I took a look at how CRDs are fetched for project-controller - thanks for linking that. Since I want to get the Dashboard Config patching fixed today I've created another issue to handle this in the future here. PTAL and let me know if that's ok.