Workaround for plugin window size on Mac Retina

This is a patch for https://github.com/DISTRHO/DPF/issues/291. It is far from perfect, for example it assumes plugin windows are displayed on the main screen. Have been testing a similar solution for a while in my plugins and could not find negative side effects.

shouldnt this be handled directly in pugl?
or at least this needs to go in the window private data class, as we can create windows that are not part of a plugin.
(for example, for an about dialog or preferences, that is not embed in the host; or just standalone tools even)

I think the culprit is only a mismatch between the coordinate systems of the DPF plugin (ultimately provided by Pugl, right?) and the host. The former already has the scaling factor applied and the latter expects AppKit, non-scaled pixels, ie. what you would find in a NSView rect (this is an assumption but I cannot think why it should be otherwise). So when the host queries the plugin window size it gets oversized dimensions on Retina. If this is correct then there is no generalized issue, and no need to cover the mentioned additional use cases.
One fact that supports this is that the standalone examples look perfect without the patch applied (and the patch also won't affect them).

I am also assuming Pugl pixels are not AppKit pixels but expressed in the OpenGL coordinate system instead. But Pugl and OpenGL are really out of my league. Take the above with a grain of salt.

Tried a hacked d_states that popups a 200x200 window when one of the blocks is clicked. See how the black 200x200 window size remains constant for all tested scenarios: standalone, standalone+patch, reaper, reaper+patch. I understand this as proof that the bug only affects the main window and only when running as plugin. And the problem is actually in the container view provided by the host, which is oversized because of the explanation above, there is no problem with the DPF windows themselves.
ExampleUIStates.cpp.zip

I dont quite get how backingScaleFactor() changes between use in one application and not the other, but alright if it works it works.
Putting it on the UI class is still not ideal though.
Please try moving the special division case to Window::PrivateData class, on its onPuglConfigure method.
The uwidth/uheight can be modified in there if isEmbed is true, which then will make this apply to all Windows that are embed into something else (without them having to be plugins).

Oh and then for moving this to window class we can no longer use the plugin UI methods, so getMacMainScreenBackingScaleFactor needs the same treatment regarding pugl.hpp/cpp as you did in the previous PR.
From there we can have access to NSApplication and NSView of pugl, so maybe there is a way to access the current screen of the view, instead of referencing the "mainScreen".

I dont quite get how backingScaleFactor() changes between use in one application and not the other, but alright if it works it works.

That is not quite what is happening but I'm sure it is my fault for not properly presenting the issue.
These snippets from Pugl are illustrative:
https://github.com/lv2/pugl/blob/c98ee490fcf93e290ae5e8a602fd88b359a61a1b/src/mac.m#L1322
PuglStatus
puglSetFrame(PuglView* view, const PuglRect frame)
{
  PuglInternals* const impl = view->impl;

  // Update view frame to exactly the requested frame in Pugl coordinates
  view->frame = frame;

  const NSRect framePx = rectToNsRect(frame);
  const NSRect framePt = nsRectToPoints(view, framePx);
  if (impl->window) {
    // Resize window to fit new content rect
    const NSRect screenPt = rectToScreen(viewScreen(view), framePt);
    const NSRect winFrame = [impl->window frameRectForContentRect:screenPt];

...

The Pugl coordinates mentioned in the code comment above ( used throughout the Pugl APIs and hence DPF ) are already multiplied by the backing scale factor. See how the PuglRect argument values are divided by the scale factor here   const NSRect framePt = nsRectToPoints(view, framePx)  before passing them to AppKit later in puglSetFrame().
https://github.com/lv2/pugl/blob/c98ee490fcf93e290ae5e8a602fd88b359a61a1b/src/mac.m#L57
static NSRect
nsRectToPoints(PuglView* view, const NSRect rect)
{
  const double scaleFactor = [viewScreen(view) backingScaleFactor];

  return NSMakeRect(rect.origin.x / scaleFactor,
                    rect.origin.y / scaleFactor,
                    rect.size.width / scaleFactor,
                    rect.size.height / scaleFactor);
}

By the way this scale factor is read from the view's attached screen which is the correct thing to do instead of reading the main screen scale, as you pointed out
Here is a hacked pugl.mm that serves as proof that on Retina, DPF coordinates != AppKit coordinates:
PuglStatus puglSetWindowSize(PuglView* const view, const uint width, const uint height)
{
    view->defaultWidth  = width;
    view->defaultHeight = height;

#if defined(DISTRHO_OS_HAIKU) || defined(DISTRHO_OS_MAC)
    // keep upstream behaviour
    const PuglRect frame = { view->frame.x, view->frame.y, (double)width, (double)height };
    PuglStatus status = puglSetFrame(view, frame);

    NSWindow *macw = (NSWindow *)puglGetNativeWindow(view);

    printf("Pugl %.f x %.f \n", view->frame.width, view->frame.height);
    printf("OS   %.f x %.f \n", macw.frame.size.width, macw.frame.size.height);

...

Running d_states:
Pugl 512 x 512
OS   256 x 256

My understanding of this is that Pugl/DPF thinks in "raw" pixels instead of the OS/AppKit "virtual" pixels hosts expect (tested on REAPER and Live). This sounds like a bold statement but the host essentially provides a NSView for drawing and these use "virtual" pixels, so why not.
First of all already tried moving this to Window::PrivateData::onPuglConfigure at no avail. However I insist we should not try to fix this anywhere but in the touching points between DPF and the host. Not sure DistrhoUI.cpp is the best place though.
Here is a link to Apple docs with methods that might be cleaner that tinkering manually with the scale factor like initially proposed https://developer.apple.com/documentation/appkit/nswindow/1419603-convertrectfromscreen

First of all already tried moving this to Window::PrivateData::onPuglConfigure at no avail. However I insist we should not try to fix this anywhere but in the touching points between DPF and the host. Not sure DistrhoUI.cpp is the best place though.

I am not sure I understand why on this point...
Let's take the example of VST2, where the plugin/UI is in charge of declaring the size to use in the window.
When the host requests effEditGetRect, DPF is giving the UI width and height.
The plugin is the one that tells the host what size to use, not the other way around.
The UI::onResize is called through the onResize virtual function all the way down from the Widget class.
This is called during a setSize() on the UI/TopLevelWidget.
Without debugging it is not clear what part of the code calls this, but there some calls to it right from the UI constructor.
Seems to me, though I can be wrong of course, that this only works due to DPF calling a setSizeCallback that will feed into the host. But this is slightly wrong, the host window should be correct when it requests effEditGetRect and not need a set-size right after creating the window. It can be a race condition.
Now, thinking more about this your approach seems correct yes.
BUT the host must still be receiving the wrong initial size, and I think it is important to get that right.
So IMO we need to try to make the host window size correct when commenting out uiData->setSizeCallback() (that is, the initial window size), and only then proceed with this patch.

btw, is the behaviour exactly the same for the LV2 version?
I still need to try this...

First of all already tried moving this to Window::PrivateData::onPuglConfigure at no avail. However I insist we should not try to fix this anywhere but in the touching points between DPF and the host. Not sure DistrhoUI.cpp is the best place though.

I am not sure I understand why on this point...
Let's take the example of VST2, where the plugin/UI is in charge of declaring the size to use in the window.
When the host requests effEditGetRect, DPF is giving the UI width and height.
The plugin is the one that tells the host what size to use, not the other way around.

Thanks for the clarification. In the case of VST2 that is exactly where the coordinates mismatch occur. Using this argument I would expect the same for any other format but for LV2 results are different, more on below.

The UI::onResize is called through the onResize virtual function all the way down from the Widget class.
This is called during a setSize() on the UI/TopLevelWidget.
Without debugging it is not clear what part of the code calls this, but there some calls to it right from the UI constructor.
Seems to me, though I can be wrong of course, that this only works due to DPF calling a setSizeCallback that will feed into the host.

This is actually correct. The issue goes away when passing "native" dimensions to setSizeCallback()

But this is slightly wrong, the host window should be correct when it requests effEditGetRect and not need a set-size right after creating the window. It can be a race condition.
Now, thinking more about this your approach seems correct yes.
BUT the host must still be receiving the wrong initial size, and I think it is important to get that right.
So IMO we need to try to make the host window size correct when commenting out uiData->setSizeCallback() (that is, the initial window size), and only then proceed with this patch.

Wouldn't this break resizing the plugin window? note I don't see any direct calls to setSizeCallback() in the UI constructor but only in UI::onResize():

btw, is the behaviour exactly the same for the LV2 version?

I still need to try this...

With latest official Carla-2.3.2-macOS-universal, LV2 plugin content view tightly fits its window but the window itself looks oversized. The patch has no effect for LV2. I'm puzzled, does this make sense to you?
Oversized is subjective but based on how d_states looks relative to the desktop size on Linux I would say there is an issue:

Note VST2 is broken on Carla, plugin keeps resizing itself to exaggerate dimensions back and forth, and closing the plugin window ultimately crashes Carla. But that deserves a separate conversation.

With carla the issue might be 2x double scaling, as carla passes the desktop/ui scaling factor to the plugin UI.
I am trying to setup something here where I can reproduce these issues.
We can focus on getting things to work nicely with standalones first (with and without desktop scaling), and then move to VST2 without the setSizeCallback stuff (to ensure the initial size the plugin gives to the host is correct). We might need to tweak things on the VST2 specific code, that will be fine.

Ok let's do this. just added something to fetch desktop scale factor in 9b9e0a36187a5a2f76add523f1eadfe8bf22dbdc
This can be used in standalones and windows created outside of host control.
I adjusted d_info so that it follows scale factor right from the start, this one is better for use compared to d_states since it has text and it will be easier to verify visually if correct or not.
My setup is using a 4k tv screen at 720p scale (so 4x). I confirmed it working correctly for standalones.
this is the result:

can you confirm latest commit makes d_info work ok for you in standalone mode?

Here running a MacBook Pro Retina, system info says 13,3-inch (2560 × 1600). No external monitor attached.
d_info looks better than before, I recall font was microscopic a couple of commits ago. However the difference compared to Linux is noticeable:

I guess the expected result is the one on Linux, around 1/3 of the screen height. On Mac it looks closer to 3/4. This makes me think whether there is an issue for standalones to start. Which is the expected result in your opinion?

There is no implementation to get scale factor on linux, so it will always be 1 for now. (in standalones)
On your screenshot the linux one looks correct, font size is similar to desktop font size.
For reference, this is the expected size on a 1080p screen:

and just the window: (size 445x296)

Curiously the size on linux doesnt match the size set by the plugin UI (which is 405x256)
The macOS one does indeed look too big.
I think I was wrongly assuming it was correct. But it is weird, because when manually setting scale to 4x in the code I got the same results as in my screenshot... still ends up looking 2x too big.
Doing some quick calculations 4x plugin UI size is 1620x1024 - I calculate about 1616x1022px on the screenshot.
So even though it looks quite big in my case, it is still correct.
Do you have your desktop set as "alike" 720p or 1080p?
The size of the topbar in your screenshot is the same as mine, so I assume you did 720p to mimic my results?
If that is the case, then it looks to be correct.

ah I see what is wrong with the screenshot of the linux UI, kwin likes to add fancy shadows. they must be around 25px in each side.
so we can assume the linux UI size is correct

an extra note: something is wrong with the way d_info scales up with the factor >1, but that is a separate issue.
something like double infoScaleFactor = 1.0 + (scaleFactor - 1.0) / 2; likely will make the size fit better with >1 factors.
I am going to check with carla + lv2 next, since I have control over both sides for that.
Then carla + vst2, and finally other hosts.
When the macOS side works 100%, the rest should be pretty easy.
Except a nice way to find scale factor under x11... ay ay

Just realized this Mac display was slightly scaled up, however setting the default does not make a lot of difference. Though that might explain why top bars were the same size...

I am quite sure there are lots of places where to check, please let me know how can I help here. I think this requires some more knowledge of the internals for all the parts involved, my reasoning has been more intuitive so far. But I am happy to test / write experimental code / etc to get this fixed.
This and https://github.com/lv2/pugl/pull/57 are kind of stoppers on Mac . Just saw there is some very recent progress in that PR !
Besides these everything runs sweet on macOS.
For X11 is it too naive to have a function that gathers as much scaling "sources" as possibly and picks one based on some heuristics? or maybe decide based on a compile time setting. I found GDK_DPI_SCALE to be effective...in my particular setup, lol.

For X11 is it too naive to have a function that gathers as much scaling "sources" as possibly and picks one based on some heuristics? or maybe decide based on a compile time setting. I found GDK_DPI_SCALE to be effective...in my particular setup, lol.

Yeah, I think this is something you can help a lot.
We can try to fetch info from as many sources as possible. We should even read the Qt test env vars IMO.
The scale factor on this case is only relevant for standalones, but with the work on RtAudio they might become quite nice soon.
On the macOS side, yeah I am following that issue closely myself. It is a tricky one..
Worst case we keep a patch against pugl while drobilla hasnt merged anything officially.
tbh I still consider current/develop DPF to be "not quite ready yet", but it is very close. Getting these final issues out of the way is crucial.
btw, I found out what was wrong with d_info.. I totally forgot I already handle all the needed scaling behind the scenes in DPF when UIs setup geometry constraints.
so the new code was scaling things 2x on top of the desktop 2x scaling.
It now looks correct on my macOS setup:

please give it a try, let me know if it looks proper for you too. (standalone)

oh I added a scale factor print on the gui as well, very handy

This looks perfect now, and reported scale factor is correct (2.0). Very promising!

I have been in almost daily contact with plugins produced out from the develop branch for several weeks now and it might not be ready for production but feels very close. Cannot recall any other serious issues, I wrote down two for Windows but those are not stoppers at all (will comment later on that).
For X11 yes I recall Qt relies on its own env vars. I came across a couple of different env vars while trying to get things to look right on a 13" 1080p display ( what a challenge ). I learnt there is no standardized approach for scaling. Will start compiling a list.

Alright, standalone and VST2 should be working well now.
I went with my idea of scaling the size before passing it to the host. Tested to work on REAPER, Renoise and Carla bridges.
Carla itself still has problems, but I think I know why.
Also, REAPER had flickering resize (UI would go on top of the UI buttons sometimes), this is fixed too.
LV2 is a harder one to tackle, REAPER does not support the extension-less approach that I am pushing with DPF.
I want to get all working within Carla first before bothering REAPER devs. (not just resize but min-size and aspect ratio from host side)

The resize issue on main Carla is solved now (Carla-side issue, nothing to do in DPF)

This is huge, thanks! also noticed that tiny bug on REAPER that made the UI display on top of the buttons, here it happened when resizing a certain plugin to the max. Minor but glad it is gone.
I tried four examples and all the size issues on Mac are gone. Excepto for d_cairoui, maybe Cairo needs special treatment?

The cairo side should be fixed now too, it was a good test as it showed a few other bugs, all fixed now.

Closing this ticket since the issues on macOS are resolved now.
For LV2 we can tackle / discuss on another place.
Still need to do some testing for Windows, we need a way to ask for global/screen/desktop scaling for standalones.

Just tested; it looks great now. I have some code for Linux and Windows, will improve the former to include some more "sources" like Qt and then open a new issue. Thanks.


Upgrade kombu

Celery wants a newer kombu

Ready for review.

Since all the tests passed, :+1:, I can't think of anything else that would be effected by this.

:+1:
Let's deploy in the morning though.


Start Reset

Azure documentation issue guidance
Thanks for opening an issue in the Azure technical documentation repository.
We use GitHub issues as the primary channel for customer and community feedback about the Azure documentation.
Creating an issue
We prefer that you create documentation feedback issues using the Feedback link on the published article - the feedback control on the doc page creates an issue that contains all the article details so you can focus on the feedback part.
You can also create a feedback issue here in the repo. If you do this, please make sure your issue lists:

[ ] The relevant Azure service or technology.
[ ] A link to the published documentation article that you have feedback about.
[ ] Clear, specific feedback that the author can act on.

Pull requests and article contributions
If you know the change that is needed in an article, we encourage you to submit the changes directly using a pull request. If the change is large, or if you want to contribute an entire article, follow these guidelines:

[ ] Don't surprise us with a big pull request or a pull request with a new article! Submit an issue that describes the details of the proposed large change or new article.
[ ] Include the service or technology area.

We'll route the issue to the appropriate content team for review and discussion.
Tech support and product feedback
If you would like to contact Microsoft about other things, such as product feedback or tech support, please review these guidelines:

If you need technical support using Azure, the paid and free support options are described here: https://azure.microsoft.com/support/options/.

Each article in the Azure technical documentation contains a product feedback button - it's best to submit product feedback directly from a relevant article. Otherwise, you can submit product feedback for most Azure products in the following product feedback forum: https://feedback.azure.com/forums/34192--general-feedback.

God bless you my Angels

@YoRobotCop Can you please share your issue and documentation link you are referring to ?

@YoRobotCop We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


Quit command mode when pressing backspace in an empty command bar

Is your feature request related to a problem? Please describe.

Press :, press <backspace>. The colon should then disappear and vit return to normal mode.
This is how (neo)vim behaves.
Describe the solution you'd like

Add a conditional statement.
Additional context

None.

In mutt the default is to not have this special behavior. in NeoMutt the default is to have it, and they provide an option:
abort_backspace
       Type: boolean
       Default: yes

       If set, hitting backspace against an empty prompt aborts the prompt.

I don't have a preference on the behavior. I'm just adding the above as more info on what other TUI apps do.

Personally I'd prefer if that was implemented as an option, since I wouldn't want that behavior.
With that behavior the user can accidentally leave EX mode when erasing to fix a command if they type one extra backspace.
Leaving EX mode with the Escape key instead seems much more robust to me, as it won't be pressed by mistake and can be pressed at any point in the command.

If somebody wants to make a PR for it, I'd consider adding it as a configurable option, as long as it doesn't make the code messy.


Preparation for RelationImpl. changes / Fix handling of combinations of relation types

Proposed Changes

Refactor handling of binary relation operations (like join, union)
Fix missing handling of combination of different Relation subtypes for those bin. operations
Test for those combinations.

@srfc what do you think of the codacy integration's review-bot? Should I keep it turned on?

@srfc Does this make sense for you?


V3.2.2 using Bootstrap 5 alpha release components which are yet to stabilize

I noticed that the js files of the latest release (v3.2.2) are using Bootstrap 5 alpha! If this is the case then this is a major inconsistency especially for those of us using coreui in production because personally I am not ready to upgrade to Bootstrap 5 until it is stable. What's worse is that this change is in a minor release. I think if you intend to move to bootstrap 5 components, since that is a huge undertaking, it should be implemented in a new major release (v4.x).

Bootstrap-based components without jQuery are available since the last year and we use them as the base of our own components since CoreUI 3.0.0 is available. If you compare our releases you will see that probably the number of Bootstrap was changed from v4.x.x to v5 and there are no significant changes in code.
As I mentioned before CoreUI based on Bootstrap and our library is 100% compatible with the latest stable version of Bootstrap, but Bootstrap development is really slow and we can wait for them, so we made a lot of improvements in their SCSS and JS files, for example, our components use Popper.js 2 when Boostrap still use Popper.js 1, we consider to move to TypeScript in CoreUI 4 while Bootstrap 5 use JavaScript.
To sum up, we use modified components from version 5 but, everything was checked by our developers, we made significant improvements, and everything is stable and production-ready.

@mrholek Is there a specific reason you didn't bump the major version to v4 when changing such a substantial dependency? I agree with @coolsam726, it's really unexpected so see such a change in a patch release.
Won't this break apps that upgrade to CoreUI 3.x and are using Bootstrap v4 specific features that were removed in Bootstrap v5?

@manuelmeurer as I said before, we didn't change anything, we use Bootstrap based components without jQuery since CoreUI 3 was released.

Ok, maybe I misunderstood... when exactly did CoreUI start using components from Bootstrap v5 alpha instead of Bootstrap v4? Was ist from CoreUI v3 on?
Just to clarify, I'm not trying to criticize, I think CoreUI is great and I appreciate all the work that you put into it! 🙇

Yes, it was from CoreUI v3 on, but please note that we made some changes, improvements, and tested everything during the alpha and beta phase. Please note that in future releases of version 3 you will see some features which will be available in Bootstrap 5 ex. grid with XXL breakpoint. We're a professional team focused only on CoreUI, that's why we have more components, styles, and we're ahead of Bootstrap and have more components.


Macbook Pro 9,1 - Error when running bat

After running the .bat file in Admin mode this the error i get on Windows 10 64bit
C:\Users\El Capitan\Desktop\gpu-switch-windows\gpu-switch>gpu-switch.exe -i
Switching: to integrated GPU
Switching: Error
Error code was: 1
Error message was: Incorrect function.
C:\Users\El Capitan\Desktop\gpu-switch-windows\gpu-switch>pause
Press any key to continue . . .

I think your Windows is not booted in UEFI mode.
See here: https://github.com/0xbb/gpu-switch/issues/8#issuecomment-127398240


bufr-to-bufr pipeline does not match on tsi

As reported by Iran, they have registered station wsi=0-364-0-40755 with tsi=40755 in their wis2box station metadata

But when they ingest data for this station it fails:

This is due to the get_valid_station-function in station.py ignoring the input tsi:
https://github.com/wmo-im/wis2box/blob/main/wis2box-management/wis2box/metadata/station.py#L356-L372
@efucile I'm trying to understand if we implemented this on purpose, to force users to encode correct wsi in their input-bufr ?
On the other hand the bufr-to-bufr pipeline is recreating the wis2box with the wsi provided from the station-metadata, so there is no reason to fail to bufr-ingestion for this.

The same issue was reported by Barbados, it seems to be a common case, so I prepare a fix to allow the bufr-to-bufr pipeline to match on tsi and encode the wigos-station-identifier provided by the station metadata.


Set tid as optional in the User model

This PR sets tid as optional in the User model as per #87.
closes #87

I've done some additional research, and I'm thinking that it might make sense to set the default for validate_iss to False in B2CMultiTenantAuthorizationCodeBearer and make it general, or to add another B2C class, as this is the only thing that I've found not working with my basic setup.

I've done some additional research, and I'm thinking that it might make sense to set the default for validate_iss to False in B2CMultiTenantAuthorizationCodeBearer and rename it to B2CAuthorizationCodeBearer, or to leave it as it is and add another B2C class, as this is the only thing that I've found not working with my basic setup.

We would have to create another one for B2CSingleTenantAuthorizationCodeBearer, yeah. In multi-tenant setups, you always want to have the ability to restrict to issuers.


The source  code of FCOS

Can you share the source code on the FCOS? Thanks a  lot .

You can refer to this issue to build your distillation framework based on your detection code. For the loss function, please refer to the branch cvpr19.
https://github.com/irfanICMLL/structure_knowledge_distillation/issues/27


Protractor E2E Tests Hang

I'm submitting a ...  (check one with "x")
[x ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/HackedByChinese/ng2-idle/blob/master/CONTRIBUTING.md#getting-help

Current behavior

After adding idle.watch() my E2E tests in protractor hang.
Expected behavior

E2E tests should run successfully and just as fast as before introducing idle.
Minimal reproduction of the problem with instructions

https://github.com/wesley-trantham/idle-protractor-example
What is the motivation / use case for changing the behavior?

I want my E2E tests to run against the exact copy of production code. While my first thought is to turn idle off for my autoe2e* users, that defeats the purpose of testing the same code that my users will see.
Please tell us about your environment:

Windows 7, VSCode, NPM, Angular CLI, Protractor

@ng-idle version: 2.x

2.0.0-beta.12

Angular version: 2.x

4.4.6

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Chrome

Language: [all | TypeScript X.X | ES6/7 | ES5]
Typescript
Node: node --version = 8.9.1

I've written what will fix the initial issue of E2E tests not running. https://github.com/wesley-trantham/ng2-idle/tree/bug/e2e-support-protractor-waitforangular
I will admit this isn't the full expected fix. My E2E tests have doubled in run time, which is better than hanging, but still undesirable.
I've tracked that down to being caused by every interrupt restarting the watch. The fix for that, I imagine, would be to refactor the watch to run the full duration, then check to see when the last interrupt was called. If an interrupt was not called, time out, otherwise add the idle time to the last interrupt time and setInterval to fire again at that point.
I'm slowly working on attempting to make that work, but that is a larger change and I'm half afraid of the breaking changes it could introduce. I'd like some feedback to make sure I'm on the right track.

I should also admit that I'm not entirely sure how to write unit tests for this, as really the existing ones should still work. Adding an E2E suite sounds like a good idea, I'm trying to think of the best way to go about doing so.

Rework of setInterval is in this branch https://github.com/wesley-trantham/ng2-idle/tree/bug/e2e-protractor-speed.

It turns out that simply listening to keydown slows down protractor, I'm not able to figure out why, yet, at least. I will be making a PR for https://github.com/wesley-trantham/ng2-idle/tree/bug/e2e-support-protractor-waitforangular soon.

Fixed by #74


Concurrent Test Grain Factory

The TestGrainFactory can be invoked outside the Orleans thread-safety guarantees in a parallel fashion by code that is invoking via IClusterClient and should offer functionality for concurrency guarantees.
I received an error in some new code in our codebase that we had to re-shape business logic to satisfy the unit test error

To be clear... the entire TestKit operates without Orleans concurrency guarantees. From the README:

The simulated grain activation context does not provide the single-threaded execution model of the Microsoft Orleans runtime. It is up to you to ensure the grain activation is used appropriately. Unfortunately, this may result in abnormal method execution or behaviors that are impossible to reproduce, especially in reentrant grains.

From the PR description and based on the new test added, it sounds like the SUT is not a grain activation, but instead some other service depending on IClusterClient. This is outside the scope of the TestKit. Instead the service should make use of its own test double/fake/mock that does not rely on a TestKit-created grain activation.
Please let me know if I'm misunderstanding something, but this looks undesirable for the TestKit.


Make session storage injectable

These changes will make the session storage object injectable into the LinkedIn class. This will allow developers to write custom implementations of the DataStorageInterface interface and use them with this library without having to modify any source code. This will allow developers to bring this package into their project (and keep it updated) via composer while implementing the concrete session storage logic inside of their own project.
The code explicitly enforces the passed in $storage variable to be of type DataStorageInterface, so the rest of the package can safely remain oblivious of the concrete implementation and keep using it through the interface.

Thank you for this PR. It has been lot more issues with this data storage then I could expect. I see that your solution really takes care of the problem. I'll be happy to merge it but there are some minor issues.
See the following code comments.

Thank you for taking a look at my PR. I just addressed all of your comments.

Oops, looks like I broke the build :crying_cat_face: I'm taking a look at it now.

I think it looks very good. I was one minor issue with the test. Please fix it and squash your commits and I'll be happy to merge

This will be a BC break for the users relying on the IlluminateStorage.
Ping @andreascreten. Can we get your 50 cents on this PR.
You will have to update your code like:
$ln = new LinkedIn(self::APP_ID, self::APP_SECRET, new IlluminateSessionStorage());

Or extend the LinkedIn class and make changes in the init function.

This is a BC break. You can modify it so IlluminateSessionStorage is still the default when nothing is injected through the constructor.
There is actually no reason to add an optional parameter to the constructor for constructor injection when there already is Happyr\LinkedIn\LinkedIn::setStorage(DataStorageInterface $store) available.
Otherwise you'll start adding additional optional arguments for the request and urlGenerator as well. This might start bloating the constructor and make it more complex for new users.

@Nyholm, @hannesvdvreken is currently working on the project which uses this class, so he takes over from me :smile:

Thank you @andreascreten
Yes @hannesvdvreken It is a BC break. I can agree with you about the constructor argument. The problem with the current implementation is that people is installing the library without using the Facades correctly (see #22, #21, some of #20 and maybe #35).
Suggestion: Instead of creating the SessionStorage in LinkedIn::init maybe we should rewrite the LinkedIn::getStorage to something like:
public function getStorage()
{
    if ($this->storage == null) {
        $this->storage = new SessionStorage();
    }
    return $this->storage;
}

If you want to use the IlluminateSessionStorage you have to:
$ln = new LinkedIn(self::APP_ID, self::APP_SECRET);
$ln->setStorage(new IlluminateSessionStorage());

@Nyholm the problem is
if (class_exists(''...)) {
   ...
}

To detect being installed in a Laravel environment. You can't remove that because that will break backwards compatibity, but ideally one would keep the class as simple as possible and not allow framework specific code in there. Ideally one would create a ServiceProvider where a LinkedIn object is created an then injected with a IlluminateSessionStorage object before it is returned by the application container.
There is no way back now.

You can't remove that because that will break backwards compatibility

It will break BC, yes. But you are allowed to break backwards compatibility if (and only if)

You bump the major version.
If the library has not reached its first stable version yet.

So, yes. I can remove it.

Ideally one would create a ServiceProvider where a LinkedIn object is created an then injected with a IlluminateSessionStorage object.

Yes, exactly. See how I've done it with Symfony

:+1: version 0.5.0 it is then!

@SmellyFish Can you make the changes according to the latest comments?

@Nyholm you're right. I didn't realize that assertEquals() was quite so loose. I moved the default session storage logic from init() to getStorage() like you had suggested. I opted for using the stricter assert same assertions in the constructor tests and looking at the object attributes directly instead of using the accessor. I also added a couple of tests for getStorage() to vet the new logic. Let me know if I missed anything. Once you're happy with the changes, I'll squash my commits into one.

Thank you @SmellyFish  for working on this. As @hannesvdvreken pointed out we should not bloat our constructor. So lets remove DataStorageInterface from the constructor completely.

No problem. Will update the code like you asked.

Would it make sense to get rid of the init() method? Seems like its logic could just be moved into the constructor.

The purpose of the LinkedIn::init was to make it easier to extend the LinkedIn class and override the that function in order to use another URLGenerator och Request.
If you want to, you might remove it completely and instantiate the objects in their respectively get-method. Just like you did with the DataStorage.

@Nyholm It looks like the library hasn't been patched to comply with the upcoming LinkedIn API update. I'll have to add more modifications to the code in the next week or two. I'm going to close this PR for now and re-open a new one once I've made all of the necessary updates.

Okey, sure. It is highly appreciated. I will merge #39 now, make sure to pull those changes.


Can't change password with ISPConfig

RainLoop version, browser, OS:
Rainloop: latest, 1.13.0
Browser: Firefox 70.0.1 (64 bits)
OS: Windows 10
Expected behavior and actual behavior:
Rainloop connected with db and try change password, but action ent with error.
Steps to reproduce the problem:
Stack on server:
nginx 1.16.1 from nginx repo
php 7.3.12-1+0~20191128.49+debian9~1.gbp24559b from sury repo
Mysql: mysql  Ver 14.14 Distrib 5.7.28-31, for debian-linux-gnu (x86_64) using  7.0 (Percona)
ISPConfig: latest, 3.1.15p2
Logs or screenshots:
[09:40:51.261][1b997b09] AJAX[NOTE]: Action: DoChangePassword
[09:40:51.261][1b997b09] POST[DATA]: {"PrevPassword":"","NewPassword":"","Action":"ChangePassword","XToken":"c3602cad2c9f345a374cb2d8da2e8a51"}
[09:40:51.263][1b997b09] INFO[DATA]: ISP: Try to change password for<EMAIL_ADDRESS>--- FlushLogCache: Trigger
[09:40:52.264][1b997b09] INFO[NOTICE]: Error: Can't change password for<EMAIL_ADDRESS>account.
[09:40:52.265][1b997b09] INFO[NOTICE]: RainLoop\Exceptions\ClientException: CouldNotSaveNewPassword[130] in /var/www/clients/client2/web3/web/rainloop/v/1.13.0/app/libraries/RainLoop/Providers/ChangePassword.php:79
Stack trace:
#0 /var/www/clients/client2/web3/web/rainloop/v/1.13.0/app/libraries/RainLoop/Actions.php(5069): RainLoop\Providers\ChangePassword->ChangePassword(Object(RainLoop\Model\Account), '', '')
#1 /var/www/clients/client2/web3/web/rainloop/v/1.13.0/app/libraries/RainLoop/ServiceActions.php(172): RainLoop\Actions->DoChangePassword()
#2 /var/www/clients/client2/web3/web/rainloop/v/1.13.0/app/libraries/RainLoop/Service.php(152): RainLoop\ServiceActions->ServiceAjax('')
#3 /var/www/clients/client2/web3/web/rainloop/v/1.13.0/app/libraries/RainLoop/Service.php(62): RainLoop\Service->localHandle()
#4 /var/www/clients/client2/web3/web/rainloop/v/1.13.0/app/libraries/RainLoop/Service.php(85): RainLoop\Service->__construct()
#5 /var/www/clients/client2/web3/web/rainloop/v/1.13.0/app/handle.php(94): RainLoop\Service::Handle()
#6 /var/www/clients/client2/web3/web/rainloop/v/1.13.0/include.php(228): include('/var/www/client...')
#7 /var/www/clients/client2/web3/web/index.php(13): include('/var/www/client...')
#8 {main}
[09:40:52.265][1b997b09] AJAX[DATA]: {"Action":"ChangePassword","Result":false,"ErrorCode":130,"ErrorMessage":"","ErrorMessageAdditional":"","Time":1017}
[09:40:52.266][1b997b09] INFO[MEMORY]: Memory peak usage: 2MB
[09:40:52.267][1b997b09] INFO[TIME]: Time delta: 1.0182549953461

Just a fair warning. If your running a multi server enviroment the change password plugin is a waste of your time. It replaces the password on the main server DB and does not use the API so it changes on all servers.

It's not a problem with multiserver - this server isn't in multiserver ecosystem.

Did you ever get this working? I'm getting this same error, latest rainloop, latest stable ISPConfig on a debian 10 server. For crying out loud, a user can't even change his/her password. Is this really so hard to code? Use perl for all I care and borrow it from the squirrelmail plugins that already did this with a php frontend.


[mesheryctl] improve mesheryctl registry update

Notes for Reviewers

This PR fixes #13016

Signed commits

[x] Yes, I signed my commits.

Hey maintainers, i think this should fix the issue

your branch needs to be resynch with master

@devhindo Please check if this was the intended fix. I used the GetString method to get the corresponding argument value of spreadsheet-id and spreadsheet-cred. In case of err, the function returns an empty string. I've checked for empty string condition in the if block and returned cmd.Help()

Hey @lekaf974, I initially just tried wrapping the error around as such but that cause segmentation fault as we are trying to called the Error() method on the returned error inside ErrUpdateRegistry. After reading the source code of cmd.Help(), i came up with the changes made by above commit.
source:
https://github.com/spf13/cobra/blob/e94f6d0dd9a5e5738dca6bce03c4b1207ffbc0ec/command.go#L475


[Feature Request]: Date Font

Is your feature request related to a problem? Please describe.
No
Describe the solution you'd like
Would it/is it possible to edit the font used for the date (and/or time for completeness)? I'd like to show the date under the time in a much smaller font if possible?

This could be solved with the proposed solution described in another feature request:
https://github.com/maykar/compact-custom-header/issues/128#issuecomment-518737841
Will update you when something like this is implemented.

This has been added in the latest pre-release 1.3.6
Example and more info here: https://community.home-assistant.io/t/compact-custom-header/83716/1109

It is still not possible to have separate sizes/fonts for date and time. I'm not sure if this is something I'd add, but I am thinking on expanded features of time and date.

Yes. please. I try to set the font-size for:
# Custom Header settings
cch:
  chevrons: true
  clock_date: true
  clock_format: '24'
  options: clock
  button_css:
    options: 'font-size: 9pt;font-weight:300'
  swipe: true
  swipe_wrap: false
  default_tab: 0
  notifications: show
  swipe_prevent_default: true
  exceptions:
    - conditions:
        user: peter.siebler
      config:
        menu: hide
        options: hide
        sidebar_closed: true
        voice: clock

But without success. The font size does not change. Change of font works.

It appears that when using a date that font size is overwritten. Going to open this one back up and possibly add date_css and time_css to config options.

@maykar
I tried, but no change. Am I doing something wrong ?
# Custom Header settings
cch:
  chevrons: true
  clock_date: true
  clock_format: '24'
  options: clock
  swipe: true
  swipe_wrap: false
  default_tab: 0
  notifications: show
  swipe_prevent_default: true
  button_css:
    options: 'font-size: 9pt;font-weight:300'
  date_css:
    options: 'font-size: 9pt;font-weight:300'
  time_css:
    options: 'font-size: 9pt;font-weight:300'
  exceptions:
    - conditions:
        user: peter.siebler
      config:
        menu: hide
        options: hide
        sidebar_closed: true
        voice: clock

Those options don't exist yet. I was proposing them as a feature to be added.

👍  Thanks

Added in the latest release. More info:
https://community.home-assistant.io/t/compact-custom-header/83716/1179


Support rendering in single page mode

Describe the feature
Add support for dynamic output with addSinglePageRoot to provide similar functionality that is available with ctx.render. It could even simply accept a handler which could do whatever it wants instead of a root and file (although at that point it might just be a new function addSinglePageHandler).
Additional context
I have a single page app and would like to direct all acceptsHtml requests to a single HTML template. The index.html template is mostly static but it has some config from the server rendered in as a script tag.
My workaround is a wildcard StaticFileHandler defined after the other routes. I am afraid of doing this long term because it must be last or it will take precedence. Here is my code simplified for brevity.
if (ContextUtil.acceptsHtml(ctx)) {
    // This code block is basically what I want to pass into addSinglePageHandler
    renderIndexHtml(ctx)
} else {
    // I should not have to do this, addSinglePageHandler would check acceptsHtml automatically
    val jettyResourceHandler = JettyResourceHandler(setOf(StaticFileConfig("/public")), JettyServerUtil.defaultServer(), true)
    if (!jettyResourceHandler.handle(ctx.req, ctx.res)) {
        ctx.status(404)
    }
}

Thanks @pgross41, this sounds like a reasonable use case. Would you like to submit a PR?

Yeah I think that is doable, I will give it a shot myself and submit a PR. Thanks for the quick response!

Submitted PR https://github.com/tipsy/javalin/pull/814

Thanks, will have a look tonight :)


Chore/BPDM added BPDM to umbrela chart

Description

This PR adds BPDM chart to the umbrella repository. Due to incompatible Portal version, I had to bump portal chart to 2.0.0. As mentioned in this issue, https://github.com/eclipse-tractusx/portal/issues/248, in version 1.8.1 of Portal, it calls this enpoint /companies/test-company/v6/ of the gate, which is incompatible with the added gate.
This BPDM is prepared to work with centralidp, but as it is planned for future release https://github.com/eclipse-tractusx/sig-release/issues/751, currently it will return 403 error in BPN step.

Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review:

[x] DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
[x] Copyright and license header are present on all affected files

@evegufy

@gomezbc the review is currently blocked by the merged of https://github.com/eclipse-tractusx/tractus-x-umbrella/pull/107, after it has been merged it would be great if you could rebase to the upgrade/24.05 branch

@gomezbc the review is currently blocked by the merged of #107, after it has been merged it would be great if you could rebase to the upgrade/24.05 branch

@gomezbc the pr #107 has been merged now, could you please rebase? then the helm test workflow should pass the check for chart version bump

@evegufy Done 👍🏼

@evegufy I have resolved the linting issues. I noticed that other components disable PostgreSQL persistence by default, so I have done the same for the BPDM database.

Hi @gomezbc sorry for the delay, I finally came around to reviewing again. When install I'm facing 401 errors for pool, gate and dummy: logs-from-bpdm-pool-in-umbrella-bpdm-pool-f5bb96f6d-d8xtn.log logs-from-bpdm-cleaning-service-dummy-in-umbrella-bpdm-cleaning-service-dummy-678cc46bb9-hps8t.log logs-from-bpdm-gate-in-umbrella-bpdm-gate-6d6cc7fdff-8mnkp.log
This might be due to missing the bdpm config discussed here eclipse-tractusx/portal-backend#819 (comment)
@nicoprow has opened #108 which might contains the config.

@gomezbc:
As @evegufy already said, you can use the newest hotfix version for BPDM 5.0.3 with the configuration provided in #108. The files also contain README instructions and a workflow to test the BPDM chart dependency setup.
The new version has the advantage that the postgres does not need to have a fullnameOverride anymore.
The ingress can be changed for BPDM but I experienced compatibility problems with the Portal. At least for the Partner Network page, I discovered that that Portal version has outdated endpoint URLs when trying to access the Pool. I don't see a way to fix that except upgrading the Portal so the correct endpoint paths are used.
I did not try the registration workflow with the Portal, so I don't know which path to the BPDM Gate the Portal expects there.

Hi @nicoprow, thanks for the comments. I have review your configuration and is awesome. As you have a better understanding of BPDM, I think the best approach would be to use your configuration.
Regarding the compatibility with the portal, in my local setup, I had to upgrade to version 2.0.0 to make it compatible with BPDM. Using that version, the registration process works correctly.
As I discussed with @evegufy (https://github.com/eclipse-tractusx/tractus-x-umbrella/pull/106#discussion_r1669237002), I will provide an upgrade to the portal, centralidp, and sharedidp. I will try to provide it as soon as I can.

Hi @nicoprow
After creating the PR for the portal version update https://github.com/eclipse-tractusx/tractus-x-umbrella/pull/110, I switched my configuration to yours to connect the portal with BPDM. However, I encountered some permission issues. Upon comparing the roles required by BPDM with those defined in CentralIdp, I resolved these issues.
The roles you defined for the Gate, Pool, and Orchestrator do not match those used by the CentralIdp sa-cl7-cx-5 client.
For example, here are the roles you set for Gate (Cl16-CX-BPDMGate):
permissions:
  readInputPartner: view_company_data
  writeInputPartner: update_company_data
  readOutputPartner: view_shared_data
  readInputChangelog: view_company_data
  readOutputChangelog: view_shared_data
  readSharingState: view_company_data
  writeSharingState: update_company_data
  read_stats: view_company_data

And here are the roles provided by CentralIdp:

To fix the Gate and Pool permissions, I deleted those settings, as the default configuration matches Cl16-CX-BPDMGate and Cl17-CX-BPDM.
For the Orchestrator, I modified the values you set in permissions to these:
permissions:
  createTask: "write_partner"
  readTask: "write_partner"
  reservation:
    clean: "write_partner"
    cleanAndSync: "write_partner"
    poolSync: "write_partner"
  result:
    clean: "write_partner"
    cleanAndSync: "write_partner"
    poolSync: "write_partner"

[!warning]
I have successfully completed the BPN creation process from the portal using the updated portal version here. It will not be possible to complete the BPN creation process with the portal version defined in this PR.

Hi @gomezbc sorry for the delay, I finally came around to reviewing again. When install I'm facing 401 errors for pool, gate and dummy: logs-from-bpdm-pool-in-umbrella-bpdm-pool-f5bb96f6d-d8xtn.log logs-from-bpdm-cleaning-service-dummy-in-umbrella-bpdm-cleaning-service-dummy-678cc46bb9-hps8t.log logs-from-bpdm-gate-in-umbrella-bpdm-gate-6d6cc7fdff-8mnkp.log
This might be due to missing the bdpm config discussed here eclipse-tractusx/portal-backend#819 (comment)
@nicoprow has opened #108 which might contains the config.

@gomezbc:
As @evegufy already said, you can use the newest hotfix version for BPDM 5.0.3 with the configuration provided in #108. The files also contain README instructions and a workflow to test the BPDM chart dependency setup.
The new version has the advantage that the postgres does not need to have a fullnameOverride anymore.
The ingress can be changed for BPDM but I experienced compatibility problems with the Portal. At least for the Partner Network page, I discovered that that Portal version has outdated endpoint URLs when trying to access the Pool. I don't see a way to fix that except upgrading the Portal so the correct endpoint paths are used.
I did not try the registration workflow with the Portal, so I don't know which path to the BPDM Gate the Portal expects there.

Just quickly clarifying on what you mentioned regarding outdated endpoints in the portal: I assume you tested with the version of the portal which is currently still in the main branch of the umbrella repo, which is the portal version 1.8.0 for the release 24.03, that one is expected to be not compatible with the BPDM version for 24.05, the portal version for the 24.05 release is the 2.0.0.
Overview of compatible version for the for R24.05 https://eclipse-tractusx.github.io/CHANGELOG#2405---2024-05-29

Hi @nicoprow
After creating the PR for the portal version update #110, I switched my configuration to yours to connect the portal with BPDM. However, I encountered some permission issues. Upon comparing the roles required by BPDM with those defined in CentralIdp, I resolved these issues.
The roles you defined for the Gate, Pool, and Orchestrator do not match those used by the CentralIdp sa-cl7-cx-5 client.
For example, here are the roles you set for Gate (Cl16-CX-BPDMGate):
permissions:
  readInputPartner: view_company_data
  writeInputPartner: update_company_data
  readOutputPartner: view_shared_data
  readInputChangelog: view_company_data
  readOutputChangelog: view_shared_data
  readSharingState: view_company_data
  writeSharingState: update_company_data
  read_stats: view_company_data

And here are the roles provided by CentralIdp:

To fix the Gate and Pool permissions, I deleted those settings, as the default configuration matches Cl16-CX-BPDMGate and Cl17-CX-BPDM.
For the Orchestrator, I modified the values you set in permissions to these:
permissions:
  createTask: "write_partner"
  readTask: "write_partner"
  reservation:
    clean: "write_partner"
    cleanAndSync: "write_partner"
    poolSync: "write_partner"
  result:
    clean: "write_partner"
    cleanAndSync: "write_partner"
    poolSync: "write_partner"

Warning
I have successfully completed the BPN creation process from the portal using the updated portal version here. It will not be possible to complete the BPN creation process with the portal version defined in this PR.

Yea, your permission configuration is exactly right to do for the Central-IDP 24.05 release. Great that you made it work!
If you want you can remove the base-URL overwrite for the BPDM clients as they are able to find each other by service name. I don't think is necessary to change it but I thought I should mention it (see the comment below)

@evegufy will check out the chart testing

Hi @gomezbc https://github.com/eclipse-tractusx/tractus-x-umbrella/pull/113 has been merged, could you please add bpdm to the the 1rst test file?

Hi @gomezbc #113 has been merged, could you please add bpdm to the the 1rst test file?

Done! 😀

Hi @gomezbc #113 has been merged, could you please add bpdm to the the 1rst test file?

Done! 😀

Awesome :)


Simulation files need to be reviewed prior to moving to the NSEC GEE server

@elinz copied a new build of the Message Simulator exe to the NSECGEE server (i.e. C:\MessageSimulator\MessageSimulator). He also created the OS Scheduled task and left it in a disabled state. He didn’t copy over any of the message files from the last Ops Server release, because he wanted someone to review all the files before we deploy message files to the new geography GEE server (NSECGEE), but everything else for the Message Simulator is now on the server.

@pHill5136 - added to backlog: https://app.asana.com/0/22926133759983/31304190918338

@pHill5136 - has the been any movement on this issue?

@pHill5136 My impression is that this issue is resolved.

:+1: Agreed.

@ScottCecilio  reviewed the land ops sim files for friendly equipment and hostile equipment over monterey airport area.


Convert from guava Optional to java.util.Optional [phab:D1508]

Created by salguarnieri at 2017-04-11 18:41:32:

salguarnieri wrote at 2017-04-11 18:43:56:

EntrySet.Builder expansion

jrtom commented inline (context lost during migration) at 2017-04-11 18:56:48:
You don't need this; just restore the comment below to refer to EntrySet.Builder.

jrtom accepted this revision at 2017-04-11 18:56:48

salguarnieri wrote at 2017-04-11 19:43:07:

java.util.Optional import

salguarnieri wrote at 2017-04-11 19:43:38:

cleanup Builder usage

salguarnieri commented inline (context lost during migration) at 2017-04-11 19:44:03:
Ack

salguarnieri closed via commit 32a3d5b90ffcfd083b608ca30926f902ea959343 at 2017-04-11 19:45:34


[iOS] [RCTTextViewManager uiManagerWillPerformMounting:] crash

Description
We are facing a crash in RCTTextViewManager uiManagerWillPerformMounting in our iOS application. The crash happens across application without any specific steps to reproduce. I am assuming this has to do with releasing an already released object. If this is the case then is there any way we can prevent this? This has become our top crash.
Crash Exception:
Crashed: com.facebook.react.ShadowQueue
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x000000000000000c

Crash Logs:
Crashed: com.facebook.react.ShadowQueue
0  libobjc.A.dylib                0x101a8 AutoreleasePoolPage::AutoreleasePoolPage(AutoreleasePoolPage*) + 80
1  libobjc.A.dylib                0x146f4 AutoreleasePoolPage::autoreleaseFullPage(objc_object*, AutoreleasePoolPage*) + 72
2  libobjc.A.dylib                0x29618 moveTLSAutoreleaseToPool(ReturnAutoreleaseInfo) + 128
3  libobjc.A.dylib                0x29488 objc_object::rootAutorelease() + 116
4  Foundation                     0x10c1c -[NSConcreteHashTable countByEnumeratingWithState:objects:count:] + 144
5  ReactNativeFramework        0x4e296c -[RCTTextViewManager uiManagerWillPerformMounting:] + 73 (RCTTextViewManager.m:73)
6  ReactNativeFramework        0x47abd8 -[RCTUIManagerObserverCoordinator uiManagerWillPerformMounting:] + 72 (RCTUIManagerObserverCoordinator.mm:72)
7  ReactNativeFramework        0x47771c -[RCTUIManager _layoutAndMount] + 1172 (RCTUIManager.m:1172)
8  ReactNativeFramework        0x435888 __32-[RCTCxxBridge batchDidComplete]_block_invoke + 1573 (RCTCxxBridge.mm:1573)
9  libdispatch.dylib              0x63850 _dispatch_call_block_and_release + 24
10 libdispatch.dylib              0x647c8 _dispatch_client_callout + 16
11 libdispatch.dylib              0x3f854 _dispatch_lane_serial_drain$VARIANT$armv81 + 604
12 libdispatch.dylib              0x402e4 _dispatch_lane_invoke$VARIANT$armv81 + 380
13 libdispatch.dylib              0x4a000 _dispatch_workloop_worker_thread + 612
14 libsystem_pthread.dylib        0x1b50 _pthread_wqthread + 284
15 libsystem_pthread.dylib        0x167c start_wqthread + 8

Version
0.69.1
Output of npx react-native info
System:
OS: macOS 12.6
CPU: (10) arm64 Apple M1 Max
Memory: 95.41 MB / 32.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.19.0 - ~/.nvm/versions/node/v16.19.0/bin/node
Yarn: 1.22.19 - /opt/homebrew/bin/yarn
npm: 8.19.3 - ~/.nvm/versions/node/v16.19.0/bin/npm
Watchman: Not Found
Managers:
CocoaPods: 1.11.3 - /Users/kunal.chavhan/.rvm/gems/ruby-2.7.5/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.2, iOS 15.2, macOS 12.1, tvOS 15.2, watchOS 8.3
Android SDK: Not Found
IDEs:
Android Studio: Dolphin 2021.3.1 Patch 1 Dolphin 2021.3.1 Patch 1
Xcode: 13.2.1/13C100 - /usr/bin/xcodebuild
Languages:
Java: 11.0.11 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: Not Found
react-native: Not Found
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Steps to reproduce
We are unable to reproduce this crash, above logs are shared from firebase.
Snack, code example, screenshot, or link to a repository
This is the way we are using Text in our code base. The crash is not reproducible at our end but we are seeing a very high volume of crashes in firebase.
export const TextImpl = (props: TextProps) => {
  const fontWeight = props.fontWeight || FontWeight.Regular
  const {
    i18n: {language},
  } = useTranslation()
  const font = getFontFamilyStyles(props.locale ?? (language as Lang))

  return (
    /* When ellipsized mode is used having space in string will cause the
      string to break at those spaces and this causes issues. So non breaking
      Space is used instead. */
    <Text
      {...props}
      allowFontScaling={false}
      style={[
        !props.inheritColor && styles.textColor,
        props.style,
        font.text,
        fontWeight === FontWeight.Bold && font.weightBold,
        fontWeight === FontWeight.Medium && font.weightMedium,
        fontWeight === FontWeight.Regular && font.weightRegular,
      ]}>
      {props?.numberOfLines === 1 &&
      (props.ellipsizeMode ? props.ellipsizeMode === 'tail' : true)
        ? Array.isArray(props.children)
          ? props.children?.map((child) =>
              typeof child === 'string'
                ? child.replace(RegExp(' ', 'g'), '\u00A0')
                : child,
            )
          : props.children?.toString().replace(RegExp(' ', 'g'), '\u00A0')
        : props.children}
    </Text>
  )
}

We are having the same problem. 100k users of us has been crashed

I see the problem fixes in this PR
\ uiManagerWillPerformMounti

@mr-dangvanhien Thank you replying. Does this fixes the issue? Also any idea when this change will go live?

@mr-dangvanhien The changes in above commit will not solve the problem as mentioned here.

@chrisdelaney10 We have not figured out a fix yet. Any help here would be appreciated.

@kunal-d11 are you using react-navigation and if so what version?

@chrisdelaney10 yes v6.

Any suggestions? I'm facing the same issue on all devices running 1OS 16

We are also facing a large number of crashes due to this ERROR.

Having this crash in production?

@lucaswitch yeah it only happens in production mode. We are getting tons of crash reports from users

Hi @kunal-d11 Could you please help how did you resolve this crash wrt to react-query?

This happens on 0.73.2 pretty consistently when i use bundled react-native modal
Here is my stacktrace:

@lucaswitch in our case sudden memory spikes was causing this crash, we were able to reproduce this crash by adding intentional memory spikes, can you do the same and try to reproduce it?

I was able to solve this issue rewriting some modals logic.

@lucaswitch , can you provide detail how you wrote modal logic. Is this related to react-native-modal or how we show alerts in React native.

Experiencing the same issue after app goes over 1GB of used memory


How can I use the parallax effect?

I can't find this function, not support?

List of available vue components is here http://appcomponents.org/material-components (see logos).
Paralax isn't good candidate for component. It's effect. You can use jquery from materialize or write function there https://github.com/Dogfalo/materialize/blob/master/js/parallax.js in plain javascript.
If you have plain js solution I would try make component for it


Allow<EMAIL_ADDRESS>peer dependency

It would be cool to have redux-form updated its peer deps of react redux. It seems, there are no real api changes aside some event order issues.
https://github.com/reactjs/react-redux/releases

^5.0.0-beta doesn't match 5.0.0?

probably sufficient, didnt notice its already in place in master, nice work!


:warning: Action Required: Replace Deprecated gcr.io/kubebuilder/kube-rbac-proxy

Description
:warning: The image gcr.io/kubebuilder/kube-rbac-proxy is deprecated and will become unavailable.
You must move as soon as possible, sometime from early 2025, the GCR will go away.

Unfortunately, we're unable to provide any guarantees regarding timelines or potential extensions at this time. Images provided under GRC will be unavailable from March 18, 2025, as per announcement. However, gcr.io/kubebuilder/may be unavailable before this date due to efforts to deprecate infrastructure.

If your project uses gcr.io/kubebuilder/kube-rbac-proxy, it will be affected.
Your project may fail to work if the image cannot be pulled. You must take action as soon as possible.

However, if your project is no longer using this image, no action is required, and you can close this issue.

Using the image gcr.io/kubebuilder/kube-rbac-proxy?
kube-rbac-proxy was historically used to protect the metrics endpoint. However, its usage has been discontinued in Kubebuilder. The default scaffold now leverages the WithAuthenticationAndAuthorization feature provided by Controller-Runtime.
This feature provides integrated support for securing metrics endpoints by embedding authentication (authn) and authorization (authz) mechanisms directly into the controller manager's metrics server, replacing the need for (https://github.com/brancz/kube-rbac-proxy) to secure metrics endpoints.
What To Do?
You must replace the deprecated image gcr.io/kubebuilder/kube-rbac-proxy with an alternative approach. For example:

Update your project to use WithAuthenticationAndAuthorization:

You can fully upgrade your project to use the latest scaffolds provided by the tool or manually make the necessary changes. Refer to the FAQ and Discussion for detailed instructions on how to manually update your project and test the changes.

Alternatively, replace the image with another trusted source at your own risk, as its usage has been discontinued in Kubebuilder.

For further information, suggestions, and guidance:

📖 FAQ and Discussion
💬 Join the Slack channel: #kubebuilder.

NOTE: This issue was opened automatically as part of our efforts to identify projects that might be affected and to raise awareness about this change within the community. If your project is no longer using this image, feel free to close this issue.

We sincerely apologize for any inconvenience this may cause.
Thank you for your cooperation and understanding! :pray:

/assign @daemon1024 @rksharma95 @camilamacedo86
To address the deprecation of gcr.io/kubebuilder/kube-rbac-proxy, I propose the following options to move forward:

Migrate to WithAuthenticationAndAuthorization:

This approach leverages the Controller-Runtime's built-in support for authentication and authorization to secure metrics endpoints.
It aligns with the latest scaffolding recommendations from Kubebuilder, eliminating the need for external tools like kube-rbac-proxy.

Replace the Image:

If an immediate upgrade is not feasible, we can replace the deprecated image with a trusted alternative, such as quay.io/brancz/kube-rbac-proxy:latest.
This would ensure continuity while we plan for a more comprehensive migration.

Could you please confirm which approach you'd prefer to proceed with? Additionally, if there are any specific constraints or considerations for the project, let me know so I can factor them into the implementation.
Looking forward to your guidance!

Hi @abhashsolanki18,
Thank you for looking into that. As described in: https://github.com/kubernetes-sigs/kubebuilder/discussions/3907
The best option to move forward is by adopting WithAuthenticationAndAuthorization with the following recommended steps:

You can upgrade your project to the latest release by re-scaffolding it and reintegrating your custom code. (regenerate all with the latest version of the tool and then add your code back on top again using an IDE for example)

You can use kubebuilder alpha generate to regenerate the project from the PROJECT config.
This ensures a default implementation (similar to kube-rbac-proxy) with options to improve production readiness, such as configuring certificates securely. This approach also allows you to take advantage of other improvements, bug fixes, and the latest updates.

If you are unable to do that:

Check out the FAQ section: "How can I manually change my project to switch to Controller-Runtime's built-in auth protection?" for detailed instructions.
Please, let me know if you need any further information or help to move forward here.


[mesheryctl] Restart logic to be simplified/reconsidered

See mesheryctl Command Tracker for current status of commands.
Current Behavior
Currently, for platform: Kubernetes, restart logic deletes the pods and the system controller detects this and restarts these.
But running kubectl get pods -n meshery shows no pods after restart if meshery was not running earlier.
Desired Behavior

Irrespective of whether meshery was running earlier, restart should result in pods running at the end of the command.
Environment

Host OS: Mac Linux Windows
Platform: Kubernetes

Implementation

Using stop and then start functions, similar to the implementation for docker.
Acceptance Tests.
Pods should be observed as running after restart, either using system status or kubectl get pods -n meshery.

Contributor Resources

mesheryctl Contributing Guide
Beginner's guide to contributing to Meshery and mesheryctl
mesheryctl Command Tracker
Meshery CLI Commands and Documentation
Layer5 Community Slack

@DARK-art108 do you want to try working on this issue?

Yes, I would like to work on it!

@DARK-art108 how is this going? Any blockers you need help on?

@metonymic-smokey will let you know for any help, working upon it! Thanks :)

Closed via #3285


Gesture Recognizer Pi sample update to detect gestures for multiple hands

Description
Updates recognize.py to recognize gestures for 2 hands.
Fixes # (issue)

Removes the extended frame to display the recognized gesture for a single hand
Detects gestures for both the hands now

Hi @PaulTR,
Could you kindly review this pull request aimed at implementing the detection of both hands in a single frame for the Gesture Recognize Pi sample. Currently, there is a challenge in detecting both hands in a single frame on Raspberry Pi. For a more detailed understanding, you may refer to the ongoing issue.
Thank you!


Request: List of Userpermissions

Can you provide a list of usable permissions? Its for the German/English Wiki i create =)

Thank you =)


Add heartbeat latency

It would be like client.ws.ping

This is something that not many devs really need. I don't think it is worth having this in the core lib especially when it is not required to have a bot function. It would take up memory for each shard for no reason whatsoever for most bots. For most bots a Date.now - message.timestamp is enough.
For the rare few who need this latency it's actually really easy to do yourself.

Use the rawGateway event to handle incoming events for heartbeats and ack events.
Use the debug event with the gatewayHeartbeat type filter and you can tell when a heartbeat is sent.

This is something that not many devs really need. I don't think it is worth having this in the core lib especially when it is not required to have a bot function. It would take up memory for each shard for no reason whatsoever for most bots. For most bots a Date.now - message.timestamp is enough.
For the rare few who need this latency it's actually really easy to do yourself.

Use the rawGateway event to handle incoming events for heartbeats and ack events.
Use the debug event with the gatewayHeartbeat type filter and you can tell when a heartbeat is sent.


removing placeholder css custom property

Same as the change in inputs. This will require a visual diff update.

Hmm... so why did the visual diff tests pass if I removed one of them?

I think the visual-diff is only going to compare images for tests in your PR.
Previously with the goldens in S3, the obsolete/orphaned golden images would have been removed when the goldens were updated, but their presence would not have caused a failure.  I suspect (but not 100% sure) that these obsolete goldens will be removed from GitHub master when the goldens are updated.  @margaree, ya?

That's my suspicion as well.


Metal Semaphores

Semaphores are used in the following scenarios in Vulkan:

Synchronizing different command queues
Synchronizing rendering with the presentation engine (effectively, a hidden queue)
Ordering command buffers within submissions

Metal exposes multiple command queues but without any means to synchronize between them. The target use case is having completely independent workloads done in parallel. This poses a problem of implementing VkSemaphore on Metal.
First decision that's going to partially address the problem is exposing a single command queue. This solves (1). Synchronizing with the presentation engine needs more investigation, but it doesn't appear that it would require much magic, so we should be good with (2) as well.
As for (3) - it comes down to the serialization problem of command buffers for submission. We just need to analyze the incoming dependency graph of command buffers within a single submission (where semaphores mark dependencies), and derive the actual Metal submission order from it. Since Vulkan requires no deadlocks posed by semaphores, there should be at least one way to order the command buffers.

:+1:
Exposing a single command queue let's us decouple command pools (and therefore buffers) from specific queues and allows us to couple them with queue families instead (as done in Vulkan) without trying to expose one family for each queue.

@kvark I think the command buffer callback feature will be sufficient to synchronize with Swapchain if we continue to handle presentation manually, and we'll probably want to keep a dispatch_semaphore_t around (like it is in the current implementation) for this case.

I think this is done, at least within the context of a single queue.


The plugin google_maps_flutter could not be built due to the issue above.

C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapController.java:18: error: cannot find symbol
import androidx.lifecycle.DefaultLifecycleObserver;
                         ^
  symbol:   class DefaultLifecycleObserver
  location: package androidx.lifecycle
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapController.java:49: error: cannot find symbol
    implements DefaultLifecycleObserver,
               ^
  symbol: class DefaultLifecycleObserver
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapsPlugin.java:19: error: cannot find symbol
import io.flutter.embedding.engine.plugins.lifecycle.FlutterLifecycleAdapter;
                                                    ^
  symbol:   class FlutterLifecycleAdapter
  location: package io.flutter.embedding.engine.plugins.lifecycle
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapController.java:110: error: incompatible types: GoogleMapController cannot be converted to LifecycleObserver
    lifecycleProvider.getLifecycle().addObserver(this);
                                                 ^
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapController.java:477: error: incompatible types: GoogleMapController cannot be converted to LifecycleObserver
      lifecycle.removeObserver(this);
                               ^
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapController.java:510: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapController.java:518: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapController.java:526: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapController.java:534: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapController.java:542: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapController.java:550: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapController.java:552: error: incompatible types: GoogleMapController cannot be converted to LifecycleObserver
    owner.getLifecycle().removeObserver(this);
                                        ^
C:\Users\user\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\google_maps_flutter-1.0.6\android\src\main\java\io\flutter\plugins\goog
lemaps\GoogleMapsPlugin.java:92: error: cannot find symbol
    lifecycle = FlutterLifecycleAdapter.getActivityLifecycle(binding);
                ^
  symbol:   variable FlutterLifecycleAdapter
  location: class GoogleMapsPlugin
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
13 errors

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileReleaseJavaWithJavac'.
> Compilation failed; see the compiler error output for details.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get
 full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1s

enable androidX in your application

Hello @TomerconDevelopers
Try the above solution and if still the problem is there then please send the flutter doctor -v, flutter run -v, and minimal reproduction code
Thanks.

@TomerconDevelopers
If you were trying to hot restart or hot reload after adding google_maps plugin, then you first need to stop the app instance, run flutter pub get and then flutter run. You may also try flutter clean and then flutter run to see if it works.
If problem still persists, provide flutter doctor -v, pubspec.yaml and minimal code sample without any 3rd party plugins that shows the issue.
Thanks.

I fixed it by creating new project with latest flutter version, then moved code to new project.

I fixed it by creating new project with latest flutter version, then moved code to new project.

Yes its works, i have same issue and try lot of way, but create new project in different directory location and add plugin in pubsepc.yaml
google_maps_flutter:
its working see in given image

I was create new project and add dependencies from my old pubspec.yaml but still not working. i got this errors. any clues?
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:18: error: cannot find symbol import androidx.lifecycle.DefaultLifecycleObserver;
                         ^
  symbol:   class DefaultLifecycleObserver
  location: package androidx.lifecycle
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:49: error: cannot find symbol
    implements DefaultLifecycleObserver,
               ^
  symbol: class DefaultLifecycleObserver
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapsPlugin.java:19: error: cannot find symbol
import io.flutter.embedding.engine.plugins.lifecycle.FlutterLifecycleAdapter;
                                                    ^
  symbol:   class FlutterLifecycleAdapter
  location: package io.flutter.embedding.engine.plugins.lifecycle
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:110: error: incompatible types: GoogleMapController cannot be converted to LifecycleObserver
    lifecycleProvider.getLifecycle().addObserver(this);
                                                 ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:477: error: incompatible types: GoogleMapController cannot be converted to LifecycleObserver
      lifecycle.removeObserver(this);
                               ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:510: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:518: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:526: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:534: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:542: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:550: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:552: error: incompatible types: GoogleMapController cannot be converted to LifecycleObserver
    owner.getLifecycle().removeObserver(this);
                                        ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapsPlugin.java:92: error: cannot find symbol
    lifecycle = FlutterLifecycleAdapter.getActivityLifecycle(binding);
                ^
  symbol:   variable FlutterLifecycleAdapter
  location: class GoogleMapsPlugin
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output 13 errors

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileReleaseJavaWithJavac'.
> Compilation failed; see the compiler error output for details.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 6s

The plugin google_maps_flutter could not be built due to the issue above.

I was create new project and add dependencies from my old pubspec.yaml but still not working. i got this errors. any clues?
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:18: error: cannot find symbol import androidx.lifecycle.DefaultLifecycleObserver;
                         ^
  symbol:   class DefaultLifecycleObserver
  location: package androidx.lifecycle
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:49: error: cannot find symbol
    implements DefaultLifecycleObserver,
               ^
  symbol: class DefaultLifecycleObserver
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapsPlugin.java:19: error: cannot find symbol
import io.flutter.embedding.engine.plugins.lifecycle.FlutterLifecycleAdapter;
                                                    ^
  symbol:   class FlutterLifecycleAdapter
  location: package io.flutter.embedding.engine.plugins.lifecycle
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:110: error: incompatible types: GoogleMapController cannot be converted to LifecycleObserver
    lifecycleProvider.getLifecycle().addObserver(this);
                                                 ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:477: error: incompatible types: GoogleMapController cannot be converted to LifecycleObserver
      lifecycle.removeObserver(this);
                               ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:510: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:518: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:526: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:534: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:542: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:550: error: method does not override or implement a method from a supertype
  @Override
  ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapController.java:552: error: incompatible types: GoogleMapController cannot be converted to LifecycleObserver
    owner.getLifecycle().removeObserver(this);
                                        ^
C:\flutter_1.22\.pub-cache\hosted\pub.dartlang.org\google_maps_flutter-1.1.1\android\src\main\java\io\flutter\plugins\googlemaps\GoogleMapsPlugin.java:92: error: cannot find symbol
    lifecycle = FlutterLifecycleAdapter.getActivityLifecycle(binding);
                ^
  symbol:   variable FlutterLifecycleAdapter
  location: class GoogleMapsPlugin
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output 13 errors

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileReleaseJavaWithJavac'.
> Compilation failed; see the compiler error output for details.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 6s

The plugin google_maps_flutter could not be built due to the issue above.


Run Percy without Cypress's GitHub Actions package

Percy fails on GitHub Actions while it works locally. The difference is whether we use Cypress's GitHub Actions package or not.
re: #21

Still doesn't work...
We should forget running Percy on GitHub Actions server.

This pull request won't be merged to the main branch, as we've decided not to run Percy on CI.


No module named env

Hello,
Congratulations on winning the Neurips 2020 Flatland Challenge. I am trying to reproduce your results, but I think that the folder env is missing. I got the following error while trying to run train.py:
Traceback (most recent call last):
  File "train.py", line 10, in <module>
    from env.observations import SimpleObservation, ShortPathObs
ModuleNotFoundError: No module named 'env'

Thank you in advance,

I am having the same issue. please upload the env folder.

Hello, is it still there? Is this warehouse not maintained


Compatibility with MCMCChains

This is a very minor pull request for conveniently bundling samples from AdvancedHMC.jl into an Chains object from MCMCChains.jl. Very similar to the interface in AdvancedMH.jl, it should make it easier to switch from one to the other.

I think ultimately we should try to improve the packages and interfaces such that downstream packages get this for free/automatically or by implementing a more minimal interface (at least don't have to depend on MCMCChains/Requires). Weak dependencies could help with this in Julia >= 1.9 but somehow it feels unsatisfying if similar code is added to every sampler package.

Documenting this with a usage example would also be great.

thanks @kaandocal and @sethaxen!


sst_dump tool should show both the offset and size from the index block handle and metaindex block handle

Owner:
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

sst_dump tool should show both the offset and size from the index block handle and metaindex block handle

sst_dump tool should show both the offset and size from the index block handle and metaindex block handle

@qianyich - I am adding some information for clarification. Feel free to correct me if you think it is necessary.
When sst_dump displays the file's footer information, it displays the metaindex_handle and the index_handle in their encoded format (A single hexadecimal value is displayed) . A handle consists of 2 components (offset and size).
The request is to decode the handles, and display these 2 components (offset and size) explicitly, and after decoding.


Added states and modes for zwave climate

Description:
Added support for Fan Only State @balloob
Added additional missing modes and states this should correct issue #25216
Related issue (if applicable): fixes #25216
Checklist:

[X] The code change is tested and works locally.
[X] Local tests pass with tox. Your PR cannot be merged unless tests pass
[X] There is no commented out code in this PR.
[X] I have followed the [development checklist][dev-checklist]

I think I found one more mode: "Energy Heat" or "Heat Econ" from my Heatit Z-Therm2

@olbjan I am not sure how to translate your info to the mappings, so will merge this now and get it in 96.1.
@stboch could you convert the info from @olbjan into a new PR ? Tag me when you do.
Cheers!


Typo in build_instructions.md.

Very simple typographical error.

Hi Steve,
I will give this a review in a few days. I am out on holiday at the moment.
Kindest regards and thank you for the help,
Matt
Steve Powell<EMAIL_ADDRESS>schrieb am Do., 25. Juni 2015 um
18:01:

Very simple typographical error.
You can view, comment on, or merge this pull request online at:
https://github.com/matttproud/gochecklist/pull/2
Commit Summary

Typo in build_instructions.md.

File Changes

M publication/build_instructions.md
https://github.com/matttproud/gochecklist/pull/2/files#diff-0 (2)

Patch Links:

https://github.com/matttproud/gochecklist/pull/2.patch
https://github.com/matttproud/gochecklist/pull/2.diff

—
Reply to this email directly or view it on GitHub
https://github.com/matttproud/gochecklist/pull/2.

Thank you for the edit, @Zteve!


Add "slots" before and after locations

Resolve https://github.com/VictorCazanave/react-svg-map/issues/30

Codecov Report

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

@@            Coverage Diff            @@
##            master       #42   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            3         3
  Lines           86        86
  Branches        20        20
=========================================
  Hits            86        86

Impacted Files
Coverage Δ

src/checkbox-svg-map.jsx
100.00% <ø> (ø)

src/radio-svg-map.jsx
100.00% <ø> (ø)

src/svg-map.jsx
100.00% <ø> (ø)

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 2cfb984...2560907. Read the comment docs.


Use stringex to make url slugs

For Projects, Users, UserGroups, and Collections. Enables
human-readable, but still safe urls
Closes #863

@brian-c @aweiksnar  basically you'll need to be using the "slug" attribute instead of display name for collections and projects.

Also I'd like to get this merged before doing the user migration since this will require migrating a slug field for every user.

looks good to merge, just some specs to clean up.


Stacker issue with lava bucket

Hi, a user from my pack commented on an issue when using stacked lava buckets and it consumes the whole stack but only sees it as x1.
Please see more info here - https://github.com/gamerpotion/DarkRPG/issues/58
There is a video link on there as well from the user.

From what I understand is there is no Vanilla way to stack Lava buckets... They could instead just use a tank that inputs lava into the Forge unless that pack has no tanks or pipes to transfer such.

@Noaaan @gliscowo Thoughts?

Thanks for letting us know. I have implemented a fix for this which should prevent similar issues from happening.


release v1.5.1

:beetle:

Please write "LGTM" next time since label changes don't trigger notifications

No problem, I was keeping an eye on the Semaphore test-suite

We need to mention the data dir issue in the changelog more clearly.

We need to mention the data dir issue in the changelog more clearly.

Ooops. Right.

LGTM on green


Tracking issue: Create validator for values hashed by SHA-3 512 algorithm

Original issue: https://github.com/RedHatInsights/insights-data-schemas/issues/66

Implemented in https://github.com/RedHatInsights/insights-data-schemas/pull/72

Implemented in https://github.com/RedHatInsights/insights-data-schemas/pull/72


OIDC4VC advanced settings : add switch Credential Manifest Support

Add a new switch
Credential Manifest Support
Default: On
Support of the DIF wallet rendering specifications
Becareful this switch is the same parameter as the configuration parameter
see cofiguration file
 "selfSovereignIdentityOptions": {
        "displayManageDecentralizedId": true,
        "displaySsiAdvancedSettings": true,
        "displayVerifiableDataRegistry": true,
        "oidv4vcProfile": "ebsi",
        "customOidc4vcProfile": {
            "securityLevel": "low",
            credentialManifestSupport": true,

Profile EBSI and DUTCH BLockchain, parameter is off (false) for custom profile it is "on" (true)

when switch is off, the display of the credential is defined by the "display" attribute of the openid-configuration (OIDC4VCI)

Add logic support


Impact
random numbers :smile_cat:
Expected behavior
normal boot
Encountered behavior
[...]
Oct 16 17:20:24 localhost rngd[276]: read error
Oct 16 17:20:24 localhost rngd[276]: read error
Oct 16 17:20:24 localhost rngd[276]: read error
Oct 16 17:20:24 localhost rngd[276]: No entropy sources working, exiting rngd

Can confirm that the failure happens on AWS ARM. (tested several months ago)
Removed the label channel/alpha, as all channels from Stable to Alpha now support ARM.

We are using a really old version of rng-tools, I'm updating it to a newer version which handles missing hwrng better.


Enable ASP.NET Core app to share auth/identity decisions with ASP.NET app

Current tooling allows incremental migration to share ASP.NET authentication with an ASP.NET Core app for quick startup moving endpoints.
In addition to this existing functionality, it would be useful to be able to have the ASP.NET Core authenticate users and forward identity information to the ASP.NET app (in cases where it's necessary to fall back to the ASP.NET app to handle a request). This would allow developers to migrate authentication at any point in the migration process that was convenient instead of having to wait until all ASP.NET endpoints have been migrated first.

We have a couple of requests for this in #261

Would this include consideration around Microsoft.AspNet.Identity (in particular, Microsoft.AspNet.Identity.EntityFramework) as well, or is that a new issue (or even out of scope for this repo)?
Even though EF6 supports .NET Standard 2.1, Microsoft.AspNet.Identity.* doesn't (only .NET 4.5.1), so when the data layers have this dependency (for things like IdentityUser), business layers are blocked from migrating to .NET Standard 2.0 or higher. Currently the answer here is doing it all in one hit (which is antithetical to incrementally migrating), or duplicating the identity types in the DAL to remove the dependency.
(I'd love to move to EFCore first, but netstandard2.0 hasn't been a supported target since 3.1, and I'd be rewriting UserStore and such to work with ASP.NET).

Hi,
is there any progress on this request? Appears to be no activity since March 2023 and its a pretty crucial piece of the incremental migration story.

Hi
Thanks for this amazing work.
We are trying to upgrade out 20 year old app and some of our clients use Windows authentication.
Is there any progress here or #246 ?
Without this we are unable to use Incremental upgrade.

@twsouthwick @adityamandaleeka @mjrousos Any updates/plans on this please