toward using C++/WinRT to develop iOS apps as part of “DLL all the things”

Islandwood's/WinObjC's wrapper of Objective-C runtime to .DLL & .winMD
First off, thank you immensely much for bringing C++/WinRT into existence.  Although C++/WinRT (and Modern-C++ before that) has done a beautiful job of making standard‡ C++ capable of elegantly writing UWP apps, it seems that C++/WinRT is on the verge of making something equally as miraculous possible:  making standard‡‡ C++ capable of elegantly writing native‡‡‡ iOS or MacOS apps (instead of Objective-C or Swift or the Objective-C graft-on within Objective-C++).
‡ instead of C++/CX
‡‡ instead of Objective-C++ and (most notably!) instead of C++/CX, as rajsesh indicated on 27 November 2017.
‡‡‡ For the remainder of this thread, let's define ObjCRT-native (i.e., Objective-C runtime native) as the way that Objective-C and Swift generally present their object files and libraries to iOS and MacOS, ignoring the finer points of Swift runtime differing from (or layer on) Objective-C runtime.  If the topic of Xamarin.iOS even arises herein, let's completely ignore the Mono+ObjCRT alternative (extrapolated) definition of “native” that Xamarin.iOS utilizes; herein let's redesignate that Xamarin.iOS flavor of “native” as called Mono+ObjC iOS apps (or if one insists on the word native: Mono-native iOS apps).  I somewhat doubt that Xamarin.iOS would even arise again in this thread, because, as apparently effectively indicated by Miguel de Icaza himself on 23 January 2018, Mono lacks the ability to participate in the .winMD world for the foreseeable future; hence the current way that C# and F# (but not C++/CX and Visual Basic) can develop via Xamarin.iOS atop Mono‡‡‡‡ can be ignored along this thread.  Hence the reason that I omitted C# and F# from the “instead of” list of languages capable of producing (ObjCRT-)native apps for iOS and MacOS.
‡‡‡‡ instead of preXamarin-Microsoft's .NET proper, ignoring .NET Core overlap of .NET proper with Mono
And now returning to C++/WinRT's 2nd potential miracle, earning it the de facto name C++/RT, taming not only WinRT but also ObjCRT:
It seems as though C++/WinRT is on the verge on making the following sequence of steps possible:

Have an existing Xcode project on a Mac.  Also, have the Windows SDK 17025 installed on a Windows 10 computer (e.g., slow-ring Windows 10 Insider Preview of 17025).
Import that Xcode project into VisualStudio 2017 running on Windows 10, as if one were going to author (in Visual Studio 2017 on Windows 10) a garden-variety C++ non-UI library supporting (as backend processing) a UI coded entirely in Swift or Objective-C on Xcode.
Pair Windows 10's Visual Studio 2017 with that Mac to somewhat seamlessly build & (push & pull &) execute that C++ library that is shared between Visual Studio on Windows 10 and Xcode on the Mac.
But instead of behaving ourselves to write merely some backend-processing library, we instead:
4.1) Copy each iOS (or MacOS for that matter) Objective-C runtime framework {Foundation, UIKit, (AppKit,) ...} over to Windows 10.
4.2) Invoke Islandwood's/WinObjC's objc2winmd tool to wrap the Objective-C runtime as a WinRT component, producing both .DLL† and .winMD for each Apple framework.
4.3) Invoke cppwinrt.exe to project the WinRT-componentized iOS (or MacOS) framework into C++/WinRT source.
4.4) Utilize the generated C++/WinRT-ized projection of each objc2winmd-ized Apple framework in our C++ library that is shared between Visual Studio 2017 on Windows 10 and Xcode on MacOS.
4.5) Assure that the generated .DLL†† is copied to Xcode to be packaged into the app.
4.6) From Swift or from Objective-C in Xcode-based source code, invoke at least one entry point in the C++ library that is shared between Xcode on Mac and Visual Studio 2017 on Windows 10.  Those invoked C++ member-functions then instantiate UI objects from Apple's Objective-C frameworks via the objc2winmd-ized .DLLs that were copied over.

† Oops, by default on Windows-10-based Visual Studio, this .DLL is likely produced as x86-64 ABI to be consumed on Windows 10—not as an ARM ABI to be consumed on Apple iDevices.  But then again WinObjC is open source and Clang/LLVM-based, so it is conceivable to coerce it to produce an ARM ABI for Apple iDevices and to produce an Intel ABI suitable for MacOS.  Perhaps this .DLL produced as x86-64 is less of an issue if the app in Xcode is for MacOS, which is Intel-based nowadays (instead of PowerPC).
†† in an ARM ABI for Apple iDevices for iOS apps; in an Intel ABI for MacOS apps
It seems that
a) the lack of some VSIX smoothness
and
b) perhaps the ABI in which the objc2winmd .DLL is generated to target
and
c) copyright/licensing restrictions regarding copying Apple's Objective-C runtime frameworks and .winMD/.DLL derivative-works thereof
are the 3 weakest links in the chain.  Where can I learn more (especially from Microsoft itself) about utilizing C++/CX for iOS development in order to then in turn determine the feasibility of C++/WinRT for iOS development?

From https://docs.microsoft.com/en-us/cpp/cppcx/visual-c-language-reference-c-cx

C++/CX is a set of extensions to the C++ language that enable the creation of Windows apps and Windows Runtime components in an idiom that is as close as possible to modern C++.

You can't use C++/CX for iOS development.

@devhawk, I am expecting a deep reading of my issue above, not a shallow reading.  Of course, the party line until now is that C++/CX has been focused on UWP, not iOS.  We all know that for multiple years.  But it appears that well-memorized old party-line positions might be starting to erode & crumble due to rather recent 2017 releases of open-source tools such as WinObjC and its objc2winmd.
To my point, the 15 September 2017 date on the C++/CX webpage that you provided predates by 2 months the 27 November 2017 date that rajsesh indicated in a reply to WinObjC GitHub issue #20 that WinObjC's objc2winmd would permit C++/CX to access Objective-C runtime's types (presumably as part of porting Objective-C code from iOS to UWP, not the opposite direction that my issue above is driving the topic).  WinObjC is Clang/LLVM-based, so presumably it conceivably still retains its ability to target its DLLs/ELFs toward an ARM ABI that is suitable for iOS (and an Intel ABI that is suitable for MacOS), as .app, .so, or .dylib just as Clang normally does for iOS and MacOS.  DLL all the things.

@devhawk, btw, based on some of Kenny Kerr's public comments about your innovative boundary-pushing experimentation with C++/WinRT, you were the one & only person on the planet who I thought might have conceived of all of my issue above ahead of me.

I'm on this thread because Kenny pointed it out to me. :)

I'm pretty sure that clang doesn't support C++/CX. So if you built a WinRT component in ObjC via the objc2winmd tool, you wouldn't be able to access it on iOS from C++/CX.

@devhawk, let's not fixate on the “C++/CX for iOS” botched wording of what I meant:  “Where can I learn more (especially from Microsoft itself) about how C++/CX is utilized to port formerly iOS-based source code to UWP as well as any ancillary/tangential capabilities that WinObjC has in addition to that use-case?”  As I have said twice before, I am not really interested in using C++/CX for doing iOS development.  Any interest in C++/CX that I have herein related to WinObjC is learn from whatever pieces of the puzzle that they have for the iOS→UWP direction that can be repurposed in the opposite direction, using the .winMD and whatever LLVM-based Objective-C-runtime library-building capabilities still exist within WinObjC.  Obviously rajsesh's reply and alovchin91's original posting are both implicitly discussing porting an iOS app to UWP.  Conversely, the WinObjC and objc2winmd portions of that use-case appear to have at least a latent amount of the Clang/LLVM and iOS-related capabilities to utilize C++/WinRT the other direction‡ (without C++/CX ever entering the conversation at all in the objc2winmd→C++/WinRT→Xcode→iOS[-Xamarin.iOS-esque] direction).
‡ if WinObjC's LLVM backend can still generate the customary LLVM-centric library formats for iOS-suitable ARM ABI and MacOS-suitable x86-64 ABI.  If so, then can it generate those Apple-esque libraries in objc2winmd mode instead of WinRT-component .DLL?
I will be opening mirror-image issues over at WinObjC tomorrow.

I was addressing the question of C++/CX because that was the question you asked in the original post. I don't quite understand why you are interested in it. I'm pretty sure it has no role in the WinObjC story beyond "can consume WinRT Components implemented with objc2winmd".
I would think the files generated by cppwinrt would be more interesting for you to look at. In particular, you'll notice in base.h that there are clang specific compiler directives. However, that is clang on windows. While cppwinrt is iso standard c++, there are a variety of windows dependencies which would keep it from working on other platforms.

@devhawk, I jammed in that final question at the end of the original issue above simply because I had written a substantial issue, but had never asked a question.  I jammed in whatever perfunctory open-ended question came to mind—hence why the final question wasn't worded as tightly as the rest of the issue.  The focus of the issue is every word other than the last sentence.  The final question is there only because it seems odd to post an issue without asking a question or reporting an extant bug.  I guess I could have jammed in “Please critique each step above regarding its feasibility, as well as point out additional investigative lines of reasoning to support this use-case.”
I am not expecting everything to work straight from Microsoft today.  Yes, I am assuming that there are some Windows dependencies that would need to be edited out from the files generated by cppwinrt.exe.  These dependencies would be replaced by Apple-framework dependencies‡ instead, such as via an AST-based Clang source-code transformer.
‡ or better yet: replaced by dependencies on iOS-/MacOS-consumable libraries output by a modified winmd2objc in Islandwood/WinObjC, where those libraries in turn are what depends on Apple frameworks, because the API façade of those libraries mimics the API façade of WinRT-component DLLs.  This would keep the DLL-centric architecture of C++/ObjCRT analogous to the DLL-centric architecture of C++/WinRT.  DLL all the things.
I am assuming some source-code modification of Islandwood's/WinObjC's winmd2objc and of perhaps objc2winmd too, so that they have command-line options to generate libraries whose ABI is consumable on iOS and on MacOS instead of .DLLs consumable on UWP.
What I am doing is gap analysis to see how many and how big the gaps are, to then determine feasibility.

Sorry, I have a hard time following your writing style with all the footnotes. That's why I simplified and answered the one question you asked.
I'm not 100% clear exactly what you are attempting to do - so it's hard to judge it's feasibility or help you with a gap analysis. I think you want to be able to write an app in standard C++ that you can cross compile for iOS and Windows. On the surface, that sounds pretty infeasible. However, since WinObjC has implemented many Apple frameworks on Windows and has a tool that purports to wrap ObjC frameworks in WinRT, it may be more feasible that it looks on the surface.
It does seem like a lot of effort to go thru if your goal is to write your app in C++ instead of ObjC. Especially since I don't think this approach will work on Android. I'm not aware of any java / winrt tooling (in either direction) and I'm not aware of any ports of Apple frameworks to Java similar to WinObjC's ports of those frameworks to Windows.

