Crash due to excessive memory usage when using lpad/rpad functions with large numeric values

Environment:

eKuiper version: 1.12.7
Hardware configuration: Intel-I7, 8 GB RAM
OS: Alpine docker running on Ubuntu 22.04 host

What happened and what you expected to happen:
When using the lpad and rpad functions with a large numeric value as the argument in eKuiper, the application crashes due to excessive memory usage. This issue arises when the specified argument is exceptionally large, causing eKuiper to consume an excessive amount of memory, ultimately leading to a crash. To address this, a potential fix could be to implement a validation check within the lpad and rpad functions to throw an error when the second argument exceeds a certain size, thus preventing excessive memory consumption and subsequent crashes.
In my use case i was collecting data with EdgeX and i eKuiper i have a simple rule that uses function rpad(A,B) with twa variables. Some times the B variable value is very large and ekuiper crashes due to excessive memory usage
How to reproduce it (as minimally and precisely as possible):
SELECT lpad(A,B) as comp_result from source where B is a very large number
Or SELECT rpad(A,125012521102) as comp_result from source

How to decide the threshold? Maybe you can do it by a filter like: SELECT lpad(A,B) as comp_result from source WHERE B < 999999

I agree with you, there is no logical way to define the threshold but i thought you may want to document this behavior


[17.06] allocator: Retry failed allocations immediately upon a deallocation

Cherry pick https://github.com/docker/swarmkit/pull/2235.
git cherry-pick -s -x e91352325579da2af724033599bc391eb7269956

Cherry-pick was not clean.

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "17.06-retry-failed-allocations" git@github.com:nishanttotla/swarmkit.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842357627600
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

I think one more change is missing from the original PR:  https://github.com/docker/swarmkit/pull/2235/files#diff-119d353212583d96a59cba8c82b80280R656
I think this is around like 750 in this branch?

I also don't know enough about the old allocator code - there are a couple more places where committing we attempt to roll back an allocation because a commit failed (at https://github.com/nishanttotla/swarmkit/blob/97dcb699cf732d0d2816a57a2d777b0f5f59fd14/manager/allocator/network.go#L816 for example) - do we need to add somethingDeallocated = true to those places?  They're not in the original PR, but I wasn't sure if they should be.

Rebased on https://github.com/docker/swarmkit/pull/2643 to fix tests.

Current failure seems like it's https://github.com/docker/swarmkit/issues/2577.
Ping @anshulpundir

Effectively reverted after docker:bump_v17.06 was reset back to 90897c12967088cb43f100596c1ed41a8cbe91be/https://github.com/docker/swarmkit/pull/2584


bug:

Current behavior:
ion select's alert interface option not accepting css class.
Expected behavior:
Accepts custom css class and shows alert accordingly.
Steps to reproduce:
For ion select with alert interface, pass interface options with custom css class
<ion-select interface="alert" [interfaceOptions]="customOptions" placeholder="Select Item">
          <ion-select-option>A</ion-select-option>
          <ion-select-option>B</ion-select-option>
          <ion-select-option>C</ion-select-option>
</ion-select>

.ts
//imports

export class Sample{
//....
customOptions: any = {
    header:'Header works, class doesnt!',
    cssClass:'dropdown'
  };
//....
}

.scss
ion-select.dropdown{
    --background:green;
    --min-width:500px;
    --min-height:500px;
}

Ionic info:
Ionic:

   ionic (Ionic CLI)             : 4.5.0
   Ionic Framework               : @ionic/angular 4.5.0
   @angular-devkit/build-angular : 0.13.7
   @angular-devkit/schematics    : 7.2.4
   @angular/cli                  : 7.3.6
   @ionic/angular-toolkit        : 1.4.0

Cordova:

   cordova (Cordova CLI) : not installed
   Cordova Platforms     : not available
   Cordova Plugins       : not available

System:

   NodeJS : v10.16.0 (C:\Program Files\nodejs\node.exe)
   npm    : 6.9.0
   OS     : Windows 10

Hi there,
Thanks for the issue. I am going to close this as this is a support question.
The cssClass is applied to the ion-alert element that appears, not the ion-select element. Your CSS should target ion-alert.dropdown instead.
Thanks!

Hey liam!,
I tried applying the cssClass to ion-alert previously as well, in v4.5 as well as v5.2. Are you sure the issue is unable to be reproduced?

If you provide a repo with the code required to reproduce this issue, I can take another look. Thanks!

Sure! Here is a test repo...
https://github.com/shrihari1999/testApp

Thanks for the follow up. A few things I noticed:

When setting the cssClass property, you don't need to put a period before the class name. So just do cssClass: "dropdown" instead of cssClass: ".dropdown".
You should place your alert's custom css in global.scss not in home.page.scss.

After making those two changes, the styles were properly applied.

Thanks! Worked perfectly.


Investigate playlist issue on foldable devices

As a user, I should be able to play videos from a playlist without having the videos overlapping on the player surface on a foldable device.
This can be reproduced in the Pillarbox demo on a foldable emulator running API 34 (see screenshot below), as well as in the Media3 demo.
Next steps

Try to reproduce this scenario on a real foldable device.
Report the issue to Media3 if necessary.

It might be related to https://github.com/androidx/media/issues/1316


0.4.0-SNAPSHOT of the driver doesn't exist

The version of the driver was bumped to 0.4.0-SNAPSHOT per https://github.com/ldbc/ldbc_snb_implementations/commit/7cf3c3ace0f08b4c7462e93bb873147985f0c777. However, at the time of writing this, the latest version of the driver is 0.3.2 https://github.com/ldbc/ldbc_snb_driver/commit/42c7640111a66ea23faf0540b7bdf39ec833c667. https://github.com/ldbc/ldbc_snb_implementations/commit/7cf3c3ace0f08b4c7462e93bb873147985f0c777 needs to be reverted until a a new version of the driver is released.

The driver has a newer version on the dev branch - https://github.com/ldbc/ldbc_snb_driver/tree/dev
Need to make this more explicit in its README. Thanks for raising this.

Deferred with https://github.com/ldbc/ldbc_snb_driver/commit/0ed1cd4c63105d892b5a40966693de75d2e2b419

Hello @szarnyasg, this might still an issue for newcomers. I landed at the README of this repository which instructs me to build the driver without mentioning the dependency on the dev branch.

@zakkak good point - I amended the README.


[Bug] Tab key control does not move to a dropdown value hence user cannot change value user keyboard

Description
When using Tab key to move control through the property pane, control does not move inside of a dropdown hence user is unable to make a selection using keys
Steps to reproduce the behaviour:

Drag and drop a text widget on to the canvas
Use tab key to move control on the property pane of the widget and observe that control does not move to dropdown property

Important Details

Version: Cloud
OS: Win10
Browser: Chrome
Environment: Production

The problem here is that the focus styling is not available on the select widget, If the selection shows up properly our problem is solved

removing this from goodfirst because this is a core control component and we need to be careful here

Reopening this since tab control works only limitedly. Using keys on trigger fields does not work as expected
https://www.loom.com/share/3eb4999664354081a140cab8108f2f52

@ramsaptami That is being tracked on #9920


Standardized Drift errors and exceptions

We are getting errors when our app tries to write to the database after the connection has been closed.
AFAIK, there is not a way to know whether the database connection is opened/closed, other than catching the error thrown by Drift when we try to access the closed database. This seems to be what was addressed in 2b96100480b3484139ba71538ccdc013e9193538, by throwing a StateError.
My issue is that StateError is a Dart generic error. This is not ideal for handling this exception, as it could come from anywhere in the code really.
Specifically, we are dealing with these 2 StateErrors
- "Can't re-open a database after closing it. Please create a new database connection and open that instead."
- "Tried to send  ... over isolate channel, but the connection was closed!:
Would love to see an interface for all DriftException. This approach would provide us a clear and standardized way to handle and manage exceptions coming from your package.
Something like this for example
abstract class DriftError extends Error{}

class BadStateError extends DriftError{}

// etc

And thank you for an amazing package!

Thanks for opening the issue and starting the discussion on this. I agree that a general type for drift exceptions is useful - it's a breaking change though.
When we throw a StateError (and other subclasses of Error) though, that generally indicates a API misuse and a bug in the way drift is used. I would prefer to keep throwing ArgumentErrors and StateErrors where applicable. You're not really supposed to be catching them - they shouldn't happen in the first place :)
In this case, the question is why you're continuing to use the database after potentially closing it? Are there pending asynchronous tasks that might use the database outside of your control? If needed, there might be something missing in drift to better support closing the database when you're really done with it. We could add report information on whether the connection is open for instance. But it will generally be open until you close, so this should be under your control.

@simolus3 Did you have a chance to look at my suggestion? What do you think of it?

I'm still not convinced we should make subclasses of Error thrown by drift easier to catch. To quote the Error docs:

An Error object represents a program failure that the programmer should have avoided.
These are not errors that a caller should expect or catch — if they occur, the program is erroneous, and terminating the program may be the safest response.