@devhawk, for now what I want to do is demonstrate the concept of a C++/RT family of C++/WinRT-inspired SDK projections into standard C++ that extrapolates the same app-domain-facing meta-class surface that C++/WinRT presents to app-domain source code for the Windows SDK so that:

C++/AndroidRT presents a very C++/WinRT-eqsue meta-class personality for the Android SDK to an app's source code
C++/ObjCRT presents a very C++/WinRT-eqsue meta-class personality for Apple's Objective-C frameworks for iOS and for MacOS to an app's source code
and then the grand finale:  to an app's source code, C++/UniRT would present a very C++/WinRT-esque meta-class personality for a trans-OS UI API inspired by Xamarin.Forms in concept but for C++/RT instead and drastically relaxing Xamarin.Forms' harsh restrictions on absolutely no layout (e.g., no dynamically-appearing activity-indicator spinner) during lengthy Xamarin.Forms-internal redraw walks of the view tree.  I also detest having substantially-different variants of ReactiveX libraries for each of C#/C++/F# (those 3 are substantially the same) versus Swift versus Kotlin/Java (those 2 are substantially the same).  I also detest the harsh impedance mismatch between C# for UIs and C++ for high-performance backend processing, even with (mostly one-way) CppSharp.  I am tired of cobbling everything together on non-Microsoft OSes with mylar tape and bobby-pins; I want everything much more Microsoft-ized via C++/WinRT's and ReactiveX's obviously-very-wise leadership.

As I mentioned over on the sibling Android-related issue #331, I am now thinking that Mono's Embeddinator-4000 might be the most expedient cppwinrt.exe-like thingy to demonstrate such a C++/RT for app development for UWP's, iOS's, MacOS's, and Android's respective SDKs as based on WinRT components for UWP via C++/WinRT and based on Xamarin.iOS, Xamarin.MacOS, and Xamarin.Android (Mono-).NET assemblies.  This will incur the Xamarin/Mono overhead for now, but eventually bypassing Xamarin/Mono in each runtime to perhaps increase performance is something for future study after the initial proof of concept.

Embeddinator-4000's C++ support that is indicated in its command-line help-text ends immediately with a not-yet-implemented exception when invoked.

It would take a lot to convince me that a C++ based "trans-OS" solution would be any better than the existing tools out there like Xamarin.Forms or Cordova. Sure, it would be C++ instead of C# or JS. But the issues I typically have with such tools have little to do with language and everything to do how much harder it is to abstract away platform differences the closer you get to the user.
Instead of trying to abstract the entirety of the iOS or Android runtimes, have you considered a smaller scope proof of concept?

Of course.  The would-be C++/OverRT‡ is what you are mentioning there—the analogue of Xamarin.Forms, but designed differently to be less like a cattle chute, and more like a bag of tools.  Of course, C++/OverRT is not the •initial• proof of concept (any more than Xamarin.Forms was not the first step for Xamarin either).  C++/ObjCRT might be the easiest 1st proof of concept, because the Objective-C runtimes in Apple OSes encodes a fairly rich amount of parameter names, analogous to .winMD in Microsoft OSes (or should I say, the various editions of a single OS: Windows 10).  So the order might best be:  C++/ObjCRT, then C++/AndroidRT, then insert whichever other OS Xamarin/Mono fully supports by that date here (e.g., Google FusciaOS, Samsung Tizen), then and only then C++/OverRT.
‡ renamed from C++/UniRT, because uni- too easily evokes Unix, even though historically the uni- of Unix actually is the Latin root uni- and its meaning of single/one/unified that was intentionally overtly criticizing the multi- at the heart of the Multics name.  Multics was an OS that had multiples in places where Unix had singletons in 1970:  threads per process (multiple for Multics; singleton for Unix), executable segments per process (multiple snapped DLLs for Multics; singleton text-segment for Unix), entry points per executable segment (multiple entry-point subroutines per DLL segment; single main() for Unix),  and so forth.  For modern people below a certain (retirement-)age, much of the Latin root uni- at the heart of the Unix name has been forgotten.  Hence, not C++/UniRT.  How about C++/panRT using the Latin root pan- to evoke “across”?  Good Latin, but bad choice due to "to pan" in English is a verb that means to bash or give a bad review.  How about C++/überRT using the German prefix über-?  Good core spatial meaning, good German language, but bad at evoking some “über alles” memories of the past; also bad at evoking the competitor of Lyft too easily.  So translate über- to English:  C++/OverRT, a portable C++ library over all the runtimes‡‡ of various OSes.
‡‡ especially the •UI• runtimes of various OSes
Regarding your “take a lot of convincing“, the reason to enact C++/ObjCRT‡‡‡ and C++/AndroidRT‡‡‡ is the same for C++/WinRT:  to eliminate the so-called impedance-mismatch between the managed portion of a .NET app and the processor-native portion of that same app.  The motivation for C++/ObjCRT is 100% congruent to the motivation for C++/WinRT on every aspect.  Each reason for C++/WinRT to exist has an analogous reason for C++/ObjCRT to exist.  Please try to prove me wrong by trying to find a reason for C++/WinRT to exist on Microsoft OSes that is totally absent without any analogue in a C++/ObjCRT on Apple OSes.  I am fairly certain that I can construe a rather direct conceptual analogue on a C++/ObjCRT for a purported reason for C++/WinRT to exist that is truly unique to Microsoft OSes.  The more that one constructs a line of reasoning for a C++/ObjCRT to not exist, the more one constructs much the same line of reasoning (translating from Apple-centric concepts to Microsoft-centric concepts) for C++/WinRT to not exist, and the converse:  every reason for C++/WinRT to exist on Microsoft OSes begets a transliteration to Apple OSes for a C++/ObjCRT to exist.  Or in fewer words in C++ syntax
class ReasonsForCppObjCRTbypassingMonoAndXamarinToExist : public ReasonsForCppWinRTtoExist
{
// ... snip all sorts of conceptual polymorphic overrides ...
}

‡‡‡ that eventually does not depend on invoking runtime functionality via Xamarin.iOS/Xamarin.Mac and Xamarin.Android respectively.  Initially in the proof of concept, perhaps it would be expedient to incur the overhead of Mono & Xamarin to show the proof of concept, then (at the 2.0 rewrite) bypass invocation through Mono & Xamarin when invoking the OSes runtime.  That bypass of Xamarin.iOS/Xamarin.Mac & Xamarin.Android is the step that would bring the hope of C++ achieving processor-native level of performance that could compete directly head-to-head speedwise with Objective-C on iOS & on MacOS with the Swift efficiencies of compile-time elimination of Objective-C's run-time selector look-up and caching thereof.  Hence, C++/ObjCRT could conceivably out-perform both Objective-C and Swift on Apple OSes via removing the speed-robbing language-design/features of each of Objective-C & Swift.
Conversely, the reasons for C++/AndroidRT(2.0-bypassing-Xamarin.Android) to exist seems to hang its hat on only a single nail:  reducing the so-called impedance mismatch of an app's UI code and an app's backend-processing libraries (by moving the unfortunately-required JVM-based impedance mismatch out of app-domain source code into a library/framework/infrastructural guts hidden from the app-domain source code).

Of course there are "transliterated analogues" for a technology like WinRT to exist on other platforms. But that doesn't make it easy or feasible. Both iOS and Android have settled on a language strategy of only supporting a small set of "platform native" languages - ObjC & Swift on iOS, Java & Kotlin on Android - without appearing to give much thought or care to supporting languages beyond that. Both platforms support C++, but as what seems like a second class citizen. Workaround exist of course, but without the platform vendor's involvement, the amount of work to expose the existing platform APIs to C++ seems like a huge amount of work.
Even if Apple and Google decided they wanted to treat C++ as a first class citizen on their respective platforms - and decided to use WinRT style technology to get there - that wouldn't get you any closer to an "uber" API for mobile apps as you describe. You'd end up with something like the Xamarin ecosystem - build your business logic in a component that can be shared across your mobile apps and build separate per-platform apps. Maybe a Xamarin.Forms-style framework would emerge, but it would have the same issues that Xamarin.Forms has - it wouldn't be able to expose the power of each underlying platform, leaving developers to either target a lowest common denominator or write a lot of platform specific code in their so-called "uber" mobile app.
I hope you understand that I'm sympathetic to some of what you're writing about. I just want to see any "boundary pushing" effort scoped down to be achievable.

I would say that C# is •the• one & only 2nd-class citizen on Android and on iOS & MacOS via Xamarin/Mono.  I would say that C++ is less than a 2nd-class citizen.  Without stepping on too many political toes in the currently-immigration-charged environment, it is as though C++ is a green-card resident immigrant (noncitizen), even lower in the pecking-order totem pole than C# via Xamarin/Mono/.NETcore.  What I am advocating is that C++ get up to 2nd-class citizen status with C# on Android and iOS.
(And I won't hardly mention much of RemObjects efforts to provide all of {Java, C#, Swift, Object Pascal} across all of {UWP, iOS, MacOS, Android JVM, Android Native, desktop JVM}.  RemObjects' approach is to meld all the open-source compilers of those languages into one superdooper compiler that shares some sort of AST unification among the languages, permitting each language to deeply map its feature-set into each of the other languages.  RemObjects' approach is not really at outward-facing language projection in the C++/WinRT sense or the Embeddinator-4000 sense.  RemObjects' approach is more inward-facing within the compiler.  The RemObjects approach is uninteresting so far for this GitHub-issue because thus far RemObjects has shown no interest in bringing Clang into the Elements confederation of compilers that share each other's guts with the other languages.)

I don't want to argue language citizenship status, but I will agree that C++ doesn't have access to significant parts of the iOS and Android platforms.
However, I don't see the value in investing to get C++ to the same level of platform access that Xamarin has. It would be an enormous amount of work to replicate what Xamarin has done over the past 13 years. More importantly, Xamarin already exists.
C# is a great language for building apps. It's productive and performant. There's no question C++ is more powerful and really has closed much of the productivity gap relative to C#. But it's also more finicky and verbose. I don't think C# a good choice for system development - but not because of any issue with the language but rather because I don't believe non-deterministic garbage collection is a reasonable foundation to build a system on.
Let me ask you a couple questions:

What are the problems you have with Xamarin, in particular Xamarin Forms?
What about your proposed "uber" C++ RT solution would solve those issues?

I think that the iOS bar charts in this WWWpage are very revealing:

Objective-C selector look-up & caching is less performant than compile-time-generated vtables.
In some scenarios, Objective-C's selector look-up & caching dominates, but in others Xamarin.iOS's Mono ‘dual-stack’ overhead dominates.  C++/ObjC 1.0 would eliminate Objective-C's selector look-up & caching, which is Swift's main performance-gain claim-to-fame too.  C++/ObjC 2.0 would eliminate Xamarin.iOS's Mono dual-stack overhead.
Despite Apple's general claim that Swift is 40% faster than Objective-C, there exists a chronic set of symptoms perennially popping up here & there like Whack-a-Mole that Objective-C is actually faster than Swift, even in recent Swift in 2017.  Perhaps Swift's LLVM-backend optimization developers can hardly keep up with Swift's front-end feature-set developers (or something similar to that situation), which would correct itself over time if an app refrained from utilizing new Swift language features to stop being on any bleeding edge.  (Conversely, how many LLVM-backend optimizations recognize only the Swift idiom to optimize but fail to recognize the directly-analogous Objective-C idiom to optimize?  As Swift gets more optimized, some substantially-similar Objective-C idioms might be benefiting too, improving Objective-C's performance, so perhaps occasionally no net gain for Swift vis a vis any other Clang-based language, such as Objective-C or even perhaps a C++/ObjC.)  But the jury is still out whether Swift's chronic 4-year-running not-quite-perfectly-impressive performance is due to transient issues in releases of Swift due to all the feature-set churn, or whether it is due to something more fundamental & quasi-permanent.