There might be places in drift where we're currently throwing an Error where we really should be throwing an exception subclass. I'll gladly revisit those occurrences if they seem overly strict in drift, but I agree with the notion that an error is a bug in the application. Making these easier to catch under an umbrella type goes against the idea of the Error type in my opinion.
That said, I still like the idea of a common DriftException type for things that aren't errors. We could possible have it as a mixin, so that things that are currently a SqliteException would be an internal DriftSqliteException type implementing both types, thus avoiding a breaking change.

Yes the challenge is that there are some pending async tasks that might use the database after it's been closed.

But why are you closing the database then? It's not necessarily a reliable detection, but we're using a  finalizer to close the underlying sqlite3 database once there are no live references to it. So if you don't know when you're done using the database, perhaps not closing it is better than potentially throwing some tasks off (especially if they do non-transactional writes that might leave the database in an inconsistent state).

I agree with the notion that an error is a bug in the application

I understand your point.

I still like the idea of a common DriftException type for things that aren't errors. We could possible have it as a mixin, so that things that are currently a SqliteException would be an internal DriftSqliteException type implementing both types, thus avoiding a breaking change.

Happy to help if I can

But why are you closing the database then?

There are futures that are queued before the database is potentially closed. We close the database on logout. In this case, we log the user out if they refuse to re-authenticate. It is a challenge to prevent or cancel these pending calls.
If we there was a way for us to know whether the database in a state where we can read/write from it that would solve it. I just really feel like there should be a isOpened property somewhere...  @simolus3

To be clear, once the database is closed we don't want to use it anymore. This is more of a side effect.
If we really can't check if the db is opened/closed, and also we can't catch the error thrown if the database is accessed after it's closed.  We're kind of stuck, is there anything else that you can suggest?


✨ [REQUEST] Nextcloud

Checked

[X] If a new addon, I have checked on  Google that such as addon doesn't already exists
[X] If a new feature, I have searched in the discussions & issues that it was not already covered

Which addon?
Nextcloud
Is your feature request related to a problem? Please describe
Kinda, the addon runs just fine, but I am not able to access the Cloud, like HomeAssistant and other Addons, from outside my network. And if I press the button "Open user UI" (in German: Benutzeroberfläche öffnen) in the addon overview where I can also restart, stop, and reinstall it, it opens my HomeAssistant DuckDNS domain with the Nextcloud port, which is not usable. I need to access the cloud by the IP of the server with the port of the cloud.
Describe the solution you'd like
I would love if it would show up in the sidebar in HomeAssistant, like AdGuard, GoogleDrive Backups, and things like this. I guess if it would be accessible from there, I would also not need to get a domain and certificate just for the cloud, because I already have one for HomeAssistant.

Hi, this is not possible due to the way the app is built. Your only solution is to open the port in your router, or use the mobile apps

Hi, well I'm using the nextcloud app on iPhone to access my data from the phone. However indeed I spoke too quickly you also need to open the port in the router to access your files from remote...
Last option i see could be to use a vpn to access your local network remotely, like the fritzbox router offers. However it is a slow and complex solution

ok thx you i just thoght there would be a way that i dont know, case im pretty new in this whole networking, home lab szene xD. i guess i stay with the synology vpn than. i just thoght there would be a easy way to change the "open user UI" button to the correct ip / show the addon in the side bar. but thx you for the work on the addon, and these quick reply's

Mmh in theory it opens with whatever op you are using to access HA! So if you open HA with your external up then the open ui should open nextcloud, as long as you have opened it's port in the router? Wouldn't it?

i dont want to open the port for it. but atm i acces HA with my duckdns domain. since i have done that i can not acces it with its local ip, just with the duckdns one. i remember that the tutorial mentiont something about the router that they notice, that the domain is actually in your local network and dont evan send it out of your local network. anyways if i press this UI button, i just get the duckdns domain with the nextcloud port. witch is not working. for the nextcloud, i need to acces it with the local IP witch is not working for the HA. i guess it has something to do with the routing (i cant anymore acces HA with its local IP). It is absolutly possible, that it would work with no DNS like mine, but as i just said. i do not fully understand all these networking stuff.

Looks complex indeed... I'm lucky to have a server name free with my fritzbox router and everything works out of the box so I don't have to really think about it ;) I would have thought it would work as a redirect to the external ip so all ports opened in the router should be transfered to the duckdns but I've never used it myself so this is perhaps not a correct view... Good luck!

thx for your thoghts. it will definitly be somthing about the routing. the keyword redirects actually helpt me thx man. i figured it out what the actual ip and port is so i am fine. thx

Happy it works then! Have fun


DokanFileInfo should it really be a class?

in dokan net DokanFileInfo is a class which makes me think it lives in the memoryHeap, but maybe it lives in the stack, so it would make more sense if it was a struct, and we could decide to pass by reference or copy it around...
This is again a question because i'm not really sure how instances are marshalled between the kernel and the userland

It gives quite a bit of performance gain to make it a struct, particularly in use cases with lots of file I/O. In my "high-performance" fork I have done exactly that and also changed most list buffers to enumerating results etc. But it involves several breaking changes and I would say that it is difficult to implement at this time in Dokan.net.
Link to the fork, if it sounds interesting:
https://github.com/LTRData/dokan-dotnet
I think though that some other things from this fork can easily be migrated back into the original dokan.net, for example the way it uses Span<byte> to avoid temporary byte arrays for Stream backends in .NET Core etc. (But I will make a separate post about that in some future.)

that is quite intresting, as we are observing a lot of gc pressure using dokan

i was looking at your fork, and i was thinking about why not using the in keywork  instead of ref, it should be "safer", also i would pass all the other params with the in keyword

i was looking at your fork, and i was thinking about why not using the in keywork  instead of ref, it should be "safer", also i would pass all the other params with the in keyword

The in keyword is really only relevant for value types, so it would only be confusing to use it for other parameters.

mmmmh, i don't mean the variance in keyword, the one for the struct to be passed by reference instead of being copied, but it imply that their value should not be changed, it behaves like a readonly ref (that would have had more sense if you ask me)...
By the way, i've opened the solution and for the dokanfileinfo ref is the only option unless we change the api even more

what about removing the object from the dokanfileinfo and adding an out parameter in createfile ? that would make sense, except for the added api change

what about removing the object from the dokanfileinfo and adding an out parameter in createfile ? that would make sense, except for the added api change

Not sure I understand, the object needs to be marshalled by the DokanFileInfo.Context property logic and the GC pointer needs to be stored in a field in DokanFileInfo, so I think it makes sense to keep it a property in DokanFileInfo. Or did you mean something else?

doesn't matter i was proposing a change in dokany

I am fine with performance improvement that breaks the compatibility 👍

another change we could try out to increment performance and reduce marshalling is create two structures for each method, instead of having let's say
public delegate NtStatus ZwCreateFileDelegate(
          [MarshalAs(UnmanagedType.LPWStr)] string rawFileName,
          IntPtr securityContext,
          uint rawDesiredAccess,
          uint rawFileAttributes,
          uint rawShareAccess,
          uint rawCreateDisposition,
          uint rawCreateOptions,
          [MarshalAs(UnmanagedType.LPStruct), In, Out] DokanFileInfo dokanFileInfo);

we could have
public delegate CreateFileResult CreateFileDelegate(CreateFileInput input)
this would also increase readability
@LTRData you seem quite expert about those kind of changes

The parameters to ZwCreateFile etc need to be the way they are to maintain compatibility with the C++ dll. Also, it would not give any particular performance gain to wrap it in a structure either because it just moves necessary marshalling to another place, when marshalling the structure instead.
The only thing that really needs marshalling in my fork with struct version of DokanFileInfo is the string with the file name and there is not much we can do about that. Everything else is just mapped values.

i was proposing changin the C++ dll aswell

Okay, but really, there is really no performance difference between marshalling fields in a structure compared to parameters. It is basically the same thing.

@TrabacchinLuigi the V2 is a partial merge of a pr that is still opened on dokany repository and it is addressing this of have a single struct pointer that has all of the parameters in it.
I must they that I really liked the idea but in reality have all the wrappers and existing implementation to migrate to it is ... difficult. Like I am afraid the just loose people.
Regarding marshalling that another subject :D

If we are talking about native C++, in my opinion the idea of allocating a struct on stack and send a pointer to it in function calls made a lot of sense on x86 architecture. However, on x64 architecture parameters are passed in CPU registers and do not require stack writes or reads, but a struct would need stack writes and then sending a pointer to that struct in a CPU register and the called functions need stack reads to get the values instead of having them in registers directly from start. The performance difference is extremely small, but in most cases it gives better performance to send parameters directly instead of wrapping them in a struct and send a pointer to the struct.
Then on to managed code and marshalling, any needed marshalling is basically the same for fields in structs and for parameters so there is no real performance gain for using one over another.

So: + readability, -lot of work (double minus because i won't have much allocated time), -users would need to migrate projects. -would probably conflict with some already started work.
I think i'll skip that. but thanks to have took the time to reason about it with me

FYI DokanFileInfo is since v2 part of DOKAN_IO_EVENT which is allocated / pop from the memory pool. One per thread.
https://github.com/dokan-dev/dokany/blob/master/dokan/cleanup.c#L43
https://github.com/dokan-dev/dokany/blob/master/dokan/dokan.c#L800

That is a really nice solution. If it is turned into a blittable struct in the .NET world it can be immediately mapped as a .NET struct without any marshalling needed. It is typically the fastest and most efficient that can be done when calling managed code from unmanaged etc.


Debug build is not working, usage of JUCE's CMake API seems incorrect

Describe the bug
Doing a basic debug build causes a linker error:
JUCE/modules/juce_core/juce_core.h:384: undefined reference to `juce::this_will_fail_to_link_if_some_of_your_compile_units_are_built_in_release_mode::this_will_fail_to_link_if_some_of_your_compile_units_are_built_in_release_mode()'

JUCE explains why this appears:
 /*
    As the very long class names here try to explain, the purpose of this code is to cause
    a linker error if not all of your compile units are consistent in the options that they
    enable before including JUCE headers. The reason this is important is that if you have
    two cpp files, and one includes the juce headers with debug enabled, and another does so
    without that, then each will be generating code with different class layouts, and you'll
    get subtle and hard-to-track-down memory corruption!
 */

To Reproduce
Steps to reproduce the behavior:

Set up a project using juce-end-to-end or use my project
cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug
cmake --build build
See error

Expected behavior
Build completes without error.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: Arch Linux
Juce version: 7.0.5
Version 0.0.15

Additional context
Compare these invocations from the same build in my project:
[1/17] ccache /usr/bin/g++ -DDEBUG -DJUCE_GLOBAL_MODULE_SETTINGS_INCLUDED=1 -I/home/barabas/projects/software/flutter_juce_ipc_plugin/juce_ipc/example/tool/host/cmake-build-debug/_deps/juce-end-to-end-src/source/cpp/include -I/home/barabas/projects/software/flutter_juce_ipc_plugin/juce_ipc/example/tool/host/JUCE/modules -I/modules -g -fdiagnostics-color=always -std=gnu++17 -MD -MT _deps/juce-end-to-end-build/source/cpp/CMakeFiles/focusrite-e2e.dir/source/Command.cpp.o -MF _deps/juce-end-to-end-build/source/cpp/CMakeFiles/focusrite-e2e.dir/source/Command.cpp.o.d -o _deps/juce-end-to-end-build/source/cpp/CMakeFiles/focusrite-e2e.dir/source/Command.cpp.o -c /home/barabas/projects/software/flutter_juce_ipc_plugin/juce_ipc/example/tool/host/cmake-build-debug/_deps/juce-end-to-end-src/source/cpp/source/Command.cpp

[13/17] ccache /usr/bin/g++ -DDEBUG=1 -DJUCE_GLOBAL_MODULE_SETTINGS_INCLUDED=1 -DJUCE_MODULE_AVAILABLE_juce_core=1 -DJUCE_MODULE_AVAILABLE_juce_data_structures=1 -DJUCE_MODULE_AVAILABLE_juce_events=1 -DJUCE_MODULE_AVAILABLE_juce_graphics=1 -DJUCE_MODULE_AVAILABLE_juce_gui_basics=1 -DJUCE_STANDALONE_APPLICATION=1 -DJUCE_STRICT_REFCOUNTEDPOINTER=1 -DJUCE_VST3_CAN_REPLACE_VST2=0 -DLINUX=1 -DPIP_JUCE_EXAMPLES_DIRECTORY_STRING=\"/home/barabas/projects/software/flutter_juce_ipc_plugin/juce_ipc/example/tool/host/JUCE/examples\" -D_DEBUG=1 -I/home/barabas/projects/software/flutter_juce_ipc_plugin/juce_ipc/example/tool/host/cmake-build-debug/ChildProcessDemo_artefacts/JuceLibraryCode -I/home/barabas/projects/software/flutter_juce_ipc_plugin/juce_ipc/example/tool/host -I/usr/include/webkitgtk-4.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/home/barabas/projects/software/flutter_juce_ipc_plugin/juce_ipc/example/tool/host/JUCE/modules -I/home/barabas/projects/software/flutter_juce_ipc_plugin/juce_ipc/example/tool/host/cmake-build-debug/_deps/juce-end-to-end-src/source/cpp/include -g -fdiagnostics-color=always -pthread -std=gnu++17 -MD -MT CMakeFiles/ChildProcessDemo.dir/ChildProcessDemo_artefacts/JuceLibraryCode/Main.cpp.o -MF CMakeFiles/ChildProcessDemo.dir/ChildProcessDemo_artefacts/JuceLibraryCode/Main.cpp.o.d -o CMakeFiles/ChildProcessDemo.dir/ChildProcessDemo_artefacts/JuceLibraryCode/Main.cpp.o -c /home/barabas/projects/software/flutter_juce_ipc_plugin/juce_ipc/example/tool/host/cmake-build-debug/ChildProcessDemo_artefacts/JuceLibraryCode/Main.cpp

First one is building a file in this library, the second is building the generated Main.cpp file for my project. There are many extra JUCE compile flags on the second invocation, and we can also see the _DEBUG, which is directly responsible for the failing linker.
There are a few topics on the JUCE forum discussing similar use cases:  https://forum.juce.com/t/how-to-create-a-static-library-that-use-juce-in-official-cmake/50080/3. Generally the advice seems to be that the same JUCE flags are required everywhere where a JUCE header gets included.
As far as I understand, the current build setup in this library has a chance to produce errors (linker, compiler or possibly UB) depending on the JUCE flags set by the user project. To fix this, there needs to be a way for the user project to supply the correct JUCE flags to this library. Possibly instead of linking directly to the JUCE modules in https://github.com/FocusriteGroup/juce-end-to-end/blob/51c5200d254df42ab912eb7d3c87ff5c0fcb6d94/source/cpp/CMakeLists.txt#L24-L43, it should link to a user defined target that can have the correct flags.

This seems to be breaking the build in example/app as well.
I get a linker error again, and the build commands show that JUCE_USE_CURL=0 is not used when building juce_core.cpp, but it is used for some other files.
: && /usr/bin/c++   source/cpp/CMakeFiles/focusrite-e2e-tests.dir/tests/main.cpp.o source/cpp/CMakeFiles/focusrite-e2e-tests.dir/tests/TestCommand.cpp.o source/cpp/CMakeFiles/focusrite-e2e-tests.dir/tests/TestComponentSearch.cpp.o source/cpp/CMakeFiles/focusrite-e2e-tests.dir/tests/TestResponse.cpp.o source/cpp/CMakeFiles/focusrite-e2e-tests.dir/__/__/_deps/juce-src/modules/juce_core/juce_core.cpp.o source/cpp/CMakeFiles/focusrite-e2e-tests.dir/__/__/_deps/juce-src/modules/juce_events/juce_events.cpp.o source/cpp/CMakeFiles/focusrite-e2e-tests.dir/__/__/_deps/juce-src/modules/juce_gui_basics/juce_gui_basics.cpp.o source/cpp/CMakeFiles/focusrite-e2e-tests.dir/__/__/_deps/juce-src/modules/juce_graphics/juce_graphics.cpp.o source/cpp/CMakeFiles/focusrite-e2e-tests.dir/__/__/_deps/juce-src/modules/juce_data_structures/juce_data_structures.cpp.o -o source/cpp/focusrite-e2e-tests  source/cpp/libfocusrite-e2e.a  /usr/lib/libfreetype.so  -lrt  -ldl  -lpthread && :
/usr/bin/ld: source/cpp/CMakeFiles/focusrite-e2e-tests.dir/__/__/_deps/juce-src/modules/juce_core/juce_core.cpp.o: in function `juce::CURLSymbols::create()':
juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0x37): undefined reference to `curl_easy_init'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0x4d): undefined reference to `curl_easy_setopt'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0x64): undefined reference to `curl_easy_cleanup'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0x7b): undefined reference to `curl_easy_getinfo'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0x92): undefined reference to `curl_multi_add_handle'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0xa9): undefined reference to `curl_multi_cleanup'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0xc0): undefined reference to `curl_multi_fdset'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0xd7): undefined reference to `curl_multi_info_read'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0xee): undefined reference to `curl_multi_init'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0x105): undefined reference to `curl_multi_perform'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0x11c): undefined reference to `curl_multi_remove_handle'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0x133): undefined reference to `curl_multi_timeout'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0x14a): undefined reference to `curl_slist_append'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0x161): undefined reference to `curl_slist_free_all'
/usr/bin/ld: juce_core.cpp:(.text._ZN4juce11CURLSymbols6createEv[_ZN4juce11CURLSymbols6createEv]+0x178): undefined reference to `curl_version_info'
collect2: error: ld returned 1 exit status
[29/29] : && /usr/bin/c++   example/app/CMakeFiles/e2e-example-app.dir/source/Main.cpp.o example/app/CMakeFiles/e2e-example-app.dir/__/__/_deps/juce-src/modules/juce_gui_extra/juce_gui_extra.cpp.o example/app/CMakeFiles/e2e-example-app.dir/__/__/_deps/juce-src/modules/juce_gui_basics/juce_gui_basics.cpp.o example/app/CMakeFiles/e2e-example-app.dir/__/__/_deps/juce-src/modules/juce_graphics/juce_graphics.cpp.o example/app/CMakeFiles/e2e-example-app.dir/__/__/_deps/juce-src/modules/juce_events/juce_events.cpp.o example/app/CMakeFiles/e2e-example-app.dir/__/__/_deps/juce-src/modules/juce_core/juce_core.cpp.o example/app/CMakeFiles/e2e-example-app.dir/__/__/_deps/juce-src/modules/juce_data_structures/juce_data_structures.cpp.o -o example/app/e2e-example-app_artefacts/e2e-example-app  source/cpp/libfocusrite-e2e.a  /usr/lib/libfreetype.so  -lrt  -ldl  -lpthread && :
ninja: build stopped: subcommand failed.


[SelectionArea] with custom actions and actions widget overlay builder

Use case
When select text and has feature translated as google translate extension on browser

Proposal
SelectionArea should have params actions, and actions widget builder with position and direction

Hi @phamconganh, I'm not sure I fully understand what you're requesting. Can you provide a bit more information to make this clear?

@danagbemava-nc, in the latest release, Flutter has a SelectionArea to get selectable widgets. My requirement is the case where the user selects the text then the app shows the pop-ups (e.g. show an icon button for the submitted data for translation as some extension like google translate on chrome). So SelectionArea should have parameters for custom actions and not just copy and select all as it is now, and should have a builder with position and orientation popup overlay to show the developer's custom widget on selection.

Thanks for the clarification.

@chunhtai

This looks like can be solved by https://github.com/flutter/flutter/pull/107193/files#diff-24359f8e68613891e848c22ce4f0ac32f7da39dfafd1b7d377fdfac5429e5d36
See the example selectable region toolbar example in the pr.
@phamconganh Can you double check if that can solve your use case?

Hi @phamconganh, does the contextMenuBuilder parameter in SelectionArea fit your needs or is this issue related to something else?

Hi @Renzo-Olivares, problem solved. So I will close this issue.


[RELEASE] Release 1.6.3

What's the task? Please describe.
Action items for releasing v<1.6.3>
Roles

Release captain: @derekbit
QA captain: @chriscchien @roger-ryao

Describe the sub-tasks.
Pre-Release
The Release Captain needs to finish the following items.

[ ] Before creating RC1, create a new release branch for the following component repositories, and then create RC1 from the new branch. Leave the master branch for the next feature release development (This task is only needed when doing a feature release such as 1.7.0).

longhorn-manager
longhorn-ui
longhorn-tests
longhorn-engine
longhorn-instance-manager
longhorn-share-manager
backing-image-manager
longhorn-spdk-engine (needed after GA)
cli

[x] Trigger the GA release build by longhorn/longhorn Actions

The QA captain needs to coordinate the following items before the GA release.

[x] Regression test plan (manual)
[x] Run e2e regression for pre-GA milestones (install, upgrade) @yangchiu
[x] Run security testing of container images for pre-GA milestones @yangchiu
[x] Verify longhorn chart PR to ensure all artifacts are ready for GA (install, upgrade)
[x] Run core testing (install, upgrade) for the GA build

Upgrade from the previous patch of the same feature release.
Upgrade from the last patch of the previous feature release.

Release
The Release Captain needs to finish the following items.

[x] Release note - Release Captain

[x] Deprecation note
[x] Upgrade notes including highlighted notes, deprecation, compatible changes, and others impacting the current users

[x] Publish the new version of doc and add a next patch version of dev doc.
[x] Release longhorn/chart from the release branch to publish to ArtifactHub by longhorn/charts Actions
[x] Marked the release as latest release in longhorn/longhorn README.md
[x] Marked the release as stable release

For the first stable release, we need to consider several factors and reach a consensus by maintainers before claiming it stable.
For any patch release after a stable release, we need to wait 1-2 weeks for user feedback.

Post-Release
After marking the release as a stable release, Release Captain needs to coordinate the following items

[ ] Update https://github.com/longhorn/longhorn/blob/master/deploy/upgrade_responder_server/chart-values.yaml  - @PhanLe1010
[ ] Add another request for the rancher charts for the next patch release - @rebeccazzzz

Rancher Charts
The Release Captain needs to coordinate the following items.

[x] Verify the chart can be installed & upgraded - QA captain
[x] rancher/image-mirrors update - @mantissahz @PhanLe1010
[ ] rancher/charts active branches for Rancher App Marketplace - @mantissahz @PhanLe1010

cc @longhorn/qa @longhorn/dev

Run security testing of container images for pre-GA milestones:
v1.6.3-rc1: 3 CRITICAL, 46 HIGH

The v1.6.3-rc1  regression test resolution
We have related tickets & PRs as follows:

Issue:

test_support_bundle_should_not_timeout
test_recurring_job

Update test case: https://github.com/longhorn/longhorn-tests/pull/2091/
Flaky case https://github.com/longhorn/longhorn-tests/pull/2095

Negative Test cases CI

https://github.com/longhorn/longhorn/issues/9438
~~https://github.com/longhorn/longhorn/issues/9422~~ ( test case issue )

The v1.6.3-rc1 release testing, we have the following related tickets and PRs:
* **Regression Issues**:

  * [test_support_bundle_should_not_timeout](https://github.com/longhorn/longhorn/issues/9452)
  * [test_recurring_job](https://github.com/longhorn/longhorn/issues/9454)

I think https://github.com/longhorn/longhorn/issues/9439 should be included as well.

Run e2e regression for pre-GA milestones (install, upgrade):
v1.6.3-rc1 amd64: 12 failures
v1.6.3-rc1 arm64: 2 failures
v1.6.3-rc1 amd64 upgrade: 7 failures
v1.6.3-rc1 arm64 upgrade: 4 failures

[x] 1. Run core testing (install, upgrade) for the GA build from the previous patch (1.6.2) and the last patch of the previous feature release (1.5.5)

[x] v1.6.3 amd64 core tests: 0 failures
[x] v1.6.3 arm64 core tests: 1 flaky
[x] v1.6.2 to v1.6.3 amd64 core tests: 0 failures
[x] v1.6.2 to v1.6.3 arm64 core tests: 0 failures
[x] v1.5.5 to v1.6.3 amd64 core tests: 0 failure
[x] v1.5.5 to v1.6.3 arm64 core tests: 0 failure

[x] 2. Verify longhorn chart PR to ensure all artifacts are ready for GA (install, upgrade):
Verification passed for the following actions:

[x] Fresh install / upgrade from v1.5.5/v1.6.2 / uninstall by chart
[x] v1(RWX/RWO) / v2 volume replica offline rebuilding
[x] v1(RWX/RWO) / v2 volume detachment and reattachment
[x] Volume backup and restoration

Known CVE issues in some CSI sidecar images. https://github.com/longhorn/longhorn/issues/9132#issuecomment-2362801578

@PhanLe1010 @mantissahz @rebeccazzzz v1.6.3 is just marked as stable. We can start the remaining post tasks. Thank you.

Have we created the 1.6.3 rancher chart PR?

I'm preparing the chart PRs.

@mantissahz Please check the items if they are completed. Thanks.

@mantissahz Please check the https://github.com/longhorn/longhorn/issues/9433#issue-2515785870 if they are completed. Thanks.

Rancher charts have been merged. Checked.
@roger-ryao, I think the item Verify the chart can be installed & upgraded - QA captain could be marked as checked.

Rancher charts have been merged. Checked.

They are merged to dev-* branches but not released to release-* branch yet.
Once @roger-ryao tested this v2.7 branch https://github.com/rancher/charts/pull/4544#issuecomment-2408273887, I will ping Rancher team to release them and upgrade the upgrade responder server

Rancher charts have been merged. Checked.

They are merged to dev-* branches but not released to release-* branch yet.
Once @roger-ryao tested this v2.7 branch rancher/charts#4544 (comment), I will ping Rancher team to release them and upgrade the upgrade responder server

I have completed the testing of the v2.7 branch.

Charts are released and the upgrade responder sever is updated @derekbit

Thank you all :+1:

Charts are released and the upgrade responder sever is updated @derekbit
Thank you @PhanLe1010 and @mantissahz

Completed


uploding website_blocker

hey can you check out my pull request

Please check out My PULl request @Mrinank-Bhowmick

Please check out My PULl request @Mrinank-Bhowmick

Please check out My PULl request @Mrinank-Bhowmick


[BUG] The old instance-manager-r Pods are not deleted after upgrade

Describe the bug
During an upgrade of Harvester, I occasionally encounter the issue that the upgrade waits for the number of LH instance-manager-r Pods to become 1 on a specific node after LH has been upgraded.
node-2:~ # k -n harvester-system logs hvst-upgrade-6z2mt-apply-manifests-nv2jf
...
instance-manager-r pod count is not 1 on node node-0, will retry...
instance-manager-r pod count is not 1 on node node-0, will retry...
instance-manager-r pod count is not 1 on node node-0, will retry...

Though the check is Harvester-specific, this reflects the situation that the old IM-r Pod is not deleted after a new one has spun up, and it lasts almost forever. Some of the replicas are managed by the old IM-r Pod, and some of them are managed by the new one.
The instance-manager-r Pods running on node-0:
node-2:~ # k -n longhorn-system get po -l longhorn.io/instance-manager-type=replica,longhorn.io/node=node-0 -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
instance-manager-r-06d7a790     longhornio/longhorn-instance-manager:v1_20221003
instance-manager-r-d5acb311     longhornio/longhorn-instance-manager:v1_20220303

The replicas managed by the above instance-manager-r Pods on node-0:
node-2:~ # k get lhr -n longhorn-system -l longhornnode=node-0
NAME                                                  STATE     NODE     DISK                                   INSTANCEMANAGER               IMAGE                               AGE
pvc-1d923869-7b4c-4395-a5e8-ad9785417abd-r-85e55078   stopped   node-0   24e133ac-90bf-47ea-bf3f-0a519adda3ec                                                                     11d
pvc-6a4edb98-5e84-4550-92f8-eee461c3d02c-r-798f26e8   stopped   node-0   24e133ac-90bf-47ea-bf3f-0a519adda3ec                                                                     11d
pvc-bdf1cf10-99f4-4a60-869f-68b79453d1b6-r-3196d015   running   node-0   24e133ac-90bf-47ea-bf3f-0a519adda3ec   instance-manager-r-d5acb311   longhornio/longhorn-engine:v1.2.4   11d
pvc-bdf1cf10-99f4-4a60-869f-68b79453d1b6-r-b5b9fcae   stopped   node-0   24e133ac-90bf-47ea-bf3f-0a519adda3ec                                                                     91m
pvc-e63be9a3-e698-4be0-b104-d58d6b8d71cd-r-507976a7   running   node-0   24e133ac-90bf-47ea-bf3f-0a519adda3ec   instance-manager-r-06d7a790   longhornio/longhorn-engine:v1.3.2   154m
pvc-fdb1cda6-090c-4389-be78-23913f020b39-r-54f5cb14   stopped   node-0   24e133ac-90bf-47ea-bf3f-0a519adda3ec                                                                     91m
pvc-fdb1cda6-090c-4389-be78-23913f020b39-r-5a499dab   running   node-0   24e133ac-90bf-47ea-bf3f-0a519adda3ec   instance-manager-r-d5acb311   longhornio/longhorn-engine:v1.2.4   11d

All the attached volumes are healthy:
node-2:~ # k -n longhorn-system get lhv
NAME                                       STATE      ROBUSTNESS   SCHEDULED   SIZE          NODE     AGE
pvc-1d923869-7b4c-4395-a5e8-ad9785417abd   detached   unknown<PHONE_NUMBER>0            11d
pvc-6a4edb98-5e84-4550-92f8-eee461c3d02c   detached   unknown<PHONE_NUMBER>0            11d
pvc-94ddaff8-01e2-4048-8ce5-bdaec9a3a48c   detached   unknown<PHONE_NUMBER>0            11d
pvc-bdf1cf10-99f4-4a60-869f-68b79453d1b6   attached   healthy<PHONE_NUMBER>0   node-3   11d
pvc-e63be9a3-e698-4be0-b104-d58d6b8d71cd   attached   healthy<PHONE_NUMBER>0   node-0   165m
pvc-fdb1cda6-090c-4389-be78-23913f020b39   attached   healthy                  10485760      node-3   11d

However, we found some of the volumes' engine images are not updated successfully:
node-2:~ # k -n longhorn-system get lhv pvc-bdf1cf10-99f4-4a60-869f-68b79453d1b6 -o jsonpath='[{.spec.engineImage}, {.status.currentImage}]'
[longhornio/longhorn-engine:v1.3.2, longhornio/longhorn-engine:v1.2.4]
node-2:~ # k -n longhorn-system get lhv pvc-fdb1cda6-090c-4389-be78-23913f020b39 -o jsonpath='[{.spec.engineImage}, {.status.currentImage}]'
[longhornio/longhorn-engine:v1.3.2, longhornio/longhorn-engine:v1.2.4]

Here are the suspicious logs found in the Longhorn Manager
node-2:~ # k -n longhorn-system logs longhorn-manager-z9pps
...
time="2022-10-17T02:56:54Z" level=warning msg="Error syncing Longhorn replica longhorn-system/pvc-bdf1cf10-99f4-4a60-869f-68b79453d1b6-r-007cf816" controller=longhorn-replica error="failed to sync replica for longhorn-system/pvc-bdf1cf10-99f4-4a60-869f-68
b79453d1b6-r-007cf816: invalid Instance Manager instance-manager-r-33e2295c, state: , IP: " node=node-1
time="2022-10-17T02:56:54Z" level=warning msg="Error syncing Longhorn replica longhorn-system/pvc-fdb1cda6-090c-4389-be78-23913f020b39-r-2aedd343" controller=longhorn-replica error="failed to sync replica for longhorn-system/pvc-fdb1cda6-090c-4389-be78-23
913f020b39-r-2aedd343: invalid Instance Manager instance-manager-r-33e2295c, state: , IP: " node=node-1
time="2022-10-17T02:56:54Z" level=warning msg="Error syncing Longhorn replica longhorn-system/pvc-bdf1cf10-99f4-4a60-869f-68b79453d1b6-r-007cf816" controller=longhorn-replica error="failed to sync replica for longhorn-system/pvc-bdf1cf10-99f4-4a60-869f-68
b79453d1b6-r-007cf816: invalid Instance Manager instance-manager-r-33e2295c, state: , IP: " node=node-1
time="2022-10-17T02:56:54Z" level=warning msg="Error syncing Longhorn replica longhorn-system/pvc-fdb1cda6-090c-4389-be78-23913f020b39-r-2aedd343" controller=longhorn-replica error="failed to sync replica for longhorn-system/pvc-fdb1cda6-090c-4389-be78-23
913f020b39-r-2aedd343: invalid Instance Manager instance-manager-r-33e2295c, state: , IP: " node=node-1
time="2022-10-17T02:56:54Z" level=warning msg="Error syncing Longhorn replica longhorn-system/pvc-bdf1cf10-99f4-4a60-869f-68b79453d1b6-r-007cf816" controller=longhorn-replica error="failed to sync replica for longhorn-system/pvc-bdf1cf10-99f4-4a60-869f-68
b79453d1b6-r-007cf816: invalid Instance Manager instance-manager-r-33e2295c, state: , IP: " node=node-1
time="2022-10-17T02:56:54Z" level=warning msg="Error syncing Longhorn replica longhorn-system/pvc-fdb1cda6-090c-4389-be78-23913f020b39-r-2aedd343" controller=longhorn-replica error="failed to sync replica for longhorn-system/pvc-fdb1cda6-090c-4389-be78-23
913f020b39-r-2aedd343: invalid Instance Manager instance-manager-r-33e2295c, state: , IP: " node=node-1
E1017 02:56:54.695340       1 replica_controller.go:179] failed to sync replica for longhorn-system/pvc-fdb1cda6-090c-4389-be78-23913f020b39-r-2aedd343: invalid Instance Manager instance-manager-r-33e2295c, state: , IP:
time="2022-10-17T02:56:54Z" level=warning msg="Dropping Longhorn replica longhorn-system/pvc-fdb1cda6-090c-4389-be78-23913f020b39-r-2aedd343 out of the queue" controller=longhorn-replica error="failed to sync replica for longhorn-system/pvc-fdb1cda6-090c-
4389-be78-23913f020b39-r-2aedd343: invalid Instance Manager instance-manager-r-33e2295c, state: , IP: " node=node-1
E1017 02:56:54.695919       1 replica_controller.go:179] failed to sync replica for longhorn-system/pvc-bdf1cf10-99f4-4a60-869f-68b79453d1b6-r-007cf816: invalid Instance Manager instance-manager-r-33e2295c, state: , IP:
time="2022-10-17T02:56:54Z" level=warning msg="Dropping Longhorn replica longhorn-system/pvc-bdf1cf10-99f4-4a60-869f-68b79453d1b6-r-007cf816 out of the queue" controller=longhorn-replica error="failed to sync replica for longhorn-system/pvc-bdf1cf10-99f4-4a60-869f-68b79453d1b6-r-007cf816: invalid Instance Manager instance-manager-r-33e2295c, state: , IP: " node=node-1
...

The replica failed to sync and the state and the IP address info are gone. This might be related to the issue.
To Reproduce
Steps to reproduce the behavior (not always reproducible):

Prepare a 4-node Harvester cluster in v1.0.3 (with Longhorn v1.2.4)
Upgrade the cluster to master-head (with Longhorn v1.3.2)
The upgrade might be stuck waiting for the number of IM-r Pods to become 1 on a certain node

Note: I haven't tried deploying Longhorn without Harvester yet, don't know if that will also happen the same issue.
Expected behavior
There should be only new IM-r Pods existing (eventually) after an LH upgrade.
Log or Support bundle
longhorn-support-bundle_023cfbdf-eb2f-4ca5-b38b-f73236c0f7e8_2022-10-17T10-19-37Z.zip
Environment

Longhorn version: v1.2.4 (upgrade to v1.3.2)
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): Helm
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: RKE2 v1.22.12+rke2r1

Number of management node in the cluster: 3
Number of worker node in the cluster: 1

Node config

OS type and version:
CPU per node: 8 (first mgmt node) / 4 (remaining nodes)
Memory per node: 16GB (first mgmt node) / 8GB (remaining nodes)
Disk type(e.g. SSD/NVMe): SSD
Network bandwidth between the nodes:

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): KVM
Number of Longhorn volumes in the cluster: 6

Additional context
The Harvester support bundle is provided here if that helps.
supportbundle_ebe4b217-6355-4356-823a-f9e5f09e28b4_2022-10-17T15-48-16Z.zip

cc @shuo-wu @derekbit @PhanLe1010

The instance manager pods eventually get state & IP updated in the support bundle.
A weird observation is all new replicas of the volume  pvc-fdb1cda6-090c-4389-be78-23913f020b39 (pvc-fdb1cda6-090c-4389-be78-23913f020b39-r-6bfa3fb9, pvc-fdb1cda6-090c-4389-be78-23913f020b39-r-54f5cb14 , and pvc-fdb1cda6-090c-4389-be78-23913f020b39-r-2aedd343) have spec.desirestate: stopped . This prevent the volume from from being finish upgrading engine image. I am not sure why these replica has spec.desirestate: stopped . From the code, they should be set to running https://github.com/longhorn/longhorn-manager/blob/a9c9fe22395dd58a99e3d729a8d932daaa439eaf/controller/volume_controller.go#L3054-L3075
Oh looks like, we later stops the newly cloned replica here as the new IM pods have empty state at the beginning. Then when the IM pods has non empty state, we still don’t try to restart it.
So may be the reproduce step is trying to upgrade the volume when the default replica IM pod has empty Status.CurrentState
Yeah, looks like I triggered it:

Deploy Longhorn v1.3.1. Enable auto engine upgrade by setting Concurrent Automatic Engine Upgrade Per Node Limit to  > 0
Create a volume and attach it
Deploy longhornio/longhorn-engine:v1.3.2 and wait for it to be deployed. This step is to make sure to expose the race condition that Longhorn tries auto engine upgrade while the new default IM is still starting
Upgrade Longhorn to v1.3.2
Observe that Volume is stuck in upgrading forever

Workaround: Detach and reattach the problematic volumes

Verified that detaching and reattaching the problematic volumes in the original environment can get this over.
The problematic volume with the new engine image configured still remains with the old image after the upgrade:
node-2:~ # k -n longhorn-system get lhv pvc-fdb1cda6-090c-4389-be78-23913f020b39 -o jsonpath='{.spec.engineImage} {.status.currentImage}'
longhornio/longhorn-engine:v1.3.2 longhornio/longhorn-engine:v1.2.4

Detaching the volume by setting the workload replicas to 0:
node-2:~ # k -n cattle-monitoring-system edit deploy rancher-monitoring-grafana
deployment.apps/rancher-monitoring-grafana edited
node-2:~ # k -n longhorn-system get lhv pvc-fdb1cda6-090c-4389-be78-23913f020b39
NAME                                       STATE      ROBUSTNESS   SCHEDULED   SIZE       NODE   AGE
pvc-fdb1cda6-090c-4389-be78-23913f020b39   detached   unknown                  10485760          12d

Soon it'll become the new one, then change the workload replicas back.
node-2:~ # k -n longhorn-system get lhv pvc-fdb1cda6-090c-4389-be78-23913f020b39 -o jsonpath='{.spec.engineImage} {.status.currentImage}'
longhornio/longhorn-engine:v1.3.2 longhornio/longhorn-engine:v1.3.2

Thanks!

cc @longhorn/qa

@mantissahz Please remember update the above check-list comment.

This is a day 1 issue, so let's remove this from 1.2.6 because need some time for review.

Verified in longhorn master a0a641 with steps
Result Pass
Volume not stuck at upgrading when upgrade Longhorn from v1.3.2(Concurrent Automatic Engine Upgrade Per Node Limit > 0 and longhornio/longhorn-engine:master-head deployed) to master-head .


Example not working with installed coinbase app

I tried integrating this SDK to my application but whatever I tried, it never opened the confirmation screen with installed coinbase app. It always opened the website flow. I tried it with the example and it also doesn't work. Is this an issue with the SDK or coinbase app update?
Link to a video recording to better sum up what I'm talking about:
https://www.dropbox.com/s/lgx4tg1yruku8pj/ScreenRecording_12-03-2017 18%3A27.MP4

You need to add in your info.plist
LSApplicationQueriesSchemes -> Array<com.coinbase.oauth-authorize>


Convert Existing Mod to CSV

To facilitate processing of already-existing namelists, create a CLI mode that converts an existing mod to CSV file and allows it to be processed through the standard process.

Since I'm only planning on converting 2 existing external mods at this time, it'd be faster to just convert them to csv manually and run them through NMG.


Swift implementation

Hi!
I'm trying to implement the camera in Swift. So far I've been able to instantiate it, take a picture, and manipulate the resulting pic.
Where I'm running into trouble is with the functions in AVCaptureDevice+FastttCamera.m. I can't seem to get the syntax right to call these functions in Swift.
var myCam = FastttCamera()
if FastttCamera.isFlashAvailableForCameraDevice(myCam.cameraDevice){
    myCam.setCameraFlashMode(FastttCameraFlashMode.Off)
}

'FastttCamera' does not have a member named 'setCameraFlashMode'
I know I'm probably approaching this incorrectly but figured I'd ask for help since I'm stuck. If someone could take a quick look I'd really appreciate it.

Have you tried setting it using normal property dot syntax?
myCam.cameraFlashMode = FastttCameraFlashMode.Off
That should work.

Ah, it's a property not a method. I see. Thank you!


sheet_to_csv skips first blank line with blankrows: true option

sheet_to_csv skips the first blank line of a sheet, even with an explicit {blankrows: true} set.
Code sample:
  var ws = XLSX.utils.aoa_to_sheet([
    [  ,   ,    ,    ,   ,   ,   ],
    ["S", "h", "e", "e", "t", "J", "S"],
    [  ,   ,    ,    ,   ,   ,   ],
    [  1,   2,    ,    ,   5,   6,   7],
    [  2,   3,    ,    ,   6,   7,   8],
    [  3,   4,    ,    ,   7,   8,   9],
    [  4,   5,   6,   7,   8,   9,   0]
  ]);

  console.log(XLSX.utils.sheet_to_csv(ws, {blankrows: true}));

Result:
S,h,e,e,t,J,S
,,,,,,
1,2,,,5,6,7
2,3,,,6,7,8
3,4,,,7,8,9
4,5,6,7,8,9,0

Expected:
,,,,,,
S,h,e,e,t,J,S
,,,,,,
1,2,,,5,6,7
2,3,,,6,7,8
3,4,,,7,8,9
4,5,6,7,8,9,0

This is an aoa_to_sheet issue.  It will generate a sheet where the starting cell is A2 rather than A1.  See https://github.com/SheetJS/sheetjs/issues/2737 for more details on why the range is relevant.
The simplest fix is to pin the starting point to the origin in https://github.com/SheetJS/sheetjs/blob/master/bits/27_csfutils.js#L176 (we'll accept a PR):
  if(range.s.c < 10000000) {
    if(range.s.c > _C) range.s.c = _C;
    if(range.s.r > _R) range.s.r = _R;
    ws['!ref'] = encode_range(range);
  }

Is the issue still open? I would like to take it up if that is the case.

Is the issue still open? I would like to take it up if that is the case.

is it still open?

i will work on it

Has this issue been solved? I am seeing a PR request for a fix. If the issue has not been solved I would like to take it up.

"Hello, I have a solution for this issue. If it has not been solved yet, I would love to solve it."

by using  Array(7).fill('') as a blank row we can solve this issue

could you assign this issue to me? @pibi


acgan: Use Generator/Discriminator more closely resembling the ones from the referenced paper

This depends on PR https://github.com/fchollet/keras/pull/8452, and should be merged after it.
Generator:

Remove extra embedding layer.
Remove extra 1x1 convolutions.
Use transposed convolutions instead of NN upsample+conv (=conv with fractional slides). Note that this corresponds to the paper, but contrary to author's own later advice in Deconvolution and Checkerboard Artifacts. Still, I found that paper network works better on MNIST in this example.

Discriminator:

Use LeakyReLU slope 0.2, instead of default 0.3

These changes

made generated images more diverse (for example, thick and thin are on the same epoch, compare https://github.com/fchollet/keras/pull/8482#issuecomment-344401396 to https://github.com/fchollet/keras/pull/8409#issue-271565775)
Can tolerate harder soft_labels (all the way to 1.0 works without generator collapse, but the results are not as good as 0.9).
Reduced the number of trainable parameters in generator by 65% from 8,698,356 to 3,182,580.
Reduced training time per epoch by 50% from 90 sec to 45 sec on Titan X Maxwell.

Below, left image is generated, right image is actual MNIST dataset. In generated images, latent vector is the same per-row (see PR https://github.com/fchollet/keras/pull/8409)
Epoch 32:

Epoch 45:

Epoch 48:

@lukedeo if your time allows, could you check out this PR as well?

@fchollet Overall, this looks good and is a welcome change.
@ozabluda you mention that you remove the extra embedding, but I don't see it removed here... the embedding wasn't mentioned in the paper, but I found the hadamard-y interaction to be useful. Not sure what the intention was here.

This extra "embedding" was removed:
https://github.com/fchollet/keras/pull/8482/files#diff-dc5bc2fdbf2d3f3268e301900b75e68eL52
Actual Embedding:
https://github.com/fchollet/keras/pull/8482/files#diff-dc5bc2fdbf2d3f3268e301900b75e68eR76
and its Hadamard product (which is cool) are untouched:
https://github.com/fchollet/keras/pull/8482/files#diff-dc5bc2fdbf2d3f3268e301900b75e68eR79
Please note that this PR is on top of PR https://github.com/fchollet/keras/pull/8452

Ah ok I see, sure, that extra hidden rep is extraneous and makes it more in-line with the paper.
Re: #8452, how noticeable is the improvement in quality when the discriminator receives zero weight for the auxiliary task on generated samples? If we're going to go full paper reproduction mode, my thought is to go all the way. I could be fairly easily convinced though, as having the discriminator minimize classification accuracy on generated samples can lead to the generator not examining sections of the support where the the likelihood ratio approaches a flat posterior

A brief history:
Recently acgan example was broken - generating all-black images. The minimal first fix for it was to introduce soft real/fake labels, PR "acgan: Fix generator producing pure black images" https://github.com/fchollet/keras/pull/8383, see generated examples there. This fix was either mandatory for later fixes (to prevent all-black), or was producing batter results. So far, all further fixes made soft labels harder and harder, which is an evidence that those are good fixes).
Second fix was PR "acgan: don't train discriminator to produce class labels for generated images" https://github.com/fchollet/keras/pull/8452, see generated examples there for how much more diverse they are than before. See https://github.com/fchollet/keras/pull/8452#issuecomment-343249641 for alternatives, and https://github.com/fchollet/keras/pull/8452#issuecomment-343705650 for the history how it ended up in the paper and the justification of its removal from the example (initially I was also hesitant to remove it, see the second sentence here: https://github.com/fchollet/keras/pull/8452#issue-272669339). It's better to keep the discussion of that PR in that PR.
Third fix is this PR. It depends on second and first.

Several PRs were merged into this PR. See https://github.com/fchollet/keras/pull/8409#issuecomment-346877248

Review comments addressed.


Fixed #149

Fixed https://github.com/javascript-obfuscator/javascript-obfuscator/issues/149

Coverage increased (+0.0006%) to 98.139% when pulling b4de9e78f4e12a1de6e00ff4fd7396296130f78b on issue-149 into 70c78859c20cda5d2c530a5177ae57a2377ac8a3 on master.


fix http4s output encoding to UTF-8

Currently, in http4s server JsonEntities outputs String with default charset. This is a problem in my case, which is Windows OS in Japan with default charset of windows-31j (Shift-JIS). If I set environ variable JAVA_TOOL_OPTIONS to be '-Dfile.encoding=UTF8', output is encoded with UTF-8 as expected. However, if output is encoded properly without setting the environment variable, it would be better. The cause of this behavior seems to be encodeJsonResponse method of JsonEntities uses getBytes(), which encodes with default charset. By modifying it to getBytes("UTF-8"), it becomes to encode output with UTF-8 irrespective of default charset. I think the modified behavior is favorable because almost anyone expected Json strings are encoded with UTF-8. So, would you please consider incorporating thie modification to the library code?

You need to format the code by running scalafmt in sbt.


email confirmation

when confirme email , the completion not responding in django 2.0 python 3.6

Exception Value:
'bool' object is not callable

C:\Users\pelysee\dev\facescorte\src\userprofiles\signals.py in set_email_confirmed, line 26

Fixed. It was just a minor code update to make for Django 2. Thanks for reporting


In the browser plug-in, allow choosing where Open Crunchyroll points to

Assuming #5 can be fixed and the plugin doesn't lose it's purpose, it would be nice if a setting could be added to the plugin, which would allow me to choose which exactly CR page I want opened upon clicking Open Crunchyroll.
In my case, I always want to go to my queue instead of the front page, although its possible that some users will want to go straight to some show or elsewhere.

Hi,
you could fix this issue yourself, if you edit a little file in the extensions settings.

Open the folder of the extension. In my case it's at the following path:
C:\Users\adarkhero\AppData\Local\Google\Chrome\User Data\Profile 1\Extensions\agapeeilkibacbfeijlidlgppmjaaijn\2.2.2_0

Open the file popup.js with a text editor

On line 23, replace http://crunchyroll.com/videos/anime/ with https://www.crunchyroll.com/home/queue/

The next time, you click on the button, you should be redirected to your queue page. Just tried it myself, it seems to work fine.

Thanks for this, but I think it'd be nicer to have this from upstream :)
Unless you don't plan to develop the extension anymore...

The problem I have with that is that I have no way to update all users. The extension repo is down and it's taken down from the chrome webstore. Sure I could implement it and upload it somewhere but I wouldn't know who has the version then which would make debugging and support extremely difficult with everybody being on a different version. Furthermore is my time at the moment fairly limited.

Oh, I'm actually a Firefox user, and luckily the extension is still there.

I personally have nothing to do with the distribution on the firefox store

Oh, i see. OK then. :)

The extension repo is down

And.. didn't you like try to tell github there was an error?

GitHub can take repos on request down which circumvent access restrictions to restricted content, which my extension did

The DMCA notice just mentioned phony "copyrighted proprietary source code".


Create Roadmap so we can contribute effectively

Hi @Ignema ,
First of all thanks for your hard working and contributing an interesting project to open source community. 😄
I'am plannig to add some features to this project but i can't find a helpful document about roadmap.
If you can share with us, if you have one. Otherwise, we can list some features here, randomly, and pick up the most important ones.

Hello @ghWass93, thank you for taking interest in the project!
I initially didn't have a long-term roadmap when I first started the project. For the time being, I think the biggest steps forward are linking the frontend portion with the backend fully and then moving on to more architectural decisions concerning which features to add and which design elements to improve. I encourage you to list out as you mentioned the features that seem the most important to you and share them here and thank you once again!


(String)JToken vs JToken.ToString()

Except for #1241 there's a problem with the following code:
String js = "{ \"DateTime\": \"2017-03-07T17:26:40.352Z\" }";
var jo = JObject.Parse(js);
String ds1 = (String)jo["DateTime"];
String ds2 = jo["DateTime"].ToString();

ds1 is not equal to ds2 - while ds1 apparently has some english or american format, ds2 contains a localized version. I would expect that both values are equal.

I found the same issue, and I made a test to isolate it:
[Fact]
void Test_DateAsString()
{
    string str = "{ \"value\" : \"2008-12-28T00:00:00\"  }";
    var json = JObject.Parse(str);
    Assert.Equal("2008-12-28T00:00:00", json.Value<string>("date"));
}

Since I read value as a string value, it should return the exact string.

This is related to #904 right?

Yes, it seems so.


[Discussion] API to define loader hooks

Discussion
Purposes:

The solely purpose of this issue is to convey into a solid API for the 4 hooks used by loader.

Questions:

How to define hooks in loader objects?
How to customize/wrap/specialize existing hooks?

Hooks:

resolve
fetch
translate
instantiate.

The purpose of the hook system is to provides a hookable pipeline, to allow front-end packaging solutions  to hook into the loading process. E.g.: if a JavaScript program wants to translate .coffee files to JavaScript on the fly, the Loader defines a "translate" hook that can be used to get the coffee source code and transpile it into javascript before instantiation process.
note: each hook has its own signature, e.g.: fetch(key) vs translate(key, payload).
Current proposal:
// fetch hook:
// - getter
var fetchHook = loader.hook('fetch');
// - setter
loader.hook('fetch', function (key) {
    // do something here...
});

note: it is confusing. the hook concept is new, it looks like an observable, but it is not. No precedent on this kind of api AKAIK.
Simple Getter and Setters:
// fetch hook:
// - getter
var fetchHook = loader.fetch;
// - setter
loader.fetch = function (key) {
    // do something here...
});

note: the problem with this approach is that one of the hooks is called resolve, and one method of loader is also called resolve(), which is an important one.
Getter and Setters:
// fetch hook:
// - getter
var fetchHook = loader.fetchHook;
// - setter
loader.fetchHook = function (key) {
    // do something here...
});

note: the problem with this approach is that there is no precedent of the concept of hooks, it might be confusing, and on top of that it is ugly IMO.
Others

loader.onFetch() looks like an observable/event, which is not the case, only 1 hook can be in place.
loader.hookFetch same as loader.fetchHook.

I'm a fan of the Simple Getter and Setters approach as discussed in the subclassability issue because it will make it much easier to make custom loaders this way.

note: the problem with this approach is that one of the hooks is called resolve, and one method of loader is also called resolve(), which is an important one.

I don't think "resolve" is a good name for this hook, the proper name is "locate".  It's been discussed ad nauseum about the change from normalize/locate -> resolve, but "locate" is not what was deprecated. Normalize is what was deprecated.  Resolve is really just locate.  It's locate with the knowledge of the parent url.
tldr; I would change "resolve" to "locate".

A few thoughts (caveat: I know very little about how the API will work):

Subclassing can work well for this kind of thing: Each hook is a method, customizing/using a hook means overriding the method.
Subclassing does not work if you want to use the same hook multiple times. Then I’d use something event-based, because that’s what most web dev people are familiar with.

If there will only ever be a limited number of hooks then I would not provide a generic solution with strings as keys. For example, a variant of “current proposal” without generic keys is:
// Get
var fetchHook = loader.hookFetch();
// Set
loader.hookFetch(function (key) {
    // do something here...
});

Subclassing does not work if you want to use the same hook multiple times. Then I’d use something event-based, because that’s what most web dev people are familiar with.

Being able to call them as function is an important part of the hooks, so if they were events they would be far less useful.  One thing you do often when working on loader stuff is generate keys.  I want to be able to call resolve (or whatever it is to be called) so that I can get the key for a module.

I'd need some more background on the problems you're trying to solve and how this maps to those problems. Right now, I'm unsure of what I'm reading.

resolve
fetch
translate
instantiate

What do these do? And what are hooks?

@nzakas and co, let me provide more details:
The loader's "internal engine" will carry on some procedures to locate, fetch, parse and execute each module, this procedures are executed in a predictable order. But for the sake of aligning with EWM, we want to provide access to the "internal engine" of the loader, specifically, provide a mechanism to control and even alter those procedures in user-land, whether that's by using AOP or any other similar pattern.
As today, we have identified four stages during the internal life cycle that we will like to expose somehow, those are the one listed above. The question here is how to provide an API that is simple enough and powerful enough that allow users to tap into the internal procedures of the loader to add some extra functionalities for the loader.
Additionally, we want to have a single access point for each of this stages (a single hook), but users might decide to chain them (in user-land using AOP or something else) if they choose to.

Can you explain what each of those four stages do? It would be helpful for you to walk through an example, like:
import { foo } from "bar";

What would the process be to implement this?

This should probably use symbols, if we ever want to extend the pipeline in the future. Otherwise we may find authors squatting on names that are needed.
So loader[System.fetch] = ... maybe.

@domenic I like the idea of using symbols, but using them from System might be a problem since we will use them in Reflect.Loader class definition.
@nzakas let me try to use a real example:
<script>
// initialization of the app by executing `main.js`
System.loader.import('main.js');
</script>

As part of the internal process, loader will:

first, analyze main.js and the context in which it was imported (the referrer), in this case the referrer is the page itself (top level script using imperative API), as a result, main should be relative to base of the page (which is computed by browsers based on the <base> header or the current url). As a result, main will be expanded to https://mydomain.com/main.js (assuming the page was https://mydomain.com/) by default. Hooking into this resolution process might help users to define rules to avoid the need for .js in the module name, or resolve the URL to main differently.

second, once the URL for main.js is ready (from the previous step), the default fetch mechanism will be to issue a request (using fetch most likely), and wait for the result to arrive. Hooking into this fetching process might help users to define rules to fetch the actual code from different places, maybe from a local database, or using a worker, or any other alternative way of provision assets.

third, once the source code is ready (from the previous step), the default translate mechanism will do nothing by default. Hooking into translate process might help users to define new rules to transpile/transform the source code before executing it.

four, after getting the source code ready to be executed, the default execute mechanism will parse it, and execute it, producing a new Module exotic object. Hooking into execute process might help users to define a new rule to execute the source code, maybe setting up some variables before and after the code gets executed, maybe just executing the code in a different thread, or whatever crazy idea people will come up with.

In my mind, people will do a lot of AOP here to support various variations of modules and other assets that modules depends on, ideally that composition process for each hook is nice and easy.

Why be fancy? Wouldn’t the simplest solution be subclassing plus overriding methods? Your protocol looks like there will only ever be four methods, which is why you don’t need an approach that is very flexible w.r.t. names.
To avoid name clashes, you can give hook methods the name prefix hook: hookResolve, hookFetch, hookTranslate, hookInstantiate. I expect that only the loader spec will introduce new hooks and that the only challenge is to keep hook methods and loader methods from clashing(?)
However, loader base class methods and loader derived class methods may still clash, which is why non-public methods should use symbols as keys.

@rauschma right. the problem with that approach is the default loader instance implemented by browsers, which is available thru System.loader on every realm. In theory, most users will use that instance, and will have no need to create a new instance of it, instead they can just set up some new hooks into System.loader.

In theory, most users will use that instance, and will have no need to create a new instance of it, instead they can just set up some new hooks into System.loader.

The default instance should have a constructor as well. So you can extend it with:
class SuperLoader extends System.loader.constructor {
  fetch() {
    ...
  }
}

System.loader = new SuperLoader();

System.loader = new SuperLoader();

That last line is not clear yet @matthewp, essentially because we don't know yet how that affects the behavior of <script type="module"></script>. For now, we might go with the more restrictive approach where System.loader reference can't be changed.

Fair enough, so use wrapping if you want to override the default instance. You could still define the hooks in a class, create an instance and then wrap System.loader.
I personally would just tell my users to call myCustomLoader.import()... in terms of having portability for libraries that expect to be able to use System.loader, once we have the ability to do import loader from this.metadata or whatever the becomes it will mitigate the need to worry about the system loader too much.
One problem with the wrapping approach is that you really need a way to unwrap. I've run into this from time to time, you apply a hook (for testing purposes for example) and later want to remove the hook... it's much easier to simple create a new class and instantiate it for that purpose.

Ok, decision was to use symbols (thanks @domenic for the suggestion), two main reasons:

symbols for the hooks will signal that this is a very low level api.
with symbols there is not need to access the hooks via a getter when subclassing to access the internal slot.

We will stick to the same four hooks:

The basic usage will be:
var fetchHook = System.loader[Reflect.Loader.fetch];
System.loader[Reflect.Loader.fetch] = function (key) {
    // do something here...
};

More about this change here: https://github.com/whatwg/loader/pull/65

Playing devil’s advocate one last time:

I like the simplicity of of just modifying properties. It makes use of JavaScript’s flexibility and avoids the weight of some kind of registry pattern. There is only one caveat: two levels are conflated now – the level of the loader and the level of the hooks (with a registry, those levels are separate). I don’t think that will cause problems in practice, though.

On the other hand, if you use symbols you are keeping things flexible, possibly too flexible: Will there ever be more than 4 hooks? Will name clashes (= the use case for symbols) between hooks ever be an issue? Why not four properties where a name prefix prevents clashes with non-hooks: hookResolve, hookFetch, hookTranslate, hookInstantiate. That would be the simplest possible solution.

It’ll be interesting to see whether people chain hook functions (for the same hook). But doing so manually still seems better than supporting chaining via the API, e.g. via a special registry mechanism.


Color is not visible in light mode

i am using Minimal theme, but i guess it is not the main issue

It's quite visible for me with minimal in light mode with the default settings.  Perhaps you've changed something in the settings?  Your colors are quite different from the ones showing on my screen, both for quick-explorer and pane-relief.  Mine show a darker text font, your font is white.

It's quite visible for me with minimal in light mode with the default settings.  Perhaps you've changed something in the settings?  Your colors are quite different from the ones showing on my screen, both for quick-explorer and pane-relief.  Mine show a darker text font, your font is white.

It's quite visible for me with minimal in light mode with the default settings. Perhaps you've changed something in the settings? Your colors are quite different from the ones showing on my screen, both for quick-explorer and pane-relief. Mine show a darker text font, your font is white.

yes i changed some stuff in setting and added some css too, but i copied setting from other people and it was a longtime ago. do have any suggestion to where to look to fix this?
I also use Show current file path plugin which shows a similar thing in bottom windows bar and it has not problem:

I would check if there is an option to reset the defaults, and disable the CSS snippets.  I'd also look for any place where you've set a light font color.   You could also use the Chrome inspector functions to identify the exact CSS rule being used to set the color for those elements, and then find that rule in the CSS snippets or see what variable is being used to configure in the theme settings.