The problems that I have with Xamarin.Forms is fundamental to its rendering phase:  no ability (even for Xamarin itself) to have any variant of an activity-indicator spinner while rendering complex UI layout that take too long.  StackOverflow and Xamarin forums have a multitude of requests to solve this problem specifically of how to display such an activity-indicator.  Solutions exist only for when the lengthy operation is •not• a Xamarin.Forms-internal walk of the view-tree, such as a database retrieval or a network communication.
The problems that I have in general with Xamarin.Forms is its sluggish performance of its rendering.  Numerous Xamarin.Forms forum postings and numerous Xamarin WWWpages discuss ways of performing variants of loop-optimization to get app-domain operations out of Xamarin rendering walk of the view-tree.  But this does not improve the internal sluggishness of Xamarin.Forms itself.  This does not mitigate in any way the aforementioned ability to help bail out the embarrassment by putting up an activity-indicator when the app developer knows that the triggered rendering is complex enough to cause annoying-to-human-users-of-the-app latency.  From human user touch on the device all the way to custom-rendering a rectangle, there is really no meaningful way for the app source code to do anything but serve the Xamarin.Forms rendering operations as servant and wait for the benevolent dictator to finish its seemingly leisurely stroll throughout the entire grounds of his vast estate.  And this is on UWP and iOS.  Performance matters are far far worse on Android because of the additional higher overhead penalty of the big thick Mono stack outside the JVM JNIing the big thick Java stack inside the JVM.
I consider the primary architectural flaw of Xamarin.Forms to be the relegation of accessing the underlying SDK only during actual redraw after walk of the tree of Xamarin.Forms views.  The underlying SDK's objects should be available by drill-down during the walk of the tree of Xamarin.Forms views, not postponed until after the entire walk, quarantining accessing the underlying SDK's objects only during redraw by a custom renderer.  The architecture should permit a shared responsibility between the Xamarin.Forms-esque infrastructure and the app source code, so that the the app source code can get involved with the walk of the view-tree and tweak it, interact with it, bail out its embarrassing performance with at least displaying an activity-indicator, and even optimize it.  The current Xamarin.Forms architecture is very much handoff-handback, as if throwing a gigantic red electrical switch (or railroad switch) between mine/app versus yours/Xamarin.Forms.    Not only is the X not public in the X-prime, X is not private within X-prime either.  Xamarin.Forms models the X as not even existing/mapped to the X-prime until rendering.  X is an astronomical secret to X-prime until the final step of rendering.  Total full divorce between the X and the X-prime.  It is as though 2 spouses are married but are kept entirely away from each other most of the time, only to see each other when conceiving offspring, and then immediately imprisoned away again from each other separately until the next rendering of offspring.  I spend 90% of my time fighting Xamarin.Forms' architecture, bailing out Xamarin.Forms performance, and extending abandoned open-source extensions of Xamarin.Forms that try to teach it to interesting/nontrivial UI/UX tricks.  (Other than for apps that are literally nothing more than the provided example apps,) I gave up on Xamarin.Forms; developing an analogous UI for the same app 4 times in Xamarin.iOS, Xamarin.Mac, Xamarin.Android, and UWP.NET is so much faster than fighting Xamarin.Forms.
But then I regret  that I am expending 4 repeats of effort to get less-than-Swift, less-than-Objective-C, less-than-Android, less-than-Kotlin, less-than-C++/WinRT performance via Mono's C# stack, so then I forego Xamarin.iOS, Xamarin.Mac, Xamarin.Android, C#.NET, and thus C# altogether, writing the 4 repeats of UI with substantially similar UX in Swift on iOS, Swift on Mac, Kotlin on JVM, and C++/WinRT on UWP, with C++ backend processing as much as possible as “business logic”.  But then I run into the needless gratuitous variance among each of those language's different ports of the ReactiveX library {RxKotlin, RxSwift, RxCpp}, which disrupts/erodes some of the ability to write substantially the same verbatim app with the same C++ backend libraries with the not-quite-the-same ReactiveX framework.  One would hope that the 4 intended-to-be-verbatim apps would differ in only SDK and minor language features & nits (plus menus/window-frames on nonmobile devices versus the lack thereof on mobile devices), but in practice the 4 apps' source code diverges vastly more than I would like it to.
Having C++/WinRT, C++/AndroidRT, C++/ObjCRT, and RxCpp (and porting RxCocoa & RxAndroid to be RxCpp-based, if I must) would solve in the long-run most of my performance challenges, would solve prior to that all of my 4-app source-code divergence challenges, would solve the impedance-mismatch between C++ backend-processing libraries and each different UI/UX language & runtime.  And, btw, that is typically 3 different OO-high-fidelity‡ solutions for the impedance mismatch:  C++-versus-Kotlin, C++-versus-Swift, and C++-versus-C# (if using C# for UWP instead of C++/WinRT or C++/CX), which causes further divergence among the intended-to-be-but-fails-to-be-verbatim 4 apps.  Oh, and it will soon be 5 apps, once Tizen devices start showing up in large numbers in industrialized nations.
‡ not C nonOO, not SWIG

Sorry, I know very little about UI frameworks. So your fairly deep description of Xamarin's architecture and the problems you're seeing is lost on me. I'm absolutely sure the issues you describe are real. I'm also pretty sure that the issues you describe are intrinsic to abstracting something as complex as the primary UI framework on three separate platforms, each of which targets a separate programming language.
I seriously doubt that switching to C++ will solve that problem.
Any chance you have a code example of this scenario you describe: "writing the 4 repeats of UI with substantially similar UX in Swift on iOS, Swift on Mac, Kotlin on JVM, and C++/WinRT on UWP, with C++ backend processing as much as possible as so-called “business logic”.". I'd love to see how you're connecting Swift and Kotlin to C++ via Rx.

Well, using Rx across the UI-to-backend boundary is the stretch-goal for a C++/RT-family language projection, so that is not current technology.
But minus Rx, I use Djinni to generate Java and Objective-C with Swift bridge.

And then you use Rx to connect the UI to the bridged C++ code?

WinRT doesn't define IObserver/IObservable unfortunately.

Is there a VIPER based cross-platform UI framework?

I am not working on an open-source app.  My company's work is closed-source.  It does not take very much imagination; the outcome of VIPER is fairly direct:  In the VIPER architecture, all VIPER classes other than the VIPER Views are eligible (and encouraged) to be cross-platform.  The VIPER Views of an app quarantine the OS's/SDK's UI proprietaryness, whereas VIPER Presenters free the UX to be cross-platform at the “uber” level, to use our earlier term.    Within the VIPER Presenters (and the Routers, when considering what navigation & dependency injection provides in MVVM), every app developer develops that app's own perspective on what cross-platform UX constructs & behaviors look like, separate from a specific OS's/SDK's UI.  Indeed, to the point of this original issue and subsequent discussion, the VIPER Presenters & Routers (and of course obviously the Interactors and Entities) can be thought of as a backend-processing library, written in standard C++, leaving only the VIPER Views written in OS-/SDK-specific languages & runtimes & frameworks as Java, C#, F#, C++/CX, C++/WinRT, WinRT components, .NET, Objective-C, Swift, Kotlin, Mono, JVM, and so forth.  Once cross-platform UX design is coded in portable C++ in the future, then the natural goal is to have the OS's/SDK's nonportable UI be coded in •nonportable• C++ code specific to that SDK.  And then once we were have that in the future, the the next goal in the future is take the cycles of learning from the modest amount of abstraction in all the plethora of Presenters harvested from many apps to arrive at a Xamarin.Forms-esque portable C++ replacement for the vast majority of the VIPER Views of interOS-/interSDK-(onto‡-)mappable UI constructs & behaviors, leaving only the one-off unique-capability UIs peculiar to only one OS/SDK as the remaining few nonportable-C++ classes in the VIPER Views.  But because this factoring was arrived at via VIPER architecture instead of MVVM architecture, the similarities between Xamarin.Forms and this portable-C++-UI replacement of previously-nonportable-C++ VIPER Views are in the conceptual domain of goals & missions‡‡, not at the blow-by-blow detailed analysis of their technical guts of how those missions & goals are accomplished.
‡ not necessarily one-to-one
‡‡ e.g., display a master-detail drill-down-tree; display a carousel of photos; display a pull-down refreshable newsfeed; display a swipe-right/swipe-left list

So if you own the app, why not do exactly what you suggest but use C# instead of C++? Wouldn't the process and outcome be basically the same?

Define C# interfaces for each of your views
Build the non-view components of your app in C# against the .NET Standard specification
Build the view components of your app in C# using Xamarin.iOS, Xamarin.Android and UWP
Over time, harvest common view patterns into common shared implementations and publish them as an alternative to Xamarin.Forms

Also, this sentence totally threw me:

Once cross-platform UX design is coded in portable C++ in today's VIPER approach, then the natural goal in the future is to have the OS's/SDK's nonportable UI be coded in •nonportable• C++ code specific to that SDK.

I don't understand this approach at all. Building a good + portable UI framework abstraction is the hard part. (By "hard" I mean "probably not even possible". I don't agree that using the VIPER software architecture in any way "refutes that claim".) Why would you spend the time and effort to build a portable UI framework if your "natural goal" is to build non-portable UI.
Even if you were hell bent for leather to use C++, wouldn't it be easier to just build C++ bindings for platform native UI components on iOS and Android? (Windows already has them.) I mean, even though we clearly disagree about the level of difficulty in building a good + portable UI abstraction framework, clearly it would be easier to not build it right,?

@devhawk, in response to my pointing out the severe architectural defect of X-prime having only an extremely-transient relation with X (where X-prime doesn't merely hide its X private:ly, but rather X is kept secret & separate from X-prime) only during rendering, you wrote “I'm also pretty sure that the issues you describe are intrinsic to abstracting something as complex as the primary UI framework on three separate platforms …”.  The VIPER architecture's “owns and sends user actions” relation clearly is an overt direct refutation of your (and Xamarin.Forms designers') claim that X must be kept secret & separate from X-prime except for a transient temporary conjugal visit during rendering.  X-prime here stands for each Xamarin.Forms' cross-platform-abstracted UI view, but also X-prime is analogous to each VIPER Presenter.  X here stands for source code in Xamarin.Forms' renderers that itself invokes each nonportable OS/SDK UI element, but also X is analogous to each VIPER View.  Clearly, VIPER does not keep X locked up in some far away secretive castle dungeon most of the time, except for occasional conjugal visits during rendering, but Xamarin.Forms does.  Clearly, each VIPER View and its corresponding VIPER Presenter have a never-severed reciprocal pair of “owns and sends user actions” and “updates” relations that arguably Xamarin.Forms completely lacks in the static/permanent sense (or should I say, exists extremely transiently as something unseemly only during the conjugal visits during rendering).  Clearly, this is a black & white, day & night difference that I am exposing.  Clearly, VIPER has something useful (to the VIPER way) that Xamarin.Forms lacks.  It is a difference that makes a difference.  The Xamarin.Forms lack thereof is not inherent to the problemspace, as you claim.  The very fact that VIPER has something that Xamarin.Forms lacks proves that the lack (which you claim is intrinsic to the problemspace, and thus part of all solutions) is not dictated by the gods of fate & reality & reason.  There does exist another way that is quite different, which VIPER clearly reveals.

@devhawk, regarding “use C# instead of C++”, I would say that the answer is the same as “why not just forget about C++/WinRT and use C# instead?”  A case in point is that utilizing C++ for backend-processing libraries and C# for the UI/UX means that the impedance mismatch of the C++/C# boundary erupts into app-domain source code as handcrafted work-around, whereas in the aforementioned C++/RT-family approach, the C++/runtime boundary is buried within automatically-generated infrastructure instead of app-domain source code.  Because the C++/C# boundary lacks a rich set of aware-of-both-sides refactoring or aspect-oriented tooling, tweaking the C++/C# boundary for performance or design reasons is forever a laborious manual effort extending across the entire façade.  Conversely, because the Win/RT-family approach would be code-generator-based (e.g., analogous to today's wincpprt.exe), the C++/runtime boundary can be tweaked for any reason (e.g., performance, semantics, new language features) as easily as it is to write a little bit of new code in the code generator, then invoke msbuild or make.

I'm no expert in building user experiences. My experiments with Xamarin.Forms haven't made it past the "Hello World" level and I'd never heard of VIPER before you mentioned it. I don't even understand why you conflate Xamarin.Forms and VIPER - one is a software architecture and one is a software library, so it feels to me that you are comparing apples and oranges. If you can show me some actual code to demonstrate your opinions about VIPER, I'll be happy to take a look.
As for C++/C# - an area where I have much more experience - it comes down to app ownership. Remember, I said, "So if you own the app, why not do exactly what you suggest but use C# instead of C++?" In the Windows platform, by definition, we never "own the app". In the Windows platform, we want to meet developers where they are most comfortable using the tools and languages that they want to use. Likewise, we want the same thing for Project "Rome", which is why we ship SDKs for Windows, iOS, Android, and Xamarin.

Not to be too blunt, but I (and quite a few other C++ developers) want to use C++ everywhere, not C# everywhere, not C++/CX on only UWP, and even not C++/WinRT on only Windows components.  I would like to think that we C++ developers who think this way are part of the they of which you speak, as being most comfortable and preferring certain language's natural characteristics & overheads (or lack thereof).  Project Rome is most excellent at providing a hand-off SDK among disparate OSes.  Thank you, everyone at Microsoft who make Project Rome possible!  What I envision for C++/RX would be pointed at the one of the iOS, Android, or Xamarin SDKs to language-project a façade to C++, then C++ would also have an SDK to Project Rome for each of the other OSes.  Btw, I think that Project Rome should have an SDK for MacOS and Tizen eventually; conceivably that is implicit in the Xamarin{.iOS, .Android, .Mac, .Tizen} SDK.  There isn't really Xamarin per se; there is Xamarin.iOS, Xamarin.Mac, Xamarin.Android, and Xamarin.Tizen.  And hand-off to the TV & auto(motive-dashboard) variants of those OSes as well.
Xamarin.Forms (as well as every other body of software since software was invented) has some form of software architecture (even if that software architecture is chaotic big ball of mud).  So, yes, one can compare Xamarin.Forms' MVVM-centric software architecture with VIPER software architecture.  No “conflation” needed, because it is an architecture-to-architecture masterplan-to-masterplan apples-to-apples comparison.  Likewise, one can compare an actual extant physical building's architecture with the blueprint of another differently-designed building's architecture to see whether one building serves its purposes better or whether one is maldesigned; no conflation needed.

Go ahead and be as blunt as you want. I'm cool with it.
The whole reason we build WinRT in the first place was to enable developers to use the tools they want. So I totally get wanting to use C++ everywhere. I argued strongly against C++/CX at the time. To be fair, we ended up in a better place now (i.e. C++/WinRT) than we would have if we had integrated WinRT into the VC++ compiler the way it's integrated into the C# and JS runtimes.
It's too bad that Apple and Google don't share Microsoft's goal of fully empowering C++ developers on their platforms. However, there's little I or the C++/WinRT team can do about that.
Thanks for your kinds words about Project Rome. There are lots of things we'd like to do, but as you are no doubt aware realities of available resources and time when it comes to pulling items off the backlog. I'm not aware of much interest in Project Rome for Mac or Tizen, but feel free to file an issue on our GitHub repo

I think that we have explored quite a few avenues of this potential future for an extrapolation of C++/WinRT to a C++/ObjCRT as part of a C++/RT family of C++/WinRT-esque C++ language projections for other OSes' SDKs in other OSes' runtimes, and perhaps eventually a C++/uberRT to permit writing portable app-domain source code for those UI constructs that all other OSes' UI/UX has in common (vaguely analogous to Xamarin.Forms, but perhaps with a drastically different software architecture).  Along some of these avenues, it seems Mono's Embeddinator-4000 might be the furthest along to serve a cppwinrt.exe-like functionality for C++/ObjCRT.  Extending Embeddinator-4000 (or merging the nonWindows portion of WinObjC into Embeddinator-4000) might be the path of least resistance for anyone seeking a C++/ObjCRT.  It will be interesting to see what Mono eventually generates as its language projection for C++ for Objective-C runtimes in Embeddinator-4000; work had been progressing there somewhat during 2017.  In one potential future, perhaps that Mono work (also Microsoft-based) will borrow heavily from C++/WinRT.  Or in another potential future, perhaps Mono will devise a drastically different family of C++ language projections, one of which might be to Windows 10 editions, hence forming a(n unfortunate) competitor of sorts to C++/WinRT.
Thank you everyone (especially Kenny Kerr) for patiently allowing an at-time free-wheeling discussion of a potential future without closing this issue prematurely.  For now, I am going to close this issue, so that if any aspect of this broad topic arises again by anybody, new issue(s) can be opened on finer granularities of C++/WinRT-extrapolated-to-other-OSes topics.


fix: Allow on_demand_throughput optional values and disabling of table TTL

Description
Bumping provider version to include some provider bugfixes:

Allow table TTL to be disabled by allowing ttl[0].attribute_name to be set when ttl[0].enabled is false
Fix validation error when optional attribute in on_demand_throughput is excluded (this bug resulted in both max_read_request_units and max_write_request_units being required to be set when both are optional)

Motivation and Context

https://github.com/hashicorp/terraform-provider-aws/issues/40046
https://github.com/hashicorp/terraform-provider-aws/issues/39784

Breaking Changes
No.
How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[x] I have tested and validated these changes using one or more of the provided examples/* projects

[x] I have executed pre-commit run -a on my pull request

I am not sure that we need to merge this one because nothing new or changed there. Provider versions are always set to a minimum, and it is up to users to upgrade them if they want.


Certain errors are not shown under VSC "Problems" tab

Sometime an issue is highlighted in the code, but it's missing in Problems.
Like in the following example issue "Either all return statements in a function should return an expression, or none of them should.Pylint(R1710:inconsistent-return-statements)" is visible in the code, but missing under Problems.

@VAR-IN Code types that are refactoring are marked as severity hint. If you want to see these types in problem window, you can set the pylint.severity setting.
This is the default:
"pylint.severity": {
    "convention": "Information",
    "error": "Error",
    "fatal": "Error",
    "refactor": "Hint",
    "warning": "Warning",
    "info": "Information"
}

You can change it to this:
"pylint.severity": {
    "convention": "Information",
    "error": "Error",
    "fatal": "Error",
    "refactor": "Information",  // this will cause it to show up in problems window.
    "warning": "Warning",
    "info": "Information"
}


Redirects

Summary of changes

Installed gatsby-plugin-client-side-redirect
Created redirect on Gatsby (client side) using Drupal redirects

Frontend

Redirects should now exist (based on Drupal redirects)

Backend
Multidev: https://redirect-chug.pantheonsite.io

Enabled Redirect module
Allow Publishers, Gatsby Build and Gatsby Preview to administer Redirects

Test Plan
Note: If you are testing locally, you will need to run gatsby build rather than gatsby develop, then navigate to the public folder to find the page with the client-side redirect on it. Alternatively, you can test via Gatsby Cloud.

Visit https://build-4ddb6ee8-b2ab-4693-bd9b-70626397c73e.gtsb.io/testing-0 which should redirect to another page
Go to https://redirect-chug.pantheonsite.io
Add a new basic page or program
Trigger a build at mmtest
Go to http://mmtest.gatsbyjs.io/ and view the page you created (Copy the URL)
Back on Drupal, change the name of the page or program
Trigger a build again at mmtest
Once the build is done, go back to the URL you copied. It should redirect to the updated URL.

Looks like some conflicts have developed as a result of updates to master since this PR was opened. Try merging the latest changes (on your multidev as well if possible)

Merged in the master branch
Recreated the multidev at https://redirects-chug.pantheonsite.io
Once the multidev is merged, the automatic checks against UG Content Hub should start working

It doesn't seem to work for me. On the redirects Drupal site, I changed the URL for an existing page - https://tqtest.gatsbyjs.io/studentexperience/indigenous-undergraduate-research-assistantships to https://tqtest.gatsbyjs.io/studentexperience/iura - but when I go to https://tqtest.gatsbyjs.io/studentexperience/indigenous-undergraduate-research-assistantships I get the Gatsby "Not Found" page. I've tried doing a cache clear and manual rebuild and opening in an incognito window, but it makes no difference. As far as I can tell, the redirect should be in place:


Add "OnBlockConnected" signals bench to console

See https://app.clickup.com/t/40ra67.

@quantumagi is this also only ever shown if the -displaybenchstats is passed?

Yes.


Feature: Add a seeding to db

Is your feature request related to a problem? Please describe.
whenever new developer set the repo they have to create their own data to test for any new feature
Describe the solution you'd like
to tackle this what usually does is a seed file is created as its name suggests on the initial run of the server we will seed some demo data into our database so that developers don't have to create test data.
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.

also please close the existing issues i thought they were pending from last 2 weeks you have merged there changes but haven't closed the issues yet.

@sohambuilds @SourasishBasu @rycerzes  anyone?

also please close the existing issues i thought they were pending from last 2 weeks you have merged there changes but haven't closed the issues yet.

Which issue numbers ?

@dead8309  could you check i have made the pr and do add the tag
all of these issues are merged


Feature overview method cli memory is bugged

memory         total        used           free
               33 GB        6791 MB (20%)  842 MB (2%)

Fixed in https://github.com/nozel-org/freebsd-serverbot/commit/e839a0a4582919ea0a8547618a4097426083b911.


Send bold text as a photo caption?

Is it possible to send bold text as a photo caption? parse_mode is only available for bot.sendMessage so i think it's just not possible.

Your guess is correct, it is not possible to send formatted text in the caption field.


panic: hop_window: entered unreachable code

Describe the bug
logs_out.txt
To Reproduce
No response
Expected behavior
No response
Additional context
No response

@liurenjie1024 Please take a look and feel free to reassign to others. Thanks!


Copyable Entities

Consider the flag ActionOnDeath
This stores an ActionEntity, containing all the actions to be carried out when the actor dies. These are not copyable, so the components within the entity are moved into the current actor's actions on death. This works fine, but because of the move the stored ActionEntity ends up empty. Not a problem on death though, because that only ever happens once (until you ressurrect lol)
Now for a ActionOnHit flag, this breaks down because the stored entity is emptied out on the first hit. For this reason, we need Entity to be copyable. To do this, the component types need to be unique-cloneable. This is a bit unfortunate but shouldn't be too much boilerplate as iirc engine has some functionality for this.
Make Action and Flag unique-cloneable and use that new assumption to do one of the following things:
Option A: Copy ctor and assign for Entity

Good:

FlagParams and ActionParams can be copyable more often, dont have to code defensively for it as something like FlagParamsFlagID::ActionOnDeath will become copyable

Bad:

Lots more domain for unnecessary copying and poor perf

Option B: Implement Entity::copy_components(Entity& other)

Good:

Minimal implementation to get ActionOnHit working
Copying stuff over needs to be done explicitly, should prevent unnecessary copying

Bad:

Still must assume FlagParams and ActionParams can't be copyable. This might be ok, but it's definitely going to end up limiting at some point

Implemented in 1a62a26ea5cc76de720f4f1179d86faf4f14d529


Incorrect conversion when Adding ${ on a multi-line template string within quotes

If you have a multi-line template string, quotes inside of it are converted as if you aren't in a template string already at all. This demonstration is without "Convert Within Template String" on (same behavior with it on as well).
https://github.com/meganrogge/template-string-converter/assets/19843782/f4016ec8-b5d4-4d23-b8e2-361567deb9e6

this setting manages that case template-string-converter.convertWithinTemplateString

I mentioned that I disabled that setting and was still getting this issue.

this setting manages that case template-string-converter.convertWithinTemplateString

As an aside, it's strange that that setting isn't turned on by default: I can't imagine anyone wanting:
$('div[data-testId="foo"]')

to become:
('div[data-testId='${foo}`]')

Everyone would want it to become:
`$(`div[data-testId="${foo}"]`)`

But instead I had to think the extension was defective, come here, and learn about "the setting that makes the extension work" from this ticket :(


Update web_engine Flutter Recipe to not rely on Xcode/iOS Simulator

As part of https://github.com/flutter/flutter/issues/99885, the LUCI recipes for flutter must be updated to only run tests for Safari Desktop instead of iOS Safari. Since https://github.com/flutter/engine/pull/33757 has merged, we can now validate golden testing with Webkit via Desktop Safari instead of iOS, which removes the dependency on the iOS Simulator and Safari, which has been a source of flakiness on newer builds of macOS.
Looking through the recipe, a few things that might need updating:

The recipe actually installs Xcode twice per run. I believe that is just an error in the recipe itself, but after this change I think we should be able to get away with not installing Xcode at all for the web_engine tests, since we only installed Xcode for the iOS simulator previously.
macOS has some special logic to compile the tests in a separate test, so that the same compiled tests can be used for iOS and macOS Safari. This is no longer necessary since we will be running on only one browser
There is an additionalArgs variable in the recipe that is only updated in the macOS branch, but only used in a non-macOS path. As a result I think this variable is actually unnecessary and can just be removed.

Once the recipe is updated, we can make a small change to the .ci.yaml in the engine repo to remove the dependency on old Xcode/macOS. Once that lands, the build bots running older macOS versions can be upgraded.

Validated 3) works by removing the additioinal_args.
As for 1) removing Xcode context fails the build:
ERROR at //build/config/ios/ios_sdk.gni:45:9: Script returned non-zero exit code.
        exec_script("ios_sdk.py", ios_sdk_args, "list lines")
        ^----------
Current dir: /opt/s/w/ir/cache/builder/src/out/host_debug_unopt/
Command: python3 /opt/s/w/ir/cache/builder/src/build/config/ios/ios_sdk.py --sdk iphoneos
Returned 1.
stderr:

xcode-select: note: no developer tools were found at '/Applications/Xcode.app', requesting install. Choose an option in the dialog to download the command line developer tools.

I went ahead and filed https://github.com/flutter/flutter/issues/105805 as a follow-on task. For now, let's change the recipe so that Xcode is installed if a specific version is specified as a dependency in .ci.yaml, which it currently is. Once we clean up our build such that we don't need Xcode at all to perform the web build and run web tests, we will remove the dependency from .ci.yaml and the recipe should just skip the Xcode install.

After removing line 192-209, the xcode context, and updated felt_test.append('run_tests_ios-safari') to felt_test.append('run_tests_safari'), both old xcode and new xcode builds hit timeout issue on paragraph_builder_test:
xcode: 12c33: https://ci.chromium.org/raw/build/logs.chromium.org/flutter/led/keyonghan_google.com/dab788f47578dd54e0c98c0df321df945e14b835c69493bd5885babea4b2783a/+/build.proto?server=chromium-swarm.appspot.com
xcode: 13a233: https://ci.chromium.org/raw/build/logs.chromium.org/flutter/led/keyonghan_google.com/3e2e4d2dffb92f9bca5aa8a98fc36295b867606abd7b4a9ca0b4e7bf62be6ad1/+/build.proto?server=chromium-swarm.appspot.com
@eyebrowsoffire could you help take a look?

Can we try replacing lines 229-233 with:
            felt_test = copy.deepcopy(felt_cmd)
            felt_test.append('test')
            felt_test.append('--require-skia-gold')
            felt_test.append('--browser=safari')
            api.step(
                api.test_utils.test_step_name('Run tests on macOS Safari'), felt_test
            )

Both succeeded! (old xcode v.s. latest one)
Let me finishup the recipes cl.

Recipes landed. Closing assuming fixed.


Builder Form - change between form configuration files

Hey guys,
Here's the deal, I have a Model called "Pages", and I wanna have multiple and distinct forms PER Page, I wanna have the homepage.yaml form config file for the Homepage page, I wanna have the about.yaml form config file for the About page, for example...
The default form file is "fields.yaml", and I wanna show a list of all those .yaml files so the user can select which file (form layout) he wants to use/fill through the backend.
I know you can change the form .yaml file in the config_form.yaml on your controllers folder, but I was wondering if there is a way to change it through a dropdown list on the backend...
Thank you in advance,
Adriano Ramalho

This isn't really a question specific to the builder plugin, more so just about extending October in general. The easiest way of doing this would be to implement custom model fields.yaml files per context in the config_form.yaml, and then implement actions to handle those contexts and just link to those actions.
Another way you could handle it is by having a dropdown in your list toolbar on your index page, and then store the selected value in the session or user preferences and use that in the constructor to dynamically choose which config_form.yaml to load


Doc update

A little doc update would be great to explain how is to be used. Do I need to keep that in a separte directory, install it, have it as part of my adapter...?
I am a bit lost but would like to use it.

I know 😅, maybe I'll have some time tomorrow.


Issue with quota related configuration in the dimension table

Should the Dimension table honor replication at all or not (for quota), because looks like it don't seem to apply it.
For example, say if I am having a pinot cluster with 4 servers, on creating a dimension table with storage configured to be 200 MB. Since this is a dimension table, the table is replicated on all the servers.
Now, if we populate this dimension table with segments having 100k records and the uncompressed size of this segment being ~23 MB (232 byte for each record in the segment).
So as per the calculation, the expectation was the table will be able to hold around ~900k records. However, that is not the case. The table is not processing more than 2 segments, i.e, when trying to push 3rd segment Pinot is throwing an error, looks like the following calculations are happening:
23 MB (Size of each segment) * 2 (Number of segment already present) * 4 (since we have 4 nodes and dimension table is copied on all the nodes):
= 23 * 2 * 4 = 184 MB
Size of the new incoming uncompressed segment = 23 MB,
so the newly estimated size = 184 + 23 = 207, this is greater than 200 MB that is why Pinot is not processing any more segment of 100k records.

On checking the code Code Link, numReplicas is being fetched from the table configuration and the allowedSize is getting calculated.
If a table is replicated on 4 servers then the replication factor should be taken to be 4 while computing the allowedSize and not to be taken from the table configuration as the user might just specify 1 as the replication factor despite having more than 1 server in the setup

The analytics are correct. We should specialize the dimension table by counting all the servers within the tenant, and ignore the replication settings within the table config.
Do you want to contribute a fix for this issue?

Sure @Jackie-Jiang, I will work on fix for this issue


python312Packages.streamlit: 1.39.0 -> 1.40.1, cleanup dependencies

Changelog: https://github.com/streamlit/streamlit/releases/tag/1.40.1

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 357977

x86_64-linux

:x: 1 package failed to build:

python311Packages.skops

:white_check_mark: 3 packages built:

python311Packages.streamlit
python312Packages.skops
streamlit (python312Packages.streamlit)

aarch64-linux

:white_check_mark: 4 packages built:

python311Packages.skops
python311Packages.streamlit
python312Packages.skops
streamlit (python312Packages.streamlit)

x86_64-darwin

:white_check_mark: 4 packages built:

python311Packages.skops
python311Packages.streamlit
python312Packages.skops
streamlit (python312Packages.streamlit)

aarch64-darwin

:white_check_mark: 4 packages built:

python311Packages.skops
python311Packages.streamlit
python312Packages.skops
streamlit (python312Packages.streamlit)


Calculate how much days/nights are chosen, when we have two separate inputs with Litepicker

Hi again, I have new case: we have a two separate input for arrival and departure dates initialized with Litepicker. On date select we want to show on some block under the inputs how much days/nights are chosen. The problem comes when I want to get the chosen date on change event of the corresponding input (it is not triggered, I saw that it already you closed another issue about it). So how could I get the selected dates outside initialisation of Litepicker without using change event, so I can calculate the difference between the two separate dates?
Thank you!

You can count how many days in the onSelect event.
Outside Litepicker you can use the getStartDate and getEndDate methods and calculate how many days.

Ok, but how to catch the change when I use onSelect?
if(arrivalInput) { 	var arrivalPicker = new Litepicker({  		element: arrivalInput, 		numberOfMonths: 1, 		numberOfColumns: 1, 		inlineMode: false, 		singleMode: true, 		mobileFriendly: true,         showTooltip: true, 		onSelect: function(val) {             parent.classList.add('form__group--filled'); 			arrivalDay = moment(val).format('DD/MM/YYYY');   			  			return arrivalDay;   		} 	}); }
When I use it like this I cant get the new value that is chosen, because OnSelect is getting the current date. Here I have only the arrival date, I have another initialisation for departure. Click event is not catching the change eather.. So what are my options?
Thank you!

from docs:

Example: onSelect: function(date1, date2) { console.log(date1, date2); }

So if you need to get the end date, you must use two parameters in the event.

I have one input element for arrival and second input for departure. When I use onSelect, the second element is undefined, because I am not using it like one input for range picker. They are to separate initialisations.

I think that instead of two initializations you need to use only one with elementEnd option.
In this case you will receive the start and end dates in the onSelect event.

Well, I have a design that needs to be completed. In this case that you are describing how to manage to show the calendar on the second input field?

Have you checked elementEnd option ?

I am not sure how I can use it, can you give me example please? Thank you!

https://jsfiddle.net/waki/9kztrsqp/

Hello, there were some changes in the requirements for the calendar. If the arrival date is chosen first automaticly to add 7 days for departure, and if the user chose first departure date - nothing to happend. I managed to use both of arrival and departure values with separate inputs and not using elementEnd. So here is the code:
var currentDate = moment().format('YYYY/MM/DD');
var arrivalInput = document.getElementById('arrival');
var departureInput = document.getElementById('departure');
var departureDayFormat = '';
var arrivalDateFull = '';
var departureDateFull = '';
var departureDay = 0;
var arrivalDay = 0;
var arriving = '';
var departure = '';
var countNights = 0;
if(arrivalInput) {
var arrivalPicker = new Litepicker({
element: arrivalInput,
format: 'DD/MM/YYYY',
minDate: currentDate,
numberOfMonths: 1,
numberOfColumns: 1,
inlineMode: false,
singleMode: true,
mobileFriendly: true,
showTooltip: true,
onSelect: function(val) {
// Get arrival date in DD-MM-YYYY format
arrivalDay = moment(val).format('DD/MM/YYYY');
		if(departurePicker.options.startDate === null) {
			// Create date for departure, adding 7 days from arrival
			departureDayFormat = moment(arrivalDay, "DD/MM/YYYY").add(7, 'days');
			// Set the appropriate date format for departure date
			departureDay = moment(departureDayFormat).format('DD/MM/YYYY');

			// Set the value of the departure input
			departurePicker.options.element.value = departureDay;

			// Add style for form__label
			departureParent.classList.add('form__group--filled');
			// Count how many nights are chosen
			arriving = moment(arrivalDay, 'DD/MM/YYYY');
			departure = moment(departureDay, 'DD/MM/YYYY');
			countNights = departure.diff(arriving, 'days')

			if(departure > 0) {
				document.querySelector('.number-nights').innerText = countNights;
			}
			else if(departure <= 0) {
				document.querySelector('.number-nights').innerText = "0";
			}
		}
		else if (departurePicker.options.startDate !== null) {
			// set full dates to be compared
			arrivalDateFull = val;
			departureDateFull = departurePicker.options.startDate.dateInstance;

			// Set the appropriate date format for departure date
			departureDay = moment(departureDateFull).format('DD/MM/YYYY');

			arriving = moment(arrivalDay, 'DD/MM/YYYY');
			departure = moment(departureDay, 'DD/MM/YYYY');
			countNights = departure.diff(arriving, 'days');

			if((departureDateFull <= arrivalDateFull) && (countNights !== NaN)) {
				document.querySelector('.number-nights').innerText = "0";
			}

			else if ((departureDateFull > arrivalDateFull) && (countNights !== NaN)) {
				document.querySelector('.number-nights').innerText = countNights;
			}
			else {
				document.querySelector('.number-nights').innerText = "0";
			}
		}
	}
});

}
if(departureInput) {
var departurePicker = new Litepicker({
	element: departureInput,
	format: 'DD/MM/YYYY',
	minDate: currentDate,
	numberOfMonths: 1,
	numberOfColumns: 1,
	inlineMode: false,
	singleMode: true,
	mobileFriendly: true,
	showTooltip: true,
	onSelect: function(val) {
		if(arrivalPicker.options.startDate !== null) {
			arrivalDay = moment(arrivalPicker.options.startDate.dateInstance).format('DD/MM/YYYY');
			departureDay = moment(val).format('DD/MM/YYYY');

			// set full dates to be compared
			arrivalDateFull = arrivalPicker.options.startDate.dateInstance;
			departureDateFull = val;

			arriving = moment(arrivalDay, 'DD/MM/YYYY');
			departure = moment(departureDay, 'DD/MM/YYYY');
			countNights = departure.diff(arriving, 'days');

			if((departureDateFull <= arrivalDateFull) && (countNights !== NaN)) {
				document.querySelector('.number-nights').innerText = "0";
			}

			else if ((departureDateFull > arrivalDateFull) && (countNights !== NaN)) {
				document.querySelector('.number-nights').innerText = countNights;
			}
			else {
				document.querySelector('.number-nights').innerText = "0";
			}
		}
	}
});

}


[master] Issue 467

I believe this falls under "contributions which do no require a full Contributor's License Agreement", as described here: http://www.quartz-scheduler.org/community/contribute.html#contributions-which-do-not-require-full-contributors-license-agreement-cla
@jgallimore If you could confirm that you agree with a simple yes below that would be great!

Yes, I agree. Thank you!


Pick tolerations applied to cephtoolbox on ocsinitialization & structure the cephtoolbox tolerations on storagecluster CR

Resolves-https://bugzilla.redhat.com/show_bug.cgi?id=2131220
In 4.11 in this #1602, We moved the toolbox enable/disable & reconcile logic to the storagecluster side. But the implementation to still pick up tolerations added to the ocsinitialization CR was not there. So adding it now.
The tolerations on the same thing on the storagecluster side are also being structured properly to maintain uniformity.
And also adding missing implementation for the reconcile strategy.

/cherry-pick release-4.12

/cherry-pick release-4.11

@umangachapagain PTAL, We need to merge this today as this is targeted for 4.11.3


Axios API Requests

In this PR I:

[x] Added redux-thunk and axios.
[x] Added an action creator that updates the state with the books fetched from the API.
[x] Refactored the add and remove book action creators to make the respective API requests as well as update the state.

IMPORTANT: THERE IS A GHOST ERROR IN THE LINTERS THAT I CANNOT CHANGE

    1:30error  Missing file extension for "../../services/BookstoreService"  import/extensions

@code-reviewer If you can, please look into it

@Kingstalux Sorry to insist, but there are no linter errors locally. It is entirely out of my control.


test: add the e2e test "use existing credentials in k8s cluster"

What type of PR is this?
/kind test
What this PR does / why we need it:
Ref: Option#1: use existing credentials in k8s cluster
Which issue(s) this PR fixes:

Fixes #80
Special notes for your reviewer:
Release note:

/test pull-blobfuse-csi-driver-e2e


bug: deployed libraries should be included in vm.stopAndReturnStateDiff() results

Component
Forge
Describe the feature you would like
Currently, if you deploy a contract that requires an externally linked library while recording with vm.startStateDiffRecording(), the results returned will not include an AccountAccess struct for deploying the library. Can we include library deployments in the state diff results?
Additional context
No response

external libraries are deployed before tests, therefore not possible to include in returned state diffs. Propose looking into post v1


Notebook API tests

1 failing
  1) Notebook API tests
       edit API batch edits undo/redo:
     Error: asPromise TIMEOUT reached
      at Timeout._onTimeout (extensions/vscode-api-tests/src/utils.ts:132:11)
      at listOnTimeout (node:internal/timers:557:17)
      at processTimers (node:internal/timers:500:7)

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=178904&view=logs&j=9833cdaa-2e92-5f8d-56a8-239fd18fd628&t=2f009c1d-81d8-5a7e-ba44-a6542d1f1704&l=641

Can be related to https://github.com/microsoft/vscode/issues/155587

It's due to the same asPromise wrapper for NotebookDocumentChange event, let's merge it into https://github.com/microsoft/vscode/issues/155587


Also spelling mistake

But I am less sure if it is just spelling fix or something else required as well.

hey @arafalov , thanks for the correction 👍

Glad it was helpful. Just a note that I accidentally created two pull request for this (one against each file). So, the UI one is still open.

true - I just closed #17

I see this fix, however I think the right place to fix this in application.conf!  Will submit another PR for that ;-)   Hi @arafalov nice to see your PR!


OpenALPR Windows 10 Compilation

What should I do here? I'm stucked with this. Please help me.

OpenCV is a big file to clone, wait for an hour and it will complete.


prevent exception when there is no legacy build

Thanks @bitbirddev !

@lhapaipai you're welcome! thanks for this great bundle! ;)


List switch

List Switch PR with synced master branch and added schema arg list-switch to rest call.
See PR #594

+1 Good to go.
@henn need an extra +1

+1, merging.


Requires plugins doesn't seem to work

https://github.com/WordPress/plugin-check-action/blob/862fefb6dd127a406f57e6ee5f55b7c6564b626d/action.yml#L95
Hi, it doesn't seem that the requires plugin field is actually getting any info, resulting in a failed test. My plugin adds a woocommerce shipping method which requires the use of a class by WC which can't be found by the test. Is there a way to fix this? It's the first time I'm testing with GitHub actions and would love to have this set up 😁

Please share your GitHub repository and how you define your plugin dependencies.

@swissspidy I've given you access to the private repo.

Awesome, thanks.
So the WooCommerce dependency is definitely seen as it is correctly installed:
Installing WooCommerce (9.3.2)
Downloading installation package from https://downloads.wordpress.org/plugin/woocommerce.9.3.2.zip...
Unpacking the package...
Installing the plugin...
Plugin installed successfully.
Activating 'woocommerce'...
Plugin 'woocommerce' activated.
Success: Installed 1 of 1 plugins.

P.S. The output is a bit cluttered because your plugin is registering scripts too early. Your registerScripts() method is fired on plugins_loaded but the earliest you can do it is init. To fix this, you could do:
-$this->registerScripts();
-$this->registerStyles();
+add_action('init', [$this, 'registerScripts']);
+add_action('init', [$this, 'registerStyles']);

Further, you are calling $this->autoRequireDir('includes'); on plugins_loaded too, which means your ShippingMethod class is loaded at that point.
According to the WooCommerce documentation, that is too early, as custom shipping classes should only be loaded at the woocommerce_shipping_init hook.
So the issue is not with Plugin Check but with how you are trying to access this WooCommerce class too early. Their documentation looks helpful so I'd start there with debugging :-)
Good luck!

Thank you very much! Especially for the long and helpful response. Made some changes, and now it does seem to be working. Time to fix some stuff it outputted ;-)
I was wondering however why requires_plugins isn't a valid field when I try it in the terminal, while the same command seems to work in the script:
boelens-graszoden\app\public>wp plugin get boelens-graszoden --field=requires_plugins
Error: Invalid field: requires_plugins.

You are probably running an outdated version of WP-CLI or wp-cli/extension-command.
The latest version is WP-CLI v2.11.0


Select: fix clear value & remote label

Please makes sure these boxes are checked before submitting your PR, thank you!

[ ] Make sure you follow Element's Contributing Guide.
[ ] Rebase before creating a PR to keep commit history clear.
[ ] Add some descriptions and refer relative issues for you PR.

#784 #786


Comicvine issue

Hello,
Thanks for the project.
I am having problems making komf work with Comicvine (I know it is on beta), I have configured komf with kavita, and I can see in komf container logs, that my calls from the user script in Kavita are coming correctly.
But the query is launching to Comicvine the komf container is getting a 403 error, but if I copy the same URL and paste it into the browser I get the correct answer from Comicvine.

Hello,
Thanks for the project.
I am having problems making komf work with Comicvine (I know it is on beta), I have configured komf with kavita, and I can see in komf container logs, that my calls from the user script in Kavita are coming correctly.
But the query is launching to Comicvine the komf container is getting a 403 error, but if I copy the same URL and paste it into the browser I get the correct answer from Comicvine.

Update the version of komf you are using to 0.31.1, this issue was fixed in it.

Thanks, I created my container hours before was updated :smile: , now it works.
The problem is that when I fetch the metadata, only fills the publishing year, but no other fields are filled. I tried also for komga, and I cannot see anything updated, even that I can see in the komf container logs, that info is received from comicvine.

from your logs it seems like it's updating issue fields like summary authors and others so it should be reflected in komga
Not sure why it's not showing anything for you. Is this the case for every series for you?

They are not reflected, the only change I saw it comes the publisher in some of them and added the link but nothing about writers, authors, etc.

can't reproduce. Feel free to reopen if issue is still persists


Default email template for Password Reset via OTP does not reflect OTP specifically

Currently both the default subjects and body text for Password Reset via Recovery Email and Password Reset via OTP contains the same subject and body text. Please change them to reflect difference between each other to make the first time user to use them with ease as well as to complete the user experience

Thank you for your contribution!
We are closing this issue since it has not been prioritized for a long time. Chances are that it has already been solved in more recent versions. If not, we will be re-evaluating this when it becomes a priority.


 The CSS standardizes the thumbnail heights so that the delete buttons stay aligned.
Looks like this:

Looks good! Thanks for this


ToolbarItems Font For Other States

Hi , setting ToolbarItems Fonts is currently just set for the .normal state of the buttons and when you click it or longPress (hold) on it the font is changed to default for a moment or for the time you are holding it

Hi @Mahan3340, thanks for the post. Do you have any suggestions to improve this? .normal is currently hardcoded.

Hi , sorry I forgot to mention that I fixed it by adding .selected state like below
barButtonItem.setTitleTextAttributes([.font: toolbarItemsFont!], for:UIControlState.selected)

I assume you did that in your own fork? This seems like a nice option to add in to McPicker but I can’t think of a way to do it using the ‘didSet’ approach. I think it would have to be changed to a ‘func’. What do you think?

yea I unlocked the files and made changes to them , and I've also added this to didSet
 public var toolbarItemsFont: UIFont? {
        didSet {
            applyToolbarButtonItemsSettings { (barButtonItem) in
                barButtonItem.setTitleTextAttributes([.font: toolbarItemsFont!], for: .normal)
                 barButtonItem.setTitleTextAttributes([.font: toolbarItemsFont!], for:UIControlState.selected)
               }
        }
    }

Actually, looking at the code you posted I feel like setting the same font for .normal and .selected should be the default behavior. I'd sure think 99% of the time you'd want these the same. I will get it added the next time I work on this.

yea I guess no one want different fonts for these states so can be added right there 👍


Bump k8s version in KinD

As per title, this patch follows up https://github.com/knative/pkg/pull/2595.

/cc @psschwei @nader-ziada


Add user-friendly labels to components available from App Builder

It looks like this:

I looked into using custom labels to support translation, but it looks like they're not available in .design files. "Label expressions in markup are supported in .cmp and .app resources only." - https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/components_config_for_app_builder_design_files.htm
Critical Changes
Changes
Issues Closed
New Metadata
Deleted Metadata

**lurch:attach W-030366

Tracking W-030366


Add containsDescendants selector

Proposed Changes
Adds selector containsDescendants which allows selecting a view that has a selection of descendant elements. The motivation for this was to provide an easier way to verify the contents of individual list items.
Testing

Added integration tests
Using in internal Maestro flows
Tested in Wikipedia app

Thanks for taking the time to raise this PR @larryng! This API addition makes sense to me and the changes look good. Could you also raise a PR updating this documentation page which can be done via updating this file? Thanks!

Force-pushed to resolve merge conflict. Looking into update the docs.

Thanks for the contribution @larryng 🙌


Start video from a position

I think this feature is  standard and very useful for every video player library.
Translation:
添加从指定位置开始播放视频功能，觉得这个功能是每个视频播放库的标配。

I agree
Translation:
靠谱

4.0 done


get_schema function doesn't accept any authentication parameters

The get_schema function (https://goo.gl/tcPi8L) doesn't accept as input authentication parameters: username and password.
On the other hand the openURL function takes as parameters the username and password (https://goo.gl/B4C7zE)
Inside the get_schema we call the openURL function. IMO we should pass username and password as parameters in the get_schema function.
A quick fix would be to modify the get_schema static function so that it accepts as input the authentication parameters:
def get_schema(url, typename, version='1.0.0', timeout=30, username=None, password=None):
...

Seems like this issue may be closed as fixed.

Seems to be fixed by PR #385.


warn if nothing to index

conda-index will happily index no packages when you pass it the wrong directory. it should not do it.
It will also populate the current directory with channeldata.json if you run it with no arguments.

conda-index should just print a help page when given no arguments


Scalable barrier

The barrier was implemented using a K-ary tree approach with the algorithm
as presented here: http://www.cs.fsu.edu/~asriniva/papers/HiPC15.pdf
The arity is configurable through hpx.lcos.collectives.arity and the cut off when
to switch to the tree based algorithm is hpx.lcos.collectives.cut_off.

The config settings need to be added to the docs, still.

Can anyone review this please?

It was not clear to me that the changed boundaries would fix the issue. I think there should be some code checking pre-conditions if the barrier breaks with boundaries set too low.

What do you mean? Which boundaries? The code is fine, the arity and cut off were chosen experimentally to get the best performance. Every value here should work

Sure. I trust the values used as a default now are fine. What I meant was that those values could be changed by the user and as we have seen, providing bad values not only could slow down the execution (I wouldn't care about this case, the user is not supposed to play with those values), but could break the barrier altogether (as the failing test has shown). So what I'd suggest is to add tests verifying that the selected values don't break the barrier functionally.

On Mittwoch, 5. Oktober 2016 11:25:33 CEST Hartmut Kaiser wrote:

Sure. I trust the values used as a default now are fine. What I meant was
that those values could be changed by the user and as we have seen,
providing bad values not only could slow down the execution (I wouldn't
care about this case, the user is not supposed to play with those values),
but could break the barrier altogether (as the failing test has shown). So
what I'd suggest is to add tests verifying that the selected values don't
break the barrier functionally.

The failing test was due to a bug in the algorithm which has been fixed.
The values have been determined only after the algorithm was fixed and the unit
test ran successfully. Did you encounter problems when testing this branch?

The failing test was due to a bug in the algorithm which has been fixed. The values have been determined only after the algorithm was fixed and the unit test ran successfully. Did you encounter problems when testing this branch?

Ok. This was a misunderstanding on my end, then.
LGTM, please go ahead and merge it (after resolving the conflicts, that is).

The remaining problem has been fixed.


Sequence of structs doesn't work with 0.2

I'm afraid it's me again. The repro is extremely simple this time, though:
             extern crate serde;
#[macro_use] extern crate serde_derive;
#[macro_use] extern crate serde_json;
             extern crate serde_qs;  // either 0.2 or HEAD as of this writing

#[derive(Deserialize, Debug)]
struct TestStruct {
    v: String,
}

#[derive(Deserialize, Debug)]
struct NestedStruct {
    ts: Vec<TestStruct>,
}

fn main() {
    println!("serde_json: {:?}", serde_json::from_str::<NestedStruct>(&json!({
        "ts": [{"v": "foo"}, {"v": "bar"}],
    }).to_string()));
    println!("serde_qs: {:?}", serde_qs::from_str::<NestedStruct>(
        "ts[0][v]=foo&ts[1][v]=bar"
    ));
}

This gives:
serde_json: Ok(NestedStruct { ts: [TestStruct { v: "foo" }, TestStruct { v: "bar" }] })
serde_qs: Err(Error(Custom("invalid type: map, expected a sequence"), State { next_error: None, backtrace: None }))

Seems directly related to the recent changes to handling indexed sequences. The last revision without this bug is 071affd963ed88bfdcede6aa7b20626d3cf0f368; it occurs on 6f22cff63ad58c722293f8d74c978a0bf616be67 and beyond (including 0.2 on crates.io).

Yup, good spot. Missed creating the correct type of map when dropping down a level.
Thanks again! These are super useful.
Actually, I'm going to open an issue to get some code coverage so I can make sure I'm getting these corner cases.


Avoid lock in attest InternalEscrowDataRecvd

We may run handleEncryptedKeyFromDeviceCreate before entering main loop of attest. So we should check it and avoid possible lock in state channels.
Signed-off-by: Petr Fedchenkov<EMAIL_ADDRESS>

@giggsoff This can happen only when subscription to those topics (such as types.EncryptedVaultKeyFromDevice) are activated before we run attestModuleStart, right?
If that is the case, can we run attestModuleStart() before we activate these topics? i.e move call to attestModuleStart() ahead of call to initPostOnboardSubs().

@giggsoff This can happen only when subscription to those topics (such as types.EncryptedVaultKeyFromDevice) are activated before we run attestModuleStart, right?

Correct. I did not see the problem with the current logic of EVE-OS. But seems it is because of agent start order. During work on another PR #2848 about starting all services in parallel I get this problem relatively often.

If that is the case, can we run attestModuleStart() before we activate these topics? i.e move call to attestModuleStart() ahead of call to initPostOnboardSubs().

Well, it is possible, but It seems we have lot of additional logic between initPostOnboardSubs and attestModuleStart. We wait for DeviceNetworkStatus, for configuration come in configTimerTask, anything else before sending ATTEST_REQ_NONCE to the controller. So I think it will add complexity and possible errors.

@giggsoff This can happen only when subscription to those topics (such as types.EncryptedVaultKeyFromDevice) are activated before we run attestModuleStart, right?

Correct. I did not see the problem with the current logic of EVE-OS. But seems it is because of agent start order. During work on another PR #2848 about starting all services in parallel I get this problem relatively often.

If that is the case, can we run attestModuleStart() before we activate these topics? i.e move call to attestModuleStart() ahead of call to initPostOnboardSubs().

Well, it is possible, but It seems we have lot of additional logic between initPostOnboardSubs and attestModuleStart. We wait for DeviceNetworkStatus, for configuration come in configTimerTask, anything else before sending ATTEST_REQ_NONCE to the controller. So I think it will add complexity and possible errors.

Ok.  I was also checking if there would be any consequence of losing this message.  With the proposed fix, since we are populating EscrowData in the attestCtx and just avoiding queuing up the event, we should be able to proceed later on with SendAttestEscrow() successfully from handleAttestSuccessfulAtAttestWait(), so I don't see any problem.


automatically add host fingerprint to known hosts

Fixes #17. This was basically vendored from https://github.com/dmcgowan/docker/compare/tls_libtrust_auth#diff-085728486480676f7b89e9fcee68da74R19.

LGTM


Lookup field not working when adding a new line

When I try and add a new line and then use the lookup field functionality, nothing returns and the lookup field just shows a spinning circle indefinitely. Please see the attached video for further explanation and demonstration. Thanks!
https://github.com/ondutysoftwaresolutions/oddatatable/assets/129521719/9475eca7-e695-4998-acda-ae0891e2e20e

Thank you for rising this, I will have a look and try to figure it out why is happening

Hi @bkkelley can you please share the conditions you are using for the lookup?
I cannot replicate this behaviour.
Sorry for the really late response. I just have time to review the issues now.


[Bug]: Fix compatibility with llama-cpp-python and add documentation

What happened?
llama-cpp-python has a OpenAI compatible server
I am serving a model as:
GGML_SYCL_DEVICE=0 python3 -m llama_cpp.server --model mistral-7b-instruct-v0.2.Q8_0.gguf --chat_format mistral-instruct --host <IP_ADDRESS> --port 7836 --n_ctx 16192 --n_gpu_layers 35

Output from llama-cpp-python:
INFO:     Started server process [12022]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://<IP_ADDRESS>:7836 (Press CTRL+C to quit)
INFO:     <IP_ADDRESS>:51186 - "GET /v1/models HTTP/1.1" 200 OK # Librechat is requesting
INFO:     <IP_ADDRESS>:51198 - "POST /v1 HTTP/1.1" 404 Not Found # Librechat is requesting

I have checked http://<IP_ADDRESS>:7836/docs works # the llama-cpp-python openapi spec endpoint with this ip on my system
This is my librechat output when I try to chat with my model
Something went wrong. Here's the specific error message we encountered: Failed to send message. HTTP 404 - {"detail":"Not Found"}

This is my librechat.yaml configuration
# Configuration version (required)
version: 1.0.1

# Cache settings: Set to true to enable caching
cache: true

# Definition of custom endpoints
endpoints:
  custom:

    - name: "llama"
      apiKey: "sk-1234"
      baseURL: "http://<IP_ADDRESS>:7836/v1" # I have tried with just "http://<IP_ADDRESS>:7836" also, librechat again hits invalid endpoint
      iconURL: "<some url>"
      models:
        default: ["mistral-7b-v0.1", "mistral-7b-instruct-v0.2"] # I was loading multiple models first, but I was trying to diagnose the error with 1 model only
        fetch: true
      titleConvo: true
      titleModel: "mistral-7b-v0.1"
      titleMethod: "completion"
      summarize: true
      summaryModel: "mistral-7b-v0.1"
      forcePrompt: true
      modelDisplayLabel : "llama"

Possibilities:

llama-cpp-python is not serving a OpenAI compatible server
I am missing some configuration in Librechat, since chat format is --chat_format mistral-instruct
I am missing some configuration for llama-cpp-python with chat format is --chat_format mistral-instruct

Steps to Reproduce
Stated above
What browsers are you seeing the problem on?
No response
Relevant log output
No response
Screenshots
No response
Code of Conduct

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

https://github.com/abetlen/llama-cpp-python/issues/1174

To be honest, I've never setup llama-cpp-python for use in LibreChat, which is why there are compatibility/documentation issues.
My next big priority will be open source LLMs, and I will look into this.
Also, maybe the compatibility is better addressed to openai-node, as the project relies on the official OpenAI node SDK, and llama-cpp-python compatibility with that library would mean compatibility with many other projects using openai-node.


Deployments field tests before the [big] release

Actions

[X] simcore traefik --> increase replicas
[x] make revision on manager EC2 machines

Tests

[x] crucial manager --> put down and test
[x] simcore node --> put down and test

OPS tests

[x] make sure that postgres backup apply works
[x] make sure aws snapshot apply works

To observe

[X] What happens if Rabbit is 10 minutes down
[X] What happens if Postgres is 10 minutes down
[X] What happens if Redis is 10 minutes down

Insights

director-v2 --> not restartable
director-v2 --> one instance
storage --> one instance

@mrnicegyu11 @sanderegg @matusdrobuliak66

The tests are scheduled for Mon (Jan. 29) from 8:00 AM till 12:00 PM

Idea:

Keep a spare fully prepared node in the lcuster(in drain mode), so that when one node breaks, we can swiftly introduce a healthy node

Observations:

When Redis is down, we return 404 (webserver is down)

Test Simcore Node is down
Preparation

Prepare AWS Instance (with Simcore AWS Instance settings / parameters + Ansible)
Stop working Simcore Instance in AWS GUI
Add new / fresh Simcore Instance to the swarm and configure docker node labels
Observe system

Things to consider to increase platform robustness and recoverability

Shall simcore node have only simcore label and run services that can easily move to another node
AWS LB healthcheck mechanism will consider node unhealthy in >1.5 min. Isn't it too long?

Reconsider AWS LB Target Group healthcheck settings

Things to consider to increase platform robustness and recoverability

Shall simcore node have only simcore label and run services that can easily move to another node
AWS LB healthcheck mechanism will consider node unhealthy in >1.5 min. Isn't it too long?

Reconsider AWS LB Target Group healthcheck settings

AWS Snapshop [postgres] restore:

it works
while restoring, you need to provide all the settings of the NEW RDS instance that you want to restore the snapshot to

apparently, there is no way to restore the snapshop into existing database (https://stackoverflow.com/a/24279273)


Implement data model for permissions on items

User stories
As a Developer I want a data model for permissions on items in order to be able to further build on that.
Acceptance Criteria

[ ] 4 Levels (owns, can borrow (others call it lend), can see, cant do anything)
[ ] owns need to support both users and groups, only one entity can own an item (always 1 never 0)
[ ] all other need to support only groups, but can support users if implementation is easier multiple entities can have those permission (even 0)
[ ] permissions are different on every item

Review: @dasGoogle


foundry: Foundry V12 Compatibility

Establish minimum compatibility with Foundry V12.
If feasible, eliminate any deprecated functionality without compromising Foundry V11 compatibility.

All V12-specific changes have been applied. Tying this release to dnd5e 3.2 compatibility #599


Add wait loop to verify the disk creation

Currently no wait loop is added in the cloud package to verify disk state after the disk creation request is given.
CreateDisk should return positive results only if the disk is available for the user.
Current implementation:
func (d *controllerService) CreateVolume(ctx context.Context, req *csi.CreateVolumeRequest) (*csi.CreateVolumeResponse, error) {
	....
        ....

	opts := &cloud.DiskOptions{
		Shareable:     false,
		CapacityBytes: volSizeBytes,
		VolumeType:    volumeType,
	}

	disk, err := d.cloud.CreateDisk(volName, opts)
	if err != nil {
		return nil, status.Errorf(codes.Internal, "Could not create volume %q: %v", volName, err)
	}
	return newCreateVolumeResponse(disk), nil
}

proposed approach reference: https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/pkg/cloud/cloud.go#L378

/assign

The create volume operation is considered to be successful only when the state value of the volumeDetails is available.
The state represents the attachment state of the volume. The state in-use  represents that the volume is already attached.
We don't need to add a new method to wait for the volume to be available. We can use the existing method WaitForAttachmentState in here: WaitForAttachmentState.

The create volume operation is considered to be successful only when the state value of the volumeDetails is available. The state represents the attachment state of the volume. The state in-use represents that the volume is already attached.
We don't need to add a new method to wait for the volume to be available. We can use the existing method WaitForAttachmentState in here: WaitForAttachmentState.

nice, I almost forgot about this function, lets reuse whatever we have.
Couple of comments:

WaitForAttachmentState name doesn't make sense to me, we can make it more generic like WaitForVolumeState to wait for any state
There is dump statement in the WaitForAttachmentState, need to be removed.


Question: Does this have a simple CDN version that one can use plug n play?

Hi there
Thanks for this awesome lib. Do you happen to have a compiled CDN version that one can just use on the script tag?
Thanks

Hey, great suggestion. I have just added a bundled version with the updated readme. You can just take the bundle.js and use it standalone on any project.
Once included it will create an object on the global scope you can use. Please take a look at the updated readme and let me know if you are having troubles.
I'll see how this can get distributed via CDNs later but for now you should be able to use it just including the file.

Let me know if this worked so maybe we can close this issue 😄

Thank you so much. Let me give it a try.

I can display it but it has an error, something about t.filter

could you show me how you are importing it and calling the library ?


Case flags data migration

Change description
Enter a description.
JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/SPTRIBS-
Before merging a pull request make sure that:

[ ] tests have been updated / new tests has been added (if needed)
[ ] README and other documentation has been updated / added (if needed)

If this ticket will have any visible impact on users and is not behind a feature toggle, make sure that:

[ ] this ticket been reviewed by QA
[ ] the user story been signed off by the PO

Note that bug fixes, dependency updates and technical tasks do not directly impact the user experience and can be merged without QA and PO review.
If this user story cannot be immediately merged find a way to put it behind a feature toggle and get it merged.

as per previous discussion I believe there was going to be a sanity check on a single case before migrating all existing cases

updated query for pulling single record